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 [email protected]:/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 [email protected]:/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 [email protected]:/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
时间: 2024-08-03 01:16:31