引言

在 MySQL 生產(chǎn)運維里，主從復(fù)制是數(shù)據(jù)備份、讀寫分離、高可用架構(gòu)的核心，但配置、網(wǎng)絡(luò)、磁盤、數(shù)據(jù)一致性、日志清理等問題，總能讓復(fù)制突然中斷。

今天我把實戰(zhàn)中 9 類高頻主從復(fù)制故障整理成文，包含問題模擬、報錯分析、分步解決方案，遇到問題直接對照處理，高效救場！

1. server_id 重復(fù)導(dǎo)致復(fù)制中斷

問題現(xiàn)象

從庫啟動復(fù)制報錯：server_id of slave is equal to server_id of master，IO 線程無法啟動。

解決方案

1. 主從節(jié)點 server_id 必須唯一，修改從庫：

set global server_id=唯一ID;

2. 重啟復(fù)制并驗證：

stop slave;
start slave;
show slave status\G

看到 Slave_IO_Running/Slave_SQL_Running 均為 Yes 即恢復(fù)。

2. 主從 3306 端口不通

問題現(xiàn)象

從庫狀態(tài)顯示 Slave_IO_Running: Connecting，報錯連接超時 / 拒絕。

解決方案

1. 主庫放行從庫 IP 的 3306 端口，清空攔截規(guī)則：

iptables -D INPUT 規(guī)則行號

2. 從庫驗證端口連通性：

telnet 主庫IP 3306

3. 重啟復(fù)制即可恢復(fù)。

3. 從庫磁盤空間滿

問題現(xiàn)象

磁盤使用率 100%，復(fù)制延遲飆升，甚至 MySQL 進程崩潰。

解決方案

1. 清理無用大文件、過期日志：

rm -f 無用文件

2. 磁盤釋放后重啟 MySQL 與復(fù)制：

/etc/init.d/mysql.server start
stop slave; start slave;

4. 主從數(shù)據(jù)沖突（對象已存在）

問題現(xiàn)象

從庫已有主庫要同步的庫 / 表，SQL 線程中斷。

解決方案

• GTID 模式：跳過沖突事務(wù)

stop slave;
set @@session.gtid_next=沖突GTID;
begin; commit;
set session gtid_next='AUTOMATIC';
start slave;

• 位點模式：跳過 1 個事務(wù)

stop slave;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave;

5. 主庫更新記錄在從庫缺失

問題現(xiàn)象

更新主庫存在、從庫已刪的記錄，報錯：Can’t find record。

解決方案

1. 解析 Relay Log 定位缺失數(shù)據(jù)：

mysqlbinlog 中繼日志 --start-position=位點 --base64-output=decode-rows -v > 解析文件

2. 從庫補全記錄后重啟復(fù)制。

6. 主庫 Binlog 被清理，位點找不到

問題現(xiàn)象

從庫提示：Could not find first log file name。

解決方案

1. 有正常從庫：直接從正常從庫重建復(fù)制。
2. 無正常從庫：用 XtraBackup 備份主庫，重建從庫復(fù)制關(guān)系。

7. GTID 空洞問題

產(chǎn)生原因

手動跳過事務(wù)、主從切換、盲目配置 slave-skip-errors=all。

規(guī)避建議

• GTID 模式禁止用 SQL_SLAVE_SKIP_COUNTER
• 主從切換前保證全量同步
• 不全局跳過所有錯誤

8. 主從 UUID 重復(fù)

問題原因

服務(wù)器克隆導(dǎo)致 auto.cnf 文件一致，UUID 相同。

解決方案

1. 停止從庫 MySQL
2. 刪除 data/auto.cnf
3. 重啟 MySQL，自動生成新 UUID
4. 重新建立主從關(guān)系

9. 從庫會讀到比主庫更新的數(shù)據(jù)？

在 “一主兩從” 架構(gòu)（1 個異步從庫 + 1 個半同步從庫）中，需結(jié)合 MySQL 復(fù)制類型和兩階段提交原理分析：

前置知識

1. 兩階段提交：InnoDB 事務(wù)提交分兩步：
   • Prepare 階段：寫入 Redo Log，標記事務(wù)為 “準備提交”；
   • Commit 階段：寫入 Binlog，再將 Redo Log 標記為 “已提交”。
2. 復(fù)制類型：
   • 異步復(fù)制：主庫提交事務(wù)后立即返回客戶端，不等待從庫同步；
   • 半同步復(fù)制（after_commit）：主庫執(zhí)行 Commit 階段后，等待從庫確認接收 Binlog 再返回；
   • 增強半同步復(fù)制（after_sync）：主庫執(zhí)行 Prepare 階段后，先發(fā)送 Binlog 給從庫，待從庫確認后再執(zhí)行 Commit 階段。

結(jié)論

特定場景會出現(xiàn)：增強半同步 after_sync 模式下，從庫已落盤、主庫未提交，從庫可讀到更新數(shù)據(jù)。

規(guī)避

改為 after_commit 模式，保證一致性。

排查總思路

1. 先看線程：IO 線程問題→網(wǎng)絡(luò) / 配置 / 權(quán)限；SQL 線程問題→數(shù)據(jù)沖突 / 結(jié)構(gòu)不一致
2. 查日志：show slave status\G + 系統(tǒng)錯誤日志
3. 按復(fù)制模式（GTID / 位點）選修復(fù)方案

日常運維建議

• 定期檢查磁盤、復(fù)制延遲、GTID 完整性
• 主庫 Binlog 保留足夠時長
• 禁止手動修改從庫數(shù)據(jù)
• 半同步優(yōu)先用 after_commit

以上就是MySQL主從復(fù)制故障排查及解決方案的詳細內(nèi)容，更多關(guān)于MySQL主從復(fù)制故障排查解決的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論