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

主库自动切换“漂移”——基于zookeeper分布式选举和一致性保证朱金清 (穆公)mugong.zjq@微博： suinking大纲背景基于zk的分布式选举切换的数据一致性保证zk的监控效果页面总结背景互联网应用以普通的PC服务器为主免费的开源软件: Linux平台、mysql分布式系统的本质困难Partial failure 部分故障如果要么一个都不坏，要么全坏，那处理简单多了无法及时准确定位出故障的原因背景-可靠性衡量可靠性指标MTBFMean Time between failures1million hours的含义10,000台服务器同时运行100小时就会坏一台服务器主要部件MTBF主板、CPU、硬盘 1million hours (厂家标称值)内存 4million hours(8根内存 ~ 1million hours)整体的MTBF~1million/4=250000h~1万天年故障率约2%-4%Ref URL: 分布式系统的工程化开发方法/view/7943585c3b3567ec102d8a0f.html/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] The Chubby lock service for loosely-coupled distributed systems （google论文）[2] /wiki/bin/view/Main/ThePartTimeParliament/wiki/bin/view/Main/ThePartTimeParliament[3] /zookeeper/zookeeper[4] PaxosLease: /pdf/PaxosLease.pdfPaxosLease/pdf/PaxosLease.pdf: Diskless /pdf/PaxosLease.pdfPaxos/pdf/PaxosLease.pdf for Leases我们的方式：漂移拆分成很多套数据库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, int recv_timeout …);主库切换逻辑watcher事件/lock主库切换选举每个mysql的客户端对应一个节点主库对应的节点为第一个节点若主库挂了，节点消失发起选举，只有一个节点获得lock 即成为新主库/x-0001/x-0002/x-0003watcher事件部署场景可靠的zk集群保障zk机器可靠性可以保障半数以上机器存活即可稳定的第三方场景：有三个机房zk部署在三个机房mysql：cm3,4,6mysql:agent=1:1主库切换的触发条件agent异常a1：agent异常退出a2：agent与mysql的通信异常a3：agent与zk之间的网络异常a4：机器死机mysql数据库m1：访