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

?

排查過程：

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

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

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

?

Slave上報(bào)錯(cuò)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是完全一樣的，如下：

?

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

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

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

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

?

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

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

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

?

討論幾個(gè)問題：

???? 一、為什么上面的情況有時(shí)會(huì)有報(bào)1062的錯(cuò)誤，有時(shí)候沒有呢？

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

嘻嘻，歡迎大家討論

?

總結(jié)：

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

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

?

?

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

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

總結(jié)

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

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