MySQL PITR 是什么
时间点恢复（Point-in-Time Recovery）把实例还原到过去的某一时刻：先恢复一份全量逻辑备份，再从该备份记录的 binlog 位点开始顺序回放日志，停在误操作发生之前的瞬间。停止点选在哪里，直接决定丢失窗口有多大，因此恢复前的信息收集比恢复动作本身更关键。
基本信息
| 前提 | 全量备份含位点记录，且备份之后的 binlog 完整归档 |
|---|---|
| 关键参数 | mysqlbinlog 的 --start-position、--stop-datetime、--stop-position |
| 停止点选择 | 误操作发生前的时刻或位点，宁早勿晚 |
| 推荐做法 | 恢复到新实例验证无误后再切换 |
PITR 流程
PITR 流程
# 1) 还原全量备份
mysql -u root -p < /backup/full-2026-10-11.sql
# 2) 从备份位点开始回放，到误操作前一秒停止
mysqlbinlog --start-position=<备份位点> \
--stop-datetime='2026-10-12 10:29:59' \
/backup/binlog/binlog.000123 /backup/binlog/binlog.000124 | mysql -u root -p
# 3) 核对关键表行数并做业务抽检停止点选择对照
| 停止方式 | 适用情形 | 风险 |
|---|---|---|
| --stop-datetime | 知道误操作发生的大致时刻 | 时区不一致会恢复错时间 |
| --stop-position | 已从日志中定位到具体事务坐标 | 坐标算错会连带重放误操作 |
| --stop-never | 边追日志边供只读查询 | 属于持续同步，不是恢复 |
恢复前的准备动作
- 确认误操作类型与时间：DROP、DELETE、UPDATE 对应的停止点不同，需要先查清再由业务方确认
- 核对日志连续性：确认备份位点到目标时刻之间的 binlog 文件一个不少
- 确认日志格式：ROW 格式下 DML 记录为行事件，回放结果与 STATEMENT 格式不同
- 准备独立环境：恢复到新实例比对，避免在故障库上反复试验造成二次损失
- 演练脚本化：把回放命令写成可重复执行的脚本，减少现场手写出错
停止点取在误操作之后会把错误一并重放；恢复完成后立刻核对关键表行数与业务抽检，确认无误再对外提供服务。
日志过期时间要长于备份周期：若 binlog 在下次备份之前就被清理，恢复链会在中途断档，时间点恢复能力随之失效。