現今大部分MySQL集群都是以主從復制為基礎，如MHA、MGR、第三方中間件等，一旦主從復制出現異常，整體集群都會受到影響，主從復制出現異常分為兩類：IO線程異常與SQL線程異常。

IO線程異常，常見有：

• 復制用戶或密碼錯誤

• 網絡不穩定

• 復制心跳時間大于slave_net_timeout參數，IO線程空閑被終斷

  
  

SQL線程異常，常見有：

• 復制點指定錯誤

• 主鍵或唯一鍵沖突

• 記錄不存在

• 表結構不一致

今天所講案例便是SQL線程異常的最后一種情況：主從表結構不一致。

查看異常

接到一生產主從復制異常告警，登陸數據庫查看異常信息如下：

上述信息僅表示執行一事務失敗，并不詳細；因使用并行復制，查詢以下表，了解更詳細信息

錯誤信息表明，表中編號為3的字段不能進行類型轉換。

上面的錯誤信息表明，很大可能是主從兩邊表結構不一致，登陸主從，查看兩邊該表表結構如下：

該表在主從兩邊共有4處不一致，復制報錯信息中僅顯示了一處：3號字段即“operate_method”字段。

我們在做數據遷移的時候，如果碰到目標字段長度比源字段大且字符集相同，那遷移過程中就不會出現問題，但以Row格式為基礎的MySQL主從復制卻會出現意外。

在MySQL數據庫中，表上字段的類型包括字段的數據類型、定義的數據類型長度兩個因素。因此通常情況下，主從兩邊表結構必須保持一致，才能夠保障主從復制的正常進行，進而保證主從數據的完全一致性。如果是上述情況僅字段類型不一致的話，MySQL會針對不同的binlog格式進行處理。

語句格式

如果事務SQL語句能夠在從庫正常執行，那主從復制就不會出現問題。

行格式

對于行格式而言，MySQL會針對不同的情況分別處理

• 從庫目標字段長度小于主庫

MySQL采取有損數據類型轉換，對數據進行類型內的截取操作。

• 從庫目標字段長度大于主庫

MySQL采取無損數據類型轉換，轉換后數據不會丟失。

mix格式

上述兩種情況的綜合處理。

上述現象中從庫存在目標字段長度大于、小于主庫兩種情況，主從復制即要進行無損數據類型轉換，又要進行有損數據類型轉換；而控制這一行為的是從的”slave_type_conversions”數據庫參數，該參數默認情況下為空，即主從復制遇到這種情況不會進行任何操作。設置該參數為以下值，重啟主從復制，主從復制恢復正常

該參數包括兩個值，ALL_LOSSY有損轉換、ALL_NON_LOSSY無損轉換，對應上述兩種目標字段長度情況。

異構表復制

在mysql數據庫主從復制中，源表和目標表不必相同，源表可以具有比目標表更多或更少的列。此外，在一定條件下，源表與目標表的列可以擁有不同的數據類型。

在源表與目標表擁有不同定義的情況下，源表與目標表必須擁有相同的庫名、表名，下面將講述上面兩種不同情況的操作要求。

源表、目標表擁有不同數量的列

在源表、目標表擁有不同數量列的情況下，保證主從復制正常進行，必須滿足以下條件：

源表、目標表擁有不同數據類型的列

通常情況下，同一表在主庫、從庫上的列必須使用相同的數據類型，但是在符合某些條件下，這并不總是嚴格執行的，此時MySQL可以進行有損、無損數據類型轉換，驅使主從復制順利進行，但卻不保證主從數據的完全一致性。

• 來自源表列的數據類型在目標表上變為相同大小或更大的數據類型時，這稱為屬性上升，此時可以進行無損數據類型轉換。

• 來自源表列的數據類型在目標表上變為更小的數據類型時，這稱為屬性下降，此時可以進行有損數據類型轉換。

  
  

MySQL支持以下不同但相似數據類型間的轉換：

• TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT間的整數類型轉換

• DECIMAL, FLOAT, DOUBLE, and NUMERIC間的類型轉換

• CHAR, VARCHAR, and TEXT間的類型轉換

• BINARY, VARBINARY, and BLOB間的類型轉換

• BIT間的類型轉換

  
  

不允許上述以外的類型轉換，當向小類型轉換時，數據被截斷后復制至從庫，此時主從數據就產生了不一致。

MySQL主從復制相對比較靈活，即可以單表復制，又可以部分表復制，更可以進行異構表復制，但對于已生產的主從復制，必須保證主從兩邊的數據結構一致性，從而保證主從兩邊的數據一致性；對于數據遷移或數據割接的場景，依據MySQL異構表復制規則進行操作，便可以正常的進行數據復制。