用 binlog2sql 找回误删数据的两小时

周三下午四点，业务在群里发来求救：update 忘了带 where 条件，把一张配置表 3 万行全更新了。表没有备份任务覆盖（讽刺的是正因为"配置表很小"被排除在备份清单外），最近的全量备份是三天前的。最终靠 binlog2sql 两小时完整恢复，过程值得记录。

前提条件先核对：binlog 开着且格式为 ROW（8.0 默认 ROW，这个老库幸好前一年刚切过来），误操作时间点大约在 14:37，之后到发现为止没有其他写入这张表的业务。恢复思路是反向操作：binlog 里记录了每行变更的前像（改动前数据），把这段时间该表的变更全部解析出来，逆序生成反向 SQL 回放即可。

操作过程浓缩如下：

# 1. 定位事故时间段的 binlog 文件
mysqlbinlog --no-defaults -vv mysql-bin.000482   | grep -n -B5 "t_config" | head

# 2. 解析出正向 SQL 先确认影响范围
python binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'***'   --databases=cfgdb --tables=t_config   --start-file='mysql-bin.000482'   --start-datetime='2026-10-14 14:35:00'   --stop-datetime='2026-10-14 14:40:00'   > forward.sql

# 3. 加 -B 生成反向 SQL（update 前像回填）
python binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'***'   --databases=cfgdb --tables=t_config -B   --start-file='mysql-bin.000482'   --start-datetime='2026-10-14 14:35:00'   --stop-datetime='2026-10-14 14:40:00'   > rollback.sql

回放前做了三件事保命：rollback.sql 先在预发库回放验证，抽样比对 20 行数据正确；生产回放放在事务里，比对行数后再提交；从库延迟暂停，避免回放被放大。14:37 到 14:40 之间业务对该表还有 200 多条正常写入，反向 SQL 逆序回放正好把这些变更也"倒掉"了，需要在正向 SQL 里找出这批行手工重放——这是整个恢复里最费人力的部分，也是为什么发现越早恢复越简单。

恢复演练之后把 binlog2sql 的使用门槛也降了下来：预打包成平台工具，输入库名表名和时间范围就能出反向 SQL，并强制先在影子库回放验证。工具越顺手，误操作的恢复速度越快，但也要防止滥用——工具页面上我们加了审批和操作留痕，恢复数据的权限本身就该被管控。

事故后的整改很直接：配置表纳入备份清单，核心表开启延迟 1 小时的延迟从库做"后悔药"，高危 update 强制走带 where 校验的工单系统。工具能救命，但流程才是防复发的药。