0、导读

在复制环境中，有个表的列类型总是被修改，导致复制进程报错停止

1、问题描述

问题发生在朋友的数据库上，做了主从复制，其中某表有一列类型是INT，但是该表上的INSERT事件在BINLOG中却总被记录为MEDIUMINT类型，导致这个事件在SLAVE上执行失败。

相关现场信息见下：

MySQL版本：官方5.5.版本。

表DDL定义：

CREATE TABLE `t` (

`userid` int(10) unsigned NOT NULL DEFAULT 0,

这个表上的INSERT事件在BINLOG中的记录：

### INSERT INTO `imysql`.`t`

### SET

### @1=207 /* MEDIUMINT meta=0 nullable=0 is_null=0 */

我们看到BINLOG中，这个列类型显示为MEDIUMINT，这个事件在SLAVE上就会报告下面的错误，导致SLAVE无法继续复制：

Column 0 of table 'imysql.t' cannot be converted from type 'mediumint' to type 'int(10) unsigned

又是一个看起来很奇葩的案例。

2、原因分析

经过沟通排查，了解到他们的业务模式有点特殊，是从一个旧的空表中复制表结构生成每天日志表，然后再将当天的日志写入该表。也就是大概做法是：

1、创建每天日志表

CREATE TABLE t SELECT t_orig;

2、写入日志

INSERT INTO t SELECT * FROM t_orig;

其实问题就出在每天创建新表的过程中，源表结构像是这样的：

CREATE TABLE `t_orig` (

`userid` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,

从源表复制到新表之后，又执行了ALTER TABLE，把 userid 列类型从 MEDIUMINT 改为 INT，创建存储过程等其他工作。

生成新表后，再写入生成的日志。但是呢，写入日志却又是采用INSERT...SELECT的用法。一般情况下当然没问题，但这个例子中，源表、目标表的 userid 列类型恰好不一样（源是MEDIUMINT，目标是INT），结果导致在 binglog 中记录event时，将 userid 列类型强制转换为 MEDIUMINT 了。这个 INSERT 在 MASTER 端可以正常执行完毕，但却引发了 SLAVE 检测到二者数据类型不一致，写入失败，复制异常中断。

3、问题建议

遇到这种案例也真的是醉了，从源表每天克隆一个新表做法没问题，采用INSERT...SELECT也没问题，但为啥要源表和新表使用不同数据类型呢，直接把源表的也改成INT不就行了吗，只能说某些人懒得不像样了。

4、类似案例

FAQ系列 | 写新数据时某列值总是被自动修改