GTID与MHA

矫情吗；* 2022-12-02 15:05 136阅读 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完成数据同步，以加快切换速度。
    
    
    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