gt-checksum v4.0.0 新功能解读系列文章(3):反向回滚 SQL

📅 2026/6/29 21:06:50
gt-checksum v4.0.0 新功能解读系列文章(3):反向回滚 SQL
功能简介genRollSQL是 gt-checksum v4.0.0 新增的核心参数配合maxRollRowNum和rollFileDir一起使用用于在生成修复 SQL 的同时自动生成反向回滚 SQL。参数说明参数默认值可选值说明genRollSQLOFFON/OFF/ 自定义表名控制是否生成回滚 SQLmaxRollRowNum10000正整数单表待修复行数超过该阈值时不生成回滚 SQLrollFileDirrollsql目录路径回滚 SQL 文件存储目录三种genRollSQL模式的区别模式行为OFF不生成回滚 SQL默认行为ON对所有校验的表生成回滚 SQL自定义表名仅对指定的表生成回滚 SQL支持逗号分隔多个表名支持%通配符使用方式非常简单在配置文件gc.conf中添加几行genRollSQLONrollFileDirrollsqlmaxRollRowNum10000二、功能作用及使用场景深入解读2.1 为什么需要回滚 SQL在生产环境中执行数据修复面临的风险远比测试环境复杂场景一审计与合规在金融、医疗等对数据变更审计要求严格的行业不仅需要知道改了什么还需要知道怎么改回去。回滚 SQL 是修复操作可审计性的重要组成部分。场景二修复逻辑误判在复杂的类型映射、字符集转换场景下校验工具判定的差异可能只是格式差异而非真实数据差异例如DECIMAL精度差异、utf8mb4_general_civsutf8mb4_0900_ai_ci的 collation 差异。修复后业务验证不通过需要回退。场景三修复导致业务中断修复 SQL 中的DELETE或UPDATE可能与正在运行的业务事务产生锁冲突或者修复了业务正在使用的数据行导致业务报错。此时需要快速回退恢复原状。2.2 回滚逻辑是如何工作的gt-checksum 的回滚 SQL 生成采用反向映射策略对每条修复 SQL生成一条语义相反的回滚 SQL。核心映射关系修复 SQL 类型回滚 SQL 类型说明DELETE FROM ... WHERE ...INSERT INTO ... VALUES(...)目标端删除的行回滚时重新插入INSERT INTO ... VALUES(...)DELETE FROM ... WHERE ...目标端插入的行回滚时删除TRUNCATE TABLE ...特殊处理仅在目标端整表为空时生成详见 2.3DELETE → INSERT 的转换过程修复 SQL 中的DELETE语句包含WHERE条件其中的列-值对就是被删除行的数据。回滚生成器解析WHERE子句提取所有列名和对应的值重新组装为INSERT INTO语句-- 修复 SQLDELETEDELETE FROM db1.orders WHERE id 1001 AND order_no ORD-20260101;-- 回滚 SQLINSERTINSERT INTO db1.orders(id,order_no) VALUES(1001,ORD-20260101);对于有LIMIT子句的 DELETE无主键表场景回滚生成器会先剥离LIMIT再提取 WHERE 条件中的列值对。INSERT → DELETE 的转换过程修复 SQL 中的INSERT语句包含列名和值的完整映射。回滚生成器解析列名和值列表仅使用主键列或唯一键列构建DELETE的WHERE条件-- 修复 SQLINSERTINSERT INTO db1.orders(id,order_no,amount) VALUES(1001,ORD-20260101,99.50);-- 回滚 SQLDELETE仅使用 PK 列 idDELETE FROM db1.orders WHERE id 1001;NULL 值的特殊处理在 WHERE 条件中NULL值不能用 NULL表达回滚生成器会自动转换为IS NULL-- 修复 SQLDELETE FROM db1.users WHERE id 500 AND email IS NULL;-- 回滚 SQLINSERT INTO db1.users(id,email) VALUES(500,NULL);2.3 TRUNCATE 回滚整表为空时的特殊处理当目标端表在校验开始前整表为空行数为 0时修复 SQL 会是大量INSERT语句。如果逐行生成回滚 DELETE文件会非常大。此时 gt-checksum 采用一种更高效的策略生成单条TRUNCATE TABLE回滚语句忽略maxRollRowNum参数限制。关键安全约束只有校验开始前已确认目标端整表为空精确COUNT(*)为 0时才会生成 TRUNCATE 回滚。程序不会因为某个 chunk 的目标端为空就推断整张表为空——否则目标端非空但恰好某个 chunk 无数据时会误生成整表 TRUNCATE回滚这将导致回滚时丢失目标端原有的有效数据。同时当 TRUNCATE 回滚已生成后后续的逐行 INSERT 修复对应的回滚 DELETE 会被抑制避免回滚时先 TRUNCATE 再逐行 DELETE 的重复操作。⚠️重要提醒TRUNCATE 属于 DDL 操作执行时会隐式提交当前事务。使用 TRUNCATE 回滚 SQL 前需人工评估其影响。2.4 回滚 SQL 文件的生成与管理文件存储结构回滚 SQL 文件统一存储在rollFileDir目录默认rollsql下文件命名规则为rollsql/table.{schema}.{table}.rollback-{TYPE}-{seq}.sql其中{TYPE}为INSERT、DELETE或TRUNCATE{seq}为文件序号。例如rollsql/table.db1.orders.rollback-INSERT-1.sqlrollsql/table.db1.orders.rollback-DELETE-1.sqlrollsql/table.db1.users.rollback-TRUNCATE-1.sql文件内容格式每个回滚 SQL 文件包含完整的事务边界和会话设置SET FOREIGN_KEY_CHECKS0;SET UNIQUE_CHECKS0;BEGIN;DELETE FROM db1.orders WHERE id 1001;DELETE FROM db1.orders WHERE id 1002;COMMIT;BEGIN;DELETE FROM db1.orders WHERE id 1003;COMMIT;自动滚动切分当单个回滚 SQL 文件的语句数量或文件大小超过阈值由fixTrxNum和fixTrxSize参数控制时会自动创建新的文件。这确保了单个文件不会过大便于人工审计和分批执行。与 datafixtable 的配合关系当datafixtable在线修复模式时修复 SQL 会直接在目标端执行。但回滚 SQL始终只写文件不在线执行——这是刻意的安全设计。回滚 SQL 写入rollFileDir目录后需要人工审计确认无误再通过repairDB ./rollsql执行回滚。2.5 无主键表的 DELETE 合并优化对于没有主键和唯一键的表修复 SQL 中可能出现多条DELETE ... WHERE ... LIMIT 1语句其 WHERE 条件完全相同因为同一组值可能在目标端出现多次。gt-checksum 的回滚写入器内置了mergeDuplicateDeleteLimits优化-- 优化前3 条相同 WHERE 的 DELETEDELETE FROM db1.log_data WHERE ts 2026-01-01 AND msg test LIMIT 1;DELETE FROM db1.log_data WHERE ts 2026-01-01 AND msg test LIMIT 1;DELETE FROM db1.log_data WHERE ts 2026-01-01 AND msg test LIMIT 1;-- 优化后合并为 1 条LIMIT 累加DELETE FROM db1.log_data WHERE ts 2026-01-01 AND msg test LIMIT 3;这个优化仅在表无主键/唯一键时生效因为有主键表的每条 DELETE 的 WHERE 条件天然不同。2.6 与断点续传的配合当resumeON且任务中断后续传时回滚 SQL 的处理同样遵循安全原则续传开始时已有的回滚 SQL 文件会经过完整性截断定位到最后一个完整的COMMIT边界截断后续不完整的内容如果续传时某个表需要重新校验对应的旧回滚 SQL 文件会被清理后重新生成回滚文件的序号会从上次中断的位置继续不会覆盖已完整写入的文件2.7 回滚 SQL 的执行方式生成回滚 SQL 后需要人工审计确认无误然后通过repairDB工具执行# 审计回滚 SQL 文件ls -la rollsql/# 使用 repairDB 执行回滚repairDB ./rollsql