MySQL 同步复制及高可用方案总结

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%

7.结束语

上面的高可用方案，只是我本身比较熟悉的，并且也是应用比较多的。mysql毕竟发展了有20多年了，各类高可用方案仍是不少的，其余的高可用方案各位钥匙有兴趣，能够本身研究。