一次 MySQL 主从复制故障规复的过程记录

第一步：查察当前复制进度和状态

1. SHOW SLAVE STATUS\G

复制代码

重点关注以下参数：

• I/O 线程位置（Master_Log_File / Read_Master_Log_Pos）：表现 IO 线程已经从 master 的 Master_Log_File 文件中读取到 Read_Master_Log_Pos 位置，并将该位置之前的全部 event 写入本地 relay log。
  
• SQL 线程位置（Relay_Master_Log_File / Exec_Master_Log_Pos）：表现 SQL 线程已经实行到 master binlog 的哪个位置，即  文件中  之前的 event 已经在从库实行完成。
  

注意：SQL 线程实行的是本地 relay log 中的 event，但仍旧可以知道这个 event 在 master 的 binlog 中对应的位置，由于 IO 在 relay log 的 event header 里记录了这个 event 原来在 master binlog 的位置

第二步：在 Master 节点查察对应的 binlog 文件是否还存在

1. SHOW BINARY LOGS;

复制代码

第三步：克制复制并重新天生 relay log

1. STOP SLAVE;
2. RESET SLAVE;

复制代码

RESET SLAVE 会删除全部 relay log，并清空 SQL 线程的复制进度（mysql.slave_relay_log_info），但会保存 master 的毗连信息（mysql.slave_master_info）。

第四步：重新指定复制出发点

1. CHANGE MASTER TO
2. MASTER_LOG_FILE='<Relay_Master_Log_File>',
3. MASTER_LOG_POS=<Exec_Master_Log_Pos>;

复制代码

根据 SQL 线程已经实行完成的位置重新创建复制，重新实行 change master to 时，未显式指定的参数会保存原值，显式指定的参数会覆盖原有值。(永世以 SQL线程位置为准)

第五步：重新启动复制

1. START SLAVE;

复制代码

第六步：再次查察复制状态：

1. SHOW SLAVE STATUS\G

复制代码

确认：Slave_IO_Running: Yes；Slave_SQL_Running: Yes；Seconds_Behind_Master: 0 ，此时表现复制规复正常。