磁盤寫滿導致MySQL復制失敗的解決方案
案例場景
今天在線上發(fā)現(xiàn)一個問題，由于監(jiān)控沒有覆蓋到，某臺機器的磁盤被寫滿了，導致線上MySQL主從復制出現(xiàn)問題。問題如下：
localhost.(none)>show slave status\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: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, the server was unable to fetch a keyring key required to open an encrypted relay log file, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
于是查看error log，發(fā)現(xiàn)error log中的內(nèi)容如下：
2021-03-31T11:34:39.367173+08:00 11 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. 2021-03-31T11:34:39.368161+08:00 12 [ERROR] [MY-010596] [Repl] Error reading relay log event for channel '': binlog truncated in the middle of event; consider out of disk space 2021-03-31T11:34:39.368191+08:00 12 [ERROR] [MY-013121] [Repl] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, the server was unable to fetch a keyring key required to open an encrypted relay log file, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: MY-013121 2021-03-31T11:34:39.368205+08:00 12 [ERROR] [MY-010586] [Repl] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000446' position 9489626
從描述中可以看到，error log是比較智能的，發(fā)現(xiàn)了磁盤問題，并提示我們需要"consider out of disk space"
解決問題
登錄服務器，很快就發(fā)現(xiàn)是MySQL所在的服務器磁盤使用率達到100%了，問題原因跟error log中的內(nèi)容一致。
現(xiàn)在就解決這個問題?；镜乃悸肪褪乔謇泶疟P文件，然后重新搭建復制關(guān)系，這個過程似乎比較簡單，但是實際操作中，在搭建復制關(guān)系的時候出現(xiàn)了下面的報錯：
### 基于gtid的復制，想重新搭建復制關(guān)系 localhost.(none)>reset slave; ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset localhost.(none)>reset slave all; ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset
第一步：因為復制是基于gtid進行的，所以直接記錄show slave status的狀態(tài)后，就可以重新reset slave，并利用change master語句來重建復制關(guān)系了。
但是卻出現(xiàn)上面的報錯，從報錯信息看是mysql無法完成purge relay log的操作，這看起來不科學。好吧，既然你自己不能完成purge relay logs的操作，那就讓我來幫你吧。
第二步：手工rm -f 刪除所有的relay log，發(fā)現(xiàn)報錯變成了：
localhost.(none)>reset slave all; ERROR 1374 (HY000): I/O error reading log index file
嗯，好吧，問題沒有得到解決。
然后思考了下，既然不能通過手工reset slave 來清理relay log，直接stop
slave 然后change master行不行呢？
第三步：直接stop slave，然后change master，不執(zhí)行reset slave all的語句，結(jié)果如下：
localhost.(none)>change master to master_host='10.13.224.31', -> master_user='replica', -> master_password='eHnNCaQE3ND', -> master_port=5510, -> master_auto_position=1; ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset
得，問題依舊。
第四步：反正復制已經(jīng)報錯斷開了，執(zhí)行個start slave看看，結(jié)果戲劇性的一幕出現(xiàn)了：
localhost.(none)>start slave; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 262 Current database: *** NONE *** Query OK, 0 rows affected (0.01 sec) localhost.(none)> [root@ ~]#
執(zhí)行start slave之后，實例直接掛了。
到這里，復制徹底斷開了，從庫實例已經(jīng)掛了。
第五步：看看實例還能不能重啟，嘗試重啟實例，發(fā)現(xiàn)實例還能起來。實例重新起來后，查看復制關(guān)系，結(jié)果如下：
localhost.(none)>show slave status\G *************************** 1. row *************************** Slave_IO_State: Queueing master event to the relay log 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: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, the server was unable to fetch a keyring key required to open an encrypted relay log file, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Skip_Counter: 0
復制關(guān)系依舊報錯。
第六步：重新reset slave all看看，結(jié)果成功了。
localhost.(none)>stop slave; Query OK, 0 rows affected (0.00 sec) localhost.(none)>reset slave all; Query OK, 0 rows affected (0.03 sec)
第七步：重新搭建復制關(guān)系并啟動復制
localhost.(none)>change master to master_host='10.xx.xx.xx', -> master_user='replica', -> master_password='xxxxx', -> master_port=5511, -> master_auto_position=1; Query OK, 0 rows affected, 2 warnings (0.01 sec) localhost.(none)>start slave; Query OK, 0 rows affected (0.00 sec) localhost.(none)>show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.xx.xx.xx Master_User: replica Master_Port: 5511 Connect_Retry: 60 ... Slave_IO_Running: Yes Slave_SQL_Running: Yes
發(fā)現(xiàn)實例的復制關(guān)系可以建立起來了。
一點總結(jié)
當磁盤寫滿的情況發(fā)生之后，mysql服務無法向元信息表中寫數(shù)據(jù)，relay log也可能已經(jīng)不完整了，如果直接清理了服務器上的磁盤數(shù)據(jù)，再去重新change master修改主從復制關(guān)系，可能會出現(xiàn)報錯，不能直接修復，因為這不是一個正常的主從復制關(guān)系斷裂場景。
所以，正確的做法應該是：
1、清理服務器的磁盤
2、重啟復制關(guān)系斷開的那個從庫
3、重新reset slave all、change master來搭建主從復制關(guān)系即可
如果有更好的方法，還請不吝賜教。
以上就是磁盤寫滿導致MySQL復制失敗的解決方案的詳細內(nèi)容，更多關(guān)于MySQL復制失敗的解決方案的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
MySQL數(shù)據(jù)庫中提供了很豐富的函數(shù),下面這篇文章主要給大家介紹了關(guān)于Mysql庫函數(shù)的相關(guān)資料,文中通過代碼介紹的非常詳細,對大家學習或者使用Mysql具有一定的參考借鑒價值,需要的朋友可以參考下2024-04-04
這篇文章主要介紹了mysql中between的用法及說明，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-07-07
mysql 8.0.16 winx64及Linux修改root用戶密碼 的方法
這篇文章主要介紹了mysql 8.0.16 winx64及Linux修改root用戶密碼 的方法，本文給大家介紹的非常詳細，具有一定的參考借鑒價值,需要的朋友可以參考下2019-07-07
MySQL數(shù)據(jù)庫通過Binlog恢復數(shù)據(jù)的詳細步驟
MySQL的binlog日志是MySQL日志中非常重要的一種日志,記錄了數(shù)據(jù)庫所有的DML操作,下面這篇文章主要給大家介紹了關(guān)于MySQL數(shù)據(jù)庫通過Binlog恢復數(shù)據(jù)的相關(guān)資料,文中通過圖文介紹的非常詳細,需要的朋友可以參考下2022-06-06
這篇文章主要介紹了mysql如何獲取自增id問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-07-07
數(shù)據(jù)通常分布在多個表中,為了獲取全面的信息,需要進行聯(lián)表查詢,本文主要介紹了MySQL的聯(lián)表查詢實現(xiàn),具有一定的參考價值,感興趣的可以了解一下2024-08-08
這篇文章主要介紹了mysql8連接不上問題及解決,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08
MySQL如何從數(shù)據(jù)庫中刪除表中所有數(shù)據(jù)
這篇文章主要介紹了MySQL如何從數(shù)據(jù)庫中刪除表中所有數(shù)據(jù)問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-06-06
centos 6.5下 mysql-community-server. 5.7.18-1.el6安裝
這篇文章主要介紹了centos 6.5下 mysql-community-server. 5.7.18-1.el6安裝,需要的朋友可以參考下2017-04-04
這篇文章主要介紹了MySQL中的多表查詢與事務操作,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-03-03