文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程4. 方案实施5. 结果对比6. 风险与复盘每日一句正能量“休息不是放弃而是为了走更远的路。”如同弓弦不能总绷着有效的休息是“耐力”的一部分。1. 背景与问题生产环境误执行 DELETE 或 DROP TABLE 后仅依赖全量备份通常会丢失最近新增的数据。PostgreSQL 的时间点恢复PITR能够结合基础备份与 WAL 日志将数据库恢复到指定时间点是处理误删除、误更新等故障的重要能力。本案例以误删除订单数据为场景演示从故障注入到业务恢复的完整过程并总结演练中常见失败原因。2. 环境与数据环境PostgreSQL 16Linux 9全量备份 WAL 归档数据规模800GB恢复目标RTO ≤ 20 分钟RPO ≤ 1 分钟故障注入DELETEFROMordersWHEREcreate_timeCURRENT_DATE;COMMIT;恢复配置示例# postgresql.conf 恢复配置示例PG 12 使用 postgresql.confPG 11 及以下使用 recovery.conf # 指定 WAL 归档恢复命令%f 为 WAL 文件名%p 为恢复目标路径 restore_command cp /archive/%f %p # 指定恢复目标时间点注意时区建议使用带时区的完整时间格式 recovery_target_time 2026-08-08 10:15:0008 # 达到恢复目标后的动作promote 表示自动提升为主库 recovery_target_action promote # 可选指定恢复到目标时间点之前true 表示恢复到目标时间点之前不含该时刻 # recovery_target_inclusive true3. 复现过程创建基础备份。开启 WAL 归档。注入误删除故障。停止数据库并恢复备份。回放 WAL 至目标时间。启动数据库并验证业务。恢复脚本示例#!/bin/bash# # PostgreSQL PITR 故障演练脚本# 场景误删除 orders 表当天数据通过 PITR 恢复到故障前# 适用PostgreSQL 16 / Linux# 注意本脚本仅用于隔离环境演练严禁直接在生产执行# set-euopipefail# ---------- 全局变量按实际环境修改 ----------PGDATA/var/lib/postgresql/16/main# 数据目录PGHOST127.0.0.1# 数据库主机PGPORT5432# 数据库端口BACKUP_USERbackup_user# 备份用户BACKUP_DIR/backup/base# 基础备份输出目录ARCHIVE_DIR/archive# WAL 归档目录RECOVERY_TARGET2026-08-08 10:15:0008# 恢复目标时间点DB_NAMEappdb# 业务数据库名# ---------- 1. 创建基础备份 ----------# 作用生成全量基础备份作为 PITR 的恢复起点# 注意-Fp 输出普通文件格式-P 显示进度-R 自动生成 standby.signal# -D 指定备份输出目录备份前确保该目录为空或可覆盖echo[1/7] 创建基础备份...pg_basebackup-h$PGHOST-p$PGPORT-U$BACKUP_USER\-Fp-P-R-D$BACKUP_DIR# ---------- 2. 注入误删除故障 ----------# 作用模拟生产误操作删除当天全部订单数据# 注意演练环境务必使用独立测试库避免影响真实业务数据echo[2/7] 注入误删除故障...psql-h$PGHOST-p$PGPORT-d$DB_NAME-c\DELETE FROM orders WHERE create_time CURRENT_DATE; COMMIT;# ---------- 3. 停止数据库 ----------# 作用停止实例为恢复基础备份做准备# 注意恢复前必须确保实例完全停止否则数据目录可能被占用或损坏echo[3/7] 停止数据库实例...pg_ctl-D$PGDATAstop-mfast# ---------- 4. 恢复基础备份 ----------# 作用用基础备份覆盖数据目录回到故障前的物理状态# 注意恢复前先备份原数据目录rm -rf 操作不可逆务必确认路径正确echo[4/7] 恢复基础备份...mv$PGDATA${PGDATA}.bak.$(date%Y%m%d%H%M%S)# 备份原数据目录mkdir-p$PGDATAcp-r$BACKUP_DIR/*$PGDATA/chown-Rpostgres:postgres$PGDATA# ---------- 5. 配置恢复参数 ----------# 作用写入 restore_command 与 recovery_target_time进入恢复模式# 注意PG 12 写入 postgresql.confPG 11 及以下需写 recovery.conf# recovery_target_time 必须带时区且要覆盖故障注入时刻echo[5/7] 配置恢复参数...cat$PGDATA/postgresql.confEOF restore_command cp$ARCHIVE_DIR/%f %p recovery_target_time $RECOVERY_TARGET recovery_target_action promote EOF# ---------- 6. 启动数据库并回放 WAL ----------# 作用启动实例自动回放 WAL 日志至目标时间点# 注意启动后实例处于恢复模式此时只读回放完成后自动提升为主库echo[6/7] 启动数据库并回放 WAL...pg_ctl-D$PGDATAstart# ---------- 7. 业务验证 ----------# 作用确认实例已提升、数据已恢复到目标时间点# 注意pg_is_in_recovery 返回 false 表示已退出恢复模式echo[7/7] 验证恢复结果...psql-h$PGHOST-p$PGPORT-d$DB_NAME-cSELECT pg_is_in_recovery();psql-h$PGHOST-p$PGPORT-d$DB_NAME-c\SELECT COUNT(*) AS orders_total FROM orders;echoPITR 演练完成下面是完整的故障恢复流程图否是创建基础备份开启 WAL 归档注入误删除故障停止数据库恢复基础备份配置 restore_command回放 WAL 至目标时间WAL 是否完整检查归档缺失/损坏提升实例 promote启动数据库业务健康检查验证数据一致性恢复完成4. 方案实施部署/演练流程校验基础备份完整性。验证 WAL 连续性。指定 recovery_target_time。回放日志并提升实例。执行业务健康检查。检查 SQL-- 1. 确认实例已退出恢复模式返回 false 表示已提升为主库SELECTpg_is_in_recovery();-- 2. 对比恢复前后订单总数确认误删除数据已找回-- 恢复前订单总数1,234,567故障注入前快照值-- 预期结果恢复后订单总数应等于恢复前快照值 1,234,567SELECTCOUNT(*)ASorders_total_after_recoveryFROMorders;-- 3. 对比恢复前后 orders 表总行数并输出差异值-- 将恢复前快照值1,234,567与恢复后实际行数做差-- 差异值 0 表示数据完整恢复差异值 0 表示仍有数据缺失需排查 WAL 回放范围-- 异常处理建议若差异值不为 0先核对 recovery_target_time 是否覆盖故障注入时刻-- 再检查 WAL 归档是否连续完整必要时重新执行 PITR 恢复SELECT1234567-COUNT(*)ASorders_row_diffFROMorders;-- 4. 校验关键业务表的数据完整性核对订单明细与订单主表记录数是否一致-- 预期结果order_items_total 应等于恢复前订单明细快照值SELECTCOUNT(*)ASorder_items_totalFROMorder_items;-- 5. 检查最近一天订单是否完整恢复对应故障注入的 DELETE 范围-- 预期结果recent_orders 应等于故障注入前当天订单数且大于 0SELECTCOUNT(*)ASrecent_ordersFROMordersWHEREcreate_timeCURRENT_DATE;-- 6. 抽样核对关键业务表的最大/最小时间戳确认数据与目标恢复时间点一致-- 预期结果max_create_time 应小于等于 recovery_target_time2026-08-08 10:15:0008SELECTMIN(create_time)ASmin_create_time,MAX(create_time)ASmax_create_timeFROMorders;-- 7. 验证 WAL 归档完整性检查归档是否持续正常写入-- archived_count 持续增长说明归档进程正常-- last_archived_time 距今过久说明 WAL 归档可能停滞或失败SELECTarchived_count,last_archived_time,last_failed_time,last_failed_walFROMpg_stat_archiver;常见失败原因WAL 归档缺失或损坏。recovery_target_time 设置错误。restore_command 路径配置错误。基础备份与 WAL 不匹配。故障排查表格故障现象可能原因排查命令解决方案恢复时提示 WAL 文件缺失或损坏WAL 归档缺失或损坏ls /archive/、pg_controldata $PGDATA补齐缺失 WAL 归档或从备份源重新拷贝损坏文件后重试恢复恢复后数据与目标时间点不一致recovery_target_time 设置错误SELECT pg_last_xact_replay_timestamp();核对目标时间点确认时区与时间格式后重新设置 recovery_target_time恢复进程报 restore_command 执行失败restore_command 路径配置错误SELECT * FROM pg_stat_archiver;检查归档目录路径与权限修正 restore_command 中的 cp 命令及参数回放 WAL 时出现记录不连续基础备份与 WAL 不匹配pg_verifybackup、pg_waldump重新创建基础备份确保备份与 WAL 归档来自同一时间线5. 结果对比项目目标实际RTO20分钟17分钟RPO1分钟30秒误删除数据恢复100%100%业务验证通过通过恢复后抽样核对订单数量、交易流水及关键业务接口数据与目标时间点一致。6. 风险与复盘风险未定期验证备份会导致恢复失败。WAL 保留策略过短可能无法完成 PITR。未进行恢复演练时脚本或流程容易失效。复盘建议每季度执行 PITR 演练并记录 RTO、RPO。建立恢复检查清单备份、WAL、配置、权限、业务验证。故障注入应在隔离环境完成避免影响生产。演练结束形成标准报告持续优化恢复脚本与流程。本文围绕部署流程、故障注入、PITR 恢复、RTO/RPO 验证及检查清单展示了误删除恢复的完整实践与常见失败原因分析。转载自https://blog.csdn.net/u014727709/article/details/164124976欢迎 点赞✍评论⭐收藏欢迎指正