MySQL 從庫 1062 Duplicate Entry 故障全鏈路排查

故障現場

Last_Errno: 1062
Last_Error: Duplicate entry '250.1.1-rding-changelogs/myIDENTITY/250/xxxx.xml' 
for key 'PRIMARY'
Query: INSERT INTO `DATABASECHANGELOG` ...

表結構：PRIMARY KEY (ID, AUTHOR, FILENAME) 聯合主鍵。

排查鏈路

1. 確認從庫已存在數據

SELECT * FROM DATABASECHANGELOG WHERE AUTHOR='rding' AND ID='250.1.1';
-- 返回 1 行，DATEEXECUTED = 2013-08-12 20:41:22

2. 主庫 Binlog 分析

mysqlbinlog mysql-bin.000152 | grep 'rding'
-- 僅 1 條 INSERT (250.1.1)

3. 從庫 Relay Log 分析

mysqlbinlog mysql-relay-bin.000455 | grep 'rding'
-- 同樣僅 1 條 INSERT

主從 Binlog/Relay Log 均無重複，為何報 1062？

4. 時間戳對比發現關鍵線索

從庫執行時間比主庫晚 47 分鐘，說明 SQL 執行延遲極大（Seconds_Behind_Master 曾達 3434734 秒 ≈ 40 天）。

5. 從庫本地 Binlog 排查

解析近期 5 個 Binlog (004268-004272) 均無相關 INSERT，且 004271 解析報錯 (read_log_event)。

根因假設

1. 長延遲下的重複執行：SQL 線程卡頓、重試機制導致同一事件被應用兩次
2. Binlog 損壞：004271 解析失敗暗示文件可能截斷/校驗錯
3. 應用層幂等性缺失：Liquibase 變更日志表無幂等設計，重複應用即報錯

緊急處理與後續

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter=1;
START SLAVE;
-- Slave_SQL_Running: Yes, Seconds_Behind_Master 開始下降

系統性建議

• 監控 Seconds_Behind_Master 告警（> 300 秒即介入）
• 關鍵業務表添加幂等鍵或版本號
• 定期 mysqlbinlog --verify-checksum 檢測 Binlog 完整性
• 升級 GTID 複制 (5.6+) 簡化故障恢復