索引：
1. 什么是高可用？
2. 造成不可用的常见原因
3. 有哪些手段可以提高高可用水平？
4. 常见Mysql HA方案
5. 参考资料
一、什么是高可用？
服务能够持续运行、且以比较好的性能处理请求的能力，一般用百分比表示，比如99.999%表示每年只允许5分钟的服务不可用时间。注意成本投入和可用性的提高并不是线性关系，一般比例会越来越大，在解决实际问题时需要做个权衡。
二、造成不可用的常见原因
- 运行环境故障(比如磁盘空间耗尽，系统异常关机等等)
- 性能问题（表设计和索引设计不合理）
- Mysql复制造成的数据不一致
- 安全事故造成的数据丢失（如人工误操作）
- 其他
三、如何提高可用性水平？
一般是两类措施。一类是减少不可用时间，比如做好监控，日常运维等保障措施。第二类是提高故障恢复速度，比如做好冗余和恢复计划，故障转移演练等。
四、常见Mysql HA方案
4.1 共享存储或磁盘复制技术
共享存储，是MySQL主服务器和备用服务器使用同一个存储设备上的相同数据。主服务器失效后，备用服务器能够挂载文件系统，进行恢复和启动服务，这样就保证了Mysql服务的可用性。架构图如下，一般为了保证数据一致性，同一时间只允许maser服务器挂载共享存储（也有看到一些公司在SAN上划分2个LUN，供每个主备mysql使用，使备服务器同时提供服务，避免闲置）。
这种方案的优点：
- 实现简单，切换简单，对上层应用透明
- 使用同一份数据，保证了主备数据的强一致
- 可以避免存储外的其它组件引起的数据丢失
但也存在一些缺点：
- 存储组件是个单点，存在失效问题
- 数据如果被损坏，即使启用了备份服务器，也无法恢复
- SAN昂贵，成本较高
另一种方案是普遍使用的DRBD磁盘复制技术。与共享存储相比，DRBD是复制数据，而不是共享一份数据，因此解决了存储组件的单点问题，架构图如下。
这种方案的优点是：可用性高，支持自动切换。
这种方案也有其缺点：
- DRBD方案通常无法再秒级别完成故障转移，可能需几分钟；
- 昂贵。因为必须采用“主动-被动”的双主模式，热备服务器不能做其他任务。
- 无法代替数据备份。如果源数据被损坏，则复制的数据也是被损坏数据的副本。
- 增加了写操作的负担（网络延迟+备master的写入耗时）。
- 通过网络传输备份数据，不是100%的保证数据不丢失。
- 搭建过程复杂。
DRBD介绍
http://www.drbd.org/
DRBD(DistributedReplicatedBlockDevice)是一个基于块设备级别在远程服务器直接同步和镜像数据的软件，用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。它可以实现在网络中两台服务器之间基于块设备级别的实时镜像或同步复制(两台服务器都写入成功)/异步复制(本地服务器写入成功)，相当于网络的RAID1，由于是基于块设备(磁盘，LVM逻辑卷)，在文件系统的底层，所以数据复制要比cp命令更快。DRBD已经被MySQL官方写入文档手册作为推荐的高可用的方案之一。
Heartbeat
http://linux-ha.org/wiki/Heartbeat
4.2 Mysql同步复制
同步复制中，主库提交的事务至少在一个备库成功执行才能认为是最终成功执行了。这保证了“不存在主库崩溃时丢失‘未提交事务’的场景、至少有一个备库拥有实时副本”。
- cluster
- gr
4.3 基于复制的冗余
基于复制的冗余是使用mysql自身支持的复制功能，通过复制和重放binlong来实现数据备份，比较灵活，可以根据实际情况设计多种多样的架构。常见方案有MMM，MHA。但是MMM有很多问题（What’s wrong with MMM，Problems with MMM for MySQL），所以，生产环境更推荐MHA。
4.3.1 MMM
Master-Master replication manager for MySQL。这种复制管理器为每个mysql实例部署一个mmm agent，mmm agent与mmm manager之间保持心跳连接，agent定期向manager汇报各个mysql实例的状态。一旦主master挂掉或agent挂掉，manager就会执行切换操作，进行故障转移。
架构图如下，
当master挂掉时，MMM执行故障转移，
mmm存在的缺点：
- agent自身不支持高可用，如果agent挂掉但mysql服务正常，manager会误认为mysql服务已挂掉；
- vip难以管理
- mmm manager是个单点，存在失效问题
- vip需要使用ARP协议，跨网段、跨机房的高可用基本无法实现，保障能力有限
总体上，这个方案不太推荐使用。
4.3.2 MHA
MHA（MySQL Master High Availability）是由Facebook工程师Yoshinori Matsunobu开发的一款MySQL高可用软件，负责主库的高可用。主库发生故障时，MHA会选择一个数据最接近原主库的候选主节点作为新的主节点，并补齐和原主库差异的Binlog。数据补齐之后，即将写VIP漂移到新主库上。如下架构案例图，
（ 注意两点：
1. 心跳检测与VIP管理。可以使用heartbeat、lvs+keepalived、自行编写脚本等多种方式实现。为了防止vip
漂移，推荐脚本方式，以确保写vip同时只能被1个mysql节点占有。
2. 如上图，支持预指定备用主库(candidate master)，这样主库宕机时会选择该库做主库。当不指定
candidate master时，MHA会选择一个与master最接近的slave充当新master。
）
MHA+读写分离架构：
MHA支持多种切换方式：自主切换、在线热切换、手工执行脚本切换。
以自动切换为例，Manager进行预检查-> 关闭旧主库 -> 选择新主库，基于diff binlog补充数据 -> 启用新master -> 恢复slave，如图(from参考资料3)。
MHA的优点：
- 故障切换快
- 开源
MHA的缺点或限制：
- vip脑裂问题。这个问题集群软件普遍存在，MHA中因为网络抖动等原因，Manager误认为master挂掉而将vip漂移到备用Mysql节点上，然后网络正常后master恢复了服务，此时网络中两个节点有同一个vip。导致上层应用访问时出现换乱，导致数据不一致。
- manager失效问题。mmm manager是单点，存在失效问题。
- 数据丢失问题。当master意外宕机或由于网络故障而无法访问时，MHA切换过程中可能导致数据丢失。
4.3.3 MHA的改进版
针对VIP脑裂问题。常见方案之一是使用命名服务，对上层应用屏蔽mysql集群的拓扑信息，达到底层mysql集群的变更对上层透明的目的。第一个案例是 链家网，Name service使用zookeeper，如图（from 参考资料6）
mysql节点切换过程，上层应用始终使用对应的hostname，对节点替换无感知：
-
MHA做mysql切换
-
MHA向Zookeeper发布mysql服务信息变更 -
MZAgent订阅到变更，并修改/etc/hosts中的hostname
-
应用使用新的hostname连接mysql
针对Manager单点问题，一种做法是让MySQL数据库集群中每个节点部署Agent，发生故障时每个Agent均参与选举投票，选举出合适的Slave作为新的主库，防止只通过Manager来切换，去除MHA单点。
五、参考资料
- MySQL共享存储主备模式及实施， http://7424593.blog.51cto.com/7414593/1893767
- Heartbeat+DRBD+MySQL高可用方案及实施， http://oldboy.blog.51cto.com/2561410/1240412
- MySQL高可用架构之MHA （实施） http://www.cnblogs.com/gomysql/p/3675429.html
- MySQL高可用之MHA的实现及大规模运维实践 ， 黄华亮@京东金融
- 美团点评数据库高可用架构的演进与设想， 金龙@美团点评
- 数据一致性-分区可用性-性能—多副本强同步数据库系统实现之我见，http://hedengcheng.com/?p=892
- 基于Zookeeper+MHA的mysql高可用架构设计, 刘世勇@链家
- 《高性能Mysql》
这几天大致学习了MySQL高可用的相关技术，后续会继续学习，进行更新和补充。 最好的方式是在解决实际问题中，寻求最合适的架构。
附件中对应的ppt课件。
五、参考资料
- MySQL共享存储主备模式及实施， http://7424593.blog.51cto.com/7414593/1893767
- Heartbeat+DRBD+MySQL高可用方案及实施， http://oldboy.blog.51cto.com/2561410/1240412
- MySQL高可用架构之MHA （实施） http://www.cnblogs.com/gomysql/p/3675429.html
- MySQL高可用之MHA的实现及大规模运维实践 ， 黄华亮@京东金融
- 美团点评数据库高可用架构的演进与设想， 金龙@美团点评
- 数据一致性-分区可用性-性能—多副本强同步数据库系统实现之我见，http://hedengcheng.com/?p=892
- 基于Zookeeper+MHA的mysql高可用架构设计, 刘世勇@链家
- 《高性能Mysql》