*1.現(xiàn)象

失敗以后，mysql目錄下回產(chǎn)生 mysql-relay-bin.000*

這種文件不能直接刪除，需要進(jìn)入數(shù)據(jù)庫(kù)，通過(guò)指令進(jìn)行刪除

*2.查看備份庫(kù)的狀態(tài)

參考：https://www.cnblogs.com/chinesern/p/7279495.html

Slave_IO線程負(fù)責(zé)把主庫(kù)的bin日志(Master_Log)內(nèi)容，投遞到從庫(kù)的中繼日志上(Relay_Log)。
Slave_SQL線程負(fù)責(zé)把中繼日志上的語(yǔ)句在從庫(kù)上執(zhí)行一遍。

Yes表示正常，No表示異常
Slave_IO線程相對(duì)比較簡(jiǎn)單，一般不容易出錯(cuò)，如果Slave_IO_Running顯示為No，可能是以下幾個(gè)原因?qū)е碌?

網(wǎng)絡(luò)問(wèn)題

權(quán)限問(wèn)題，例如在配置slave同步時(shí)因?yàn)閟lave訪問(wèn)master沒(méi)有權(quán)限導(dǎo)致的問(wèn)題。

mater上的binlog文件誤刪或者其他問(wèn)題導(dǎo)致的master庫(kù)突然停止而更新了binlog日志,這時(shí)候slave
可能出現(xiàn)早不到binlog文件的情況,解決方案是找到同步的點(diǎn)和binlog文件,重新 change master。

相對(duì)的Slave_SQL線程就比較容易出錯(cuò)，例如人為手動(dòng)的在從庫(kù)插入一條數(shù)據(jù)，造成主從不一致。但此時(shí)兩個(gè)線程的狀態(tài)任然是正常的，等到主庫(kù)也插入一條同樣的數(shù)據(jù)時(shí)，通知從庫(kù)做相同操作，從庫(kù)會(huì)出現(xiàn)主鍵重復(fù)的錯(cuò)誤。此時(shí)Slave_SQL_Running的狀態(tài)會(huì)變?yōu)镹o，
而Last_SQL_Error，Last_SQL_Error_Timestamp會(huì)記錄錯(cuò)誤的原因和發(fā)生時(shí)間。
Slave_SQL線程會(huì)停止后續(xù)的SQL語(yǔ)句執(zhí)行，因?yàn)樗庾R(shí)到往后執(zhí)行會(huì)導(dǎo)致錯(cuò)誤修復(fù)的難度增加。

?**2.1.查看從庫(kù)的幾個(gè)命令

SHOW SLAVE STATUS;STOP SLAVE;START SLAVE;

**2.2. 如何判斷主從完全同步

Master_Log_File和Relay_Master_Log_File所指向的文件必須一致 Relay_Log_Pos和Exec_Master_Log_Pos的為止也要一致才行 Slave_SQL_Running_State：顯示為wait 意思是中繼日志的sql語(yǔ)句已經(jīng)全部執(zhí)行完畢

?

*3.如何刪除mysql-relay-bin.000*文件

參考：https://blog.csdn.net/u010098331/article/details/50729984

**3.1.Relay Log無(wú)法自動(dòng)刪除的問(wèn)題

綜合分析后發(fā)現(xiàn)和以下原因有關(guān)。

1).該實(shí)例原先是一個(gè)Slave?? -------導(dǎo)致relay-log 和 relay-log.index的存在。
2).該實(shí)例目前已經(jīng)不是Slave? -------由于沒(méi)有了IO-Thread，導(dǎo)致relay-log-purge 沒(méi)有起作用（ 這也是其他Slave實(shí)例沒(méi)有這種情況的原因，因?yàn)镮O-thread會(huì)做自動(dòng)rotate操作）。
3).該實(shí)例每天會(huì)進(jìn)行日常備份? -------Flush logs的存在，導(dǎo)致每天會(huì)生成一個(gè)relay-log
4).該實(shí)例沒(méi)有配置expire-logs-days ------導(dǎo)致flush logs時(shí)，也不會(huì)做relay-log清除

簡(jiǎn)而言之就是： 一個(gè)實(shí)例如果之前是Slave，而之后停用了（stop slave），且沒(méi)有配置expire-logs-days的情況下，會(huì)出現(xiàn)relay-log堆積的情況。

**3.2.刪除Mysql 從數(shù)據(jù)庫(kù)的relay logs最安全方式

參考：https://dev.mysql.com/doc/refman/5.7/en/replication-administration-pausing.html

方式二： 手動(dòng)刪除 relay log1. 設(shè)置relay_log_purge = 1 SET GLOBAL relay_log_purge = 1 2. flush logs 通過(guò)管理員用戶登陸從數(shù)據(jù)庫(kù)，然后執(zhí)行下面命令：flush logs;可以執(zhí)行多次！注意：觀察堆積的relay logs日志是否已經(jīng)刪除，如果刪除，直接執(zhí)行下面第6步“恢復(fù)relay_log_purge = 0“；如果未刪除，繼續(xù)從下面第3步”停止slave“往下操作！！！3. 停止slave 通過(guò)管理員用戶登陸從數(shù)據(jù)庫(kù)，然后執(zhí)行下面命令：stop slave;4. 刪除relay logs 可以通過(guò)rm直接刪除relay logs通使用下面方式安全刪除：(1) 統(tǒng)計(jì)所有關(guān)于relay的文件（包括 relay_log_name.index）總個(gè)數(shù)ls -A1 |grep relay | sort -rn | wc -l(2) 列出要?jiǎng)h除所有有關(guān)relay的文件：ls -A1 |grep relay | sort -rn | tail -n 100說(shuō)明： 100 為要?jiǎng)h除的relay logs 數(shù)量(3) 確定沒(méi)有問(wèn)題，刪除relay logs：ls -A1 |grep relay | sort -rn | tail -n 100 | xargs rm -rf {}注意：要保留最新的兩個(gè)relay log 要保留relay log的index文件 relay log的index一般命名為： relay_log_name.index 例如： relay-bin.index 5. 啟動(dòng)slave 通過(guò)管理員用戶登陸從數(shù)據(jù)庫(kù)，然后執(zhí)行下面命令：start slave;6 . 恢復(fù)relay_log_purge = 0 通過(guò)管理員用戶登陸從數(shù)據(jù)庫(kù)，然后執(zhí)行下面命令：SET GLOBAL relay_log_purge=0;擴(kuò)展 如果你對(duì)從數(shù)據(jù)庫(kù)要求不高，可以將relay_log_purge = 1

實(shí)際操作：

SHOW SLAVE STATUS;STOP SLAVE;SET GLOBAL relay_log_purge = 1;FLUSH LOGS;SET GLOBAL relay_log_purge=0;

**3.3.刪除后直接剩下的結(jié)果：（注意要留最新的那幾個(gè)文件）

總結(jié)

以上是生活随笔為你收集整理的mysql主从备份失败--记录现象的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。