MySQL MHA应用实践（基础知识）

一、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.conf4. 确认复制切换模式: [info] GTID failover mode = 15. 报告整个架构中的机器存活情况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 TABLES6> FLUSH TABLES WITH READ LOCK3. 等待新master执行完所有的relay logWaiting to execute all relay logs on 192.168.244.20(192.168.244.20:3306)..4. 将新master的read_only设置为off，并添加VIP5. 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架构图