MHA GTID based failover代码解析

墨蓝 2022-02-04 06:13 196阅读 0赞

作为以下文章的补充，说明MHA GTID based failover的处理流程。  
[http://blog.chinaunix.net/uid-20726500-id-5700631.html][http_blog.chinaunix.net_uid-20726500-id-5700631.html]  
  
MHA判断是GTID based failover需要满足下面3个条件(参考函数get\_gtid\_status)  
所有节点gtid\_mode=1  
所有节点Executed\_Gtid\_Set不为空  
至少一个节点Auto\_Position=1  
  
  
GTID based MHA故障切换

点击(此处)折叠或打开

1.  MHA::MasterFailover::main()  
    
2.  \->do\_master\_failover  
    
3.  Phase 1: Configuration Check Phase  
    
4.  \-> check\_settings：  
    
5.  check\_node\_version：查看MHA的版本信息  
    
6.  connect\_all\_and\_read\_server\_status：确认各个node的MySQL实例是否可以连接  
    
7.  get\_dead\_servers/get\_alive\_servers/get\_alive\_slaves：double check各个node的死活状态  
    
8.  start\_sql\_threads\_if：查看Slave\_SQL\_Running是否为Yes，若不是则启动SQL thread  
    
9.    
    
10. Phase 2: Dead Master Shutdown Phase：对于我们来说，唯一的作用就是stop IO thread  
    
11. \-> force\_shutdown($dead\_master)：  
    
12. stop\_io\_thread：所有slave的IO thread stop掉(将stop掉master)  
    
13. force\_shutdown\_internal(实际上就是执行配置文件中的master\_ip\_failover\_script/shutdown\_script，若无则不执行)：  
    
14. master\_ip\_failover\_script：如果设置了VIP，则首先切换VIP  
    
15. shutdown\_script：如果设置了shutdown脚本，则执行  
    
16.   
    
17. Phase 3: Master Recovery Phase  
    
18. \-> Phase 3.1: Getting Latest Slaves Phase(取得latest slave)  
    
19. read\_slave\_status：取得各个slave的binlog file/position  
    
20. check\_slave\_status：调用"SHOW SLAVE STATUS"来取得slave的如下信息：  
    
21. Slave\_IO\_State, Master\_Host,  
    
22. Master\_Port, Master\_User,  
    
23. Slave\_IO\_Running, Slave\_SQL\_Running,  
    
24. Master\_Log\_File, Read\_Master\_Log\_Pos,  
    
25. Relay\_Master\_Log\_File, Last\_Errno,  
    
26. Last\_Error, Exec\_Master\_Log\_Pos,  
    
27. Relay\_Log\_File, Relay\_Log\_Pos,  
    
28. Seconds\_Behind\_Master, Retrieved\_Gtid\_Set,  
    
29. Executed\_Gtid\_Set, Auto\_Position  
    
30. Replicate\_Do\_DB, Replicate\_Ignore\_DB, Replicate\_Do\_Table,  
    
31. Replicate\_Ignore\_Table, Replicate\_Wild\_Do\_Table,  
    
32. Replicate\_Wild\_Ignore\_Table  
    
33. identify\_latest\_slaves：  
    
34. 通过比较各个slave中的Master\_Log\_File/Read\_Master\_Log\_Pos，来找到latest的slave  
    
35. identify\_oldest\_slaves：  
    
36. 通过比较各个slave中的Master\_Log\_File/Read\_Master\_Log\_Pos，来找到oldest的slave  
    
37.   
    
38. \-> Phase 3.2: Determining New Master Phase  
    
39. get\_most\_advanced\_latest\_slave:找到(Relay\_Master\_Log\_File,Exec\_Master\_Log\_Pos)最靠前的Slave  
    
40.   
    
41. select\_new\_master：选出新的master节点  
    
42. If preferred node is specified, one of active preferred nodes will be new master.  
    
43. If the latest server behinds too much (i.e. stopping sql thread for online backups),  
    
44. we should not use it as a new master, we should fetch relay log there. Even though preferred  
    
45. master is configured, it does not become a master if it's far behind.  
    get\_candidate\_masters:  
    就是配置文件中配置了candidate\_master>0的节点  
    get\_bad\_candidate\_masters：  
    \# The following servers can not be master:  
    \# - dead servers  
    \# - Set no\_master in conf files (i.e. DR servers)  
    \# - log\_bin is disabled  
    \# - Major version is not the oldest  
    \# - too much replication delay(slave与master的binlog position差距大于100000000)  
    Searching from candidate\_master slaves which have received the latest relay log events  
    if NOT FOUND：  
    Searching from all candidate\_master slaves  
    if NOT FOUND:  
    Searching from all slaves which have received the latest relay log events  
    if NOT FOUND:  
    Searching from all slaves  
      
    \-> Phase 3.3: Phase 3.3: New Master Recovery Phase  
    recover\_master\_gtid\_internal:  
    wait\_until\_relay\_log\_applied  
    stop\_slave  
    如果new master不是拥有最新relay的Slave  
    $latest\_slave->wait\_until\_relay\_log\_applied:等待直到最新relay的Slave上Exec\_Master\_Log\_Pos等于Read\_Master\_Log\_Pos  
    change\_master\_and\_start\_slave( $target, $latest\_slave)  
    wait\_until\_in\_sync( $target, $latest\_slave )  
    save\_from\_binlog\_server:  
    遍历所有binary server，执行save\_binary\_logs --command=save获取后面的binlog  
    apply\_binlog\_to\_master:  
    应用从binary server上获取的binlog(如果有的话)  
    如果设置了master\_ip\_failover\_script，调用$master\_ip\_failover\_script --command=start进行启用vip  
    如果未设置skip\_disable\_read\_only，设置read\_only=0  
      
    Phase 4: Slaves Recovery Phase  
    recover\_slaves\_gtid\_internal  
    \-> Phase 4.1: Starting Slaves in parallel  
    对所有Slave执行change\_master\_and\_start\_slave  
    如果设置了wait\_until\_gtid\_in\_sync，通过"SELECT WAIT\_UNTIL\_SQL\_THREAD\_AFTER\_GTIDS(?,0)"等待Slave数据同步  
      
    Phase 5: New master cleanup phase  
    reset\_slave\_on\_new\_master  
    清理New Master其实就是重置slave info，即取消原来的Slave信息。至此整个Master故障切换过程完成

启用GTID时的在线切换流程和不启用GTID时一样（唯一不同的是执行的change master语句），所以省略。

[http_blog.chinaunix.net_uid-20726500-id-5700631.html]: http://blog.chinaunix.net/uid-20726500-id-5700631.html