以前statement復(fù)制下做表結(jié)構(gòu)變更時(shí)，一般是一臺(tái)一臺(tái)的從庫(kù)依次去做，最后做主庫(kù)。

今天在一臺(tái)從庫(kù)上進(jìn)行表結(jié)構(gòu)變更時(shí)卻遇到一個(gè)復(fù)制報(bào)錯(cuò)，
Last_Errno: 1677
Last_Error: Column 7 of table ‘user_0.user_00′ cannot be converted from type ‘varchar(10)’ to type ‘varbinary(30)’

原變更語(yǔ)句為
alter table user_00 modify `column7` varbinary(30) NOT NULL DEFAULT ”;

原表中此字段類型為
`column7` varbinary(10) NOT NULL DEFAULT ”

s 命令顯示此從庫(kù)為5.5格式，并且復(fù)制是row格式。

官網(wǎng)查詢后，發(fā)現(xiàn)這并不是一個(gè)bug，

http://bugs.mysql.com/bug.php?id=59424

在5.5的row格式復(fù)制中，有參數(shù)
slave_type_conversions來控制復(fù)制中主從結(jié)構(gòu)不一致的處理

取值見下表：

默認(rèn)為”，即不支持主從字段類型不一致，
其它3種類型為：
all_lossy 支持有損轉(zhuǎn)換，如int–>tinyint
all_non_lossy 支持無損轉(zhuǎn)換，如char(20)–>varchar(25)
all_lossy,all_non_lossy 支持所有轉(zhuǎn)換

此時(shí)手工在從庫(kù)上執(zhí)行：
stop slave;
set global slave_type_conversions=ALL_LOSSY;
start slave;

復(fù)制恢復(fù)正常