# 抽取、跳过与重建策略

LLMS 索引： [llms.txt](/llms.txt)

---

抢救策略的优先级由“可信数据来源”决定，不由某个技巧是否能让 PostgreSQL 启动决定。
完整、已验证的 backup/健康副本通常优于在坏页周围挖数据；分段抽取又优于在唯一
PGDATA 上开启会丢数据的全局参数。

## 35.5.1 优先从备份、健康副本或逻辑来源恢复 {#item-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 决定。

### 并行验证，不要串行赌注

```text
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 中的逻辑错误。每个候选都跑：

```text
startup/recovery and system identifier/timeline
offline/online physical checks
amcheck/heap checks by scope
business invariants
archive/backup continuation
```

## 35.5.2 对可读数据做分段抽取和校验 {#item-35-5-2}

### 只在 clone 上建立 extraction map

先按稳定业务 key/partition 分块：

```sql
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);
```

每块记录：

```yaml
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 上继续二分：

```text
[0, 1M) failed
  [0, 500k) pass
  [500k, 1M) failed
    ...
```

最终报告：

```text
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 引用和跨表
关系可能未知。

### 导入到新库再验证

```text
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 危险恢复参数只在克隆现场、明确损失下使用 {#item-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 上的所有行，应在
已经放弃恢复该页后才考虑。它不是“自动修页”。

### 最低授权合同

```yaml
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 何时停止自救并升级到专业支持 {#item-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 边界。

### 升级包

```text
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`](../04/) · [返回本章目录](../) · [下一节：工程取证与业务验证](../06/) ·
[查看全书目录](/toc/) · [查看索引中心](/indexes/)