1. 课程导入与应急思维建立
PostgreSQL 在生产环境中承担着交易、账务、订单、日志等关键数据的持久化职责。一旦数据库不可用或数据受损，业务损失往往以分钟甚至秒为单位放大。因此，本课程的第一件事不是背命令，而是建立一套应急思维：先判断故障类型与影响面，再选择恢复路径，最后用可验证的证据确认恢复成功。应急不是"把库拉起来"这么简单，而是"在可接受的时间内，把数据恢复到可接受的状态，并让业务重新可用"。
一、PostgreSQL 生产应急的核心目标
生产应急的目标可以拆成四个可衡量的维度，它们共同决定一次处置是否合格：
- 可用性（RTO）：从故障发生到业务可读写的时间上限。例如核心交易库 RTO 目标为 15 分钟，报表库可放宽到 2 小时。
- 数据完整性（RPO）：允许丢失的数据时间窗口。例如 RPO=5 分钟，意味着最多只能丢最近 5 分钟已提交事务。
- 一致性：恢复后的数据必须满足约束、外键与业务对账逻辑，不能出现"能连上但账不平"的假恢复。
- 可追溯：每一次切换、恢复、参数变更都要有记录，便于复盘与审计。
这四个目标之间存在权衡。追求 RPO 趋近于 0，通常需要同步流复制或高频 WAL 归档，代价是写入延迟与存储成本；追求 RTO 极短，往往需要预置备库与自动化切换脚本。应急思维的本质，就是在故障发生时快速判断"当前最该保哪个目标"。
二、常见故障分类
把故障分类，是为了让处置动作有章可循。生产中最常见的 PostgreSQL 故障可归为以下几类：
| 故障类别 | 典型现象 | 首要判断点 |
|---|---|---|
| 实例级宕机 | 进程消失、端口无响应、pg_ctl status 失败 | 是崩溃还是被 OOM/人为 kill |
| 连接与资源耗尽 | too many clients、连接池打满、CPU/IO 饱和 | 是慢 SQL 堆积还是连接泄漏 |
| 复制中断 | 备库延迟增大、pg_stat_replication 状态异常 | 是网络、WAL 缺失还是主库压力 |
| 数据损坏/误操作 | 约束报错、页面校验失败、误 DELETE/UPDATE | 损坏范围与误操作时间点 |
| 空间与 WAL 问题 | 磁盘满、pg_wal 膨胀、checkpoint 频繁 | 是归档失败还是长事务阻塞 |
| 锁与阻塞 | 大量会话 waiting、DDL 卡住 | 阻塞源头会话与锁模式 |
分类之后，处置路径就清晰了：实例宕机优先看日志与崩溃恢复；连接耗尽优先定位慢 SQL 与连接池；复制中断优先看 WAL 与网络；数据损坏则必须走备份 + PITR 或逻辑修复。切忌一上来就重启——重启可能让可恢复的现场消失。
三、恢复演练的价值
很多团队有备份，却从未验证过备份能否恢复。演练的价值正在于此：
- 验证备份可用性：备份文件是否完整、能否在目标版本上还原、归档 WAL 是否连续。
- 测量真实 RTO：从拿到备份到业务可用的实际耗时，往往远大于文档中的理论值。
- 暴露流程缺口：谁有权执行恢复、密钥在哪、切换后应用连接串如何更新。
- 训练判断力：在压力下快速区分"该切主"还是"该等恢复"。
四、本课程学习路径与实战环境准备
本课程按"认知—工具—操作—验证—复盘"的节奏推进：先建立应急思维与故障分类，再掌握备份、WAL 归档、PITR、流复制、逻辑复制等核心机制，随后进入主备切换、误删恢复、复制中断排障等实战场景，最后通过复盘沉淀为可执行的预案。
实战环境建议准备两台 Linux 主机（或容器），安装同一大版本 PostgreSQL（如 16），并提前配置好以下基础：
# 示例：初始化数据目录并开启归档（教学示例参数）
initdb -D /pgdata/16/main
# postgresql.conf 关键项
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /pgarchive/%f && cp %p /pgarchive/%f'
max_wal_senders = 10
hot_standby = on
# 备库基础备份示例
pg_basebackup -h 192.168.10.11 -D /pgdata/16/standby -U repl -Fp -Xs -P -R下面这张图把本节的核心逻辑串起来：从故障发生，到分类判断，再到选择恢复路径并验证目标是否达成。
把这张图记在心里，后续每一章的具体操作都会落在这条主线的某个环节上。遇到真实故障时，先问三个问题：现在最坏的情况是什么？我能接受丢多少数据？我手上可用的恢复手段有哪些？回答清楚这三个问题，再动手，恢复成功率会显著提高。