GTID与MHA

Posted 2020-10-07 polestar

MHA 基于binlog文件位置的复制

* Phase 3: Master Recovery Phase..
* Phase 3.1: Getting Latest Slaves Phase..
             Latest slaves (Slaves that received relay log files to the latest):
* Phase 3.2: Saving Dead Master\'s Binlog Phase..
             scp from root@192.168.0.50:/tmp/saved_master_binlog_from_192.168.0.50_3306_20140421201548.binlog to local:/var/log/masterha/app1.log/saved_master_binlog_from_192.168.0.50_3306_20140421201548.binlog succeeded.
* Phase 3.3: Determining New Master Phase.
* Phase 3.3: New Master Diff Log Generation Phase..
             scp from local:/var/log/masterha/app1.log/saved_master_binlog_from_192.168.0.50_3306_20140421201548.binlog to root@192.168.0.60:/tmp/saved_master_binlog_from_192.168.0.50_3306_20140421201548.binlog succeeded.
* Phase 3.4: Master Log Apply Phase..
* Phase 3: Master Recovery Phase completed.

* Phase 4: Slaves Recovery Phase..
* Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
* Phase 4.2: Starting Parallel Slave Log Apply Phase..

 Executed CHANGE MASTER.
* Phase 5: New master cleanup phease..

基于binlog文件位置的复制
    在Master宕机后会尝试从Master上拷贝binlog日志进行补偿　　　
    如果候选Master不拥有最新的relay log，会从拥有最新relay log的Slave上生成差异的binlog传送到候选Master并实施补偿　　
    新Master的日志补偿完成后，同样采用应用差异binlog的方式将其它Slave和新Master同步后再change master到新Master

MHA+GTID

* Phase 3: Master Recovery Phase..
* Phase 3.1: Getting Latest Slaves Phase..
* Phase 3.3: Determining New Master Phase.
* Phase 3.3: New Master Recovery Phase..
             Fetching binary logs from binlog server 10.99.73.9..
             scp from root@10.99.73.9:/data/mysql/mha/saved_binlog_binlog1_20170221174620.binlog to local:/var/log/masterha/app1/saved_binlog_10.99.73.9_binlog1_20170221174620.binlog succeeded.
             Applying differential binlog /var/log/masterha/app1/saved_binlog_10.99.73.9_binlog1_20170221174620.binlog ..

* Phase 4: Slaves Recovery Phase..             
* Phase 4.1: Starting Slaves in parallel..

* Phase 5: New master cleanup phase..

基于GTID的复制　　

    如果候选Master不拥有最新的relay log，让候选Master连上拥有最新relay log的Salve进行补偿。　　
    尝试从binlog server上拉取缺失的binlog并应用
    新Master的数据同步到最新后，让其它的Slave连上新Master并等待数据完成同步。并且可以给masterha_master_switch传入--wait_until_gtid_in_sync=1参数使其不等其它Slave完成数据同步，以加快切换速度。


GTID模式下MHA不会尝试从旧Master上拷贝binlog日志进行补偿，所以在MySQL进程crash而OS仍然健康的情况下，应尽量不要做主备切换而是原地重启MySQL，除非有其它能确保切换后不丢数据的措施             

 

参考

http://www.cnblogs.com/gomysql/p/3675429.html

https://www.ywnds.com/?p=8129

http://www.cnblogs.com/kevinhao/p/5516936.html

https://mp.weixin.qq.com/s/IF1Pld-wGW0q2NiBjMXwfg