35.5 抽取、跳过与重建策略
抢救策略的优先级由“可信数据来源”决定，不由某个技巧是否能让 PostgreSQL 启动决定。 完整、已验证的 backup/健康副本通常优于在坏页周围挖数据；分段抽取又优于在唯一 PGDATA 上开启会丢数据的全局参数。
35.5.1 优先从备份、健康副本或逻辑来源恢复
候选来源矩阵
| 来源 | 优点 | 必须验证 |
|---|---|---|
| physical backup + WAL | 保留完整 PostgreSQL 状态，可 PITR | restore、checksum、lineage、损坏是否已进入 backup |
| healthy physical replica | RPO 较新，可快速重建 | 独立故障域、replay、checksum、同 system id/timeline |
| storage snapshot | 快速封存大量字节 | crash consistency、覆盖 tablespace/WAL、设备独立性 |
| logical dump/export | 隔离物理布局，适合重建 | 全对象覆盖、snapshot、权限/DDL/large object |
| upstream/event/ledger | 可恢复业务事实 | 完整性、顺序、幂等、删除与外部副作用 |
| corrupted clone extraction | 最后可取回部分数据 | 明确缺口、不可验证范围、重复与编码 |
“最近”与“最好”不同。一个 5 分钟前但含坏页的 replica，不如 30 分钟前已 restore 验证 且有完整 WAL 的 backup；是否接受 RPO 由业务 owner 决定。
并行验证，不要串行赌注
track A: preserve and diagnose original
track B: restore latest known backup to isolation
track C: validate independent replica/snapshot
track D: prepare logical reconciliation每条 track 不写另一个 track 的来源。先得到可用候选，再按 RPO、完整性、时间和风险 选择，不要等在唯一 damaged instance 上的“修复”失败后才想起恢复 backup。
物理来源也可能复制损坏
backup 工具成功退出不等于每个 page 正确；physical replication/WAL 会忠实传播合法 page changes，也不能修复已在 source 中的逻辑错误。每个候选都跑：
startup/recovery and system identifier/timeline
offline/online physical checks
amcheck/heap checks by scope
business invariants
archive/backup continuation35.5.2 对可读数据做分段抽取和校验
只在 clone 上建立 extraction map
先按稳定业务 key/partition 分块：
COPY (
SELECT id, tenant_id, occurred_at, payload
FROM public.events
WHERE id >= :lo AND id < :hi
ORDER BY id
) TO STDOUT WITH (FORMAT binary);每块记录：
range: "[lo, hi)"
snapshot: ...
rows: ...
min_max: ...
ordered_digest: ...
copy_exit_status: ...
error_relation_block: ...
destination_rows_digest: ...不要用 OFFSET/LIMIT 做可恢复分块；行在并发/错误下可能跳动，复杂度也高。ctid 可辅助
定位 physical block，但会随 UPDATE/VACUUM/rewrite 改变，不能作为业务去重身份。
二分定位只是抽取方法
若某 key range 读取失败，可以在 clone 上继续二分：
[0, 1M) failed
[0, 500k) pass
[500k, 1M) failed
...最终报告：
verified exported ranges
failed/unreadable ranges
rows known exported
rows estimated/unknown lost
duplicates and reconciliation rule
TOAST/large object coverage
constraints not yet validated不能把“成功导出了 99% range”说成“只丢 1% 行”：坏块上的行数、TOAST 引用和跨表 关系可能未知。
导入到新库再验证
load into quarantine schema
retain source range/run id
reject or quarantine constraint conflicts
build indexes after source import when appropriate
validate counts/digests/business ledger
deduplicate by stable identity
record every transformation不要直接把 best-effort 数据导回生产表覆盖已有正确数据。
35.5.3 危险恢复参数只在克隆现场、明确损失下使用
参数不是普通 troubleshooting 开关
| 手段 | 可能让什么继续 | 代价 |
|---|---|---|
ignore_checksum_failure=on | 尝试读 checksum 不匹配页 | 可能 crash、隐藏/传播损坏 |
zero_damaged_pages=on | 跳过坏 page header | 内存中把整页置零，丢失该页所有行 |
ignore_invalid_pages=on | recovery 忽略无效 page 引用 | 可能 crash、丢数据、隐藏/传播损坏 |
pg_resetwal | 在缺 WAL/control continuity 时尝试启动 | 数据与事务一致性可能不可证明 |
官方对 zero_damaged_pages 的描述非常明确：它会销毁 damaged page 上的所有行，应在
已经放弃恢复该页后才考虑。它不是“自动修页”。
最低授权合同
target: exact disposable clone hash
original_evidence: immutable and independently stored
healthy_source_search: exhausted_or_documented
expected_loss:
object_blocks_rows: ...
business_effect: ...
parameter:
name_value_scope: ...
reason: ...
extraction_only: true
no_return_to_service: true
owner_approval: ...
stop_condition: ...危险参数只为了抽取仍可读数据，产出的 cluster 永不直接回到服务。抽取后在全新 cluster 重建、验证。
不要发布复制粘贴“魔法命令”
每个损坏现场的 PG version、system id、WAL、checkpoint、relation 与硬件证据不同。
尤其 pg_resetwal 应由熟悉 PostgreSQL 内部与业务损失的人在 clone 上分析；本书实验
不执行它，也不提供绕过 guard 的快捷命令。
35.5.4 何时停止自救并升级到专业支持
技术停手线
- system catalog、control file、WAL 或多个关键 relation 损坏；
- 服务器反复 crash，core/stack 尚未保存；
- 存储/内存仍报告硬件错误；
- primary、replica、backup 对同一事实给出冲突结果；
- 不知道某动作会否覆盖唯一恢复来源；
- dangerous GUC/
pg_resetwal成为下一步； - encryption/key、filesystem、volume snapshot 需要专项能力；
- 估计损失跨越 financial/security/compliance 边界。
升级包
business impact and decision deadline
immutable evidence manifest and access method
PostgreSQL/system/extension/locale versions
system id/timeline/LSN/control projections
exact errors with UTC and SQLSTATE
relation/fork/block mapping
kernel/storage/hardware evidence
backup/replica/source candidates
all actions already performed in order
questions requiring expert decision不要为了“给专家一个更干净的环境”先删除日志、重启十次或运行 repair。未经请求不要 把含 PII/凭据/密钥的完整 PGDATA 或日志发给外部支持；先走安全与法律批准、最小披露和 加密传输。
时间与选择权
专业支持不是承诺一定恢复所有数据，而是避免用不可逆试错继续缩小选择空间。若业务 deadline 更早，可并行恢复已验证 backup，同时保留 damaged original 供后续取证；恢复 服务与确定根因不必串行。
上一节：索引、collation 与 amcheck · 返回本章目录 · 下一节：工程取证与业务验证 ·
查看全书目录 · 查看索引中心