一次mysql数据库从库UPDATE失败的分析

库：mysql5.6.19

从：mysql5.6.37

场景:昨天开发组反应从库和主库的数据同步有问题，在主库中进行更新过的数据，从库中有的没有更新，导致他们根据触发器变化的数据不准确。

起先接到这个问题，我把惊着了，按理说mysql从库的版本远远高于主库的，即使要出问题，也应该是早期的从库版本出问题才对，但是另一个版本号为5.6.19的从库，数据一切都正常，唯独版本为mysql5.6.37这个数据库出问题了。

这个问题让我百思不得其解，后来我打开mysql5.6.37从库的日志，发现大量1062的错误信息，类似下面这种：

Detailed error: Duplicate entry 'D2A03020711-0-28304342' for key 'devid';, Error_code: 1062

刚开始的时候我还没在意，因为在mysql的配置文件中，我已经设置了忽略1032和1062这两个错误，程序应该会处理好这个问题才对。

当我排查完主库中的binlog日志中，在从库中未变更的每一个对应信息都能找到对应的update语句。

而这一部分update语句在mysql5.6.37的binlog日志中，有时能找到，大90%都找不到，但是能在relay日志中又到找到找到。

问题定位到此，结论已经基本搞清楚了，在relay日志中的update语句，要么是没执行，要么是执行失败了。

所以我把解析后的update语句重新在mysql5.6.37的从库上执行了一次。结果我发现，报的错误正是error日志中所留下来的错误。

这个时候，我才发现原来我对跳过1062的Error_code理解是有问题的，正常处理的1062，在error日志中应该不会留下痕迹，但是如果留下痕迹，那就是说明有相应的sql没有执行成功。

问题产生的原因：

于是我打开主库和从库的表进行查看，认真对比后，发现没有任何问题。但是error日志的提示，问题产生的原因在于从库A表中使用了`devid` (`devid`,`typeid`,`userId`)唯一索引。

于是我把从库中的表进行删除，并重新同步了数据，然后看到的问题消失了。我以为问题就算解决完了。

但是过了一会，相同的问题又在mysql5.6.37的从库中出现了。

但另外一个低版本的mysql5.6.19也使用同样的索引，那么为何高版本mysql5.6.37这个唯一索引，在update时会有问题，而低版本的mysql在执行update时不没有问题呢，对这个我百思不得其解。

后来我问了同事，刚才做了什么操作，原来是在mysql5.6.37的mysql上添加了触发器。

这才算是真正找到了问题的原因。

原来他设计的触发器刚好就是把之前表中变更的数据记录，全部更新到B表中，而且使用了和之前A表中一致的唯一索引devid。

于是果断去掉B表的唯一索引，发现更新数据就正常了。