More Related Content
Similar to 淘宝主备数据库自动切换 (20)
淘宝主备数据库自动切换
- 2. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 4. 背景-可靠性衡量
• 可靠性指标MTBF
– Mean Time between failures
• 1million hours的含义
– 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
- 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论文)
• [2] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament
• [3] http://hadoop.apache.org/zookeeper
• [4] PaxosLease: PaxosLease: Diskless Paxos for Leases
- 8. 我们的方式:漂移
• 拆分成很多套数据库
• Master(read-only)-Master-slave
• 数据库中间层部署在程序端,配置推送
• 采用IP的方式
• 优势
– 备库与主库可以在不同机房
– 不受限于DNS
– 全页面操作
– 人工情况下可以将
主库切往任何备库
- 9. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 10. zk介绍
• Yahoo!参考Chubby开发的分布式协调服务
– Chubby采用Paxos算法
– zk采用zab协议,基于TCP来保证消息有序性
• 服务器端Java实现,客户端目前支持Perl,Python,Java,
C等编程语言(有第三方PHP)
• 我们的系统(漂移):C++ / PHP
- 11. zookeeper的配置
• Stand-alone模式 & Cluster模式
– 有三种端口配置
• 客户端通信端口
• 服务器通信端口
• 服务器选举端口
• 超时设置(2~20倍限制)
– zk服务器之间的超时
• initLimit (连接+同步)
• syncLimit (同步)
– 客户端程序与zk的超时
• zookeeper_init(host, wacher, int recv_timeout …);
- 12. 主库切换逻辑
watcher
/lock 事件
• 主库切换选举
– 每个mysql的客户端对应一个节点 /x-0001
– 主库对应的节点为第一个节点
/x-0002
– 若主库挂了,节点消失
– 发起选举,只有一个节点获得lock /x-0003
即成为新主库
watcher
事件
- 13. 部署场景
• 可靠的zk集群保障
– zk机器可靠性可以保障
– 半数以上机器存活即可
– 稳定的第三方
• 场景:有三个机房
– zk部署在三个机房
– mysql:3,4,6
– mysql:agent=1:1
- 14. 主库切换的触发条件
• agent异常
– a1:agent异常退出
– a2:agent与mysql的通信异常
– a3:agent与zk之间的网络异常
– a4:机器死机
• mysql数据库
– m1:访问异常
– m2:机器死机(同a4)
– m3:机器的网络异常(同a3)
– m4:所在的整个机房down掉
- 15. 主库切换的触发条件-agent
• a1:异常退出
– 要求在recv_timeout的时间内可重启
– 否则将会进行切换
• 需要记住client端的session
• 否则进行自动recover
• 无法设置read-only,需第三方
• a2:与mysql的通信异常
– 与mysql进行读写测试
– 重试机制,重试次数、间隔可控制
– 若mysql正常,通信问题可以忽略(同一台机器)
- 17. 主库切换的触发条件-mysql
• m1:访问异常
• 定期进行读写(设置read-only)
– 主库:插入时间戳(可重试,重试间隔可设置)
» 若mysql连接被kill掉,重新创建连接
– 从库:读取时间戳(同上)
– 若异常,认为mysql挂断,进行切换
• m2:机器死机(同a4)
• m3:机器的网络异常(同a3)
• m4:所在的整个机房down掉
• zookeeper也挂掉,被踢出集群
• 类似于mysql机器与majority隔离
发起自动切换
- 22. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 24. 数据可能丢失的地方-Cont.
• binlog能否获取到
– ssh获取直接获取
– 否则,semi-replication
• DBA自己开发的ESR
– 采用DRC:
• DBA自己开发的类IO线程的模块
• Slave机器上的relay-log损坏
• Slave的relay-log损坏
– 判断Exec和Read的pos
– 若无法相等说明可能有丢失
- 25. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 30. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 32. 大纲
• 背景
• 基于zk的分布式选举
• 切换的数据一致性保证
• zk的监控
• 效果页面
• 总结
- 33. 总结
• 主从库构成分布式环境,但是有状态
– 确保agent可重启,可以任意次重启
– 但是有超时限制
• 主库切换逻辑可以通过zookeeper实现
– 锁的升级实现
• read-only的设置显得尤为重要,
• 故障切换 + APP切换