Problem entry · machine-readable · 构建与部署

MySQL 误删数据后如何恢复(binlog 闪回)

本页嵌入 #trove-entity JSON(本条目全量结构化数据);全库数据见 /agent/trove.json。

元数据

idmysql-binlog-flashback收录2026-08-30
问题域构建与部署主题分组构建与部署
适用工具mysql · 外部工具

症状

手滑 DELETE 不带 WHERE 全表被删(或 UPDATE 误改全表);数据在 binlog 开启的库中仍有痕迹;重启数据库或继续写入会丢失恢复机会。

原因

binlog(ROW 格式)按事务记录全部 DML;误删 DELETE 是独立事务,其起始 position 之前的写入仍完整保存在 binlog。用 `mariadb-binlog/mysqlbinlog --start-position --stop-position` 精确导出误删前区间并重放,即可恢复到误删前一刻;`--rewrite-db` 可先恢复到新库验证。

解法

1. 止损:`FLUSH TABLES WITH READ LOCK` + 备份 binlog,不重启、不写入;

2. `SHOW BINARY LOGS` + `SHOW BINLOG EVENTS` 定位误删事务起点 position;

3. `mariadb-binlog --start-position=INSERT起点 --stop-position=DELETE起点` 导出闪回 SQL(只含误删前写入);

4. `--rewrite-db` 重放到恢复库验证,确认后切回生产。

验证证据

- 本地实测(2026-08-30,Ubuntu WSL + MariaDB 11.8.6):开启 binlog(ROW)→ 建表插 5 行 → `DELETE FROM orders` 全删 → `SHOW BINLOG EVENTS` 定位(INSERT 事务 869~1335,DELETE 事务 1335 起)→ `--start-position=869 --stop-position=1335` 闪回导出(grep DELETE = 0)→ `--rewrite-db` 重放到恢复库 → 5 行 100% 恢复,内容顺序一致。

- 实测复现日志(2026-08-30)

来源与证据

素材来源:https://www.cnblogs.com/zrui-xyu/p/22563082

验证证据:Evidence details kept locally (2026-08-30)