淘宝mysql数据库高可用的设计实现-tmha-public


淘宝mysql数据库高可用的设计实现-TMHA 穆公(朱金清) mugong.zjq@taobao.com 微博: 淘穆公 阿里DBA团队博客:http://www.taobaodba.com/ 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 背景 • 互联网应用以普通的PC服务器为主 • 免费的开源软件: Linux平台、MySQL • MySQL数据库的主要问题 – 主库单点问题 • 通过业务功能的写入主库通常只能有1个 • 除非应用程序自己完成容灾 背景-可靠性衡量 • 可靠性指标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://en.wikipedia.org/wiki/Mean_time_between_failures http://wenku.baidu.com/view/7943585c3b3567ec102d8a0f.html 故障率较高 MySQL常用容灾方案—复制 Master : 数据发生改变 记录变化 Slave: 获取master的改变 同步这些变化 Binary-log master slave slave slave Write Read Client 数据有延迟 MySQL复制的演示、延迟 Client Master 98. Insert 232. Update 313. Delete… 532. …..Insert Update Delete… BINLOG DB/Tables Insert Update Delete… Logging Slave Insert Update Delete… IO Thread SQL Thread DB/Tables Insert into Table Values (32,―ICDB‖ …); Insert into Table Values (32,―ICDB‖ …); • 单条SQL • 执行(执行时间为T)完直接写入binlog • 延迟大概为T • 一个事务(包括N条) • 先缓存到cache,全部执行完写入 • 延迟为NT 数据一致性 背景—mysql切换 • master挂了,如何? – 选择新的主库 – 通知应用切换 – master恢复之后,如何同步 • 着重问题: – 故障是存在的 – MS数据的一致性保证 – 新主库的选举 / 应用程序感知 Client(Jboss/tomcat) R W DB/WEB 同时切换 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 对应用透明的常用方法 • Master采用虚IP的方式 – 前提:备库与主库在同一网段 – 阿里云的RDS、云聊PHPWind [1] – 腾讯的CDB[2] • DB对外的接口是DNS – 优势:备库与主库可以在不同机房 – 缺点:受限于DNS,若DNS故障,服务不可用 • MHA[3]: 多个从库之间选择一个主库 –[1] http://app.phpwind.com/ –[2] http://wiki.opensns.qq.com/wiki/CDB –[3] http://code.google.com/p/mysql-master-ha 分库2分库1 分布式数据中间层(TDDL) Master RW Master R-Only ASYNC 1. Master和Master-Readonly的mysql部署在不同机房 2. 异步复制,有数据延迟 3. 分库分表 APP TDDL Master RW Master R-Only ASYNC 路由 连接数控制 分层级的连接 超时控制 读写分离(权重可调整) … TMHA(master HA)整体架构 Master Slave App 动态数据源(TDDL) ZooKeeper /Agent1 /Agent2 Agent Agent SwitchManager A) 维护切换,如换机器、内存维修等 (双十一当天FusionIO交易主库切换) B) 异常切换: 1) master异常挂掉,zookeeper的agent1结点消失(如果网络,zk感知) 2) agent2得知watcher事件,记录异常,创建异常结点 3) SwitchManager获取最新的异常结点,再次确认是否异常 4) 异常,推送tddl配置,将新主库read-only置为false,即新主库可写 • 切换类型 – 正常切换 (机器维修、扩容等) – 强制切换 (主库load非常高,双十一) – 自动切换 – 批量切换 (16、32套库批量切换) 切换类型 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 分布式系统的异常检测思路 • 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 1. 初始化阶段: 创建/transfer服务节点 2. 创建lock子节点,zoo_create(― /locks/x-‖, SEQUENCE|EPHEMERAL) 3. zoo_get_child(―/lock‖, NULL) //不设置watcher 4. 若当前client的id(序列的id)是当前最小的节点,则获得锁,退出 5. 否则,zoo_wexists(last child before id, watcher) a) 若id不存在,则返回第3步 b) 等待watcher的触发 主库选举的检测逻辑 /lock /x-0001 /x-0002 /x-0003 watcher 事件 watcher 事件 • 主库切换选举 (zk实现写锁) – 每个mysql的客户端对应一个节点 – 主库对应的节点为第一个节点 – 若主库挂了,节点消失 – 发起选举,只有一个节点获得lock 即成为新主库 切换部署及使用场景 • 优势 – 备库与主库不同机房 – 不受限于DNS • 场景:三个机房 – zk部署在三个机房 – mysql:agent=1:1 主库 主库(Read-only) 从库-容灾库 A机房 B机房 C机房 Agent Agent Agent ZookeeperZookeeper Zookeeper 主库切换的触发条件 • agent异常 – a1:agent异常退出 – a2:agent与mysql的通信异常 – a3:agent与zk之间的网络异常 – a4:机器死机 • mysql数据库 – m1:访问异常 – m2:机器死机(同a4) – m3:机器的网络异常(同a3) – m4:所在的整个机房down掉 主库 主库(Read-only) 从库-容灾库 A机房 B机房 C机房 Agent Agent Agent ZookeeperZookeeper Zookeeper 触发条件的抽象化、程序化 Master Slave App 动态数据源(TDDL) ZooKeeper /Agent1 /Agent2 Agent Agent SwitchManager watcher 事件 1. 所有条件的表现都是/Agent1结点消失  mysql异常,agent1主动删除结点  zk/网络异常,达到zk的超时后消失 2. Agent2得到Agent1消失的事件(zookeeper的Watcher机制) 切换的 二次确认 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 一致性—可能丢失的数据 • 挂掉的master的binlog能否获取到 (记做Δ1) • Slave机器上的relay-log损坏(记做Δ2) • 简称delta(Δ) REF : http://code.google.com/p/mysql-master-ha/ Δ2的回补策略 • Slave的relay-log损坏 – 判断Exec/Read的pos – 若不相等可能有丢失 • 处理方案: – reset slave/change master – relay-log重新获取即可 Δ1的处理策略 • 需要根据决策来决定 – Dead主库起来, Δ1继续同步,不切换 – 切换, Dead主库起来,主库回滚Δ1 Δ1的处理策略-回滚 • 回滚宕机主库日志(必须是row模式) 逆sql: DELETE FROM test.ma WHERE id=10; Δ1回滚的原理(rollback.pl) • 倒置binlog中所有SQL顺序,保证逻辑相反 • 注意: – 适当修改mysqlbinlog工具 – 双字节,第一个字节超过7F,第二个字节为5C – URL: http://www.taobaodba.com/html/1520_binlog-to-recover.html 调用由 agent发起 Δ1回滚的使用场景 • 回滚Dead Master与新的主库一致(同步) • 误删除的数据回滚 (表级别、数据库级别) – 主库做了一个delete、update的数据(row模式) – INSERT INTO test.ma(id) values (10); 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 自动切换(配置白名单即可) Master Slave App 动态数据源(TDDL) ZooKeeper /Agent1 /Agent2 Agent Agent SwitchManager watcher 事件 1. OS、ping、mysql ping、mysql 读写自动判断即可 2. 配置白名单: 在白名单里面的列表都可以自动切换(这一块是在SwitchManager里面控制) 切换的 二次确认 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 数据复制中心(DRC) • 架构图 – 多线程写入目的端mysql等 – 支持事务、dump给商品搜索 URL: http://www.taobaodba.com/html/772_data_replication_center.html 强一致 低延迟 高可用 大纲 • MySQL高可用的难题 • TMHA的整体设计 • TMHA如何实现异常切换 • TMHA如何保证数据一致性 • TMHA如何实现自动切换 • TMHA如何解决主备库延迟 • 总结 总结 • 通过zookeeper实现配置的集中管理 • 数据一致性、read-only设置显得尤为重要 • 故障切换 + APP切换 + 人工/自动切换兼容 zk的监控改进 • 4-letter monitoring (mntr) / ganglia监控 • Taokeeper (中间件团队提供) URL: http://zookeeper.apache.org/doc/r3.3.3/zookeeperJMX.html 4-letter monitoring • 版本3.3.3需要添加patch-744方可(ant编译) • 版本3.4自动支持(另外,3.4引入observer) • mntr监控 Ganglia监控 Taokeeper监控 Q&A 微博:淘穆公 http://www.weibo.com/suinking Email: mugong.zjq@taobao.com REF: http://www.slideshare.net/suinking/v20-9043338 http://www.suinking.net/?p=32
还剩35页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

luoxuan

贡献于2016-11-02

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf