导读

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

报错还是1032 Could not execute Update_rows event

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

如果是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;的时候应该会报错啊!

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

又一村

咨询开发发现, 生产导入的时候是使用的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环境)