MHA 源码阅读第02期：MasterFailover

数据库交流

发布于 2022-04-25 08:34:51

8110

文章被收录于专栏：悦专栏悦专栏

作者简介

无为，前饿了么 MySQL DBA，现就职于某知名互联网公司，对 MySQL、 Redis、PostgrepSQL 等主流数据库有一定了解，拥有丰富的一线运维经验。

上期我们已经详细了解了 MHA manager 的 monitor 原理，这一期我们继续探索 MHA 核心功能之一的 failover

1 非 GTID 模式

1.1 调用链路

MasterFailover::main --> do_master_failover 
        --> init_config(): 初始化配置
        --> init_binlog_server(): 初始化binlog server
        --> check_settings()  
        --> force_shutdown() 
        --> check_set_latest_slaves()
        --> save_master_binlog() 
        --> find_latest_base_slave() 
        --> select_new_master() 
        --> recover_master() 
        --> recover_slaves()
        --> reset_slave_on_new_master()

1.2 流程图解

1.3 代码详解

MHA::ServerManager::init_binlog_server( $binlog_server_ref, $log ); <!--binlog server 初始化-->

MHA::HealthCheck::ssh_check_simple()
MHA::ManagerUtil::get_node_version()

MHA::MasterFailover::check_settings($servers_config_ref);  <!--配置初始化-->

check_node_version():
connect_all_and_read_server_status():
get_dead_servers()，get_alive_servers()，get_alive_slaves()：
print_dead_servers():
MHA::DBHelper::check_connection_fast_util :
MHA::NodeUtil::drop_file_if(failover_error_file|failover_complete_file):
start_sql_threads_if():
is_gtid_auto_pos_enabled():

force_shutdown($dead_master);

stop_io_thread():
force_shutdown_internal($dead_master):  master_ip_failover_script:  shutdown_script：

check_set_latest_slaves

read_slave_status():
identify_latest_slaves():
identify_oldest_slaves():

save_master_binlog

dead master ssh 可达

save_master_binlog_internal
diff_binary_log
file_copy

dead master ssh 不可达

差异日志丢失

find_latest_base_slave($dead_master);

find_latest_base_slave_internal

<!--# We pick relay logs here. This should not reconfigure slave settings until other slaves connect to new master-->

find_slave_with_all_relay_logs:

select_new_master( $dead_master, $latest_base_slave );

get_candidate_masters()
get_bad_candidate_masters()

以下条件不能成为候选 master

dead server          
 no_master >= 1        
 log_bin=0          
 oldest_major_version=0*

check_slave_delay

也就是三种情况不能选择为主：

参数加了 no_master=1
没有开启 binlog
延迟太大

选举流程：先看 candidate_master，然后找 latest slave, 然后再随机挑选

recover_master( $dead_master, $new_master, $latest_base_slave,$binlog_server_ref )

recover_master_internal recover_relay_logs:  recover_master_internal:
apply_diff
1. wait_until_relay_log_applied 
2. 判断Exec_Master_Log_Pos == Read_Master_Log_Pos 
3. apply_diff_relay_logs  exec_diff  read_diff  binlog_diff
如果设置了 master_ip_failover_script 脚本，那么会执行这里面的脚本（一般用来漂移 vip）
disable_read_only()

$error_code = recover_slaves($dead_master,$new_master,$latest_base_slave,$master_log_file, $master_log_pos, $exec_gtid_set);

recover_all_slaves_relay_logs
recover_slave
change_master_and_start_slave

reset_slave_on_new_master

在 new master 上执行 reset slave all;

2 GTID 模式

2.1 调用链路

MasterFailover::main --> do_master_failover 
        --> init_config(): 初始化配置
        --> init_binlog_server(): 初始化binlog server
        --> check_settings()  
        --> force_shutdown() 
        --> check_set_latest_slaves()
        --> save_master_binlog() 
        --> get_most_advanced_latest_slave() 
        --> select_new_master() 
        --> recover_master() 
        --> recover_slaves() 
        --> reset_slave_on_new_master()

2.2 流程图解

2.3 代码详解

MHA::ServerManager::init_binlog_server( $binlog_server_ref, $log ); <!--binlog server 初始化-->

MHA::HealthCheck::ssh_check_simple()
MHA::ManagerUtil::get_node_version()

MHA::MasterFailover::check_settings($servers_config_ref);  <!--配置初始化-->

check_node_version()
connect_all_and_read_server_status()
get_dead_servers()，get_alive_servers()，get_alive_slaves()
print_dead_servers()
MHA::DBHelper::check_connection_fast_util
MHA::NodeUtil::drop_file_if(failover_error_file|failover_complete_file)
start_sql_threads_if()
is_gtid_auto_pos_enabled()

force_shutdown($dead_master);

stop_io_thread()
force_shutdown_internal($dead_master)  master_ip_failover_script  shutdown_script

check_set_latest_slaves

read_slave_status()
identify_latest_slaves()
identify_oldest_slaves()

save_master_binlog

gtid 模式下无此步骤

get_most_advanced_latest_slave

获取最新的 slave

select_new_master

get_candidate_masters()
get_bad_candidate_masters()

以下条件不能成为候选 master

 dead server          
 no_master >= 1        
 log_bin=0          
 oldest_major_version=0*

选举流程：先看 candidate_master，然后找 latest slave, 然后再随机挑选

recover_master( $dead_master, $new_master, $latest_base_slave,$binlog_server_ref )

wait_until_relay_log_applied
如果候选 master 不是最新的 slave： latest_slave->wait_until_relay_log_applied($log)  change_master_and_start_slave
获取候选 master 此时此刻的日志信息，以便后面切换
如果候选 master 是最新的 slave：获取候选 master 此时此刻的日志信息，以便后面切换
save_from_binlog_server: 如果配置了 binlog server，那么在 binlogsever 能连的情况下，将 binlog 拷贝到 Manager，并生成差异日志 diff_binlog(save_binary_logs --command=save)
apply_binlog_to_master: Applying differential binlog：应用差异的 binlog 到 new master

recover_slaves_gtid_internal

change_master_and_start_slave

reset_slave_on_new_master

在 new master 上执行 reset slave all;

3 总结

通过源码阅读我们发现在 failover 阶段 MHA 在 GTID 模式和非 GTID 模式下是不一样的，主要差异下：

GTID 模式下不执行 save_master_binlog，也就是说即使主库 ssh 可达也不会保存 binlog 到 manager；
GTID 模式下在 recover_master 阶段（binlog server 可达）会从 binlog server补齐差异日志；

所以，在 GTID 模式下需要使用 binlog server 来解决丢失事物的风险。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2020-10-27，如有侵权请联系 cloudcommunity@tencent.com 删除

ssh