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差异、新主库应用必要语句、其他从库同步差异语句、重新建立复制连接 <div id="xunlei_com_thunder_helper_plugin_d462f475-c18e-46be-bd10-327458d045bd"> 先从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                                                                 </div> <div id="xunlei_com_thunder_helper_plugin_d462f475-c18e-46be-bd10-327458d045bd"> </div>

ITPub博客

MHA源码分析

最新文章