補充 GTID 模式下的簡化恢復、監控指標體系、自動化修復腳本思路,幫助團隊建立完整的主從運維體系。
SHOW SLAVE STATUS\G Slave_IO_Running: Yes Slave_SQL_Running: No Last_SQL_Error: Duplicate entry '1169595' for key 'PRIMARY' Last_Errno: 1062
SHOW BINLOG EVENTS IN 'mysql-bin.000274' FROM 504869752 LIMIT 50;504873114STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.0000274', MASTER_LOG_POS=504873114; START SLAVE;若啟用 gtid_mode=ON,無需手動找位點:
# 1. 確認已執行事務集合 SHOW MASTER STATUS; -- Executed_Gtid_Set # 2. Slave 重新從 Master 同步 (自動定位) STOP SLAVE; CHANGE MASTER TO MASTER_AUTO_POSITION=1; START SLAVE; # 3. 或跳過單一錯誤事務 STOP SLAVE; SET GTID_NEXT='aaaa-bbbb-cccc:12345'; -- 錯誤事務 GTID BEGIN; COMMIT; -- 空事務佔位 SET GTID_NEXT='AUTOMATIC'; START SLAVE;
| 指標 | 正常值 | 告警閾值 | 說明 |
|---|---|---|---|
| Slave_IO_Running | Yes | No | IO 線程狀態 |
| Slave_SQL_Running | Yes | No | SQL 線程狀態 |
| Seconds_Behind_Master | 0-10 | > 300 | 延遲秒數 |
| Relay_Log_Space | 穩定 | 持續增長 | Relay Log 堆積 |
| Last_Errno | 0 | != 0 | 最近錯誤碼 |
| Executed_Gtid_Set 差集 | 空 | 非空 | GTID 模式下缺失事務 |
#!/bin/bash
# fix_slave_duplicate.sh
# 僅供參考,生產環境需嚴格測試
ERR=$(mysql -e "SHOW SLAVE STATUS\G" | grep Last_Errno | awk '{print $2}')
if [ "$ERR" = "1062" ]; then
# 1. 取得錯誤事務 GTID (需 GTID 模式)
GTID=$(mysql -e "SHOW SLAVE STATUS\G" | grep Retrieved_Gtid_Set | awk '{print $2}')
# 2. 空事務佔位跳過
mysql -e "STOP SLAVE; SET GTID_NEXT='$GTID'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;"
# 3. 通知
echo "Slave 1062 錯誤已嘗試自動跳過,請人工複核資料一致性" | mail -s "MySQL Slave Auto-Fix" dba@company.com
fi
| 根因 | 檢測手段 | 預防措施 | 恢復難度 |
|---|---|---|---|
| 非正常關閉導致位點滯後 | 錯誤日誌、Seconds_Behind_Master 飆升 | 重啟前 STOP SLAVE、正常 shutdown、GTID 模式 | 低 (手動校正位點) |
| DDL 未同步執行 | Schema diff 工具 | 線上 DDL 工具、變更流程管控 | 中 (需補 DDL) |
| 非冪等重複執行 | Binlog 事件分析 | 業務冪等設計、主鍵衝突處理邏輯 | 低 (跳過/校正) |
| 網路分區導致 Binlog 丟失 | Master Binlog 完整性檢查 | 雙 Master/半同步、跨可用區部署 | 高 (需重做 Slave) |
gtid_mode=ON, enforce_gtid_consistency=ON)expire_logs_days=7)Duplicate Entry 是主從同步最常見錯誤,核心在於位點管理與冪等性。GTID 模式大幅簡化恢復,監控體系讓問題早發現,演練流程讓團隊不慌亂。建議所有生產環境遷移至 GTID 模式並建立自動化運維體系。