相信大家的项目都是使用主从模式的数据库吧,我们在开发中可能要维护主从的情况比较少,只需要写增删改查就够了。但是最近自己经历一次主从异常的恢复。也算是有一份不一样的收获吧。
由于项目使用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;
到这里主从终于恢复了。