轉(zhuǎn)載說明：如果您喜歡這篇文章并打算轉(zhuǎn)載它，請私信作者取得授權(quán)。感謝您喜愛本文，請文明轉(zhuǎn)載，謝謝。
問題描述：
某測試環(huán)境的MySQL用了兩臺節(jié)點(diǎn)，主從同步結(jié)構(gòu)。忽然有研發(fā)同學(xué)反映說MySQL的主從不同步了。他在測試代碼功能的時候，調(diào)用接口在主庫insert了一條數(shù)據(jù)，然后發(fā)現(xiàn)在從庫上查不到這條數(shù)據(jù)。于是開始排查。
原因排查：
1、查看主從同步狀態(tài)
在主庫和從庫分別執(zhí)行：show master status\G; 和 show slave status\G;
發(fā)現(xiàn)從庫同步的binlog的Position跟主庫查詢到的不一致，以為是同步延遲了。然后手動在主庫創(chuàng)建了一個測試database，發(fā)現(xiàn)從庫立即同步了，主從同步的點(diǎn)也是一致的。
2、根據(jù)數(shù)據(jù)字段排查
于是再次查看表數(shù)據(jù)，發(fā)現(xiàn)主從的這張表數(shù)據(jù)量是一樣的，但是根據(jù)“id”這個字段去查，主庫能找到數(shù)據(jù)，但是從庫就是查不到。
然后換了個關(guān)鍵字“factoryId”去查詢，發(fā)現(xiàn)主從庫都有數(shù)據(jù)，但是兩個庫查詢出來的數(shù)據(jù)id是不一致的：
將兩條數(shù)據(jù)刪掉，重新調(diào)用代碼接口插入數(shù)據(jù)，結(jié)果還是一樣的，兩條數(shù)據(jù)的id就是不一樣。
然后嘗試手動insert一條語句，發(fā)現(xiàn)不存在這個問題：
3、排查insert語句代碼
最后，研發(fā)給出的結(jié)論是這樣的：
這張表的數(shù)據(jù)包含id、factoryId和appTag三個字段。
當(dāng)使用代碼調(diào)接口執(zhí)行insert語句時，代碼并沒有生成id這個字段固定的id號，只有生成了factoryId和appTag這兩個字段的內(nèi)容。
所以寫入數(shù)據(jù)的時候，只有factoryId和appTag這兩個字段的內(nèi)容的固定的，id號是在數(shù)據(jù)庫里面自己隨機(jī)生成的。而且在主庫生成了id號之后，并沒有讓從庫將主庫生成的id直接inert到從庫，而是在從庫也隨機(jī)生成一個自己的id。
所以就導(dǎo)致這樣一種情況：同一條insert插入的數(shù)據(jù)，在主庫insert的時候會隨機(jī)生成一個id；在從庫也會隨機(jī)生成一個自己的id。當(dāng)兩個庫都隨機(jī)生成自己的id的時候，就會很高概率導(dǎo)致主從庫上這條數(shù)據(jù)的id字段不一致，只有factoryId和appTag這兩個字段是一致的。
因此，當(dāng)根據(jù)id去查詢數(shù)據(jù)，就會發(fā)現(xiàn)從庫可能無法查詢到該數(shù)據(jù)。因為之前很少用id這個關(guān)鍵字去進(jìn)行數(shù)據(jù)庫操作，因此沒有注意到這個問題。
補(bǔ)充：
數(shù)據(jù)庫隨機(jī)生成id的兩種方式：
1、隨機(jī)生成uuid（uuid是根據(jù)時間戳來生成的）
2、auto_increment屬性生成id
故障的大致情形如下圖：
文章來源：http://www.zghlxwxcb.cn/news/detail-813453.html
解決方法：
需要開發(fā)修改接口代碼，修改insert語句的插入方式，將主庫隨機(jī)生成的id直接insert到從庫，從庫不再單獨(dú)生成id。問題就解決了。文章來源地址http://www.zghlxwxcb.cn/news/detail-813453.html
到了這里，關(guān)于記錄一個Insert姿勢引起的MySQL從庫上查不到數(shù)據(jù)的問題的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
