这篇文章主要介绍了MySQL中Slave库恢复的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

状况描述：

登录一个MySQL数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件，最早的文件创建日期甚至是2018年，我记得在slave库同步完master的日志操作记录后，会删除这些文件（默认设置不会删除，我记错了），于是便查看了slave库的状态，发现如下报错：

mysql>showslavestatus\G;***************************1.row***************************Slave_IO_State:WaitingformastertosendeventMaster_Host:*.*.*.*Master_User:dbsyncMaster_Port:3306Connect_Retry:60Master_Log_File:mysql-bin.000095Read_Master_Log_Pos:869242147Relay_Log_File:mysqld-relay-bin.000146Relay_Log_Pos:871280529Relay_Master_Log_File:mysql-bin.000075Slave_IO_Running:YesSlave_SQL_Running:NoReplicate_Do_DB:cdb,cdb_adminReplicate_Ignore_DB:mysqlReplicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno:1594Last_Error:Relaylogreadfailure:Couldnotparserelaylogevententry.Thepossiblereasonsare:themaster'sbinarylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'onthebinarylog),theslave'srelaylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'ontherelaylog),anetworkproblem,orabuginthemaster'sorslave'sMySQLcode.Ifyouwanttocheckthemaster'sbinarylogorslave'srelaylog,youwillbeabletoknowtheirnamesbyissuing'SHOWSLAVESTATUS'onthisslave.Skip_Counter:0Exec_Master_Log_Pos:871280384Relay_Log_Space:19994786573Until_Condition:NoneUntil_Log_File:Until_Log_Pos:0Master_SSL_Allowed:NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master:NULLMaster_SSL_Verify_Server_Cert:NoLast_IO_Errno:0Last_IO_Error:Last_SQL_Errno:1594Last_SQL_Error:Relaylogreadfailure:Couldnotparserelaylogevententry.Thepossiblereasonsare:themaster'sbinarylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'onthebinarylog),theslave'srelaylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'ontherelaylog),anetworkproblem,orabuginthemaster'sorslave'sMySQLcode.Ifyouwanttocheckthemaster'sbinarylogorslave'srelaylog,youwillbeabletoknowtheirnamesbyissuing'SHOWSLAVESTATUS'onthisslave.1rowinset(0.00sec)ERROR:Noqueryspecified

原因：

我在master节点上删除了名称为mysql-bin.00007格式的文件，其中包括mysql-bin.000075，因此，slave库找不到该文件，无法同步。

解决办法：

1、在slave库上重新指定同步位置。(不可行)

slavestop;CHANGEMASTERTOMASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=869242147;//mysqlmaster节点上mysql-bin.000095的已有位置slavestart;

slave节点上show slave status，依然报错，具体的报错内容没有复制下来，只记得errno为1236，Slave_IO_Running进程不运行，Slave_SQL_Running进程运行，大概描述就是某个库的某个表有问题。

在多次尝试指定不同的同步位置（报错的位置，master上mysql-bin-000095刚写过的位置）依然存在该错误。

实际上，表记录已经有问题，就拿描述中提出的那个表来说，slave库存放了约1200条记录，master库则有1900+的记录。除非手工将这些数据补上，否则由于记录操作数据的日志已经丢失（被我删除），是找不到最近的一致的日志操作执行位置的。

2、重做slave库。

由于数据差异太大，而且我觉得不光一张表出现了数据不一样的问题，所以干净点，把从库重做。
1）比对master、slave节点库配置信息，保证一致。（我不知道为什么设置了双主模式，实际上我只有一个实例跑在master节点上啊？）

2）在master、slave节点上查看流量情况（show processlist），保证要重做的slave库上没有业务的流量接入。

3）停止master节点上slave进程。（这个停了以后，我就没开过，不知道有没有问题，待观察）

4）记录master节点上库的日志记录位置，之后备份数据库：

mysql>showmasterstatus;+------------------+-----------+-------------------------------+------------------+|File|Position|Binlog_Do_DB|Binlog_Ignore_DB|+------------------+-----------+-------------------------------+------------------+|mysql-bin.000095|871760173|cdb,cdb_admin|mysql|+------------------+-----------+-------------------------------+------------------+1rowinset(0.01sec)mysqldump-uroot-p--databasescdb,cdb_admin>bak.master.sql

5）保险起见，备份slave节点库：

mysqldump-uroot-p--databasescdb,cdb_admin>bak.slave.sql

6）重做开始：把master库备份文件复制到slave节点上，导入该备份文件

mysql-uroot-p<bak.master.sql

7）在slave节点上，重新指定读master日志的位置：

slavestop;CHANGEMASTERTOMASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=871760173;//POS为刚才记录的master节点日志记录位置slavestart;

8）slave节点上 show slave status；此时Slave_IO_Running，Slave_SQL_Running均运行起来了，刷新slave status，Read_Master_Log_Pos数值也开始增加，重新开始同步了。

感谢你能够认真阅读完这篇文章，希望小编分享的“MySQL中Slave库恢复的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!