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資料庫工程師

熟悉mysql體系架構、主從複製，熟悉問題定位與解決。