MySQL8.0主從複製命中1032案例分析

一、故障背景

  某次，使用者MySQL資料庫出現主從同步複製報錯，並且丟擲了典型錯誤程式碼1032。對於MySQL而言，出現複製報錯，一般來講，都是主從節點資料不一致導致，或者從庫沒有被強制為只讀模式，即從庫也發生了寫動作。當然，也有可能是複製特性BUG導致，需要做進一步分析。

  MySQL複製SQL執行緒報錯資訊，如下：

二、診斷過程

  有一定MySQL維護經驗的朋友，應該都清楚，1032錯誤程式碼，通常都是SQL執行緒在重放Relay LOG的時候發現操作的行記錄不在。最開始，我們懷疑，從庫上對應的行記錄是不是被人為誤刪除了，但經過實際核查，從庫確實為只讀模式，並且對應的行記錄也能查詢的到。

  將對應的行記錄，從BinLOG日誌中解析出來，如下：

  既然，1032報錯，不是這幾個常見的原因導致。分析至此，其實可以大致猜測，該複製報錯可能是因為MySQL BUG導致。當然，我們可以進一步分析，找到SQL執行緒呼叫的程式碼片段，定位對應的函式，並分析程式碼中的邏輯，使用gdb加以除錯。再做這個之前，建議優先MySQL內部網站做下匹配，多數場景都能夠命中。

  根據1032錯誤資訊作為關鍵詞，可以到MySQL的Bug網站和Oracle內部網站MOS中查詢是否有相關的記錄。

  果然，在MOS中，匹配到了類似的故障描述。詳細可參考文件On Avoiding Replication Error: Error_code: 1032; handler error HA_ERR_END_OF_FILE (Doc ID 2804769.1)。

  針對，MySQL8.0以上版本，如果表中缺少主鍵，那麼主從複製場景中就有可能命中1032報錯，可以考慮新增主鍵進行規避。

三、解決辦法和建議

  為了不對現有的業務邏輯產生影響，建議使用者對出現1032複製報錯的業務表，新增不可見主鍵，該主鍵不會影響最佳化器對SQL執行計劃的影響。具體操作，參考如下：

  alter table emp add column empid int auto_increment primary key invisible;