现今大部分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异构表复制规则进行操作，便可以正常的进行数据复制。