MySQL时间点恢复（PITR）需满足：开启binlog且server-id非零、binlog_format为ROW、存在带binlog位置的全量备份、目标时段binlog未被PURGE。
MySQL 时间点恢复（Point-in-Time Recovery，PITR）是指将数据库恢复到某个具体时间点（如某年某月某日某时某分某秒）的状态，通常用于误删数据、错误更新或逻辑损坏后的精准回退。它依赖两个关键组件：全量备份（如 mysqldump 或 xtrabackup 备份） + 二进制日志（binlog）。
确认是否具备时间点恢复的前提条件
不是所有 MySQL 实例都默认支持 PITR，需提前检查并配置：
- binlog 必须开启：检查 my.cnf 中是否有 log-bin = mysql-bin，且 server-id 非零；执行 SHOW VARIABLES LIKE 'log_bin'; 返回 ON 才有效。
- binlog 格式建议为 ROW：执行 SHOW VARIABLES LIKE 'binlog_format';，ROW 模式可精确还原单行变更，避免语句级歧义。
- 已有可用的全量备份：比如某日凌晨 2:00 的物理备份或逻辑备份，并记录下该备份对应的 binlog 文件名和位置（可通过 SHOW MASTER STATUS; 或备份工具输出获取）。
- 从备份时刻到目标恢复时间点的 binlog 必须完整存在：检查 SHOW BINARY LOGS;，确认所需 binlog 文件未被 PURGE 删除。
确定目标恢复时间点和对应 binlog 位置
有两种常用方式定位：
- 按时间筛选：使用 mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-05-10 14:23:00" --stop-datetime="2024-05-10 14:23:30" mysql-bin.000012 查看指定时间段的操作，找到误操作前最后一个安全位置（如 DELETE 前的 COMMIT 或 UPDATE 前的 GTID）。
- 按事件位置截断：若已知误操作大致发生在哪个 binlog 文件及偏移量（例如从备份恢复后执行了 3 条命令，第 4 条出错），可用 mysqlbinlog --start-position=12345 --stop-position=67890 mysql-bin.000013 提取区间日志。
注意：跨文件恢复时，需按 binlog 顺序依次应用，不可跳过中间文件。
执行时间点恢复操作流程
以物理备份（Percona XtraBackup）为例，逻辑备份（mysqldump）步骤类似，仅初始导入方式不同：
- 停止 MySQL 服务，清空数据目录（或准备新路径）。
- 用 xtrabackup --copy-back 恢复全量备份，确保权限正确，启动 MySQL（此时数据停留在备份时刻）。
- 找到备份时记录的 binlog 文件名与 position（如 mysql-bin.000010, 198765），用 mysqlbinlog 将该位置之后、目标时间点之前的日志重放：
mysqlbinlog --skip-gtids --include-gtids='...' mysql-bin.000010 mysql-bin.000011 | mysql -u root -p
若使用 GTID，推荐加 --skip-gtids 并在 MySQL 启动时设置 gtid_mode=ON 和 enforce_gtid_consistency=ON。 - 验证数据：登录 MySQL，检查关键表记录、时间戳、业务状态是否符合预期。
常见问题与注意事项
- 误删库/表无法仅靠 binlog 恢复：DROP DATABASE/TABLE 属于 DDL，binlog 中无行数据，必须依赖备份中该对象的结构与数据。
- 主从环境下优先在从库测试恢复流程，避免影响线上主库。
- GTID 模式下更推荐按 GTID 集合恢复，例如 SET GLOBAL gtid_purged = 'uuid:1-100'; 再导入，比时间/位置更可靠。
- 生产环境建议定期校验备份有效性，包括解压、启动、binlog 连续性检查，避免关键时刻备份不可用。
