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

?

排查過程：

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

??? 2、當(dāng)出現(xiàn)1062錯誤的時候，查看Slave最近的一次備份，看這數(shù)據(jù)是否早存在Slave上了

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

?

Slave上報錯1062的信息如下：

?

查一下Master binlog的記錄：

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

之前用的binlog格式是本來是用了默認(rèn)的mixed，后來以為有可能是binlog的日志格式導(dǎo)致了數(shù)據(jù)問題，把它修改為ROW了，但問題依舊存在。

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

?

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

?

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

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()

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

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

?

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

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

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

?

討論幾個問題：

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

???? 二、是master同步數(shù)據(jù)過來的時候報了1062錯誤，還是slave上執(zhí)行定時器調(diào)存儲過程時把數(shù)據(jù)插入slave的時候報1062呢？

嘻嘻，歡迎大家討論

?

總結(jié)：

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

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

?

?

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

轉(zhuǎn)載于:https://www.cnblogs.com/xuanzhi201111/p/5051700.html

總結(jié)

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

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