• Save
淘宝主备数据库自动切换
Upcoming SlideShare
Loading in...5
×
 

淘宝主备数据库自动切换

on

  • 5,204 views

淘宝,主备,数据库,自动,切换,阿里巴巴,taobao,alibaba,mysql,zookeeper,分布式,一致性,linuc,pc,服务器,MTBF

淘宝,主备,数据库,自动,切换,阿里巴巴,taobao,alibaba,mysql,zookeeper,分布式,一致性,linuc,pc,服务器,MTBF

Statistics

Views

Total Views
5,204
Views on SlideShare
3,302
Embed Views
1,902

Actions

Likes
12
Downloads
0
Comments
1

1 Embed 1,902

http://www.mysqlops.com 1902

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • database
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

淘宝主备数据库自动切换 淘宝主备数据库自动切换 Presentation Transcript

  • 主库自动切换“漂移”——基于zookeeper分布式选举和一致性保证 朱金清 (穆公)
  • 大纲• 背景• 基于zk的分布式选举• 切换的数据一致性保证• zk的监控• 效果页面• 总结
  • 背景• 互联网应用以普通的PC服务器为主• 免费的开源软件: Linux平台、mysql• 分布式系统的本质困难 – Partial failure 部分故障 • 如果要么一个都不坏,要么全坏,那处理简单多了 • 无法及时准确定位出故障的原因
  • 背景-可靠性衡量• 可靠性指标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
  • 背景—mysql切换• mysql的replication部署• master挂了,如何? – 需根据IO/SQL的binlog位置 – 因此,数据库的leader election是有状态的分布式 选举,不像分布式中由其它任何一台就可以替代(如 hbase中的HMaster)• 着重问题: – 新主库的选举 / 应用程序感知 – 选举完后各个数据的一致性保证
  • 相关工作• Master采用虚IP的方式 – 前提:备库与主库在同一网段 – 阿里云的云聊PHPWind [1] – 腾讯的CDB[2]• DB对外的接口是DNS – 优势:备库与主库可以在不同机房 – 阿里云在考虑的自动切换 – 缺点:受限于DNS,若DNS故障,服务不可用 – [1] http://app.phpwind.com/ – [2] http://wiki.opensns.qq.com/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] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament• [3] http://hadoop.apache.org/zookeeper• [4] PaxosLease: PaxosLease: Diskless Paxos 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++ / PHP
  • zookeeper的配置• Stand-alone模式 & Cluster模式 – 有三种端口配置 • 客户端通信端口 • 服务器通信端口 • 服务器选举端口• 超时设置(2~20倍限制) – zk服务器之间的超时 • initLimit (连接+同步) • syncLimit (同步) – 客户端程序与zk的超时 • zookeeper_init(host, wacher, int recv_timeout …);
  • 主库切换逻辑 watcher /lock 事件• 主库切换选举 – 每个mysql的客户端对应一个节点 /x-0001 – 主库对应的节点为第一个节点 /x-0002 – 若主库挂了,节点消失 – 发起选举,只有一个节点获得lock /x-0003 即成为新主库 watcher 事件
  • 部署场景• 可靠的zk集群保障 – zk机器可靠性可以保障 – 半数以上机器存活即可 – 稳定的第三方• 场景:有三个机房 – zk部署在三个机房 – mysql:3,4,6 – mysql:agent=1:1
  • 主库切换的触发条件• agent异常 – a1:agent异常退出 – a2:agent与mysql的通信异常 – a3:agent与zk之间的网络异常 – a4:机器死机• mysql数据库 – m1:访问异常 – m2:机器死机(同a4) – m3:机器的网络异常(同a3) – m4:所在的整个机房down掉
  • 主库切换的触发条件-agent• a1:异常退出 – 要求在recv_timeout的时间内可重启 – 否则将会进行切换 • 需要记住client端的session • 否则进行自动recover • 无法设置read-only,需第三方• a2:与mysql的通信异常 – 与mysql进行读写测试 – 重试机制,重试次数、间隔可控制 – 若mysql正常,通信问题可以忽略(同一台机器)
  • 主库切换的触发条件-agent(2)• a3:与zk之间的网络异常(设置read-only) – 通过超时来控制,大于recv_timeout则切换 – 由于session的绑定无法恢复, 需进行切换• a4:机器死机(设置read-only) – agent与zk的通信中断 – 在大于recv_timeout之后 进行自动切换
  • 主库切换的触发条件-mysql• m1:访问异常 • 定期进行读写(设置read-only) – 主库:插入时间戳(可重试,重试间隔可设置) » 若mysql连接被kill掉,重新创建连接 – 从库:读取时间戳(同上) – 若异常,认为mysql挂断,进行切换• m2:机器死机(同a4)• m3:机器的网络异常(同a3)• m4:所在的整个机房down掉 • zookeeper也挂掉,被踢出集群 • 类似于mysql机器与majority隔离 发起自动切换
  • 故障测试—影响写入时间• 1. 超时设置4秒钟• 影响写入的时间为4-5秒钟。
  • 故障测试—mysql挂掉• 按照设置的检测超时来定(即为影响写入 的时间)
  • 故障测试—watch事件的迁移• zk集群上结点各有watch事件• Client A注册上来后watch比如在zk的M上 – 如上图的,***00031结点• 将zk的M进行shutdown• 再进行主库切换,发现Client A成为主库 – Watch照样生效,即watch可以在zk间无缝迁移
  • 故障测试—agent的自动重启• agent的退出某种程度代表了主库的退出 – 1. 自动重启agent (需要将session保持到本地) – [REF: hadoop the definitive guide chapter 13]
  • 大纲• 背景• 基于zk的分布式选举• 切换的数据一致性保证• zk的监控• 效果页面• 总结
  • 数据可能丢失的地方• 挂掉的master的binlog能否获取到• Slave机器上的relay-log损坏 REF : http://code.google.com/p/mysql-master-ha/
  • 数据可能丢失的地方-Cont.• binlog能否获取到 – ssh获取直接获取 – 否则,semi-replication • DBA自己开发的ESR – 采用DRC: • DBA自己开发的类IO线程的模块 • Slave机器上的relay-log损坏• Slave的relay-log损坏 – 判断Exec和Read的pos – 若无法相等说明可能有丢失
  • 大纲• 背景• 基于zk的分布式选举• 切换的数据一致性保证• zk的监控• 效果页面• 总结
  • 官方支持的监控• 4-letter monitoring (mntr)• jmx监控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监控
  • Nagios监控• http://10.256.31.61/nagios/
  • 大纲• 背景• 基于zk的分布式选举• 切换的数据一致性保证• zk的监控• 效果页面• 总结
  • 漂移切换界面
  • 大纲• 背景• 基于zk的分布式选举• 切换的数据一致性保证• zk的监控• 效果页面• 总结
  • 总结• 主从库构成分布式环境,但是有状态 – 确保agent可重启,可以任意次重启 – 但是有超时限制• 主库切换逻辑可以通过zookeeper实现 – 锁的升级实现• read-only的设置显得尤为重要,• 故障切换 + APP切换
  • Q&A微博:http://www.weibo.com/suinkingEmail: mugong.zjq@taobao.com关注方向: mysql、hbase、HDFS