共计 1446 个字符，预计需要花费 4 分钟才能阅读完成。
MySQL 主从复制错误如何解决，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
| 背景
有客户咨询说，自己的从库 show slave status 出现了报错，报错信息显示如下：
column 4 of table hh_db_mk.hh_vhl_application cannot be converted from type datetime to type varchar(20)截图显示如下：
得到的信息如下：
从库停了两天，重启之后新建了这个表，然后就报了这个错。
| 思路
看到这个报错，首先想到的是两边表结构是否不一致。查看后发现，表结构一模一样。
疑问客户是否有对表结构做了更改，导致了这个报错。但询问客户后，客户表示没有做任何表结构的更改。但同时向客户提出，解析下 binlog 看一下报错位置的 sql 语句。当然这个过程花了些时间。
出现列转换错误，一般都是由于主从之间字符集不一致导致的。于是询问客户，主从库之间的 sql_mode 和字符集是否不一致，结果显示均一致。表结构也一致。
这个时候，没啥思路了。但还是要求客户解析下 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，如下：
可以看到，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 主从复制错误如何解决的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
