作者：王向
爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
前言
MHA 进去将近 10 年的工夫，作为一个开源产品，能活这么久，还有这么多人追捧。基本上能够说是一种 mysql 中的规范解决方案。
不过 MHA 曾经不适宜这个时代了。。。然而这不影响咱们对他进行一波钻研。
产生 master crash 源码剖析
上面的内容比拟淦，没有趣味的同学间接跳到：总结。
对于源码能够间接去 github.com 而后搜 MHA。
sub main { ..... eval { $error_code = do_master_failover(); }; if ($@) { $error_code = 1; } if ($error_code) { finalize_on_error(); } return $error_code; .... sub do_master_failover { my $error_code = 1; #错误码 my ( $dead_master, $new_master ); # $dead_master 逝世的master # $new_master 新生的master eval { # 第一步： 查看配置 my ( $servers_config_ref, $binlog_server_ref ) = init_config(); $log->info("Starting master failover."); $log->info(); $log->info("* Phase 1: Configuration Check Phase..\n"); $log->info(); # 初始化 Binlog server MHA::ServerManager::init_binlog_server( $binlog_server_ref, $log ); # ssh_check_simple 查看SSH的连通性 # get_node_version 获取node的版本号 # 理论应用命令拿到版本号 apply_diff_relay_logs --version # 拿到版本号 Binlog server可达，否则不可达 $dead_master = check_settings($servers_config_ref); # MHA::ManagerUtil::check_node_version($log); # 查看mha的版本信息 # 后果1：没有装置mha # 后果2： $node_version < $MHA::ManagerConst::NODE_MIN_VERSION # our $NODE_MIN_VERSION = '0.54'; # 节点版本号必须等于或者高于0.54 # $_server_manager->connect_all_and_read_server_status(); # 查看各实例是否能够连贯 # my @dead_servers = $_server_manager->get_dead_servers(); # my @alive_servers = $_server_manager->get_alive_servers(); # my @alive_slaves = $_server_manager->get_alive_slaves(); # get_dead_servers/get_alive_servers/get_alive_slaves：double check各个node的死活状态 # g$_server_manager->start_sql_threads_if(); 查看Slave_SQL_Running是否为Yes，若不是则启动SQL thread if ( $_server_manager->is_gtid_auto_pos_enabled() ) { $log->info("Starting GTID based failover."); } else { $_server_manager->force_disable_log_bin_if_auto_pos_disabled(); $log->info("Starting Non-GTID based failover."); } $log->info(); $log->info("** Phase 1: Configuration Check Phase completed.\n"); $log->info(); # 第二步：敞开以后失败的IO复制线程，并执行脚本切换VIP $log->info("* Phase 2: Dead Master Shutdown Phase..\n"); $log->info(); force_shutdown($dead_master); # 判断ssh是否可达 # MHA::HealthCheck::ssh_check_simple() # MHA::ManagerUtil::get_node_version() # my $rc = $target->stop_io_thread(); 进行所有slave复制IO线程 # force_shutdown_internal() 执行配置文件中的master_ip_failover_script/shutdown_script，如果没有就不执行 # master_ip_failover_script：如果设置了VIP，则首先切换VIP # shutdown_script：如果设置了shutdown脚本，则执行shutdown脚本 $log->info("* Phase 2: Dead Master Shutdown Phase completed.\n"); $log->info(); # 第三步 新主复原 $log->info("* Phase 3: Master Recovery Phase..\n"); $log->info(); # 获取新的主从信息 $log->info("* Phase 3.1: Getting Latest Slaves Phase..\n"); $log->info(); check_set_latest_slaves(); # $_server_manager->read_slave_status(); 获取各个slave的binlog file和position点 # my %status = $target->check_slave_status(); 执行show slave status来获取从库信息 Slave_IO_State, Master_Host, Master_Port, Master_User, Slave_IO_Running, Slave_SQL_Running, Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File, Last_Errno, Last_Error, Exec_Master_Log_Pos, Relay_Log_File, Relay_Log_Pos, Seconds_Behind_Master, Retrieved_Gtid_Set, Executed_Gtid_Set, Auto_Position, Replicate_Do_DB, Replicate_Ignore_DB, Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table #其中重要的信息 $target->{Relay_Master_Log_File} = $status{Relay_Master_Log_File}; $target->{Exec_Master_Log_Pos} = $status{Exec_Master_Log_Pos}; $target->{Relay_Log_File} = $status{Relay_Log_File}; $target->{Relay_Log_Pos} = $status{Relay_Log_Pos}; # $_server_manager->identify_latest_slaves(); 比拟各个slave的Master_Log_File和Read_Master_Log_Pos,寻找latest的slave # $_server_manager->identify_oldest_slaves(); 比拟各个slave中的Master_Log_File和Read_Master_Log_Pos,寻找Oldest的slave if ( !$_server_manager->is_gtid_auto_pos_enabled() ) { $log->info(); # 进行binlog补充 $log->info("* Phase 3.2: Saving Dead Master's Binlog Phase..\n"); $log->info(); save_master_binlog($dead_master); # 判断dead master是否能够ssh连贯 # if ( $_real_ssh_reachable && !$g_skip_save_master_binlog ) { # 如果dead master能够ssh连贯 # MHA::ManagerUtil::check_node_version(); # my $latest_pos = ( $_server_manager->get_latest_slaves() )[0]->{Read_Master_Log_Pos}; save_master_binlog_internal( $latest_file, $latest_pos, $dead_master, ); # 应用node节点的save_binary_logs脚本在dead master上做拷贝 # save_binary_logs --command=save --start_file=$master_log_file --start_pos=$read_master_log_pos --binlog_dir=$dead_master->{master_binlog_dir} --output_file=$_diff_binary_log_remote --handle_raw_binlog=$dead_master->{handle_raw_binlog} --disable_log_bin=$dead_master->{disable_log_bin} --manager_version=$MHA::ManagerConst::VERSION"; # generate_diff_binary_log()： # $_binlog_manager->concat_all_binlogs_from($start_binlog_file, $start_binlog_pos, $out_diff_file) # dump_binlog() 拷贝binlog文件到到manage节点的manager_workdir目录下，如果dead master无奈ssh登录，则master上未同步到slave的txn失落 } $log->info(); # 确定新主 $log->info("* Phase 3.3: Determining New Master Phase..\n"); $log->info(); my $latest_base_slave; if ( $_server_manager->is_gtid_auto_pos_enabled() ) { $latest_base_slave = $_server_manager->get_most_advanced_latest_slave(); } else { $latest_base_slave = find_latest_base_slave($dead_master); #寻找最新的有所有中继日志的slave，用于复原其余slave # my $latest_base_slave = find_latest_base_slave_internal(); # my $oldest_mlf = $oldest_slave->{Master_Log_File}; # my $oldest_mlp = $oldest_slave->{Read_Master_Log_Pos}; # my $latest_mlf = $latest_slaves[0]->{Master_Log_File}; # my $latest_mlp = $latest_slaves[0]->{Read_Master_Log_Pos}; # if ($_server_manager->pos_cmp( $oldest_mlf, $oldest_mlp, $latest_mlf,$latest_mlp ) >= 0 # 判断latest和oldest slave上binlog地位是不是雷同，雷同就不须要同步relay log # apply_diff_relay_logs --command=find --latest # 查看latest slave中是否有oldest短少的relay log，若无则持续,否则failover失败 # 查找的办法：逆序的读latest slave的relay log文件，始终找到binlog file的position为止 } $new_master = select_new_master( $dead_master, $latest_base_slave ); #选出新的master节点 # 比拟master_log_file:read_master_log_pos # 辨认优先从库，在线的并带有candidate_master标记 # 辨认应该疏忽的从库，带有no_master标记、或者未开启log_bin、与最新从库相比数据提早比拟大(slave与master的binlog position差距大于100000000) # 抉择优先级顺次为：优先列表、最新从库列表、所有从库列表，但肯定排除疏忽列表 # 查看新老主库的复制过滤规定是否统一Replicate_Do_DB,Replicate_Ignore_DB,Replicate_Do_Table,Replicate_Ignore_Table my ( $master_log_file, $master_log_pos, $exec_gtid_set ) = recover_master( $dead_master, $new_master, $latest_base_slave, $binlog_server_ref ); $new_master->{activated} = 1; $log->info("* Phase 3: Master Recovery Phase completed.\n"); $log->info(); # 复原从库 相似独自复原主库的过程 $log->info("* Phase 4: Slaves Recovery Phase..\n"); $log->info(); $error_code = recover_slaves( $dead_master, $new_master, $latest_base_slave, $master_log_file, $master_log_pos, $exec_gtid_set ); # 中继弥补（生成Slave与New Slave之间的差别日志，将该日志拷贝到各Slave的工作目录下），指向新主库&启动复制（change_master_and_start_slave），清理新主库的slave复制通道（reset slave all） if ( $g_remove_dead_master_conf && $error_code == 0 ) { MHA::Config::delete_block_and_save( $g_config_file, $dead_master->{id}, $log ); } cleanup(); }; if ($@) { if ( $dead_master && $dead_master->{not_error} ) { $log->info($@); } else { MHA::ManagerUtil::print_error( "Got ERROR: $@", $log ); $mail_body .= "Got Error so couldn't continue failover from here.\n" if ($mail_body); } $_server_manager->disconnect_all() if ($_server_manager); undef $@; } eval { send_report( $dead_master, $new_master ); MHA::NodeUtil::drop_file_if( $_status_handler->{status_file} ) unless ($error_code); if ($_create_error_file) { MHA::NodeUtil::create_file_if($_failover_error_file); } }; if ($@) { MHA::ManagerUtil::print_error( "Got ERROR on final reporting: $@", $log ); undef $@; } return $error_code;}总结
切换过程：
1. 查看配置
- 查看 mha node 的节点版本信息（get_node_version，理论应用 apply_diff_relay_logs --version 命令）
- 查看所有 node 节点的 SSH 的连通性
- 查看所有 node 节点的存活状态
- 查看所有从库的 slave sql 线程是否曾经启动，没有启动则启动
2. 敞开以后失败的 IO 复制线程，并执行脚本切换 VIP
- 查看所有 node 节点的 SSH 的连通性
- 进行所有从库的 slave io 线程，只有有一个在线从库的 salve io 线程进行失败，那么就终止切换
- 执行 master_ip_failover_script，保障解体主库所在主机的 VIP 失活防脑裂，并执行脚本切换 VIP
3. 新主复原
获取新的主从信息
- 获取各个 slave 的复制信息（show slave status）
- 获取复制提早最小的从库、复制提早最大的从库
- 如果没有用来弥补的基准从库，终止切换
查看逝世的 master 的 SSH 的连通性
- 不可达，就会失落 binlog
- 可达，执行 save_binary_logs --command=save，将保留后的 binlog 拷贝到 manage 节点的 manager_workdir 目录下
4. 抉择新主库
- 比拟 master_log_file:read_master_log_pos
- 辨认优先从库，在线的并带有 candidate_master 标记
- 辨认应该疏忽的从库，带有 no_master 标记、或者未开启 log_bin、与最新从库相比数据提早比拟大（slave 与 master 的 binlog position 差距大于 100000000）
- 抉择优先级顺次为：优先列表、最新从库列表、所有从库列表，但肯定排除疏忽列表
- 查看新老主库的复制过滤规定是否统一 Replicate_Do_DB,Replicate_Ignore_DB,Replicate_Do_Table,Replicate_Ignore_Table
复原新主库
- 新主库落后于最新从库，那么 ssh 连贯上最新从库，执行 apply_diff_relay_logs --command=generate_and_send
- 期待新主库上曾经有的 relaylog 都重放结束，进行 slave sql 线程
- 执行主控机上的 master_ip_failover --command=start 脚本，激活新主库的 VIP
- 敞开新主库的只读，开启可写模式
5. 复原从库 & 清理新主库
复原新从库
- 中继弥补（生成 Slave 与 New Slave 之间的差别日志，将该日志拷贝到各 Slave 的工作目录下）
- 指向新主库 & 启动复制（change_master_and_start_slave）
- 清理新主库的 slave 复制通道（reset slave all）