主库自动切换“漂移”解析.pptxVIP

主库自动切换“漂移”——基于zookeeper分布式选举和一致性保证朱金清(穆公)mugong.zjq@微博：suinking大纲背景基于zk的分布式选举切换的数据一致性保证zk的监控效果页面总结背景互联网应用以普通的PC服务器为主免费的开源软件:Linux平台、mysql分布式系统的本质困难Partialfailure部分故障如果要么一个都不坏，要么全坏，那处理简单多了无法及时准确定位出故障的原因背景-可靠性衡量可靠性指标MTBFMeanTimebetweenfailures1millionhours的含义10,000台服务器同时运行100小时就会坏一台服务器主要部件MTBF主板、CPU、硬盘1millionhours(厂家标称值)内存4millionhours(8根内存~1millionhours)整体的MTBF~1million/4=250000h~1万天年故障率约2%-4%RefURL:分布式系统的工程化开发方法/view/7943585c3b3567ec102d8a0f.html背景—mysql切换mysql的replication部署master挂了，如何？需根据IO/SQL的binlog位置因此，数据库的leader election是有状态的分布式 选举，不像分布式中由其它任何一台就可以替代（如hbase中的HMaster）着重问题：新主库的选举/应用程序感知选举完后各个数据的一致性保证相关工作Master采用虚IP的方式前提：备库与主库在同一网段阿里云的云聊PHPWind[1]腾讯的CDB[2]DB对外的接口是DNS优势：备库与主库可以在不同机房阿里云在考虑的自动切换缺点：受限于DNS，若DNS故障，服务不可用[1]/[2]/wiki/CDB分布式系统常用方法Paxos：一半机器存活即可实践中，常用master+lease来提高效率分布式系统协调服务Chubby(Google:Bigtable,MapReduce)Zookeeper(Yahoo!:hbase,hadoop子项目)[1]TheChubbylockserviceforloosely-coupleddistributedsystems（google论文）[2]/wiki/bin/view/Main/ThePartTimeParliament[3]/zookeeper[4]PaxosLease:PaxosLease:DisklessPaxosforLeases我们的方式：漂移拆分成很多套数据库Master(read-only)-Master-slave数据库中间层部署在程序端，配置推送采用IP的方式优势备库与主库可以在不同机房不受限于DNS全页面操作人工情况下可以将 主库切往任何备库大纲背景基于zk的分布式选举切换的数据一致性保证zk的监控效果页面总结zk介绍Yahoo!参考Chubby开发的分布式协调服务Chubby采用Paxos算法zk采用zab协议，基于TCP来保证消息有序性服务器端Java实现，客户端目前支持Perl，Python，Java，C等编程语言(有第三方PHP)我们的系统(漂移)：C++/PHPzookeeper的配置Stand-alone模式Cluster模式有三种端口配置客户端通信端口服务器通信端口服务器选举端口超时设置(2~20倍限制)zk服务器之间的超时initLimit(连接+同步)syncLimit(同步)客户端程序与zk的超时zookeeper_init(host,wacher,intrecv_timeout…);主库切换逻辑/lock/x-0002/x-0003watcher事件watcher事件主库切换选举每个mysql的客户端对应一个节点主库对应的节点为第一个节点若主库挂了，节点消失发起选举，只有一个节点获得lock 即成为新主库部署场景可靠的zk集群保障zk机器可靠性可以保障半数以上机器存活即可稳定的第三方场景：有三个机房zk部署在三个机房mysql：cm3,4,6mysql:agent=1:1主库切换的触发条件agent异常a1：agent异常退出a2：agent与mysql的通信异常a3：agent与zk之间的网络异常a4：机器死机mysql数据库m1：访问异常m2：机器死机(同a4)m3：机器的网络异常(同a3)m4：所在的整个机房down掉主库切换的触发条件-agenta1：异常退出要求在recv_timeout的时间内可重启否则将会进行切换需要记住client端的session否则进行自动recover无法设置read-only，需第三方a2：与mysql的通信异常与mysql进行读写测试重试机制，重试次数、间隔可控制若mysql正常，通信问题可以忽略(同一台机器)主库切换的触发条件-agent(2