??? 最近經常線上的Slave老報1062的錯誤，蛋碎一地，幸好Slave暫時沒有用到業務上，也就是說沒有做讀寫分離，所以Slave有問題，影響也不大，但每隔一陣子就報1062主鍵沖突的錯誤，讓我好糾結，如果不解決的話，我都不敢上Atlas，所以一直在排查到底是什么引起的。雖然大家都知道當Master插入的數據所包含的主鍵或者唯一鍵在Slave上已經存在的時候，就會報Last_Errno: 1062，主從同步就斷開了。但是奇怪的是每次報1062的時候，Slave上的數據都和Master想插入的數據一樣的，這足以排除人為手動插入數據的可能。

?

排查過程：

????1、如果經常出現1062錯誤的時候，要注意出現的時間點，錯誤報在那個庫那個表，下次再出現的時候是否又是它。

??? 2、當出現1062錯誤的時候，查看Slave最近的一次備份，看這數據是否早存在Slave上了

??? 3、當出現1062錯誤的時候，查看Master和Slave的行記錄是否一樣，如果每次都是一樣的，這時可以考慮是是否有定時器調存儲過程進行Insert操作。

?

Slave上報錯1062的信息如下：

?

查一下Master binlog的記錄：

可以看到Master binlog是插入了一條記錄，登錄Master查一下：

之前用的binlog格式是本來是用了默認的mixed，后來以為有可能是binlog的日志格式導致了數據問題，把它修改為ROW了，但問題依舊存在。

mixed格式的問題可以參考：http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=400804310&idx=1&sn=2ea8b7455688a41621b8c9b59fbf822e&scene=0#wechat_redirect

?

查看Slave上的信息，可以看到binlog格式也是ROW，而且設置為read_only，行數據記錄和Master是完全一樣的，如下：

?

到這里是不是覺得有點怪呢，到底Slave上的數據是怎么來的呢？后來查看了一下與這個表相關的存儲過程和定時器，如下：（相關的表名我用數字代替了，請見諒！）

Create Procedure CREATE DEFINER=`root`@`localhost` PROCEDURE `_sp_1036`() BEGIN DECLARE _count INT UNSIGNED DEFAULT 0; DECLARE _current_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP();SELECT COUNT(*) INTO _count FROM _1030 WHERE F04 IS NOT NULL AND F05 > _current_time; INSERT INTO _1036 SET F01 = DATE(_current_time), F02 = HOUR(_current_time), F03 = _count ON DUPLICATE KEY UPDATE F03 = VALUES(F03);ENDCreate EventCREATE DEFINER=`root`@`localhost` EVENT `_daily_sp_1036` ON SCHEDULE EVERY 1 HOUR STARTS '2014-01-01 00:00:00' ON COMPLETION PRESERVE ENABLE DO CALL _sp_1036()

這個定時器一個小時運行一次，調用存儲過程，向表里插入數據，其實這里的存儲過程和定時器寫得都沒什么問題，問題在 CREATE DEFINER=`root`@`localhost`，歷史留下的坑好大啊，Slave上設置了read_only只對普通用戶有用，對管理級別的用戶是沒用的，所以Slave上也執行了定時器到時間就執行存儲過程，為了證明Slave有自己產生數據，我們做了測試，把Slave的SQL線程停掉：

可以看到主從同步斷開的情況，每個小時整點Slave也會產生一條記錄。Slave上的數據是怎么來的，已經很明顯了。

?

從上面可以看到Master的數據和Slave的是一樣的，這樣先把主從同步處理好，通過set global sql_slave_skip_counter=1? 跳過一個事務，如果數據不一致的情況，以Master的數據記錄為準：

可以看到出現了跳過一個事務后，報了一條很有趣的Log: the event's master log FIRST 。這時還是報同一條記錄的主鍵沖突，再執行一次

可以看到同步正常了，雖然是正常了，為了保證數據的完整性，建議使用我之前寫的pt-table-checksum校驗一個數據的完整性。

?

討論幾個問題：

???? 一、為什么上面的情況有時會有報1062的錯誤，有時候沒有呢？

???? 二、是master同步數據過來的時候報了1062錯誤，還是slave上執行定時器調存儲過程時把數據插入slave的時候報1062呢？

嘻嘻，歡迎大家討論

?

總結：

???? 一、管理好MySQL的權限，實現權限最小化管理，需要什么權限，開什么權限，禁止管理員級別的用戶運行程序相關的任何東西。

???? 二、定期進行主從的數據完整性校驗，確保主從的數據是一致性，特別是讀寫分離場景，一定要重視這類問題

?

?

? 作者：陸炫志 出處：xuanzhi的博客 http://www.cnblogs.com/xuanzhi201111 您的支持是對博主最大的鼓勵，感謝您的認真閱讀。本文版權歸作者所有，歡迎轉載，但請保留該聲明。 ?

轉載于:https://www.cnblogs.com/xuanzhi201111/p/5051700.html

總結

以上是生活随笔為你收集整理的线上Slave报1062的案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。