MySQL Master High Available 源码篇-阿里云开发者社区

MasterFailover (Non-GTID)

MHA::MasterFailover::main()->do_master_failover

failover_non_gtid

Phase 1: Configuration Check Phase

init_config(): 初始化配置
MHA::ServerManager::init_binlog_server: 初始化binlog server
check_settings()

a. check_node_version(): 查看MHA的版本
b. connect_all_and_read_server_status(): 检测确认各个Node节点MySQL是否可以连接
c. get_dead_servers()，get_alive_servers()，get_alive_slaves()：再次检测一次node节点的状态
d. print_dead_servers(): 是否挂掉的master是否是当前的master
e. MHA::DBHelper::check_connection_fast_util : 快速判断dead server，是否真的挂了，如果ping_type=insert，不会double check
f. MHA::NodeUtil::drop_file_if($_failover_error_file|$_failover_complete_file): 检测上次的failover文件
g. 如果上次failover的时间在8小时以内，那么这次就不会failover,除非配置了额外的参数
h. start_sql_threads_if(): 查看所有slave的Slave_SQL_Running是否为Yes，若不是则启动SQL thread

is_gtid_auto_pos_enabled(): 判断是否是GTID模式

Phase 2: Dead Master Shutdown Phase..

force_shutdown($dead_master):

a. stop_io_thread(): stop所有slave的IO_thread
b. force_shutdown_internal($dead_master):
  b_1. master_ip_failover_script: 如果有这个脚本，则执行里面的逻辑(比如：切换vip)
  b_2. shutdown_script：如果有这个脚本，则执行里面的逻辑（比如：Power off 服务器）

Phase 3: Master Recovery Phase..

Phase 3.1: Getting Latest Slaves Phase..

* check_set_latest_slaves()
  a. read_slave_status(): 获取所有show slave status 信息
  b. identify_latest_slaves(): 找到最新的slave是哪个
  c. identify_oldest_slaves(): 找到最老的slave是哪个

Phase 3.2: Saving Dead Master's Binlog Phase..

* save_master_binlog($dead_master);
  -> 如果dead master可以ssh，那么
       b_1_1. save_master_binlog_internal: 用node节点save_binary_logs脚本拷贝相应binlog到manager
           diff_binary_log 生产差异binlog日志
       b_1_2. file_copy: 将差异binlog拷贝到manager节点的 manager_workdir目录下
  -> 如果dead master不可以ssh
       b_1_3. 那么差异日志就会丢失

Phase 3.3: Determining New Master Phase..

b. 如果GTID auto_pos没有打开，调用find_latest_base_slave()
    b_1. find_latest_base_slave_internal: 寻找拥有所有relay-log的最新slave，如果没有，则failover失败
            b_1_1. find_slave_with_all_relay_logs:
                    b_1_1_1. apply_diff_relay_logs: 查看最新的slave是否有其他slave缺失的relay-log

c. select_new_master: 选举new master
    c_1. MHA::ServerManager::select_new_master:
       #If preferred node is specified, one of active preferred nodes will be new master.
       #If the latest server behinds too much (i.e. stopping sql thread for online backups), we should not use it as a new master, but we should fetch relay log there
       #Even though preferred master is configured, it does not become a master if it's far behind

       get_candidate_masters(): 获取配置中候选节点
       get_bad_candidate_masters(): 以下条件不能成为候选master
           # dead server
           # no_master >= 1
           # log_bin=0
           # oldest_major_version=0
           # check_slave_delay: 检查是否延迟非常厉害（可以通过设置no_check_delay忽略）
               {Exec_Master_Log_Pos} + 100000000 只要binlog position不超过100000000 就行
       选举流程： 先看candidate_master，然后找 latest slave, 然后再随机挑选

Phase 3.3(3.4): New Master Diff Log Generation Phase..

* recover_master_internal
         recover_relay_logs:
               判断new master是否为最新的slave，如果不是，则生产差异relay logs，并发送给新master
         recover_master_internal:
               将之前生产的dead master上的binlog传送给new master

Phase 3.4: Master Log Apply Phase..

* apply_diff:
       a. wait_until_relay_log_applied: 直到new master完成所有relay log，否则一直等待
       b. 判断Exec_Master_Log_Pos == Read_Master_Log_Pos, 如果不等，那么生产差异日志：
                   save_binary_logs --command=save
       c. apply_diff_relay_logs --command=apply：对new master进行恢复
                   c_1. exec_diff:Exec_Master_Log_Pos和Read_Master_Log_Pos的差异日志
                   c_2. read_diff:new master与lastest slave的relay log的差异日志
                   c_3. binlog_diff:lastest slave与daed master之间的binlog差异日志
* 如果设置了master_ip_failover_script脚本，那么会执行这里面的脚本（一般用来漂移vip）

* disable_read_only(): 允许new master可写

Phase 4: Slaves Recovery Phase..

recover_slaves_internal

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..

recover_all_slaves_relay_logs: 生成Slave与New Slave之间的差异日志，并将该日志拷贝到各Slave的工作目录下

Phase 4.2: Starting Parallel Slave Log Apply Phase..

* recover_slave:
    对每个slave进行恢复，跟以上Phase 3.4: Master Log Apply Phase中的 apply_diff一样
* change_master_and_start_slave：
    重新指向到new master，并且start slave

Phase 5: New master cleanup phase..

reset_slave_on_new_master

在new master上执行reset slave all;

MasterFailover (GTID)

failover_gitd

Phase 1: Configuration Check Phase

init_config(): 初始化配置
MHA::ServerManager::init_binlog_server: 初始化binlog server
check_settings()

a. check_node_version(): 查看MHA的版本
b. connect_all_and_read_server_status(): 检测确认各个Node节点MySQL是否可以连接
c. get_dead_servers()，get_alive_servers()，get_alive_slaves()：再次检测一次node节点的状态
d. print_dead_servers(): 是否挂掉的master是否是当前的master
e. MHA::DBHelper::check_connection_fast_util : 快速判断dead server，是否真的挂了，如果ping_type=insert，不会double check
f. MHA::NodeUtil::drop_file_if($_failover_error_file|$_failover_complete_file): 检测上次的failover文件
g. 如果上次failover的时间在8小时以内，那么这次就不会failover,除非配置了额外的参数
h. start_sql_threads_if(): 查看所有slave的Slave_SQL_Running是否为Yes，若不是则启动SQL thread

is_gtid_auto_pos_enabled(): 判断是否是GTID模式

Phase 2: Dead Master Shutdown Phase completed.

force_shutdown($dead_master):

a. stop_io_thread(): stop所有slave的IO_thread
b. force_shutdown_internal($dead_master):
  b_1. master_ip_failover_script: 如果有这个脚本，则执行里面的逻辑(比如：切换vip)
  b_2. shutdown_script：如果有这个脚本，则执行里面的逻辑（比如：Power off 服务器）

Phase 3: Master Recovery Phase..

Phase 3.1: Getting Latest Slaves Phase..

* check_set_latest_slaves()
  a. read_slave_status(): 获取所有show slave status 信息
  b. identify_latest_slaves(): 找到最新的slave是哪个
  c. identify_oldest_slaves(): 找到最老的slave是哪个

Phase 3.2: Saving Dead Master's Binlog Phase.. (GTID 模式下没有这一步)
Phase 3.3: Determining New Master Phase..

get_most_advanced_latest_slave(): 获取最新的slave

c. select_new_master: 选举new master
    c_1. MHA::ServerManager::select_new_master:
       #If preferred node is specified, one of active preferred nodes will be new master.
       #If the latest server behinds too much (i.e. stopping sql thread for online backups), we should not use it as a new master, but we should fetch relay log there
       #Even though preferred master is configured, it does not become a master if it's far behind

       get_candidate_masters(): 获取配置中候选节点
       get_bad_candidate_masters(): 以下条件不能成为候选master
           # dead server
           # no_master >= 1
           # log_bin=0
           # oldest_major_version=0
           # check_slave_delay: 检查是否延迟非常厉害（可以通过设置no_check_delay忽略）
               {Exec_Master_Log_Pos} + 100000000 只要binlog position不超过100000000 就行
       选举流程： 先看candidate_master，然后找 latest slave, 然后再随机挑选

Phase 3.3: New Master Recovery Phase..

* recover_master_gtid_internal:
    wait_until_relay_log_applied: 候选master等待所有relay-log都应用完
    如果候选master不是最新的slave：
        $latest_slave->wait_until_relay_log_applied($log): 最新的slave应用完所有的relay-log
        change_master_and_start_slave ： 让候选master同步到latest master，追上latest 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

Phase 4: Slaves Recovery Phase..

Phase 4.1: Starting Slaves in parallel..

* recover_slaves_gtid_internal:
    change_master_and_start_slave: 因为master已经恢复，那么slave直接change master auto_pos=1 的模式就可以恢复
    gtid_wait：用此等待同步全部追上

Phase 5: New master cleanup phase..

reset_slave_on_new_master

在new master上执行reset slave all;

MasterRotate （Non-GTID）

Phase 1: Configuration Check Phase

do_master_online_switch
identify_orig_master

* read_config():
    Reading default configuration from /etc/masterha_default.cnf..
    Reading application default configuration from /etc/app1.cnf..
    Reading server configuration from /etc/app1.cnf..

* connect_all_and_read_server_status:
    connect_check: 首先进行connect check，确保各个server的MySQL服务都正常
    connect_and_get_status:
            获取MySQL实例的server_id/mysql_version/log_bin..等信息
            通过执行show slave status，获取当前的master节点。如果输出为空，说明当前节点是master节点( 0.56已经不是这么判断了，已经支持multi master)
    validate_current_master：取得master节点的信息，并判断配置的正确性
    check是否有server down，若有则退出rotate
    check master alive or not，若dead则退出rotate
    check_repl_priv：
        查看用户是否有replication的权限
    获取monitor_advisory_lock，以保证当前没有其他的monitor进程在master上运行
        执行：SELECT GET_LOCK('MHA_Master_High_Availability_Monitor', ?) AS Value
    获取failover_advisory_lock，以保证当前没有其他的failover进程在slave上运行
        执行：SELECT GET_LOCK('MHA_Master_High_Availability_Failover', ?) AS Value
    check_replication_health:
        执行：SHOW SLAVE STATUS来判断如下状态：current_slave_position/has_replication_problem
        其中，has_replication_problem具体check如下内容：IO线程/SQL线程/Seconds_Behind_Master(1s)
    get_running_update_threads：
        使用show processlist来查询当前有没有执行update的线程存在，若有则退出switch
    $self->validate_current_master():
        检查是否是GTID模式

identify_new_master

  set_latest_slaves：当前的slave节点都是latest slave
   select_new_master: 选举new master
    c_1. MHA::ServerManager::select_new_master:
       #If preferred node is specified, one of active preferred nodes will be new master.
       #If the latest server behinds too much (i.e. stopping sql thread for online backups), we should not use it as a new master, but we should fetch relay log there
       #Even though preferred master is configured, it does not become a master if it's far behind

       get_candidate_masters(): 获取配置中候选节点
       get_bad_candidate_masters(): 以下条件不能成为候选master
           # dead server
           # no_master >= 1
           # log_bin=0
           # oldest_major_version=0
           # check_slave_delay: 检查是否延迟非常厉害（可以通过设置no_check_delay忽略）
               {Exec_Master_Log_Pos} + 100000000 只要binlog position不超过100000000 就行
       选举流程： 先看candidate_master，然后找 latest slave, 然后再随机挑选

Phase 2: Rejecting updates Phase

reject_update

* lock table来reject write binlog
      调用master_ip_online_change_script --command=stop
      如果MHA的配置文件中设置了"master_ip_online_change_script"参数，则执行该脚本来disable writes on the current master
      该脚本在使用了vip的时候，在origin master上删除vip{可选}
      reconnect：确保当前与master的连接正常
      lock_all_tables：执行FLUSH TABLES WITH READ LOCK，来lock table
      check_binlog_stop：连续两次show master status，来判断写binlog是否已经停止

read_slave_status


get_alive_slaves：
  check_slave_status：调用"SHOW SLAVE STATUS"来取得slave的信息：

switch_master

switch_master_internal：
    master_pos_wait：调用select master_pos_wait函数，等待主从同步完成
    get_new_master_binlog_position：通过'show master status'来获取
Allow write access on the new master：
    调用master_ip_online_change_script --command=start ...，将vip指向new master
disable_read_only：
    在新master上执行：SET GLOBAL read_only=0

switch_slaves

switch_slaves_internal：
    change_master_and_start_slave
        change_master：
        start_slave：
unlock_tables:在orig master上执行unlock table

Phase 5: New master cleanup phase

reset_slave_on_new_master
release_failover_advisory_lock

MasterRotate （GTID）

GTID模式的online switch 和 non-GTID 流程一样，除了在change_master_and_start_slave 不一样之外

GTID的小问题

今天测试了一把GTID的在线切换，遇到的问题非常诡异

问题：新搭建了一组group，做MHA在线切换，结果却导致环境混乱。

命令：masterha_master_switch --master_state=alive --conf=/etc/app1.cnf  --orig_master_is_new_slave --interactive=0

A（master），B（candidate master），C 一组复制环境，执行在线切换后，C竟然还同步在A上
    B(master)
        -> A(slave) -> C(slave)  --错误案例

正确的结果应该是：
    B(master)
        -> A(slave)
        -> C(slave)

看了MHA的切换日志，都是正常的，Switching master to xx completed successfully.

这样只能翻翻源码，果然，很快就找到了问题所在：

MHA::ServerManager->is_gtid_auto_pos_enabled->get_gtid_status()

sub get_gtid_status($) {
  my $self    = shift;
  my @servers = $self->get_alive_servers();
  my @slaves  = $self->get_alive_slaves();
  return 0 if ( $#servers < 0 );
  foreach (@servers) {
    return 0 unless ( $_->{has_gtid} );
  }
  foreach (@slaves) {
    return 0 unless ( $_->{Executed_Gtid_Set} );    -- 如果show slave status中没有执行过任何Executed_Gtid_Set，那么会认为是非GTID模式
  }
  foreach (@slaves) {
    return 1
      if ( defined( $_->{Auto_Position} )
      && $_->{Auto_Position} == 1 );
    return 1 if ( $_->{use_gtid_auto_pos} );
  }
  return 2;
}

* 解决方案也很简单：
1）因为没有执行过任何事物，那就执行一条呗
2）修改源码，将这一步验证独钓即可。

实时证明，以上两种都可以验证通过

重点需要注意的地方

mha with not binlog server

* 根据上述源码分析得到，如果没有配置binlog server的 GTID 模式failover，会导致数据丢失，即使master ssh可达

* 通过测试，的确在old master SSH可达的情况下，它也不会去save binlog，所以GTID和non-GTID模式的区别比较大。

* 解决的方案就是： 配置Binlog Server

/etc/app1.cnf

[server default]
remote_workdir=/var/log/masterha/app1
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/app1.log

[server1]
hostname=host1
candidate_master=1
check_repl_delay=0

[server2]
hostname=host2
candidate_master=1
check_repl_delay=0

[server3]
hostname=host3
no_master=1
check_repl_delay=0

[binlog1]
hostname=host1 --注意：这里既可以设置master为binlog server，也可以设置其他专用的binlog server

常用配置

/etc/app1.cnf

[server default]
remote_workdir=/var/log/masterha/app1
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/app1.log

[server1]
hostname=host1
candidate_master=1 --表示候选 master
check_repl_delay=0 --当 slave 有延迟的时候,如果没有这个参数,会失败

[server2]
hostname=host2
candidate_master=1
check_repl_delay=0

[server3]
hostname=host3
no_master=1 --永远不会成为new master
check_repl_delay=0
ignore_fail=1  -- 如果不设置为1，那么如果server3有问题，切换会失败

[binlog1]
hostname=host1 --注意：这里既可以设置master为binlog server，也可以设置其他专用的binlog server

常用命令

masterha_check_repl --conf=/etc/app1.cnf
masterha_check_status --conf=/etc/app1.cnf
masterha_stop --conf=/etc/app1.cnf
masterha_ssh_check --conf=/etc/app1.cnf
masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host_1 --interactive=1 --ignore_last_failover
masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host_1 --interactive=0 --ignore_last_failover
masterha_master_switch --master_state=alive --conf=/etc/app1.cnf  --orig_master_is_new_slave --interactive=0 --running_updates_limit=10000
masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host_1 --interactive=1 --ignore_last_failover --new_master_host=host_2
nohup masterha_manager --conf=/etc/app1.cnf --last_failover_minute=1 --ignore_last_failover &

特别的问题

M,(S1,S2)结构，如果S1是latest slave，如果master挂了，刚好S1的purge-relay-log的job也跑了，这样还能愉快的failover吗？

* 疑问
1. 大家都知道，S1，S2之间补数据，是通过relay-log来的，用最新slave的relay-log去补齐落后slave的日志，以达到数据一致。
2. 如果S1的relay log 恰好被purge了，怎么办呢？那岂不是S2的数据会丢失掉？

* 解答
1. 这的确是个好问题，这样听下去的确会导致数据丢失。
2. 但是MHA的purge有个机制，就是即便执行purge脚本，也会保留exec_master_pos + 1000000000个event，也就是说purge的时候，会保留一部分relay 日志
3. 所以由此引发几个问题和解答
    a）如果S1和S2之间的延迟差距超过这个范围，那么肯定是丢数据的
    b）如果S1和S2之间的延迟差距在这个范围之内，那么就不会丢数据

* 总结
1. 如果要保证数据的完全一致，那么no_check_delay 必须设置off
2. GTID就不会有这样的问题，只要binlog保留的足够就行

MySQL Master High Available 源码篇

MasterFailover (Non-GTID)

Phase 1: Configuration Check Phase

Phase 2: Dead Master Shutdown Phase..

Phase 3: Master Recovery Phase..

Phase 4: Slaves Recovery Phase..

Phase 5: New master cleanup phase..

MasterFailover (GTID)

Phase 1: Configuration Check Phase

Phase 2: Dead Master Shutdown Phase completed.

Phase 3: Master Recovery Phase..

Phase 4: Slaves Recovery Phase..

Phase 5: New master cleanup phase..

MasterRotate （Non-GTID）

Phase 1: Configuration Check Phase

Phase 2: Rejecting updates Phase

Phase 5: New master cleanup phase

MasterRotate （GTID）

GTID的小问题

重点需要注意的地方

特别的问题

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

MySQL Master High Available 源码篇

MasterFailover (Non-GTID)

Phase 1: Configuration Check Phase

Phase 2: Dead Master Shutdown Phase..

Phase 3: Master Recovery Phase..

Phase 4: Slaves Recovery Phase..

Phase 5: New master cleanup phase..

MasterFailover (GTID)

Phase 1: Configuration Check Phase

Phase 2: Dead Master Shutdown Phase completed.

Phase 3: Master Recovery Phase..

Phase 4: Slaves Recovery Phase..

Phase 5: New master cleanup phase..

MasterRotate （Non-GTID）

Phase 1: Configuration Check Phase

Phase 2: Rejecting updates Phase

Phase 5: New master cleanup phase

MasterRotate （GTID）

GTID的小问题

重点需要注意的地方

特别的问题

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像