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

IO線程異常，常見有：

• 復(fù)制用戶或密碼錯誤

• 網(wǎng)絡(luò)不穩(wěn)定

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

  
  

SQL線程異常，常見有：

• 復(fù)制點(diǎn)指定錯誤

• 主鍵或唯一鍵沖突

• 記錄不存在

• 表結(jié)構(gòu)不一致

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

查看異常

接到一生產(chǎn)主從復(fù)制異常告警，登陸數(shù)據(jù)庫查看異常信息如下：

上述信息僅表示執(zhí)行一事務(wù)失敗，并不詳細(xì)；因使用并行復(fù)制，查詢以下表，了解更詳細(xì)信息

錯誤信息表明，表中編號為3的字段不能進(jìn)行類型轉(zhuǎn)換。

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

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

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

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

語句格式

如果事務(wù)SQL語句能夠在從庫正常執(zhí)行，那主從復(fù)制就不會出現(xiàn)問題。

行格式

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

• 從庫目標(biāo)字段長度小于主庫

MySQL采取有損數(shù)據(jù)類型轉(zhuǎn)換，對數(shù)據(jù)進(jìn)行類型內(nèi)的截取操作。

• 從庫目標(biāo)字段長度大于主庫

MySQL采取無損數(shù)據(jù)類型轉(zhuǎn)換，轉(zhuǎn)換后數(shù)據(jù)不會丟失。

mix格式

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

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

該參數(shù)包括兩個值，ALL_LOSSY有損轉(zhuǎn)換、ALL_NON_LOSSY無損轉(zhuǎn)換，對應(yīng)上述兩種目標(biāo)字段長度情況。

異構(gòu)表復(fù)制

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

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

源表、目標(biāo)表擁有不同數(shù)量的列

在源表、目標(biāo)表擁有不同數(shù)量列的情況下，保證主從復(fù)制正常進(jìn)行，必須滿足以下條件：

源表、目標(biāo)表擁有不同數(shù)據(jù)類型的列

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

• 來自源表列的數(shù)據(jù)類型在目標(biāo)表上變?yōu)橄嗤笮』蚋蟮臄?shù)據(jù)類型時，這稱為屬性上升，此時可以進(jìn)行無損數(shù)據(jù)類型轉(zhuǎn)換。

• 來自源表列的數(shù)據(jù)類型在目標(biāo)表上變?yōu)楦〉臄?shù)據(jù)類型時，這稱為屬性下降，此時可以進(jìn)行有損數(shù)據(jù)類型轉(zhuǎn)換。

  
  

MySQL支持以下不同但相似數(shù)據(jù)類型間的轉(zhuǎn)換：

• TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT間的整數(shù)類型轉(zhuǎn)換

• DECIMAL, FLOAT, DOUBLE, and NUMERIC間的類型轉(zhuǎn)換

• CHAR, VARCHAR, and TEXT間的類型轉(zhuǎn)換

• BINARY, VARBINARY, and BLOB間的類型轉(zhuǎn)換

• BIT間的類型轉(zhuǎn)換

  
  

不允許上述以外的類型轉(zhuǎn)換，當(dāng)向小類型轉(zhuǎn)換時，數(shù)據(jù)被截斷后復(fù)制至從庫，此時主從數(shù)據(jù)就產(chǎn)生了不一致。

MySQL主從復(fù)制相對比較靈活，即可以單表復(fù)制，又可以部分表復(fù)制，更可以進(jìn)行異構(gòu)表復(fù)制，但對于已生產(chǎn)的主從復(fù)制，必須保證主從兩邊的數(shù)據(jù)結(jié)構(gòu)一致性，從而保證主從兩邊的數(shù)據(jù)一致性；對于數(shù)據(jù)遷移或數(shù)據(jù)割接的場景，依據(jù)MySQL異構(gòu)表復(fù)制規(guī)則進(jìn)行操作，便可以正常的進(jìn)行數(shù)據(jù)復(fù)制。