线上有个业务是一主两从，今天下午有一个从库突然告警：1677错误，提示数据类型不能从smallint改成varchar(20),以前有遇到过这样的错误，设置参数set global slave_type_conversions=ALL_NON_LOSSY;重新start slave就可了，但是这次改了参数还是没有效果。
经过询问，dba都没有改过表结构，只是开发人员调整了栏位的顺序。查看报错的表的表结构，发现这个从库的表结构和主库的不一样。解析日志发现relaylog里面有相关的alter table的操作，但是从库就是没有执行。比较奇怪的是另外那个从库很正常。
刚开始怀疑是配置文件参数设置有问题，但是对比后发现两个从库的配置是一样的，后来重新做了从库，然后让开发重新用工具给表的栏位重新排序，查看两个从库发现之前报错的那个从库现在没有报错，但是栏位的顺序还是没有变更。
查看数据库的版本，主库为5.5.33，正常从库也是5.5.33，报错从库为5.6.23.刚开始怀疑是不是因为版本不一样的问题，于是在命令行执行alter table语句，发现从库没有异常。
最后开始怀疑是工具的问题，我先用navicat更改表结构，复制没有问题；
用sqlyog v8.14版本操作，复制没有问题；
叫开发用navicat操作没有问题；
叫开发用sqlyog操作，之前的从库又没能复制过去。
查看开发的sqlyog版本为v11.24版本。
叫开发换成其它版本的sqlyog操作，复制没有问题。
这个问题不是很好排查，因为开发都是通过工具连的数据库，很少出现这个问题。
通过这次的问题，发现用工具连数据库还是会有很多隐患，要从根本上解决这个问题只能严格控制开发权限，只给他们select权限。
dba平时操作数据库的时候尽量在命令行操作。
本文出自 “一直在路上” 博客，请务必保留此出处http://chenql.blog.51cto.com/8732050/1715167