MHA源码分析

MHA是针对MySQL由perl实现高可用方案的软件。MHA主要分为管理节点和数据节点，管理节点主要由masterha_manager实现对数据节点的管理，而管理的实现主要通过管理节点通过建立各个节点之间的SSH互信并调用数据节点安装的MHA各个脚本。MHA的核心功能是对于mysql集群中一旦master节点宕机，如何迅速将某个slave节点提升为新的master节点。

首先，介绍下它的一些特点。

1. 10-30s实现master failover（9-12s可以检测到主机故障，7-10s可以关闭主机，在用很短的时间应用差异日志）

2. 部署简单，无需对现有M-S结构做任何改动（至少3台，保证切换后仍保持M-S结构）

3. 支持手动在线切换（主机硬件维护），downtime几乎很短0.5-2s

4. 保证故障切换后多从库数据的一致性

5. 完全自动化的failover及快速复制架构恢复方案（一主多从）

6. 恢复过程包括：选择新主库、确认从库间relay log差异、新主库应用必要语句、其他从库同步差异语句、重新建立复制连接

先从master_manager这个脚本作为MHA failover功能源码分析的切入点：
MHA::MasterMonitor::main
MHA::MasterFailover::main
上面是masterha_manager依次调用的另外两块代码，可见masterha_manager是先对集群中节点进行监控，然后一旦检测到master宕机那么将执行故障切换

MasterMonitor
|
 wait_until_master_is_dead()
|
wait_until_master_is_unreachable() - 此处会初始化MHA::ServerManager对象用来管理以及统计节点的状态并做好节点的分类（dead servers,alive servers,alive slave,real_master ...）
|
server_manager->connect_all_and_read_server_status()此处相对而言比较关键，通过对所有节点的尝试连接和节点的状态读取（如show master status,show slave status,show variables like '?'）来梳理servermanager的统计和管理内容
|
server_manager->validate_slaves  （read_only(info)?相同的ip/port(error)?relay_log_purge=0(warn)?相同的复制过滤规则?）
server_manager->get_bad_candidate_masters
server_manager->check_repl_priv
MHA::ManagerUtil::check_node_version
check_binlog_servers
server_manager->validate_num_alive_servers
以上是在server_manager对节点的状态获取和梳理后再进行的各种结果的验证，来检验slave节点配置的一致性，有无符合可切换的slave，验证节点配置用户是否拥有复制的权限等
｜
master_ping = new MHA::HealthCheck
实例化节点健康检测对象
｜
master_ping->wait_until_unreachable
如果并没有master宕机，那么会一直hang在此处


MasterFailover
｜
do_master_failover()
｜
步骤1:配置检查，说是配置检查，实际上再次进行状态获取以及对监控到dead master进行校对和验证
check_settings()
｜
步骤2:停掉所有slave的IO thread,然后检查ssh互信后调用master节点的自己制定的关闭master脚本
force_shutdown($dead_master)
｜
步骤3:master恢复
｜
步骤3.1:获得relaylog最新的slave以及relaylog最旧的slave
｜
步骤3.2:保存宕机master的binlog-其实并不是保存整个binlog,而是调用master节点的save_binary_logs命令去根据最新slave中读取的binlog位置截取最新的slave没有获取到的binlog内容，保存到管理节点
save_master_binlog($dead_master)
｜
步骤3.3:选出新的master，在选举过程中分为三个优先权（1.在启动参数中设置的master 2.最新relaylog位置的slave且同步延迟在可以接受的范围内3.配置文件中设置为candidate_master的节点 ）
select_new_master( $dead_master, $latest_base_slave )，在选出新的master后通过与最新的slave比较产生差异的relaylog
｜
步骤3.4:对新的master提供差异binlog+差异relaylog来使得其数据与原始的master数据一致
recover_master( $dead_master, $new_master, $latest_base_slave,$binlog_server_ref )
｜
步骤4:开始恢复slaves,这里的步骤和补齐新的master步骤差不多这里不再赘诉,再change master重新指向新的master
recover_all_slaves_relay_logs
｜
步骤5:清空新的master的原始slave 配置 reset slave
reset_slave_on_new_master


                                                               

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28944233/viewspace-1813591/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28944233/viewspace-1813591/