MySQL主從復制錯誤如何解決

MySQL主從復制錯誤如何解決，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

| 背景

有客戶咨詢說，自己的從庫show slave status出現了報錯，報錯信息顯示如下：

column 4 of table 'hh_db_mk.hh_vhl_application'cannot be converted from type 'datetime' to type 'varchar(20)'

  截圖顯示如下：

得到的信息如下：

• 從庫停了兩天，重啟之后新建了這個表，然后就報了這個錯。

| 思路

看到這個報錯，首先想到的是兩邊表結構是否不一致。查看后發現，表結構一模一樣。

疑問客戶是否有對表結構做了更改，導致了這個報錯。但詢問客戶后，客戶表示沒有做任何表結構的更改。但同時向客戶提出，解析下binlog看一下報錯位置的sql語句。當然這個過程花了些時間。

出現列轉換錯誤，一般都是由于主從之間字符集不一致導致的。于是詢問客戶，主從庫之間的sql_mode和字符集是否不一致，結果顯示均一致。表結構也一致。 

這個時候，沒啥思路了。但還是要求客戶解析下binlog看一下對應的sql語句，執行mysqlbinlog -vvv mysql-bin.001744 --start-position=50585341 | head -100。不過，發現對應的binlog已經被purge掉了，然后在從庫上解析對應的relay-log，執行mysqlbinlog -vvv mysql-relay.000003 --start-position=50585511 --base64=decode-rows | head -100，如下：

可以看到，relay-log里面出錯點對應的insert語句和目前的表結構確實不一樣。報錯信息顯示的是column 4 cannot be converted from type 'datetime' to type 'varchar(20)'，我們知道MySQL中的column是從0開始計數的，所以在relay-log里column 4對應的是第五個字段add_time datetime，在從庫表里對應的是第五個字段system_source varchar(20)，導致出現了這個報錯。

| 解決

表結構已經發生了變更，讓客戶重新從主庫上拉一份數據到從庫，做恢復。

| 總結

其實這是一個比較簡單的問題，但提醒我們，客戶的某些確定性的操作不能都信以為真，也有可能客戶自己也不知道，或者自己做了什么操作但是卻忘記了，以為沒有做過。

我們要做的，還是要找出真實的情況，以實際為準，不必太糾結于客戶的說法。客戶的說法不一定正確，不能因此而被誤導。

Executed_Gtid_Set記錄的是已經執行過的gtid，這里show slave status記錄的最后執行的一個事務是8c268782-517e-11e7-ab9a-005056834ee0:69415237，出錯的是下一個8c268782-517e-11e7-ab9a-005056834ee0:69415238。show slave status顯示的Relay_Log_File:mysql-relay.000003、Relay_Log_Pos:50585511，則記錄的是出錯的那個事務的位置點。

看完上述內容，你們掌握MySQL主從復制錯誤如何解決的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！