mysql mha管理平台_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.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架构图