mysql serverthread_MySQL 5.7 基于复制线程SQL_Thread加快恢复的尝试

1. MySQL 数据恢复常用办法

MySQL恢复的方法一般有三种：

1. 官方推荐的基于全备+binlog ， 通常做法是先恢复最近一次的全备，然后通过mysqlbiinlog --start-position --stop-position binlog.000xxx | mysql -uroot -p xxx -S database 恢复到目标数据库做恢复

2. 基于主从同步恢复数据，通常做法是先恢复最近一次的全备，然后恢复后的实例做slave 挂载到现有的master 上面，通过 start slave sql_thread until master_log_pos 恢复到故障前的一个pos。

现在尝试第三种恢复方式， 通过原来主库上面的binlog 把数据都恢复到slave 上。

处理思路：

因为relaylog和binlog本质实际上是一样的，所以是否可以利用MySQL自身的sql_thread来增量binlog

1)重新初始化一个实例，恢复全量备份文件。

2)找到第一个binlog文件的position，和剩下所有的binlog。

3)将binlog伪装成relaylog，通过sql thread增量恢复。

应用场景：

1. 最近的一次全备离故障位置比较远，通过上面两种方式的恢复时间太慢

2. 双主keepalived的集群，由于keepalived没有像MHA 那样有日志补全机制，出故障是有可能会有数据丢失的，万一同步有严重的复制延时出现故障切换到slave，这样数据就不一致，需要做日志补全

2. 实验步骤

1. 建立基于主从同步(这里实验基于传统的pos， 其实GTID 也一样可行)

M1 ：

root@localhost:mysql3307.sock [(none)]>select * from restore.t1;

+----+------+

| id | c1 |

+----+------+

| 1 | 1 |

| 2 | 3 |

| 3 | 2 |

| 4 | 3 |

| 5 | 6 |

| 6 | 7 |

| 7 | 9 |

| 10 | NULL |

| 11 | 10 |

+----+------+

9 rows in set (0.00 sec)

M2：(slave)

root@localhost:mysql3307.sock [(none)]>select * from restore.t1;

+----+------+

| id | c1 |

+----+------+

| 1 | 1 |

| 2 | 3 |

| 3 | 2 |

| 4 | 3 |

| 5 | 6 |

| 6 | 7 |

| 7 | 9 |

| 10 | NULL |

| 11 | 10 |

+----+------+

9 rows in set (0.00 sec)

root@localhost:mysql3307.sock [restore]>show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: m1

Master_User: repl

Master_Port: 3307

Connect_Retry: 60

Master_Log_File: 3307-binlog.000002

Read_Master_Log_Pos: 154

Relay_Log_File: M2-relay-bin.000004

Relay_Log_Pos: 371

Relay_Master_Log_File: 3307-binlog.000002

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 154

Rela