[MYSQL] 再遇1032主从不一致, 测试和生产一样的操作, 生产主从正常, 测试却主从异常

导读

前段时间遇到主从不一致,虽然找不到原因了, 但已修复. 然后最近又遇到一个主从不一致的案例, 而且生产做同样的操作主从就正常,测试就主从就不同步了; 好在这次找到原因了, 故分享分享

报错还是1032 Could not execute Update_rows event

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜

如果是mts的话,这里看不到具体的表,只能看事务级别的信息.要看表的话,可以查询performance_schema.replication_applier_status_by_worker

分析过程

这个报错原因还是很简单的, 就是主从数据不一致. 那么原因呢?

初窥原因未果

常见的原因有如下:

常见的原因都未命中, 那应该就是主库存在未记录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;

不但没找到原因, 还更离谱了, 生产导入的时候为啥会写binlog啊?

诶,生产是使用业务账号导入数据的啊, 那执行SET @@SESSION.SQL_LOG_BIN= 0;的时候应该会报错啊!

DeepSeek

幻方量化公司旗下的开源大模型平台

下载

又一村

咨询开发发现, 生产导入的时候是使用的source xxx.sql方式导入的, 该方式是交互式的, 不会因为SET @@SESSION.SQL_LOG_BIN= 0;执行失败而终止, 和mysql --force 类似; 所以生产导入的时候未报错,且同步到从库去了.

查看测试发现, 测试使用的是root账号source导入的, 也就是SET @@SESSION.SQL_LOG_BIN= 0;执行成功了, 不会记录相关binlog.

也就是生产和测试操作是一样的, 但使用的账号不一致,导致生产主从正常,而测试主从异常.

总结

往小了说是: 操作账号不一致导致的主从数据不一致.

往大了说是: 操作不规范.

这次的情况但凡有一个操作不对, 都能提早发现的. 只能说这TM就是巧合!

参考:

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;

有兴趣的可以分析分析这张表当前是否使用了压缩. (5.7环境)