Download as PDF, PPTX
![相关工作
采 虚 的 式
• Master采用虚IP的方式
– 前提：备库与主库在同一网段
前提：备库与主库在同 网段
– 阿里云的云聊PHPWind [1]
– 腾讯的CDB[2]
• DB对外的接口是DNS
– 优势：备库与主库可以在不同机房
– 阿里云在考虑的自动切换
– 缺点：受限于DNS，若DNS故障，服务不可用
– [1] http://app.phpwind.com/
– [2] http://wiki.opensns.qq.com/wiki/CDB](https://image.slidesharecdn.com/v2-0-110829020717-phpapp02/75/MySQL-6-2048.jpg)
![分布式系统常用方法
半机 存
• Paxos：一半机器存活即可
• 实践中，常用master + lease来提高效率
• 分布式系统协调服务
– Chubby (Google: Bigtable, MapReduce)
– Zookeeper (Yahoo!: hbase, hadoop子项目)
• [1] The Chubby lock service for loosely-coupled distributed systems （google论文）
• [ ] p
[2] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament
q g
• [3] http://hadoop.apache.org/zookeeper
• [4] PaxosLease: PaxosLease: Diskless Paxos for Leases](https://image.slidesharecdn.com/v2-0-110829020717-phpapp02/75/MySQL-7-2048.jpg)
![故障测试—agent的自动重启
故障测试 agent的自动重启
的 某种 度代表 库的
• agent的退出某种程度代表了主库的退出
– 1. 自动重启agent (需要将sess o 保持到本地)
自动重启age (需要将session保持到本地)
– [REF: hadoop the definitive guide chapter 13]](https://image.slidesharecdn.com/v2-0-110829020717-phpapp02/75/MySQL-21-2048.jpg)
MySQL自动切换设计与实现
- 1. 主库自动切换“漂移” ——基于zookeeper分布式选举和一致性保证 朱金清 (穆公) mugong.zjq@taobao.com g g jq 微博： 淘穆公
- 2. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 3. 背景 • 互联网应用以普通的PC服务器为主 联 应 普 的 务 为 • 免费的开源软件: Linux平台、mysql • 分布式系统的本质困难 – Partial failure 部分故障 • 如果要么一个都不坏，要么全坏，那处理简单多了 • 无法及时准确定位出故障的原因
- 4. 背景-可靠性衡量 背景 可靠性衡量 • 可靠性指标MTBF 靠性指标 – Mean Time between failures • 1million hours的含义 – 10 000台服务器同时运行100小时就会坏 台 10,000台服务器同时运行100小时就会坏一台 • 服务器主要部件MTBF – 主板、CPU、硬盘 1million hours (厂家标称值) – 内存 4million hours(8根内存 ~ 1million hours) • 整体的MTBF~1million/4=250000h~1万天 – 年故障率约2%-4% Ref URL: 分布式系统的工程化开发方法http://wenku.baidu.com/view/7943585c3b3567ec102d8a0f.html
- 5. 背景—mysql切换 背景 mysql切换 的 • mysql的replication部署 • master挂了，如何？ – 需根据IO/SQL的binlog位置 – 因此 数据库的l d 因此，数据库的leader election是有状态的分布式 选举，不像分布式中由其它任何一台就可以替 代 如 代（如hbase中的HMaster） 中的 • 着重问题： – 新主库的选举 / 应用程序感知 – 选举完后各个数据的一致性保证
- 6. 相关工作 采 虚 的 式 • Master采用虚IP的方式 – 前提：备库与主库在同一网段 前提：备库与主库在同 网段 – 阿里云的云聊PHPWind [1] – 腾讯的CDB[2] • DB对外的接口是DNS – 优势：备库与主库可以在不同机房 – 阿里云在考虑的自动切换 – 缺点：受限于DNS，若DNS故障，服务不可用 – [1] http://app.phpwind.com/ – [2] http://wiki.opensns.qq.com/wiki/CDB
- 7. 分布式系统常用方法 半机 存 • Paxos：一半机器存活即可 • 实践中，常用master + lease来提高效率 • 分布式系统协调服务 – Chubby (Google: Bigtable, MapReduce) – Zookeeper (Yahoo!: hbase, hadoop子项目) • [1] The Chubby lock service for loosely-coupled distributed systems （google论文） • [ ] p [2] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament q g • [3] http://hadoop.apache.org/zookeeper • [4] PaxosLease: PaxosLease: Diskless Paxos for Leases
- 8. 我们的方式：漂移 • 拆分成很多套数据库 拆 很多套数 库 • Master(read only) Master slave Master(read-only)-Master-slave • 数据库中间层部署在程序端，配置推送 • 采用IP的方式 • 优势 – 备库与主库可以在不同机房 – 不受限于 不受限于DNS – 全页面操作 – 人工情况下可以将 主库切往任何备库
- 9. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 10. zk介绍 参考 发的 布式 务 • Yahoo!参考Chubby开发的分布式协调服务 – Chubby采用Paxos算法 C ubby采用 a os算法 – zk采用zab协议，基于TCP来保证消息有序性 • 服务器端Java实现，客户端目前支持Perl， 实 Python，Java，C等编程语言(有第三方 PHP) • 我们的系统(漂移)：C++ / PHP
- 11. zookeeper的配置 • Stand alone模式& Cluster模式 Stand-alone模式 – 有三种端口配置 • 客户端通信端口 • 服务器通信端口 • 服务器选举端口 • 超时设置(2~20倍限制) 超时设置( 倍限制) – zk服务器之间的超时 • initLimit (连接+同步) • syncLimit (同步) – 客户端程序与zk的超时 • zookeeper_init(host, wacher, int recv_timeout …);
- 12. 主库切换逻辑 watcher /lock 事件 • 主库切换选举 库 换 /x-0001 – 每个mysql的客户端对应一个节点 每个 ysq 的客户端对应 个节点 – 主库对应的节点为第一个节点 /x-0002 – 若主库挂了 节点消失 若主库挂了，节点消失 /x-0003 – 发起选举，只有一个节点获得lock watcher 即成为新主库 事件
- 13. 部署场景 • 可靠的zk集群保障 靠的 集 保障 机器可靠性可以保障 – zk机器可靠性可以保障 – 半数以上机器存活即可 – 稳定的第三方 • 场景：有三个机房 – zk部署在三个机房 – mysql：3 4 6 mysql：3,4,6 – mysql:agent=1:1
- 14. 主库切换的触发条件 常 • agent异常 a ：age 异常退出 – a1：agent异常退出 – a2：agent与mysql的通信异常 – a3 agent与zk之间的网络异常 a3：agent与zk之间的网络异常 – a4：机器死机 • mysql数据库 – m1：访问异常 – m2：机器死机(同a4) 3 机器的网络异常(同 3) – m3：机器的网络异常(同a3) – m4：所在的整个机房down掉
- 15. 主库切换的触发条件-agent 主库切换的触发条件agent 常 • a1：异常退出 – 要求在recv_timeout的时间内可重启 要求在 ec eou 的时间内可重启 – 否则将会进行切换 • 需要记住client端的session • 否则进行自动recover • 无法设置read only 需第三方 无法设置read-only，需第三方 • a2：与mysql的通信异常 – 与mysql进行读写测试 – 重试机制，重试次数、间隔可控制 – 若mysql正常，通信问题可以忽略(同一台机器)
- 16. 主库切换的触发条件-agent(2) 主库切换的触发条件 agent(2) 的 络 常 • a3：与zk之间的网络异常(设置read-only) – 通过超时来控制，大于recv_timeout则切换 通过超时来控制，大于 ec eou 则切换 – 由于session的绑定无法恢复，需进行切换 4 机器死机(设置 d l ) • a4：机器死机(设置read-only) – agent与zk的通信中断 – 在大于recv_timeout之后 进行自动切换
- 17. 主库切换的触发条件-mysql 主库切换的触发条件mysql 访问异常 • m1：访问异常 • 定期进行读写(设置read-only) – 主库：插入时间戳(可重试，重试间隔可设置) » 若mysql连接被kill掉，重新创建连接 – 从库 读取时间戳(同上) 从库：读取时间戳(同上) – 若异常，认为mysql挂断，进行切换 • m2：机器死机(同a4) • m3：机器的网络异常(同a3) 在的整个机房 掉 • m4：所在的整个机房down掉 • zookeeper也挂掉，被踢出集群 • 类似于mysql机器与majority隔离 发起自动切换
- 18. 故障测试—影响写入时间 故障测试 影响写入时间 • 1. 超时 超时设置4秒钟 秒 • 影响写入的时间为4 5秒钟 影响写入的时间为4-5秒钟。
- 19. 故障测试—mysql挂掉 故障测试 mysql挂掉 • 按照设置的检测超时来定（即为影响写入 的时间）
- 20. 故障测试—watch事件的迁移 故障测试 watch事件的迁移 集 结点各有 事件 • zk集群上结点各有watch事件 • Client A注册上来后watch比如在zk的M上 – 如上图的，***00031结点 • 将zk的M进行shutdown • 再进行主库切换，发现Client A成为主库 – Watch照样生效，即watch可以在zk间无缝迁移
- 21. 故障测试—agent的自动重启 故障测试 agent的自动重启 的 某种 度代表 库的 • agent的退出某种程度代表了主库的退出 – 1. 自动重启agent (需要将sess o 保持到本地) 自动重启age (需要将session保持到本地) – [REF: hadoop the definitive guide chapter 13]
- 22. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 23. 数据可能丢失的地方 • 挂掉的master的binlog能否获取到 • Slave机器上的relay-log损坏 REF : http://code.google.com/p/mysql-master-ha/
- 24. 数据可能丢失的地方-Cont. 数据可能丢失的地方 Cont 能 • binlog能否获取到 ss 获取直接获取 – ssh获取直接获取 – 否则，semi-replication • DBA自己开发的ESR – 采用DRC： • DBA自己开发的类IO线程的模块 • Slave机器上的relay-log损坏 • Slave的relay-log损坏 – 判断Exec和Read的pos – 若无法相等说明可能有丢失
- 25. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 26. 官方支持的监控 • 4-letter monitoring(mntr) • jmx监控 URL: http://zookeeper.apache.org/doc/r3.3.3/zookeeperJMX.html
- 27. 4-letter 4 letter monitoring • 版本 版本3.3.3需要添加patch-744方可(ant编译) 加 编 • 版本3 4自动支持(另外，3 4引入observer) 版本3.4自动支持(另外，3.4引入observer) • mntr监控
- 28.
- 29.
- 30. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 31.
- 32. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
- 33. 总结 • 主从库构成分布式环境，但是有状态 库构 布式 境 有 态 – 确保agent可重启，可以任意次重启 确保age 可重启，可以任意次重启 – 但是有超时限制 • 主库切换逻辑可以通过zookeeper实现 – 锁的升级实现 • read-only的设置显得尤为重要， • 故障切换 + APP切换
- 34. Q&A 微博： http://www.weibo.com/suinking Email： mugong.zjq@taobao.com Email mugongzjq@taobao com 关注方向： mysql、hbase、HDFS