主库自动切换“漂移”主库自动切换“漂移”——基于zookeeper分布式选举和一致性保证

朱金清 (穆公)

mugong.zjq@taobao.comg g jq微博： 淘穆公

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

背景背景

联 应 普 的 务 为• 互联网应用以普通的PC服务器为主

• 免费的开源软件: Linux平台、mysql免费的开源软件: Linux平台、mysql

• 分布式系统的本质困难

– Partial failure 部分故障Partial failure 部分故障

• 如果要么一个都不坏，要么全坏，那处理简单多了

• 无法及时准确定位出故障的原因• 无法及时准确定位出故障的原因

背景 可靠性衡量背景-可靠性衡量

靠性指标• 可靠性指标MTBF– Mean Time between failures

• 1million hours的含义

10 000台服务器同时运行100小时就会坏 台– 10,000台服务器同时运行100小时就会坏一台

• 服务器主要部件MTBF– 主板、CPU、硬盘 1million hours (厂家标称值)内存 4million hours(8根内存 ~ 1million hours)– 内存 4million hours(8根内存 ~ 1million hours)

• 整体的MTBF~1million/4=250000h~1万天

– 年故障率约2%-4%Ref URL: 分布式系统的工程化开发方法http://wenku.baidu.com/view/7943585c3b3567ec102d8a0f.html

背景 mysql切换背景—mysql切换

的• mysql的replication部署

• master挂了，如何？master挂了，如何？

– 需根据IO/SQL的binlog位置

因此 数据库的l d– 因此，数据库的leaderelection是有状态的分布式

选举，不像分布式中由其它任何一台就可以替代（如hbase中的HMaster）代 如 中的

• 着重问题：

新主库的选举 / 应用程序感知– 新主库的选举 / 应用程序感知

– 选举完后各个数据的一致性保证

相关工作相关工作

采 虚 的 式• Master采用虚IP的方式

– 前提：备库与主库在同一网段前提：备库与主库在同 网段

– 阿里云的云聊PHPWind [1]

腾讯的CDB[2]– 腾讯的CDB[2]

• DB对外的接口是DNS– 优势：备库与主库可以在不同机房

– 阿里云在考虑的自动切换阿里云在考虑的自动切换

– 缺点：受限于DNS，若DNS故障，服务不可用

– [1] http://app.phpwind.com/– [2] http://wiki.opensns.qq.com/wiki/CDB

分布式系统常用方法分布式系统常用方法

半机 存• Paxos：一半机器存活即可

• 实践中，常用master + lease来提高效率实践中，常用master + lease来提高效率

• 分布式系统协调服务

– Chubby (Google: Bigtable, MapReduce)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[ ] p q g• [3] http://hadoop.apache.org/zookeeper• [4] PaxosLease: PaxosLease: Diskless Paxos for Leases

我们的方式：漂移我们的方式：漂移

拆 很多套数 库• 拆分成很多套数据库

• Master(read-only)-Master-slaveMaster(read only) Master slave• 数据库中间层部署在程序端，配置推送

• 采用IP的方式

• 优势• 优势

– 备库与主库可以在不同机房

不受限于– 不受限于DNS– 全页面操作

– 人工情况下可以将

主库切往任何备库

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

zk介绍zk介绍

参考 发的 布式 务• Yahoo!参考Chubby开发的分布式协调服务

– Chubby采用Paxos算法C ubby采用 a os算法

– zk采用zab协议，基于TCP来保证消息有序性

• 服务器端Java实现，客户端目前支持Perl，实Python，Java，C等编程语言(有第三方PHP)PHP)

• 我们的系统(漂移)：C++ / PHP

zookeeper的配置zookeeper的配置

• Stand alone模式 & Cluster模式• Stand-alone模式 & Cluster模式

– 有三种端口配置

• 客户端通信端口

• 服务器通信端口

• 服务器选举端口

• 超时设置(2~20倍限制)超时设置( 倍限制)– zk服务器之间的超时

• initLimit (连接+同步)• initLimit (连接+同步)• syncLimit (同步)客户端程序与zk的超时– 客户端程序与zk的超时

• zookeeper_init(host, wacher, int recv_timeout …);

主库切换逻辑主库切换逻辑/lock

watcher事件

库 换/lock

/x-0001

事件

• 主库切换选举

– 每个mysql的客户端对应一个节点/x-0002

每个 ysq 的客户端对应 个节点

– 主库对应的节点为第一个节点

若主库挂了 节点消失 /x-0003

watcher

– 若主库挂了，节点消失

– 发起选举，只有一个节点获得lockwatcher事件即成为新主库

部署场景部署场景

靠的 集 保障• 可靠的zk集群保障

– zk机器可靠性可以保障机器可靠性可以保障

– 半数以上机器存活即可

稳定的第三方– 稳定的第三方

• 场景：有三个机房

– zk部署在三个机房

– mysql：3 4 6mysql：3,4,6– mysql:agent=1:1

主库切换的触发条件主库切换的触发条件

常• agent异常

– a1：agent异常退出a ：age 异常退出

– a2：agent与mysql的通信异常

a3 agent与zk之间的网络异常– a3：agent与zk之间的网络异常

– a4：机器死机

• mysql数据库

– m1：访问异常m1：访问异常

– m2：机器死机(同a4)3 机器的网络异常(同 3)– m3：机器的网络异常(同a3)

– m4：所在的整个机房down掉

主库切换的触发条件 agent主库切换的触发条件-agent

常• a1：异常退出

– 要求在recv timeout的时间内可重启要求在 ec _ eou 的时间内可重启

– 否则将会进行切换

• 需要记住client端的session• 需要记住client端的session• 否则进行自动recover• 无法设置read only 需第三方• 无法设置read-only，需第三方

• a2：与mysql的通信异常

– 与mysql进行读写测试

– 重试机制，重试次数、间隔可控制重试机制，重试次数、间隔可控制

– 若mysql正常，通信问题可以忽略(同一台机器)

主库切换的触发条件 agent(2)主库切换的触发条件-agent(2)

的 络 常• a3：与zk之间的网络异常(设置read-only)– 通过超时来控制，大于recv timeout则切换通过超时来控制，大于 ec _ eou 则切换

– 由于session的绑定无法恢复，需进行切换

4 机器死机(设置 d l )• a4：机器死机(设置read-only)– agent与zk的通信中断

– 在大于recv_timeout之后

进行自动切换进行自动切换

主库切换的触发条件 mysql主库切换的触发条件-mysql

访问异常• m1：访问异常

• 定期进行读写(设置read-only)– 主库：插入时间戳(可重试，重试间隔可设置)

» 若mysql连接被kill掉，重新创建连接

从库 读取时间戳(同上)– 从库：读取时间戳(同上)– 若异常，认为mysql挂断，进行切换

• m2：机器死机(同a4)• m2：机器死机(同a4)• m3：机器的网络异常(同a3)

在的整个机房 掉• m4：所在的整个机房down掉• zookeeper也挂掉，被踢出集群

• 类似于mysql机器与majority隔离

发起自动切换

故障测试 影响写入时间故障测试—影响写入时间

超时 秒• 1. 超时设置4秒钟

• 影响写入的时间为4 5秒钟• 影响写入的时间为4-5秒钟。

故障测试 mysql挂掉故障测试—mysql挂掉

• 按照设置的检测超时来定（即为影响写入的时间）

故障测试 watch事件的迁移故障测试—watch事件的迁移

集 结点各有 事件• zk集群上结点各有watch事件

• Client A注册上来后watch比如在zk的M上

– 如上图的，***00031结点

• 将zk的M进行shutdown将zk的M进行shutdown• 再进行主库切换，发现Client A成为主库

– Watch照样生效，即watch可以在zk间无缝迁移Watch照样生效，即watch可以在zk间无缝迁移

故障测试 agent的自动重启故障测试—agent的自动重启

的 某种 度代表 库的• agent的退出某种程度代表了主库的退出

– 1. 自动重启agent (需要将session保持到本地)自动重启age (需要将sess o 保持到本地)– [REF: hadoop the definitive guide chapter 13]

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

数据可能丢失的地方数据可能丢失的地方

• 挂掉的master的binlog能否获取到

• Slave机器上的relay-log损坏

REF : http://code.google.com/p/mysql-master-ha/

数据可能丢失的地方 Cont数据可能丢失的地方-Cont.

能• binlog能否获取到

– ssh获取直接获取ss 获取直接获取

– 否则，semi-replication• DBA自己开发的ESR• DBA自己开发的ESR

– 采用DRC：

DBA自己开发的类IO线程的模块• DBA自己开发的类IO线程的模块

• Slave机器上的relay-log损坏

• Slave的relay-log损坏

– 判断Exec和Read的pos判断Exec和Read的pos– 若无法相等说明可能有丢失

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

官方支持的监控官方支持的监控

• 4-letter monitoring (mntr)• jmx监控jmx监控

URL: http://zookeeper.apache.org/doc/r3.3.3/zookeeperJMX.html

4 letter monitoring4-letter monitoring

版本 加 编• 版本3.3.3需要添加patch-744方可(ant编译)• 版本3 4自动支持(另外，3 4引入observer)版本3.4自动支持(另外，3.4引入observer)• mntr监控

Ganglia监控Ganglia监控

Nagios监控Nagios监控

• http://127.0.0.1/nagios/

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

漂移切换界面漂移切换界面

大纲大纲

• 背景

• 基于zk的分布式选举基于zk的分布式选举

• 切换的数据一致性保证

• zk的监控

• 效果页面• 效果页面

• 总结

总结总结

库构 布式 境 有 态• 主从库构成分布式环境，但是有状态

– 确保agent可重启，可以任意次重启确保age 可重启，可以任意次重启

– 但是有超时限制

• 主库切换逻辑可以通过zookeeper实现

– 锁的升级实现

• read-only的设置显得尤为重要，

• 故障切换 + APP切换

Q&A微博：http://www.weibo.com/suinkingEmail mugong zjq@taobao comEmail： mugong.zjq@taobao.com关注方向： mysql、hbase、HDFS