共计 4229 个字符，预计需要花费 11 分钟才能阅读完成。
1. 前言
mysql 作为应用程序的数据存储服务，要实现 mysql 数据库的高可用。必然要使用的技术就是数据库的复制，如果主节点出现故障可以手动的切换应用到从节点，这点相信运维同学都是知道，并且可以实现的。但是这种情况只是手动的切换，对可用性有要求的业务需要分别实现主库和从库的高可用，保障在数据库出现 down 机的情况下，可以自动实现数据库的故障转移，保障应用的可用性和用户体验。
本文将会对一些常用的数据库高可用方案进行介绍，根据你不同的场景，选择合适的高可用方案即可。
2.MMM 高可用方案
2.1.Mysql-MMM 介绍
MMM(Master-Master replication managerfor Mysql，Mysql 主主复制管理器) 是一套灵活的脚本程序，基于 perl 实现，用来对 mysql replication 进行监控和故障迁移，并能管理 mysql Master-Master 复制的配置 (同一时间只有一个节点是可写的)。
2.2. 组件
mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。
mmm_agentd：运行在每个 mysql 服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
mmm_control：一个简单的脚本，提供管理 mmm_mond 进程的命令。
mysql-mmm 的监管端会提供多个虚拟 IP（VIP），包括一个可写 VIP，多个可读 VIP，通过监管的管理，这些 IP 会绑定在可用 mysql 之上，当某一台 mysql 宕机时，监管会将 VIP 迁移至其他 mysql。
在整个监管过程中，需要在 mysql 中添加相关授权用户，以便让 mysql 可以支持监理机的维护。授权的用户包括一个 mmm_monitor 用户和一个 mmm_agent 用户，如果想使用 mmm 的备份工具则还要添加一个 mmm_tools 用户。
2.3. 架构图
正常工作时：
主节点故障时：
2.4.MMM 优点
（1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。
（2）配置简单，容易操作。
2.5.MMM 缺点
（1）需要一台备份服务器，浪费资源
（2）需要多个虚拟 IP
（3）agent 可能意外终止，引起裂脑。
3.MHA 介绍
MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
3.1.MHA 架构介绍
该软件由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。
在 MHA 自动故障切换过程中，MHA 试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失 (配合 mysql 半同步复制效果更佳)，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过 ssh 访问，MHA 没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用 MySQL 5.5 的半同步复制，可以大大降低数据丢失的风险。MHA 可以与半同步复制结合起来。如果只有一个 slave 已经收到了最新的二进制日志，MHA 可以将最新的二进制日志应用于其他所有的 slave 服务器上，因此可以保证所有节点的数据一致性。
注意：目前 MHA 主要支持一主多从的架构，要搭建 MHA, 要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当 master，一台充当备用 master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝 TMHA 已经支持一主一从。
3.2.MHA 架构图
正常工作时架构图：
主库 down 机时架构：
3.3. 故障转移过程
（1）从宕机崩溃的 master 保存二进制日志事件（binlog events）;
（2）识别含有最新更新的 slave；
（3）应用差异的中继日志（relay log）到其他的 slave；
（4）应用从 master 保存的二进制日志事件（binlog events）；
（5）提升一个 slave 为新的 master；
（6）使其他的 slave 连接新的 master 进行复制；
（7）在新的 master 启动 vip 地址，保证前端请求可以发送到新的 master。
3.4.MHA 优点
（1）不需要备份服务器
（2）不改变现有环境
（3）操作非常简单
（4）可以进行日志的差异修复
（5）可以将任意 slave 提升为 master
3.5.MHA 缺点
（1）需要全部节点做 ssh 秘钥
（2）MHA 出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。
（3）自带的脚本还需要进一步补充完善，且用 perl 开发，二次开发困难。
4.DRBD+（heartbeat,corosync）
4.1. 方案简介
本方案采用 Heartbeat 或者 corosync 双机热备软件来保证数据库的高稳定性和连续性，数据的一致性由 DRBD 这个工具来保证（如果可以尽量放到分布式存储上面）。默认情况下只有一台 mysql 在工作，当主 mysql 服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主 mysql 提供服务。
4.2. 组件
Heartbeat,corosync 作为心跳检测机制，监控 primary 节点的状态。当主节点宕掉之后，迅速提升 secondary 节点为新的主节点，并切换 IP；
drbd 负责数据同步
4.3. 架构图
4.4. 数据同步过程
mysql 进行刷盘时，会通过不同的 sync 方式，最终将数据写入 disk；
drbd 收到刷盘成功的信息后，将对应的磁盘块位置，和变更动作，通过网络传递至 secondary 节点；
secondary 的 drbd 接收到变更信息后，将这些信息落盘；
4.5. 切换过程
前提：secondary 节点的 mysql 服务不启动；
heartbeat 检测到 primary 的 mysql 服务停止，则摘掉 IP、umount 掉数据盘、将 primary 切换为 secondary；
在原来的 secondary 上，提升 drbd 同步为 primary，挂载数据盘，启动 mysql 服务、绑定 IP；
从库跟着 IP 和端口自动进行迁移；
4.6. 方案优点
（1）历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。
（2）数据一致性强
4.7. 方案缺点
（1）需要一台备份服务器，浪费资源
（2）不方便扩展
（3）无论 drbd 还是 headbetart，corosync 都可能发生裂脑
5.Mysql route 介绍
5.1. 什么是 mysql route
MySQL Router 是处于应用 client 和 dbserver 之间的轻量级代理程序，它能检测，分析和转发查询到后端数据库实例，并把结果返回给 client。是 mysql-proxy 的一个替代品。其架构图和功能如下。
（1）Router 实现读写分离，程序不是直接连接数据库 IP，而是固定连接到 mysql router。MySQL Router 对前端应用是透明的。应用程序把 MySQL Router 当作是普通的 mysql 实例，把查询发给 MySQL Router, 而 MySQL Router 会把查询结果返回给前端的应用程序。
（2）从数据库服务器故障，业务可以正常运行。由 MySQL Router 来进行自动下线不可用服务器。程序配置不需要任何修改。
（3）主数据库故障，由 MySQL Router 来决定主从自动切换，业务可以正常访问。程序配置不需要做任何修改。
5.2. 读写分离原理
MySQL Router 接受前端应用程序请求后，根据不同的端口来区分读写，把连接读写端口的所有查询发往主库，把连接只读端口的 select 查询以轮询方式发往多个从库，从而实现读写分离的目的。读写返回的结果会交给 MySQL Router, 由 MySQL Router 返回给客户端的应用程序。
5.3.Mysql router 用途
MySQL Router 的主要用途是读写分离，主主故障自动切换，负载均衡，连接池等。
5.4.Mysql router 主主故障自动切换的坑
Mysql router 主主故障切换功能经过测试没有问题，但是有一个比较大的坑需要注意，主库发生切换之后，从库的连接的 master 服务器地址不会发生改变，需要自己写脚本进行判断。
5.5. 优点
（1）基于 DAL 层实现 mysql 的高可用。
（2）可以同时实现主主故障切换和读写分离。
（3）插件式架构允许用户进行额外的功能扩展。
5.6. 缺点
（1）高可用功能需要进一步完善：存在主库切换之后，从库不会自动切换主库地址的坑。
（2）读写情况使用不同端口，需要修改应用程序。
6.mysql Cluster
国内用的非常少，主要因为一下三点：
（1）需要更改存储引擎
（2）付费
（3）国内几乎没有使用案例
优点：
高可用，可用率达 99.999%
6.1. 结束语
上面的高可用方案，只是我自己比较熟悉的，而且也是应用比较多的。mysql 毕竟发展了有 20 多年了，各种高可用方案还是很多的，其他的高可用方案各位钥匙有兴趣，可以自己研究。
版权申明：作者：西门飞冰，一名 90 后 it 男，一直在北京工作，热爱运动，热爱冒险，热爱旅行。由作者原创投稿，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意，谢谢。
关注 民工哥技术之路 微信公众号对话框回复关键字：1024 可以获取一份最新整理的技术干货：包括系统运维、数据库、redis、MogoDB、电子书、Java 基础课程、Java 实战项目、架构师综合教程、架构师实战项目、大数据、Docker 容器、ELK Stack、机器学习、BAT 面试精讲视频等。
