元数据
| id | mysql-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)