时间点恢复是什么
时间点恢复是把数据库拉回到过去某一时刻的完整流程，通常用于误删数据、误执行批量更新这类事故之后。它依赖两样东西：一份可用的全量备份，以及从备份位点开始连续未中断的日志归档。标准做法是先把全备恢复到隔离实例，再用归档日志重放到目标时间点之前，校验无误后切流，或者只把受损的表导回生产。
基本信息
| 适用场景 | 误删、误更新、数据错乱后的定点回滚 |
|---|---|
| 前提条件 | 全量备份加从备份位点起连续的日志归档 |
| 目标时间点 | 精确到秒，或定位到事故语句的前一条 |
| 关键工具 | 日志重放工具与服务端导入命令 |
| 执行环境 | 隔离实例，不在故障主库上演练 |
| 结果交付 | 校验后切流，或抽取需要的数据导回 |
标准流程
- 恢复最近一次全量备份到隔离实例，确认实例可用
- 确定目标时间点：以事故操作的时间戳或位点为准，留出安全余量
- 用归档日志重放到目标时间点之前的事件
- 逐段校验关键表数据，与业务日志、对账结果比对
- 决定交付方式：整实例切流，或只把受损表导回生产
- 留存本次重放日志与位点记录，便于复盘与下次加速
重放示例
重放示例
# 恢复到 2026-10-12 09:30:00 之前
mysqlbinlog --stop-datetime="2026-10-12 09:29:59" \
/data/binlog_archive/mysql-bin.000045 \
/data/binlog_archive/mysql-bin.000046 \
| mysql -uroot -p -h drill-host -P3307
# 用位点代替时间时改用 --stop-position，两个边界不要同时指定恢复前的准备
恢复前的准备
mysql -uroot -p -h drill-host -P3307 < /data/backup/all_2026-10-12.sql # 先把全备恢复到隔离实例
ls -l /data/binlog_archive/ | tail -20 # 确认归档日志连续、编号无缺口
# 备份位点要与归档起点对齐，否则中间事件会漏掉关键决策点
| 环节 | 要点 | 风险 |
|---|---|---|
| 目标时间点 | 精确到秒或语句边界 | 越过事故语句等于把误操作又执行一遍 |
| 全备选择 | 离目标点最近且完整的备份 | 备份越早，需要重放的事件越多 |
| 日志连续性 | 位点之间不能有缺口 | 缺口会造成部分变更永久丢失 |
| 执行环境 | 使用隔离实例 | 在故障主库上演练会污染现场 |
| 重放过滤 | 按库或按表过滤减少无关重放 | 过滤规则写错会漏掉数据 |
| 交付方式 | 切流或导回单表 | 切流要一并考虑应用连接与授权 |
| 工具版本 | 重放工具与服务端版本对齐 | 版本差异会导致重放报错 |
不要在故障主库上直接重放做验证：现场一旦被覆盖，事故原因与数据边界都难以还原，先恢复到新实例核对无误再决定切流。
重放边界要留出余量：目标点取在事故语句之前，并同时限定起点与终点参数，避免多放或少放一批事件。
归档日志的连续性靠日常巡检保证：定期核对归档目录的日志编号是否连续、有没有被清理脚本误删，缺一环恢复能力就退化成只能回到全备点。
恢复能力准备清单
- 备份任务与日志保留周期覆盖可接受的恢复窗口
- 定期演练恢复，记录实际耗时与卡点
- 日志归档单独存储，避免与数据目录同盘
- 事故处置流程写清：先停止写入，再定位时间点
- 重放工具版本与服务端版本登记在案
- 恢复后必须做业务数据校验，不能只看实例是否起来
恢复时长决定恢复目标能否达成：把每次演练的实际耗时记下来，才能判断当前备份策略是否支撑业务要求的恢复时间，进而决定是否升级到物理备份方案。