故障分析总结

• 原因：开发误操作删除了订单表并提交事务，导致生产库中该表及其数据缺失。
• 环境特征：PostgreSQL 已开启归档与 WAL。具备进行基于归档的时间点恢复（PITR）的条件。
• 影响范围：订单表本身及依赖对象（索引、约束、触发器、序列等）。若为 DROP TABLE，依赖对象同时丢失；若为 DELETE，结构存在但数据丢失。
• 恢复策略：在隔离实例基于最近一次可用基线备份+WAL执行 PITR，恢复到误删前 5 分钟；在只读窗口校验数据；确认无误后将隔离实例提升为可写，使用逻辑复制将订单表回灌至生产库；回灌期间对生产库相关对象维持只读。

恢复步骤详情（操作清单）

以下步骤按顺序执行。命令以占位符表示，请替换为您的实际路径、主机、端口、实例名和凭据。示例适配 PostgreSQL 12–16（请以您的主版本为准）。

0. 前置准备与冻结窗口

1. 明确误删时间点：
   • 如果为 DROP TABLE/DELETE 的执行时间记入了审计/应用日志/数据库日志，请获取准确时间戳 T_drop。
   • 目标恢复时间 T_target = T_drop - 5 分钟。
2. 在生产库冻结与订单表相关的写入（保证回灌一致性）：
   • 如果表已被 DROP：无需额外冻结，但需冻结与之相关的写入逻辑（避免提前重建/写入同名表）。
   • 如果是 DELETE：对该表设为只读（回收 DML 权限），并约束应用不再写入。 示例（按需调整角色名、模式名与表名，下同）：
     • 记录原权限： SELECT pg_get_userbyid(relowner) owner, relacl FROM pg_class c JOIN pg_namespace n ON n.oid=c.relnamespace WHERE n.nspname='public' AND c.relname='orders';
     • 撤销应用角色写权限（保留超级/DBA权限）： REVOKE INSERT, UPDATE, DELETE ON TABLE public.orders FROM app_role;
3. 确认可用备份链：
   • 找到早于 T_target 的最近一次基线备份（物理全备，称为 BaseBackup）。
   • 确认从该基线备份点到 T_target 的 WAL 归档完整可用。

1. 准备隔离恢复实例

1. 准备同主版本 PostgreSQL 的隔离主机/实例（CPU/内存/磁盘足够，区域/时区/本地化与生产一致，尤其 encoding/collation/ctype）。
2. 创建数据目录并设置权限： sudo mkdir -p /pgdata/recovery sudo chown postgres:postgres /pgdata/recovery sudo chmod 700 /pgdata/recovery
3. 从备份介质恢复基线备份至数据目录（以文件级拷贝为例，替换为您的备份工具恢复命令）： rsync -a /backup/basebackup/YYYYMMDD/ /pgdata/recovery/
4. 准备 WAL 归档挂载点（供 restore_command 读取）：
   • 假设归档目录为 /pgwal/archive，确保 postgres 用户可读。

2. 配置并执行 PITR 到目标时间

1. 编辑 /pgdata/recovery/postgresql.conf（如使用 include，请按需调整位置）：
   • hot_standby = on # 恢复期间允许只读查询
   • restore_command = 'cp /pgwal/archive/%f %p' # 从归档取 WAL 文件的可靠命令（保证失败返回非 0）
   • recovery_target_time = '2025-12-03 10:25:00+08' # 示例：替换为 T_target
   • recovery_target_timeline = 'latest'
   • recovery_target_action = 'pause' # 到达目标点后暂停，保持只读窗口 注意：
   • 时间戳请使用明确时区或与系统时区一致。
   • 若归档在其他介质，请将 restore_command 替换为相应可用的安全命令，确保校验/失败返回码正确。
2. 创建恢复信号文件：
   • touch /pgdata/recovery/recovery.signal
3. 启动实例： pg_ctl -D /pgdata/recovery -l /pgdata/recovery/logfile start
4. 监控恢复进度：
   • tail -f /pgdata/recovery/logfile
   • 期望日志出现 “reached recovery target, paused” 字样。
   • 会处于只读、已暂停状态： psql "host=... port=... dbname=... user=... sslmode=prefer" -c "select pg_is_in_recovery();" 返回：t
   • 可确认回放 LSN： SELECT pg_last_wal_replay_lsn();

3. 只读窗口内的数据验证（初检）

1. 确认对象存在（若为 DROP TABLE 场景尤其重要）： \dt+ public.orders
2. 基础核对（替换条件与列名）：
   • 行数： SELECT count(*) FROM public.orders;
   • 主键/业务键样本抽查： SELECT * FROM public.orders WHERE id IN (....);
   • 时间边界（确保数据早于 T_drop）： SELECT min(created_at), max(created_at) FROM public.orders;
3. 如需重复 PITR（目标时间不理想）：
   • 停库并清空数据目录，重新从基线备份恢复，调整 recovery_target_time，重复 2–3 步骤。
   • 注意：PITR 不是可回退操作，需从备份重新开始一次新的恢复流程。

4. 提升为独立可写（为逻辑复制做准备）

1. 确认 wal_level=logical（发布端要求）。如当前为 replica 或 minimal：
   • 在只读恢复状态下无法更改，需先提升，再重启生效。
2. 提升实例（结束暂停，成为新时间线的独立主库）： pg_ctl -D /pgdata/recovery promote 或 SELECT pg_promote(); 此时：SELECT pg_is_in_recovery(); 返回 f
3. 设置逻辑复制相关参数（如未满足）并重启： ALTER SYSTEM SET wal_level = 'logical'; ALTER SYSTEM SET max_wal_senders = 10; ALTER SYSTEM SET max_replication_slots = 10; SELECT pg_reload_conf(); 如 wal_level 由非 logical 升至 logical 需重启： pg_ctl -D /pgdata/recovery restart
4. 确保网络连通与访问权限（pg_hba.conf 允许生产库作为订阅端连接；仅开放必要白名单与最小权限账户）。

5. 在恢复实例上创建发布（仅发布订单表）

1. 确认表的复制标识（REPLICA IDENTITY）。若需要基于主键的 UPDATE/DELETE，请确保主键或唯一索引存在；若无，设置为 FULL 会有性能代价： -- 若无合适主键，谨慎使用： ALTER TABLE public.orders REPLICA IDENTITY FULL;
2. 创建发布： CREATE PUBLICATION p_orders FOR TABLE public.orders WITH (publish = 'insert,update,delete');

6. 在生产库准备订阅与只读窗口

1. 生产库上创建与源一致的表结构（DROP TABLE 场景必做；DELETE 场景建议 TRUNCATE 再回灌）：
   • 从恢复实例导出表结构并在生产执行： pg_dump -s -t public.orders -h <recovery_host> -p <recovery_port> -U | psql -h <prod_host> -p <prod_port> -U <prod_db>
   • 如存在序列、触发器、索引、检查/外键约束，同样会包含在 -s 的定义中（注意跨表外键顺序与依赖，必要时先不验证约束，回灌后再 VALIDATE）。
2. 维持/加强生产只读窗口（避免竞态写入）：
   • 确保应用层面阻止对 public.orders 的写操作。
   • 数据库侧撤销 DML 权限： REVOKE INSERT, UPDATE, DELETE ON TABLE public.orders FROM app_role;
   • 若存在引用该表的外键，考虑暂时将相关 DML 限制到最小，避免约束校验异常。
3. 创建用于订阅的最小权限账号（在恢复实例上）：
   • 仅授予连接、复制所需权限与对发布表的 SELECT： CREATE ROLE sub_user LOGIN PASSWORD '***'; GRANT SELECT ON TABLE public.orders TO sub_user; -- 如使用物化初始快照，不需要对所有对象授权，仅发布表需读权限。
4. 在生产库创建订阅（pull 模式，从恢复实例拉取）： CREATE SUBSCRIPTION s_orders CONNECTION 'host=<recovery_host> port=<recovery_port> dbname= user=sub_user password=*** sslmode=prefer' PUBLICATION p_orders WITH (copy_data = true, create_slot = true, enabled = true); 注意：
   • 若生产上表已有部分数据且需先清空，请在创建订阅前执行 TRUNCATE public.orders;（谨慎！确认已做全量备份与只读窗口）
   • 如果需要限制带宽/批量大小，可在网络与资源侧做限流；避免影响生产。

7. 监控复制、完成回灌与解除只读

1. 监控复制进度（生产库）： SELECT subname, status, received_lsn, latest_end_lsn, sync_state, stats_reset FROM pg_stat_subscription; 检查初始快照是否完成（状态变为 replicating，且无报错）。
2. 基础校验（生产库 vs 恢复实例）：
   • 行数对比（大表可抽样分段对比）： -- 生产： SELECT count() FROM public.orders; -- 恢复： SELECT count() FROM public.orders;
   • 关键指标对比（替换列为业务关键字段）： SELECT min(created_at), max(created_at) FROM public.orders; SELECT count(distinct customer_id) FROM public.orders; SELECT sum(total_amount) FROM public.orders;
   • 序列值（如有自增主键）： -- 恢复端： SELECT setval('public.orders_id_seq', (SELECT max(id) FROM public.orders)); -- 生产端（回灌完成后同样设置一次，确保后续写入不回卷）： SELECT setval('public.orders_id_seq', (SELECT max(id) FROM public.orders));
   • 抽样一致性（相同采样条件）： SELECT md5(string_agg(id::text, ',' ORDER BY id)) FROM (SELECT id FROM public.orders ORDER BY id LIMIT 100000) t; -- 大表可分段或分桶比对
3. 如存在约束在建表时设为 NOT VALID，回灌完成后进行验证（生产库）： ALTER TABLE public.orders VALIDATE CONSTRAINT ;
4. 解除订阅并保留数据（生产库）： ALTER SUBSCRIPTION s_orders DISABLE; DROP SUBSCRIPTION s_orders WITH (drop_slot = true);
5. 恢复生产库应用角色对该表的写权限： GRANT INSERT, UPDATE, DELETE ON TABLE public.orders TO app_role;
6. 更新统计信息（生产库）： ANALYZE public.orders;

验证检查清单

• 元数据一致性
  • 表、索引、触发器、约束、序列是否与恢复实例一致（pg_dump -s 对比）。
  • 所有相关 schema/search_path 与所有权、权限正确。
• 数据一致性
  • 行数、关键汇总字段（金额/数量）、时间边界一致。
  • 随机/分段抽样校验（按主键范围或哈希分桶）。
  • 序列当前值 setval 已与最大主键同步。
• 外键与完整性
  • 相关外键 VALIDATE 通过，无孤儿记录。
  • 触发器状态正常（未被禁用或误保留为 replica 触发器的特殊状态）。
• 性能与可用性
  • 索引可用（无 invalid 索引），reindex 非必需但可按需做。
  • 查询计划合理（ANALYZE 后检查关键 SQL 的执行计划）。
  • 应用读写恢复正常，错误日志无异常。
• 复制链路收尾
  • 订阅已删除、复制槽已释放。
  • 恢复实例保留/下线策略明确（避免被误连）。

预防建议

• 权限与保护
  • 生产库对 DROP/DELETE 等高危操作实施更严格权限与变更流程；引入行级/对象级审计。
  • 在变更窗口启用“保护模式”（禁止 DDL 或需审批）。
• 备份与恢复演练
  • 固化基线全备与 WAL 归档合规性巡检（可自动校验备份链完整性）。
  • 定期在隔离环境演练 PITR 与单表回灌流程，记录目标时间选择与操作手册。
• 逻辑复制与单表恢复预案
  • 为关键大表预置逻辑复制参数（wal_level=logical、replication slots 额度），降低紧急恢复配置时间。
  • 为关键表维护最新结构脚本（含序列/索引/约束），便于一键重建。
• 变更审计与告警
  • 启用 pgaudit/日志增强，关键 DDL/DML 变更触发告警，缩短发现误操作与恢复窗口。
• 最小化业务中断
  • 在应用层实现只读切换开关；预置按租户/业务域的细粒度写入冻结能力。
  • 为大表复制设定维护时段与性能隔离（I/O/网络限流、并发控制）。

紧急联系方式（官方资源）

• PostgreSQL 官方文档（恢复与 PITR）：https://www.postgresql.org/docs/current/continuous-archiving.html
• PostgreSQL 官方文档（逻辑复制）：https://www.postgresql.org/docs/current/logical-replication.html
• PostgreSQL 官方文档（备份与恢复）：https://www.postgresql.org/docs/current/backup.html
• PostgreSQL 社区支持与邮件列表：https://www.postgresql.org/list/

附：回退计划（异常场景应对）

• PITR 校验失败（目标点不理想）
  • 停止恢复实例，清空数据目录，重新从相同基线备份恢复；调整 recovery_target_time，重复恢复与校验。
• 生产端回灌异常（如冲突/复制失败）
  • 立即 DISABLE 订阅：ALTER SUBSCRIPTION s_orders DISABLE;
  • 记录错误，必要时 DROP SUBSCRIPTION s_orders WITH (drop_slot = true);
  • 将生产表重命名备份：ALTER TABLE public.orders RENAME TO orders_bak_yyyymmdd;
  • 重新以 schema 脚本创建空表，重新创建订阅并回灌；或用 pg_dump/pg_restore 从恢复实例直接导入数据。
• 数据验收不通过
  • 撤销本次回灌：在生产删除回灌所得表或回滚到回灌前快照（若有）；保持只读，重新核对 T_target 与数据来源后再执行。
• 安全兜底
  • 在回灌前对生产目标库（或目标表）做一次快速逻辑备份： pg_dump -h -p -U -Fc -t public.orders -f /backup/prod_orders_pre_restore.dump
  • 保留恢复实例，不要立即销毁，直到生产验收通过一段时间。

故障分析总结

• 根因：主节点 AOF（Append Only File）尾部损坏，导致 Redis 启动加载 AOF 失败。哨兵（Sentinel）已将业务切换到从节点，新主已在服务。
• 影响：新主上的数据可能缺失主节点上最后一段未复制的写入（RPO≈秒级）。旧主上的 AOF 不可直接加载，直接启动可能加剧损坏或污染数据。
• 目标：在不影响线上新主稳定性的前提下，基于损坏前的 AOF 可恢复部分，回补丢失/热点键；校验一致性；重建主从与持久化策略，降低未来风险。

恢复步骤详情

以下步骤默认新主已稳定对外服务。所有修复操作均在隔离环境对“文件副本”进行，避免二次损坏。

0. 稳定与准备

• 确认当前主从角色：
  • 新主：稳定对外，拒绝在旧主恢复前进行任何拓扑变更。
  • 旧主：保持关闭状态，禁止自动拉起和对外服务。
• 备份与留痕（务必执行）：
  • 备份新主当前持久化文件（RDB/AOF，如有）：冷拷贝保存。
  • 备份旧主所有持久化文件：appendonly.aof、appendonly.aof.*、appendonly.aof.manifest、dump.rdb 等。
  • 收集应用侧或监控侧热点 Key 列表（若无，后续可临时扫描估计）。

示例（在旧主机器）：

mkdir -p /tmp/redis_aof_recovery
cp -a /data/redis/appendonly.aof* /tmp/redis_aof_recovery/ 2>/dev/null || true
cp -a /data/redis/dump.rdb /tmp/redis_aof_recovery/ 2>/dev/null || true

1. 在隔离环境修复 AOF（只对副本操作）

• 校验并尽可能修复（修复实际是“截断到最后一个完整命令”，可能丢弃损坏尾部；仅在副本上操作，避免直接损失）：

  • 单文件 AOF：

    redis-check-aof --fix /tmp/redis_aof_recovery/appendonly.aof
    

  • 多分段 AOF（Redis 7+，带 manifest）：

    redis-check-aof --fix /tmp/redis_aof_recovery/appendonly.aof.manifest
    

  注意：

  • 该修复会截断不完整尾部，属于最小破坏性、官方工具支持的安全做法，但仍可能无法包含最后极少量未落盘写入。

• 启动隔离“恢复实例”（不对外，回环地址/受保护）加载修复后的 AOF：

  cat > /tmp/redis_aof_recovery/redis-recovery.conf <<'EOF'
  port 6390
  bind 127.0.0.1
  protected-mode yes
  dir /tmp/redis_aof_recovery
  dbfilename dump-recovery.rdb
  appendonly yes
  appendfilename appendonly.aof
  daemonize yes
  EOF
  
  redis-server /tmp/redis_aof_recovery/redis-recovery.conf
  redis-cli -p 6390 PING   # 期望返回 PONG
  

  验证加载是否正常：

  redis-cli -p 6390 INFO persistence | egrep 'loading|aof_last_write_status|aof_rewrite_in_progress'
  redis-cli -p 6390 DBSIZE
  

2. 识别并回补“丢失/热点键”

优先处理业务关注的“热点 Key”，在线、无停机回补到新主。

• 获取热点 Key 列表（优先使用应用/监控侧清单；若缺失可临时估算）：

  • 方式A（推荐）：从监控/日志/应用清单导出热点 keys -> hotkeys.txt
  • 方式B（谨慎使用，可能对大集群有开销）：在新主估算热点

    redis-cli -h <new_master_ip> -p 6379 --hotkeys 2>/dev/null | awk '{print $2}' > hotkeys.txt
    

    注：该方法基于 SCAN + OBJECT FREQ，在未启用 LFU 策略时只是近似。

• 对比恢复实例与新主，差异回补（仅迁移缺失或不一致的键，避免覆盖正确数据）：

  • MIGRATE 可保留 TTL，整键原子拷贝，适合小批量关键键在线回补。
  • 若新主启用 ACL，请使用 AUTH2；无 ACL 用 AUTH 或省略。

示例（无 ACL）：

# 逐键对比 DUMP（序列化值）与 TTL，不一致则从恢复实例迁移到新主
while read k; do
  # 恢复实例存在该键？
  if [ "$(redis-cli -p 6390 EXISTS "$k")" = "1" ]; then
    # 新主不存在则直接迁移
    if [ "$(redis-cli -h <new_master_ip> -p 6379 EXISTS "$k")" != "1" ]; then
      redis-cli -p 6390 MIGRATE <new_master_ip> 6379 "" 0 3000 REPLACE KEYS "$k"
    else
      # 均存在则比对序列化值，差异则覆盖
      d1=$(redis-cli -p 6390 --raw DUMP "$k" | base64)
      d2=$(redis-cli -h <new_master_ip> -p 6379 --raw DUMP "$k" | base64)
      if [ "$d1" != "$d2" ]; then
        redis-cli -p 6390 MIGRATE <new_master_ip> 6379 "" 0 3000 REPLACE KEYS "$k"
      fi
    fi
  fi
done < hotkeys.txt

示例（有 ACL）：

redis-cli -p 6390 MIGRATE <new_master_ip> 6379 "" 0 3000 AUTH2 <user> <pass> REPLACE KEYS <k1> <k2> ...

说明：

• MIGRATE 默认保留 TTL，REPLACE 仅在确认差异或缺失时使用，避免误覆盖。
• 对于特别大的值或大量键，建议分批执行并监控时延。

3. 可选：扩大校验范围（非热点）

• 若需要进一步降低数据差异风险，可在低峰期基于 SCAN 分批抽样比对（谨慎控制速率）：
  • 在恢复实例 SCAN -> 对应新主 EXISTS/DUMP 对比 -> 差异再 MIGRATE。
  • 强烈建议批量、限速、离峰执行，避免影响线上。

4. 让旧主以“干净从库”身份重新加入

为避免旧主因损坏文件污染拓扑，建议以“空数据 + 全量同步”的方式重入。

在旧主机器：

# 停旧实例，隔离旧数据
systemctl stop redis || true
mkdir -p /data/redis.bad
mv /data/redis/appendonly.aof* /data/redis.bad/ 2>/dev/null || true
mv /data/redis/dump.rdb /data/redis.bad/ 2>/dev/null || true

# 配置为新主的从库（redis.conf 或运行时）
# redis.conf 增加：
# replicaof <new_master_ip> 6379
# replica-read-only yes
# appendonly yes

systemctl start redis
redis-cli -h <old_master_ip> INFO replication | egrep 'role|master_host|master_sync_in_progress'

等待 full sync 完成后，旧主即作为健康从库存在。

5. 重建持久化与基线备份（在新主）

• 确认持久化策略（RDB + AOF）：

redis-cli -h <new_master_ip> CONFIG SET appendonly yes
redis-cli -h <new_master_ip> CONFIG SET appendfsync everysec
redis-cli -h <new_master_ip> CONFIG SET auto-aof-rewrite-percentage 100
redis-cli -h <new_master_ip> CONFIG SET auto-aof-rewrite-min-size 64mb
redis-cli -h <new_master_ip> CONFIG REWRITE

• 生成干净基线文件并落盘备份：

redis-cli -h <new_master_ip> BGREWRITEAOF
redis-cli -h <new_master_ip> BGSAVE
# 将新生成的 AOF/RDB 做离机/异地备份

6. Sentinel 与写安全加固

• Sentinel 健康与仲裁：

redis-cli -p <sentinel_port> SENTINEL masters
redis-cli -p <sentinel_port> SENTINEL ckquorum <master_name>
redis-cli -p <sentinel_port> SENTINEL slaves <master_name>

• 写安全（防止“零副本写入”导致再故障时丢数据）：

redis-cli -h <new_master_ip> CONFIG SET min-replicas-to-write 1
redis-cli -h <new_master_ip> CONFIG SET min-replicas-max-lag 5
redis-cli -h <new_master_ip> CONFIG REWRITE

验证检查清单

• 关键数据一致性
  • 抽样热点 Key（至少前 N 个）检查：TYPE、EXISTS、PTTL、DUMP 一致。
  • 执行过 MIGRATE 的键复查一次，确认值与 TTL 正确。
• 主从与哨兵
  • 新主：INFO replication 中 role=master，connected_slaves ≥ 1。
  • 旧主：ROLE 返回 slave，master_link_status=up，master_sync_in_progress=0。
  • Sentinel：SENTINEL ckquorum 通过；仅有一个主节点。
• 持久化健康
  • INFO persistence 中：
    • aof_enabled=1
    • aof_last_bgrewrite_status=ok
    • rdb_last_bgsave_status=ok
    • loading=0
• 性能与稳定性
  • 延迟与慢查询：redis-cli --latency（或监控平台）无异常峰值；SLOWLOG 中无异常堆积。
  • 磁盘与文件系统：空间充足，IO 正常，AOF 文件大小与增长速率符合预期。

预防建议

• 文件与落盘安全
  • 使用 Redis 7+ 多分段 AOF（manifest），开启 aof-use-rdb-preamble（默认开启），便于损坏时快速恢复。
  • 采用 appendfsync everysec（性能/安全折中），并保留 aof-load-truncated yes（默认）以在尾部截断情况下可自动加载，但需配合告警。
  • 定期 BGREWRITEAOF，设置合理阈值（如 100%、64MB）避免 AOF 过度膨胀。
  • 启用 stop-writes-on-bgsave-error yes（默认）防止持久化异常时继续写入。
• 拓扑与写入保护
  • 设置 min-replicas-to-write / min-replicas-max-lag，确保至少有一个同步良好的副本在线时才接受写入，降低故障瞬间的数据丢失风险。
  • 哨兵参数合理化（down-after-milliseconds、failover-timeout、parallel-syncs），避免误判和长时间不可用。
• 备份与演练
  • 定期冷备 AOF/RDB（含异地/对象存储），并进行真实恢复演练，确保 RTO/RPO 满足业务目标。
  • 监控 aof_last_write_status、aof_last_bgrewrite_status、rdb_last_bgsave_status、disk/IO 指标，异常及时告警。
• 系统层面
  • 确保宿主机磁盘与文件系统稳定（磁盘健康、无频繁掉电、禁用不稳定硬盘缓存；生产环境建议使用稳定的存储阵列与电源保护）。
  • 限制操作系统层面对 Redis 进程的 OOM 风险，避免因内存压力触发进程被杀导致文件损坏。

紧急联系方式

• Redis 官方文档（参考命令与恢复流程）
  • AOF 持久化与恢复：https://redis.io/docs/latest/operate/oss/persistence/aof/
  • redis-check-aof 工具说明：https://redis.io/docs/latest/operate/oss/persistence/aof/#aof-tools
  • MIGRATE 命令（键迁移）：https://redis.io/commands/migrate/
  • Sentinel 运维与故障转移：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/
• 社区支持
  • Redis Google Group / GitHub Issues（针对通用问题咨询与已知问题排查）
• 内部流程
  • 按贵司应急预案：联系当值 DBA / SRE 值班电话与变更审批渠道，执行高风险操作需双人复核。