另一个我在实地看到的让我感到惊讶的故事。结果显示，recovery_prefetch 可能导致停机。这种情况一直在后台悄然发生，但直到我们仔细观察才注意到。在经过大量工作后，我发现这部分是由于多年前有人给 postgres 黑客邮件列表发了一封邮件“嘿，有这个问题”，大家认为“嗯，这不会太糟糕”……而现在我们看到生产环境停机了！证据A：2021年2月，在该功能开发期间，距发布还有一年半，Stephen Frost 发出了不必要的预提取请求，对于我们已经为其预提取的块，即使在关闭 FPW 的情况下也可以说这是一个问题，但进行预提取的好处几乎肯定会抵消这一点，这意味着寻找解决办法是我们可以在将来作为改进来做的事情。我对此没有任何问题。只是当考虑 FPW 启用的情况时，这在我看来并不那么明确。最终，如果你、Andres 和 Munro 都不担心，并且没有其他人发声，那么我不会对其被提交提出异议，但正如你所说的，这似乎是一个对每个人都值得考虑的好点子。https://www.postgresql.org/message-id/20210214231815.GO27507@tamriel.snowman.net 证据B：2025年3月，来自实地的明确报告，Michael Zhilin（Postgres Pro）一位客户抱怨在现代强大裸金属服务器上，物理备用有显著的重放延迟（几个小时）。根据“top”的输出，启动过程和几个内核工作线程使用了 CPU，主要在内核空间中。经过对 perf 和 strace 输出的快速分析，禁用 recovery_prefetch 解决了这一事件。实际的 XLog 预提取代码并没有考虑共享缓冲区可能是从 WAL FPI 加载而不是从磁盘加载，并在这种情况下进行 fadvise 调用。https://www.postgresql.org/message-id/9bdb428a-fc8e-4801-8fff-1ad0bc6fa76b%40postgrespro.ru 这两封电子邮件都在正确的轨道上，但尚未完全看到全貌。首先：FPI/FPW 在今天是无处不在的。虽然它在性能方面非常昂贵，但这是 Postgres 保护操作系统重启时不丢失数据的唯一方式。因此，如今大多数生产环境中的 Postgres 安装（社区开源版本）都启用了这一功能。第二：同步复制变得越来越普遍。实际上，完全保护社区开源 Postgres 对抗硬件故障数据丢失的方式只有两种：(1) 采用 DRBD 等开源技术进行存储层复制，或者使用昂贵的专有存储和集群技术；或 (2) 使用 Postgres 的同步复制进行数据库层保护。第二个选项是与 Kubernetes 和普通硬件一起使用的常规解决方案。第三：之前未被诊断/报告的问题——recovery_prefetch 的问题不仅限于 FPI，它还涉及当主实例进行大规模顺序 I/O 时，recovery_prefetch 将这些操作转换为 8k 随机读取。对于相同数量的读取字节，这在副本上将 IOPS 放大多达 16 倍。这可能会轻易耗尽可用的 IOPS，导致副本在写入活动后显著滞后。读取 IOPS 的放大结合 Postgres 的同步复制设计使得 recovery_prefetch 成为一个真正导致停机的问题。事实证明，一旦知道步骤，这种情况很容易重现。启动 postgres 进行同步复制到备用，使用小服务器和便宜的硬盘（例如：云磁盘，500 IOPS，2个 CPU，8GB 内存）初始化 pgbench 刻度 640 以获取约 10GB 数据禁用 pgbench_accounts 的自动真空，这样它就不会干扰实验。在一个可以观看的终端中以 5 TPS 固定运行 pgbench。更新表的 5%。(检查点并更新 pgbench_accounts，其中 aid%20 = 0。)这会产生一阵写入活动。Pgbench 将放慢速度直到完成。等待这完成。杀死 walreceiver 进程以模拟中断此连接的网络/系统挂起或不稳定。TPS 降至零，所有写入挂起超过 30 分钟（较大的 pgbench 表可能是几个小时）。要一致重现此停机，这确实是如此简单。https://github.com/ardentperf-labs/walreceiver-outage-repro 而且值得一提的是，VACUUM 本身也非常能够产生写入活动。造成停机的“食谱”只是“足够的坏运气”：在写入活动激增时，中断流复制的网络故障。要理解为什么整个系统会挂起，这确实归结为两件简单的事情：(1) 同步复制和 (2) 定义 Postgres 备用服务器的核心“状态机”。 请记住，对于同步复制，我们依赖至少一台健康的备用服务器——否则我们就不能进行写入。