背景

相信大家的项目都是使用主从模式的数据库吧，我们在开发中可能要维护主从的情况比较少，只需要写增删改查就够了。但是最近自己经历一次主从异常的恢复。也算是有一份不一样的收获吧。

由于项目使用MySQL主从备份模式，在某一天因为数据异常导致数据库主从断开，钉钉也开始报警;

从钉钉告警可以知道，从库的SQL线程断了，原因在于从库没有该条数据，但是现在需要从库更新这条数据，导致的报错。

恢复过程

想要恢复主从，但是没有专业的DBA来恢复。怎么办？只有开发上场了恢复了。

跳过异常点

最初我的思路是：

跳过异常的数据点

说干就干

这里我先在从库中操作：

STOP SLAVE;

然后我们跳过有异常的这条记录：

SET @@SESSION.GTID_NEXT = '2c81fd96-5d38-11e9-99fa-005056af5ff7:109627190';

重新启动从库线程:

START SLAVE;

查看从库还有没有异常信息：

select LAST_ERROR_MESSAGE from performance_schema.replication_applier_status_by_worker 
order by LAST_ERROR_TIMESTAMP desc limit 1;

发现又出现新的错误：

Worker 1 failed executing transaction '2c81fd96-5d38-11e9-99fa-005056af5ff7:108617672' at master log mysql-bin.001581, end_log_pos 930051924; Could not execute Update_rows event on table rmp.rmp_equip_info; Can't find record in 'rmp_equip_info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.001581, end_log_pos 930051924

然后我们有跳过上面的错误点，发现还是会出现新的错误。最后干脆批量跳过。

SET @@GLOBAL.GTID_PURGED = '2c81fd96-5d38-11e9-99fa-005056af5ff7:90355471-109617802';

这里我将90355471-109617802的记录点都跳过。查看从库状态，发现IO线程和SQL线程都好了。终于可以放松一会了。

完整的恢复

结果第二天发现，又报错了。看来不能用跳过的方法了。因此我准备重新来一次完整的同步。

主要过程为：

• 备份主库数据；
• 重置主库和从库服务；
• 删除从库数据，并将主库备份的数据还原到从库库中；
• 重新开启主从同步；

备份主库

在备份数据前我们需要给主数据库开启只读功能。

在主库中操作

FLUSH TABLES WITH READ LOCK;

然后备份数据：

mysqldump -hlocalhost -uroot -P3306 -pxxxxx  rxx > ./rxx.sql

这里我们指定database，如rxx。

等待了30分钟左右，数据备份完毕，看一下sql文件，大概36GB左右。

然后将备份的sql文件拷贝到从库中：

scp ./rmp.sql sysadmin@10.xx.xx.xxx:/home/sysadmin/lvshen

现在将master服务重置（主库中操作）：

RESET MASTER;

解锁主库：

UNLOCK TABLES;

接下来需要在从库中操作了。

先删掉从库上面的数据库：

DROP DATABASE xxx;

然后创建一个新的库 xxx：

create database xxx;

将主库备份的数据还原到从库上：

SOURCE /home/sysadmin/lvshen/xxx.sql;

tips：恢复时间比较长，大概40分钟左右，需要耐心等待

最后我们重置slave服务，并且开启slave服务。

查看下从库状态，发现IO线程和SQL线程都已经正常了。

show slave status;

到这里主从终于恢复了。