Amazon RDS MySQL 5.6副本AFTER INSERT触发器失效问题求助

这确实是MySQL 5.6版本中主从复制场景下的版本特定行为限制，严格来说不算官方定义的Bug，但确实会导致你遇到的触发器触发不一致问题。

为什么会出现这个问题？ #

在MySQL 5.6中，从库的SQL线程重放主库binlog时，触发器的触发逻辑和5.7+版本有明显差异：

• 当主库使用基于语句的复制（SBR）或混合模式复制时，从库执行INSERT语句是直接重放主库的SQL语句，此时从库上创建的本地AFTER INSERT触发器不会被触发（因为MySQL 5.6认为这是复制过来的语句，跳过了本地触发器执行）。
• 而UPDATE语句在某些场景下（比如使用了非确定性函数、自增主键等）会被自动转为基于行的复制（RBR），此时从库是通过行变更来应用数据，本地的AFTER UPDATE触发器会正常触发。
• MySQL 5.7及以上版本修复了这个逻辑：无论复制模式是SBR还是RBR，从库上的本地触发器（非主库同步过来的）都会在数据变更时被触发，这也是为什么你的方案在5.7中能正常工作。

可行的解决方案 #

1. 切换到基于行的复制（RBR）模式 #

这是最直接解决问题的方法：

• 在Amazon RDS的主库参数组中修改binlog_format = ROW，然后重启主库（或者通过SET GLOBAL binlog_format = 'ROW';动态生效，但需要确保账号有SUPER权限，且RDS参数组的修改需要应用到实例）。
• 切换后，从库会以行模式重放binlog，此时本地的AFTER INSERT触发器会被正常触发。
• 注意：RBR模式会增加binlog的体积，需要评估你的存储和同步带宽是否能承受，但这也是MySQL后续版本的推荐复制模式。

2. 改用CDC工具替代触发器 #

放弃在从库上创建触发器，改用变更数据捕获工具来捕获主库的变更：

• 比如使用Debezium、Maxwell这类开源工具，直接读取主库的binlog来捕获所有INSERT/UPDATE/DELETE事件，然后将事件同步到ExternalDB。
• 优点：不需要在从库上做任何操作，避免了触发器对从库性能的影响，且不受MySQL版本的复制模式限制，同步实时性更好。
• 缺点：需要额外部署和维护工具，有一定的学习成本。

3. 直接轮询MyTable的增量数据 #

如果不想修改复制模式或引入新工具，可以调整同步逻辑：

• 给MyTable添加一个自增主键字段或者时间戳字段（比如last_modified，确保每次INSERT/UPDATE都会更新这个字段）。
• 定期从ReplicaDB查询last_modified大于上次同步最大值的记录，同步到ExternalDB后更新同步标记。
• 优点：逻辑简单，兼容性强，不需要依赖触发器；缺点：同步实时性取决于轮询频率，大量数据时可能会有查询性能损耗。

4. 升级到MySQL 5.7及以上版本 #

如果业务允许，直接将Amazon RDS的MySQL版本升级到5.7或更高：

• 升级后，从库的本地触发器逻辑会和你测试的5.7环境一致，AFTER INSERT触发器能正常触发。
• 优点：一劳永逸，还能获得新版本的性能优化和新特性；缺点：需要提前做兼容性测试，确保业务代码在新版本中正常运行，RDS升级可能会有短暂的维护窗口 downtime。

额外注意事项 #

• 在Amazon RDS从库上创建触发器时，要确保你的账号有SUPER权限，且从库的read_only参数允许创建对象（RDS默认从库是read_only=1，但SUPER权限用户可以绕过这个限制创建触发器）。
• 如果继续使用触发器方案，要尽量简化触发器逻辑，避免复杂操作导致从库复制延迟增加。

内容的提问来源于stack exchange，提问作者Karel