MySQLMHA应用实践（基础知识）

一、MHA概述
MHA（Mater High Availability）是一套非常流行和实用的MySQL高可用解决方案软件，保证MySQL主从复制集群中主库的高可用性，保证集群业务不受影响。当master异常宕机后，MHA能够保证在1~30s的时间内实现故障转移，选择一个最优slave升为最新master，同时保持数据一致性的状态，以及将整个集群的所有数据损失降到最低。因此MHA方案十分受欢迎。
二、MHA架构
MHA由Manager（管理节点）和Node（数据节点）组成。Manager服务可以运行在一台读立服务器（虚拟机）上管理多个主从集群，也可以是某一个从节点或者应用服务器节点，而Node服务需要运行在每一个MySQL服务器上。Manager会定时通过主库上的Node服务监控主库，确保主库出现故障时可自动（或指定）将最优从库升为新主库，让所有从库与最新master保持正常。
三、切换原理

创新互联专业为企业提供蟠龙网站建设、蟠龙做网站、蟠龙网站设计、蟠龙网站制作等企业网站建设、网页设计与制作、蟠龙企业网站模板建站服务，十载蟠龙做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

3.1 MHA自动切换的原理：
MHA的全名叫做mysql-master-ha，配置后可以在10-30秒内完成master自动切换，切换过程如下：
1. 检测master的状态，方法是一秒一次“ SELECT 1 As Value”，发现没有响应后会重复3次检查，如果还没有响应，shutdown并再重复一次SELECT 1 As Value确认master关闭
2. 确认SSH到master所在的机器是否可达
3. 给出消息：Connecting to a master server failed，并开始读取配置文件masterha_default.conf和app1.conf
4. 确认复制切换模式: [info] GTID failover mode = 1
5. 报告整个架构中的机器存活情况
6. 检查存活的实例版本、GTID开启情况、是否开启read_only以及复制过滤情况
7. 接下来就是在GTID复制基础上的切换过程
(1) 配置检查阶段，具体检查如下
(2)彻底关闭master连接的阶段，避免master未关闭导致的脑裂，关闭完成后给出报告
(3)master恢复阶段：
›1   确认relay log最新的slave实例
›2   确定新的master
如果在配置文件中设置了候选master,会直接确定预设机器实例为master；如果没有预设，会选择含有最新的relay log的那个slave
›3   确认新的master后，会先设置sql_log_bin=0以阻塞master日志写入使其他slave赶上复制，应用该最新relay log，最终获得这个层次的数据一致性，之后再set sql_log_bin=1使恢复日志写入。可以通过半同步复制来解决无法ssh到master所在机器所造成的事务丢失问题
待全部数据一致后，通过show master status确定新master的日志位置并在其他slave上执行change master语句创建新的主从连接
该阶段成果后给出报告
Fri Jul  1 13:35:33 2016 - [info] ** Finished master recovery successfully.
Fri Jul  1 13:35:33 2016 - [info] * Phase 3: Master Recovery Phase completed.
(4)slaves恢复阶段：
先停止IO线程，等待SQL线程执行完成后，stop slave，清除原slave信息，重新change master指向新的master，start slave ，over
(5)清除新选出的master上的slave信息
reset slave all;
至此，整个切换过程完成，最后给出切换报告

3.2 MHA在线切换的原理:
1. 检查当前的配置信息及主从服务器的信息
包括读取MHA的配置文件/etc/masterha/app1.cnf及检查当前slave的健康状态
2. 阻止对当前master的更新
主要通过如下步骤：
1> 等待1.5s（$time_until_kill_threads*100ms），等待当前连接断开。
2> 执行 read_only=1，阻止新的DML操作
3> 等待0.5s，等待当前DML操作完成。
4> kill掉所有连接。
5> FLUSH NO_WRITE_TO_BINLOG TABLES
6> FLUSH TABLES WITH READ LOCK
3. 等待新master执行完所有的relay log
Waiting to execute all relay logs on 192.168.244.20(192.168.244.20:3306)..
4. 将新master的read_only设置为off，并添加VIP
5. slave切换到新master上。
1> 等待slave（192.168.244.30）应用完原主从复制产生的relay log，然后执行change master操作切换到新master上。
2> 释放原master上加的锁。
3> 因masterha_master_switch命令行中带有--orig_master_is_new_slave参数，故原master也切换为新master的从。
6. 清理新master的相关信息。
主要是执行了reset slave all操作，清除之前的复制信息。

    注释：应用访数据集群时可以采用keepalived 。

三、MySQL复制

异步复制（Asynchronous replication）
     MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
全同步复制（Fully synchronousreplication）
    指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
半同步复制（Semisynchronous replication）
    介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

异步复制

MySQL—MHA架构图