编程宝库 - 技术改变世界

编程宝库

Mysql知识

磁盘写满导致MySQL复制失败的解决方案

案例场景

今天在线上发现一个问题，由于监控没有覆盖到，某台机器的磁盘被写满了，导致线上MySQL主从复制出现问题。问题如下：

localhost.(none)>showslavestatus\G
***************************1.row***************************
Slave_IO_State:
Master_Host:10.xx.xx.xx
Master_User:replica
Master_Port:5511
Connect_Retry:60
Master_Log_File:
Read_Master_Log_Pos:4
Relay_Log_File:relay-bin.001605
Relay_Log_Pos:9489761
Relay_Master_Log_File:
Slave_IO_Running:No
Slave_SQL_Running:No
Last_Errno:13121
Last_Error:Relaylogreadfailure:Couldnotparserelaylogevententry.
Thepossiblereasonsare:themaster'sbinarylogiscorrupted(youcancheckthisbyrunning
'mysqlbinlog'onthebinarylog),theslave'srelaylogiscorrupted(youcancheckthisby
running'mysqlbinlog'ontherelaylog),anetworkproblem,theserverwasunabletofetcha
keyringkeyrequiredtoopenanencryptedrelaylogfile,orabuginthemaster'sor
slave'sMySQLcode.Ifyouwanttocheckthemaster'sbinarylogorslave'srelaylog,
youwillbeabletoknowtheirnamesbyissuing'SHOWSLAVESTATUS'onthisslave.

于是查看error log，发现error log中的内容如下：

2021-03-31T11:34:39.367173+08:0011[Warning][MY-010897][Repl]StoringMySQLusernameor
passwordinformationinthemasterinforepositoryisnotsecureandisthereforenot
recommended.PleaseconsiderusingtheUSERandPASSWORDconnectionoptionsforSTARTSLAVE;
seethe'STARTSLAVESyntax'intheMySQLManualformoreinformation.

2021-03-31T11:34:39.368161+08:0012[ERROR][MY-010596][Repl]Errorreadingrelaylog
eventforchannel'':binlogtruncatedinthemiddleofevent;consideroutofdiskspace

2021-03-31T11:34:39.368191+08:0012[ERROR][MY-013121][Repl]SlaveSQLforchannel'':Relay
logreadfailure:Couldnotparserelaylogevententry.Thepossiblereasonsare:themaster's
binarylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'onthebinarylog),the
slave'srelaylogiscorrupted(youcancheckthisbyrunning'mysqlbinlog'ontherelaylog),
anetworkproblem,theserverwasunabletofetchakeyringkeyrequiredtoopenanencrypted
relaylogfile,orabuginthemaster'sorslave'sMySQLcode.Ifyouwanttocheckthe
master'sbinarylogorslave'srelaylog,youwillbeabletoknowtheirnamesbyissuing'SHOW
SLAVESTATUS'onthisslave.Error_code:MY-013121

2021-03-31T11:34:39.368205+08:0012[ERROR][MY-010586][Repl]Errorrunningquery,slaveSQL
threadaborted.Fixtheproblem,andrestarttheslaveSQLthreadwith"SLAVESTART".We
stoppedatlog'mysql-bin.000446'position9489626

从描述中可以看到，error log是比较智能的，发现了磁盘问题，并提示我们需要"consideroutofdiskspace"

解决问题

登录服务器，很快就发现是MySQL所在的服务器磁盘使用率达到100%了，问题原因跟error log中的内容一致。

现在就解决这个问题。基本的思路就是清理磁盘文件，然后重新搭建复制关系，这个过程似乎比较简单，但是实际操作中，在搭建复制关系的时候出现了下面的报错：

###基于gtid的复制，想重新搭建复制关系
localhost.(none)>resetslave;
ERROR1371(HY000):Failedpurgingoldrelaylogs:Failedduringlogreset

localhost.(none)>resetslaveall;
ERROR1371(HY000):Failedpurgingoldrelaylogs:Failedduringlogreset

第一步：因为复制是基于gtid进行的，所以直接记录show slave status的状态后，就可以重新reset slave，并利用change master语句来重建复制关系了。

但是却出现上面的报错，从报错信息看是mysql无法完成purge relay log的操作，这看起来不科学。好吧，既然你自己不能完成purge relay logs的操作，那就让我来帮你吧。

第二步：手工rm -f 删除所有的relay log，发现报错变成了：

localhost.(none)>resetslaveall;
ERROR1374(HY000):I/Oerrorreadinglogindexfile

嗯，好吧，问题没有得到解决。

然后思考了下，既然不能通过手工reset slave 来清理relay log，直接stop

slave 然后change master行不行呢？

第三步：直接stop slave，然后change master，不执行reset slave all的语句，结果如下：

localhost.(none)>changemastertomaster_host='10.13.224.31',
->master_user='replica',
->master_password='eHnNCaQE3ND',
->master_port=5510,
->master_auto_position=1;
ERROR1371(HY000):Failedpurgingoldrelaylogs:Failedduringlogreset

得，问题依旧。

第四步：反正复制已经报错断开了，执行个start slave看看，结果戏剧性的一幕出现了：

localhost.(none)>startslave;
ERROR2006(HY000):MySQLserverhasgoneaway
Noconnection.Tryingtoreconnect...
Connectionid:262
Currentdatabase:***NONE***


QueryOK,0rowsaffected(0.01sec)


localhost.(none)>
[root@~]#

执行start slave之后，实例直接挂了。

到这里，复制彻底断开了，从库实例已经挂了。

第五步：看看实例还能不能重启，尝试重启实例，发现实例还能起来。实例重新起来后，查看复制关系，结果如下：

localhost.(none)>showslavestatus\G
***************************1.row***************************
Slave_IO_State:Queueingmastereventtotherelaylog
Master_Host:10.xx.xx.xx
Master_User:replica
Master_Port:5511
Connect_Retry:60
Master_Log_File:
Read_Master_Log_Pos:4
Relay_Log_File:relay-bin.001605
Relay_Log_Pos:9489761
Relay_Master_Log_File:
Slave_IO_Running:Yes
Slave_SQL_Running:No
Last_Errno:13121
Last_Error:Relaylogreadfailure:Couldnotparserelaylogevententry.
Thepossiblereasonsare:themaster'sbinarylogiscorrupted(youcancheckthisbyrunning
'mysqlbinlog'onthebinarylog),theslave'srelaylogiscorrupted(youcancheckthisby
running'mysqlbinlog'ontherelaylog),anetworkproblem,theserverwasunabletofetcha
keyringkeyrequiredtoopenanencryptedrelaylogfile,orabuginthemaster'sorslave's
MySQLcode.Ifyouwanttocheckthemaster'sbinarylogorslave'srelaylog,youwillbeable
toknowtheirnamesbyissuing'SHOWSLAVESTATUS'onthisslave.
Skip_Counter:0

复制关系依旧报错。

第六步：重新reset slave all看看，结果成功了。

localhost.(none)>stopslave;
QueryOK,0rowsaffected(0.00sec)


localhost.(none)>resetslaveall;
QueryOK,0rowsaffected(0.03sec)

第七步：重新搭建复制关系并启动复制

localhost.(none)>changemastertomaster_host='10.xx.xx.xx',
->master_user='replica',
->master_password='xxxxx',
->master_port=5511,
->master_auto_position=1;
QueryOK,0rowsaffected,2warnings(0.01sec)


localhost.(none)>startslave;
QueryOK,0rowsaffected(0.00sec)


localhost.(none)>showslavestatus\G
***************************1.row***************************
Slave_IO_State:Waitingformastertosendevent
Master_Host:10.xx.xx.xx
Master_User:replica
Master_Port:5511
Connect_Retry:60
...
Slave_IO_Running:Yes
Slave_SQL_Running:Yes

发现实例的复制关系可以建立起来了。

一点总结

当磁盘写满的情况发生之后，mysql服务无法向元信息表中写数据，relay log也可能已经不完整了，如果直接清理了服务器上的磁盘数据，再去重新change master修改主从复制关系，可能会出现报错，不能直接修复，因为这不是一个正常的主从复制关系断裂场景。

所以，正确的做法应该是：

1、清理服务器的磁盘

2、重启复制关系断开的那个从库

3、重新reset slave all、change master来搭建主从复制关系即可

如果有更好的方法，还请不吝赐教。

以上就是磁盘写满导致MySQL复制失败的解决方案的详细内容，更多关于MySQL复制失败的解决方案的资料请关注编程宝库其它相关文章！

下一节：MySQL GTID主备不一致的修复方案

MySQL教程

方案一：重建 ReplicasMySQL 5.6及以上版在复制中引入了新的全局事务ID（GTID）支持。在启用了GTID模式的情况下执行MySQL和MySQL 5.7的备份时，Perc ...

MySQL UPDATE 语句的非标准实现代码

MySQL GTID主备不一致的修复方案