MHA简介

MHA在生产环境的作用

1、等待SQL线程执行完毕

2、解析最新的Slave上的中继日志（relay log）的日志头（log Header），为其他各个服务器确定出差异位置

3、将i1–>i2–>X 全部组成一个二进制日志

MHA的主要特性

• seconary_check_script

1.   调用该脚本，从多个网络路径判断MASTER是否宕机
2.   MASTER连接错误时会被调用
3.   MHA标配的脚本masterhaseconarycheck方便

• shutdown_script

1.   电源强制OFF等
2.   故障转移前的瞬间被调用
3.   SSH可以链接到的情况下mysqld，mysqld_safe强制kill，ssh连不到的情况下关闭电源

• master_ip_failover_script

1.   MASTER的IP地址更新，新建和应用程序连接所需要的用户
2.   故障转移前的瞬间和转移到新MASTER(差异反映结束后)被调用
3.   根据用途的不同来写脚本可以实现不需要更改应用程序端就可以连接到新的MASTER
4.   MASTER IP使用虚拟IP的场合

  将VIP让给新的MASTER

5.   用catalog database等来管理MASTER的IP地址的场合  

   更新该catalog database 中的信息

•  report_script 发邮件通知故障转移成功或失败等的详细情况

1.   故障转移结束后被调用

• 在DeNA的服务中（主要是社交游戏），针对有超过150组（对）MASTER/SLAVE的服务器引入MHA
• MySQL一般不会出现服务宕机，通常是由OS和H/W故障引起
• 拓展

除了Manager会对MASTER进行监控外，另外还通过其他两处的远程数据中心来检测是否可以连接到MASTER

ssh可以连接到的情况下用kill -9 mysqld mysqld_safe，ssh连接不到的情况下ipmitool等工具强制关闭电源。

 

• 针对OS挂掉的故障转移，检测系统是否挂掉需要10秒，故障转移仅需4秒

3*4-3 （9秒-12秒）

默认情况，只有其他所有的SLAVE都存货的情况下才进行故障转移

检测SLAVE，判断其工作状态（不到1秒）

1. 强制将显著的MASTER关机
2. SSH可以连接到的情况下，将有差异的二进制日志保存下来
3. 确定新MASTER
4. 将重新MASTER的IP地址有效化
5. 重开其他的SLAVE从新的MASTER之间的主从复制

当MASTER崩溃时，MHA会修复SLAVE之间的一致性问题。另外，MHA会尝试从崩溃的MASTER保存未能发送的二进制日志并应用到所有Slave。如果仅有一台SLAVE服务器，就不需要担心SLAVE之间的一致性问题。但是即使只有一台SLAVE服务器，在SSH可以连通的情况下，MHA在MASTER崩溃时抢救日志上也会非常有帮助，当然，通过半同步也可以解决这个问题。

从MHA Manager 0.52 开始支持多个MASTER(multi master)的复制。下面是MHA在多MASTER复制时注意的事项

• 只允许有一个MASTER（可写）。在其他MASTER上必须设置MySQL全局变量”read-only=1″
• 缺省情况下，所有被管理的服务器（在配置文件中定义的服务器）应该是2层级联复制。

在0.52版本以前，MHA仅在所有SLAVE都从同一个MASTER上进行复制才能进行检测，监控和故障转移操作。也就是说MHA不支持多主的配置形式。一般情况下，只要MHA可以管控自动故障转移，使用多MASTER配置的意义会很有限，比如在线模式更改。如果只是尝试使用多MASTER配置（比如仅仅为了在线模式更改）仅需在操作期间停止MHA并配置多主设置。当操作结束后，重新改为单主多从的配置，并重启MHA。

MHA默认不支持三次或更多曾的级联复制架构（比如Master->Master2->Slave3）。MHA仅在SLAVE直接从当前主要MASTER进行复制时，才会进行故障转移和恢复操作。MHA可以管理MASTER1和MASTER2并且当MASTER1崩溃提升MASTER为主MASTER，但是MHA不能监控和恢复SLAVE3，因为SLAVE3从不同的MASTER(MASTER2)上进行主从复制。为了让MHA在这种架构下能进行工作，需要以下设置：

• 在MHA的配置文件中设置MASTER和二层级联中的主机（MASTER1和MASTER2）
• 使用multi_tier_slave=1 参数并在MHA配置文件中设置所有主机。

MHA支持MySQL5.0或更高的版本。MHA不支持MySQL4.1，因为MySQL5.0开始，二进制日志的格式发生了改变（binlog v4） MHA分析二进制日志并确定位置点时止支持v4版本，所以MySQL4.1 在这里不能工作。MySQL5.0或更高版本中的mysqlbinlog同样也需要v4版本的binlog格式。在早起的MySQL版本中主从复制处理存在一些非常严重的问题，所以高度推荐使用高版本的MySQL.特别是如果你还在使用MYSQL 5.06.0 以前的版本，请考虑升级

如果当前SLAVE未设置log-bin，很明显他们都不能成为MASTER，MHA Manager内部将会检查log-bin的设置，不会将未开启binlog的Slave提升为MASTER、如果当前的Slave都没有设置log-bin，MHA将会不尽兴故障转移

所有服务器上的主从复制过滤规则（binlog-do-db，replicate-ignore-db等）MHA在启动时检查过滤规则，如果发现各服务器之间的配置不一致将不会进行监控或故障转移

当故障转移完成后，所有Slave将执行CHANGE MASTER TO 语句。必须存在一个具有复制权限的用户才能进行复制