2.Mysql之MHA高可用(01)
1.前言
在众多的Mysql高可用架构中，MHA架构目前属于现在比较成熟且岁数比较年长的架构之一了，目前，在Mysql的业界比较流行的高可用架构除了MHA，还有官方的MGR高可用架构、Percona公司出品的PXC(percona XtraDB Cluster)高可用架构以及Galera Cluster，MGR架构和PXC架构也会在本系列的高可用架构中一一讲解。
2.MHA简介
MHA架构主要是由日籍工程师youshimaton开发的，是一套在Mysql高可用性环境下进行故障切换或主从提升的优秀软件。在Mysql故障切换过程中，MHA能做到在0~30s之内自动完成数据库的故障切换操作，并且在故障切换的过程中，最大程度地保证数据的完整性和一致性，已达到真正意义上的高可用。
3.MHA架构(组件)
- MHA主要有两部分组成：MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager简易通常部署一台独立的机器上，可以管理多个master-slave集群。MHA Node运行在每台Mysql的服务器上，这里MHA Manager会定时探测集群中的master节点，当maste出现故障时，它可以自动将最新数据的slave提升为新的master,然后再将所有其他的slave重新执行新的master,并且整个故障转移的过程对应用程序是完全透明的。
3.1 软件说明
其实，MHA高可用架构主要是通过脚本进行实现设计的，其中MHA软件主要有两部分组成，即Manager工具包和Node工具包。
Manager工具包主要包含以下几个工具(脚本)
-
- masterha_check_ssh :检查MHA的ssh 配置状态
- masterha_check_repl：检查Mysql的复制状态
- masterha_manager：mha的启动脚本
- masterha_check_status：检测当前MHA运行状态
- masterha_master_monitor：检测master是否宕机
- masterha_master_switch:控制故障转移(自动或手动)
- masterha_conf_host:添加或删除配置的server信息
Node工具包(这些工具通常有MHA Manager的脚本触发，无须人为操作)，主要包括如下一个工具(脚本)
-
- save_binary_logs:保存和复制master的二进制日志
- apply_diff_relay_logs：识别差异的中继日志事件并将其差异的事件应用于其他slave.
- purge_relay_logs：清除中继日志(不会阻塞SQL线程)
4.MHA之Failover(故障转移)工作原理(重点)
4.1 自动故障转移图
4.2自动故障转移过程如下：
- 监控到主节点宕机(ping不通)
- 选主：识别含有最新更新的slave(主要通过show slave status命令中查看：Read_Master_log_Pos位置点，这里还有多个选择策略，可以看看下面的选主策略)
- 数据补偿：1）ssh能连接dead master，保存上面的binlog日志到各个从节点，然后新主apply其中的差异的日志
- 提升一个slave为新的master
- 使其它的slave连接新的master进行复制
需要打开从库的log-slave-updates以减少数据丢失的风险。
log-slave-updates:该参数用来配置从库上的更新操作是否写二进制，默认是off,即不写binlog（在Mysql8.0.23版本后，默认值是on），
如果这个从库同时也要作为其他服务器的主库，搭建一个链式的复制，或者在高可用的环境下(比如开启GTID模式下的MHA),那么就需要打开这个选项，
这样它的从库将获得它的二进制日志以进行同步操作。该参数需要和-log-bin结合使用，即如果没有开启--log-bin，即使将该参数设置ON，也不会写二进制。
5. 补充说明4中的一些细节
1. 基于GTID和非GTID模式下的MHA自动故障转移，首先是基于GTID模式下的复制通常我们一般会用增强半同步复制(5.7版本或以后)，
该复制方式保证了主库的binlog数据在传到slave节点时数据不丢失(数据一致性)的特点。因此不管基于任何时间点主节点宕机
(无论是Mysql服务宕机还是服务器宕机)，主库的binlog日志一定会传到其中的一个备库中(或者)全部。
2.传统复制模式下MHA，当主节点宕机后，备节点还可以通过ssh连接主节点时，MHA试图从宕掉的主机的服务器上保存二进制，最大程度地保证数据不丢失。
也就是说将主库的binlog日志拷贝到各个节点上。
3.总结：纯属于个人的看法：第一步：当主节点宕机后，由于管理节点发出的探测接受不到主节点存活的状态信息后(这里有个检测机制)，
立即通过ssh协议保存主节点的binlog日志到各个从节点，最大程度地保证数据不丢失(注意：这里如果是服务器宕机了，ssh就不能使用了，则第一步就可以跳过了)，
第二步：然后选最新更新的slave,也可以称做备选主机(这里有选择策略，见下文)，
第三步：应用差异的中继日志到其他的slave节点上，
第四步：应用从master保存下来的binlog日志(如果第一步跳过了，这一步也不会执行)，
第五步：把第二步这个最新更新的slave节点提升为新的master节点，
第六步：使其它的slave节点连接到这个新的master节点上进行复制。
4.选主策略：
算法一: 读取配置文件中是否有强制选主的参数？ candidate_master=1 ###设置为候选master，如果设置该参数以后，发生主从切换以后会将此从库提升为主库，即使这个主库不是集群中事件最新的slave check_repl_delay=0 ### 默认情况下如果一个slave落后master 100M的relay logs 的话，MHA将不会选择该slave作为一个新的master，
因为对于这个slave的恢复需要花费很长时间， 通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，
因为这个候选主在切换的过程中一定是新的master 算法二: 自动判读所有从库的日志量，将最接近的主库数据的从库作为新主 算法三: 按照配置文件先后顺序的进行选新主
MHA基于源码的工作原理：
1. 监控：通过masterha_master_monitor脚本，每隔ping_interval秒数探测主库心跳，如果没有心跳，会总共给4次机会，如果4次没有心跳，就认为主库宕机
2.选主：首先会生成一些数组
1) alive数组 : 保存所有存活的节点(mysqladmin ping) 2) latest数组：日志最接近主库的(Read_Master_log_Pos)
3) pref数组：候选的(candidate_master=1) 4) bad数组：不会被选主的节点(没开binglog，或者日志落后100M,或者设置了no_master=1参数)
补充：check_repl_delay=0 如果节点上设置了改参数，那么就不会检测日志落后这一选项，但是其他的条件还是要检测。
策略0：手工切换，以命令行指定的新主为准
策略1：出现在2)和3)中，但是没有出现在4）中
策略2：出现在2）中，但是没有在4）中
策略3：出现在3）中，但是没有出现4)中
策略4：出现在策略1)中，但是没有出现4)中
策略5：都没有选上，选主失败
补充：如果选出的有多个结果，会按照节点上的号码顺序选主
3.数据补偿
1）ssh能连：通过save_binary_logs立即保存主库binlog，存在在各个节点/var/tmp,进行补偿
2）ssh不能连接：从节点调用apply_diff_relay_logs，计算两个从节点的relay-log日志差异
4.切换
调用masterha_master_swith脚本主要做如下几件事情：
a.取消所有节点的从库状态，b.构建新的主从关系，c.vip进入新的节点
5.自动将故障节点，从配置文件中剔除 --remove_dead_master_conf
6.manager自杀，manager自动退出
7.应用透明：vip
8.数据补偿补充方案：binglog_server
9.切换提醒：send_report
