导读
前段时间遇到主从不一致,虽然找不到原因了, 但已修复. 然后最近又遇到一个主从不一致的案例, 而且生产做同样的操作主从就正常,测试就主从就不同步了; 好在这次找到原因了, 故分享分享
报错还是1032 Could not execute Update_rows event
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004519371.jpg)
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://www.chuangxiangniao.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
如果是mts的话,这里看不到具体的表,只能看事务级别的信息.要看表的话,可以查询performance_schema.replication_applier_status_by_worker
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004687509.jpg)
分析过程
这个报错原因还是很简单的, 就是主从数据不一致. 那么原因呢?
初窥原因未果
常见的原因有如下:
从库有业务写入从库是只读的, 也没有业务连接, 故排除此选项搭建的时候主从就不一致搭建的时候是全库导出导入的, 数据是一致的. 故也排除.
常见的原因都未命中, 那应该就是主库存在未记录binlog的事务了. 也就是有”某人”设置了sql_log_bin=off, 而只有UPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s)权限的账号才能设置这个变量, 业务账号无此权限 现有环境只有root才有这个权限, 但root是不允许业务使用的.
再一次把路堵死了
再一次把路堵死了. 我们看下报错时间,发现是2025.11.dd hh:mm:ss, 之前数据一直是同步的, 而且延迟为0, 也就是说这一刻附近做了啥骚操作,导致主从数据不一致的; 查看下history,发现该时间点存在一个登录操作. 难道这就是内鬼? 咨询业务发现在该时间存在数据导入操作.
柳暗花明
我们知道高版本的mysqldump导出的’.sql’文件是有申明SET @@SESSION.SQL_LOG_BIN= 0;的, 也就是不记录binlog, 而从库未做数据导入操作, 那问题不就又结了么. 但开发说: 生产也是这样导入的啊, 主从都是正常的.
查看监控发现,生产导入时,存在大量binlog写入, 也就是生产导入的时候有写binlog.
怀疑生产是低版本,毕竟都会先升级测试后才会升级生产, 而且低版本确实存在写binlog的情况. 但遗憾的是生产测试版本均一致;且未发生过版本变动情况. 查看导入的’.sql’文件均发现存在SET @@SESSION.SQL_LOG_BIN= 0;
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004633821.jpg)
不但没找到原因, 还更离谱了, 生产导入的时候为啥会写binlog啊?
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004615332.jpg)
诶,生产是使用业务账号导入数据的啊, 那执行SET @@SESSION.SQL_LOG_BIN= 0;的时候应该会报错啊!
PicDoc
AI文本转视觉工具，1秒生成可视化信息图
6214 查看详情
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004680877.jpg)
又一村
咨询开发发现, 生产导入的时候是使用的source xxx.sql方式导入的, 该方式是交互式的, 不会因为SET @@SESSION.SQL_LOG_BIN= 0;执行失败而终止, 和mysql --force 类似; 所以生产导入的时候未报错,且同步到从库去了.
查看测试发现, 测试使用的是root账号source导入的, 也就是SET @@SESSION.SQL_LOG_BIN= 0;执行成功了, 不会记录相关binlog.
也就是生产和测试操作是一样的, 但使用的账号不一致,导致生产主从正常,而测试主从异常.
总结
往小了说是: 操作账号不一致导致的主从数据不一致.
往大了说是: 操作不规范.
这次的情况但凡有一个操作不对, 都能提早发现的. 只能说这TM就是巧合!
![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004610646.jpg)
参考:
https://dev.mysql.com/doc/refman/8.0/en/set-sql-log-bin.html
https://dev.mysql.com/doc/refman/8.0/en/system-variable-privileges.html
题外话
前段时间,有位大佬发现当对一张表多次修改row_format之后就无法判断是否是压缩的了. 参考sql
drop table if exists db1.t20251117;create table db1.t20251117(id int primary key, c1 int, c2 int, key(c1))row_format=dynamic;show create table db1.t20251117;alter table db1.t20251117 row_format=compressed KEY_BLOCK_SIZE=8;show create table db1.t20251117;alter table db1.t20251117 row_format=dynamic KEY_BLOCK_SIZE=0;show create table db1.t20251117;![[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常](https://cdn.chuangxiangniao.com/www/2025/12/176414004768271.jpg)
有兴趣的可以分析分析这张表当前是否使用了压缩. (5.7环境)
以上就是[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/985841.html
微信扫一扫 
支付宝扫一扫 
