MySQL主从复制错误——列类型转换错误

快来打我* 2022-04-13 14:53 380阅读 0赞

## **| 背景** ##

有客户咨询说，自己的从库show slave status出现了报错，报错信息显示如下：

column 4 of table 'hh_db_mk.hh_vhl_application'cannot be converted from type 'datetime' to type 'varchar(20)'

截图显示如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 1][]

得到的信息如下：

*  从库停了两天，重启之后新建了这个表，然后就报了这个错。

## **| 思路** ##

看到这个报错，首先想到的是两边表结构是否不一致。查看后发现，表结构一模一样。

疑问客户是否有对表结构做了更改，导致了这个报错。但询问客户后，客户表示没有做任何表结构的更改。但同时向客户提出，解析下binlog看一下报错位置的sql语句。当然这个过程花了些时间。

出现列转换错误，一般都是由于主从之间字符集不一致导致的。于是询问客户，主从库之间的sql\_mode和字符集是否不一致，结果显示均一致。表结构也一致。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 5][]

这个时候，没啥思路了。但还是要求客户解析下binlog看一下对应的sql语句，执行mysqlbinlog -vvv mysql-bin.001744 --start-position=50585341 | head -100。不过，发现对应的binlog已经被purge掉了，然后在从库上解析对应的relay-log，执行mysqlbinlog -vvv mysql-relay.000003 --start-position=50585511 --base64=decode-rows | head -100，如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 6][]

可以看到，relay-log里面出错点对应的insert语句和目前的表结构确实不一样。报错信息显示的是column 4 cannot be converted from type 'datetime' to type 'varchar(20)'，我们知道MySQL中的column是从0开始计数的，所以在relay-log里column 4对应的是第五个字段add\_time datetime，在从库表里对应的是第五个字段system\_source varchar(20)，导致出现了这个报错。

## **| 解决** ##

表结构已经发生了变更，让客户重新从主库上拉一份数据到从库，做恢复。

## **| 总结** ##

其实这是一个比较简单的问题，但提醒我们，客户的某些确定性的操作不能都信以为真，也有可能客户自己也不知道，或者自己做了什么操作但是却忘记了，以为没有做过。

我们要做的，还是要找出真实的情况，以实际为准，不必太纠结于客户的说法。客户的说法不一定正确，不能因此而被误导。

Executed\_Gtid\_Set记录的是已经执行过的gtid，这里show slave status记录的最后执行的一个事务是8c268782-517e-11e7-ab9a-005056834ee0:69415237，出错的是下一个8c268782-517e-11e7-ab9a-005056834ee0:69415238。show slave status显示的Relay\_Log\_File:mysql-relay.000003、Relay\_Log\_Pos:50585511，则记录的是出错的那个事务的位置点。

## **|  作者简介** ##

**韩杰  沃趣科技MySQL数据库工程师**

熟悉mysql体系架构、主从复制，熟悉问题定位与解决。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70]: /images/20220413/8986511f342d4a038f1ee123042a5180.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 1]: /images/20220413/fb2e119ffb284c3d83f8bde51bc438e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 2]: /images/20220413/8f3e15428d47498ba7bfd55ccf7eafb7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 3]: /images/20220413/d92894fa015c42259597062c0671d961.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 4]: /images/20220413/d001d22407fe4bd3bd17924703837b9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 5]: /images/20220413/a4655e845dbf4408b3b992e0dd952f80.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 6]: /images/20220413/fc414ef2fbc9482a9253a99ab689b0a8.png