GTID与MHA

末蓝、 2022-12-06 01:22 93阅读 0赞

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完成数据同步，以加快切换速度。  
      
参考:http://www.cnblogs.com/gomysql/p/3675429.html

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

http://www.cnblogs.com/kevinhao/p/5516936.htmlhttps://mp.weixin.qq.com/s/IF1Pld-wGW0q2NiBjMXwfg

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