MySQL MHA原理

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

 

MHA监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转移。即使有些从服务器没有收到最新的relay log，MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上，因此所有的从服务器保持一致性了。还可以设置优先级指定其中的一台slave作为master的候选，由于MHA在slaves之间修复一致性，因此可以将slave变成新的master，其他的slave都以其作为新master。

 

MHA有两部分组成，MHA Manager(管理节点)和MHA Node(数据节点)：
    1：MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群，也可以部署在一台slave上。MHA Manager探测集群的node节点，当发现master出现故障的时它可以自动将具有最新数据的slave提升为新的master，然后将所有其它的slave导向新的master上。整个故障转移过程对应用程序是透明的。
    2：MHA node运行在每台MySQL服务器上(master/slave/manager),它通过监控具备解析和清理logs功能的脚本来加快故障转移的。
    

 

MHA的切换步骤
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

 

故障情况分析

1.主库挂了，但是主库的binlog都被全部从库接收，此时会选中应用binlog最全的一台从库作为新的主库，其他从主只需要重新指定一下主库即可(因为此时,所有从库都是一致的，所以只需要重新指定一下从库即可)。

2.主库挂了，所有的binlog都已经被从库接收了，但是，主库上有几条记录还没有sync到binlog中，所以从库也没有接收到这个event，如果此时做切换，会丢失这个event。此时，如果主库还可以通过ssh访问到，binlog文件可以查看，那么先copy该event到所有的从库上，最后再切换主库。如果使用半同步复制，可以极大的减少此类风险。

3.主库挂了，从库上有部分从库没有接收到所有的events，选择出最新的slave，从中拷贝其他从所缺少的events。

虽然MHA试图从宕机的主服务器上保存二进制日志，但并不是总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失最新数据。

    

如何确定最近从库以及丢失的events
    1、Master_Log_File,Read_Master_Log_Pos 可以确定(从库的IO线程)读取主库的binlog的最新进度。
    2、Relay_Log_File,Relay_Log_Pos 确定SQL线程执行本地Relay_Log的最新进度。
    3、由于Relay_Log的进度和binlog是不一样的。所以如果只看Relay_Log的信息无法确定执行事件的实际位置，Relay_Master_Log_File,Exec_Master_Log_Pos 本地SQL线程实际上执行binlog位置(用于计算seconds_behind_master)。
    4、各个从库之间，比较Master_Log_File,Read_Master_Log_Pos可以确定哪台从库接收到的日志是最完整的。
    5、当找出最新最全的从库之后，应用diff到其他从库。
    仅仅比较上面2个参数是不够确定具体缺失的events，在relay log中日志开头会指定是读哪个binlog，文尾的end_log_pos表示最后读到binlog的位置。通过对比不同从库上，最新的relay_log中的binlog file和end_log_pos位置来对比还有哪些events缺失(每个at xxx就是一个event)。如果是一个很大的事务，产生了很多日志信息(事务只会保存在一个binlog文件中,但是会出现在2个relay_log中。)面对这种情形,如果只接受到了部分的events信息。从库是不会重做这些relay_log。此时的Master_Log_File,Read_Master_Log_Pos 会指向读取到的binlog的最新位置(这是IO线程负责的)，而Relay_Master_Log_File,Exec_Master_Log_Pos只会指向最后执行的commit事务。这样就保证了不会使数据库进入不一致状态。那么在接受到其他从库最新日志的时候，也是完整的执行一次该事务(即使自己的Relay log已经有部分记录了)。
    

MHA优缺点

MHA支持GTID的复制模式

MHA在进行故障转移时更不容易产生数据丢失

同一个监控点可以监控多个集群

需要编写脚本或利用第三方工具来实现VIP配置

MHA启动后只会对主数据库进行监控，不会对从DB进行监控，如果从DB挂掉，也不会自动踢出集群，这一点上需要改进（通过其他工具，监控从DB的状态，及延迟情况）

需要基于SSH免认证配置，存在一定的安全隐患

没有提供从服务器器的负载均衡功能