当您运行关键任务应用程序（例如网上银行、医疗保健系统或全球电子商务平台）时，每一秒的停机都可能造成数百万美元的损失，并损害您的企业声誉。正因如此，许多客户都力求其应用程序达到四个九 (99.99%) 或五个九 (99.999%)的可用性。
在这篇文章中，我们将介绍这些“9”的真正含义，更重要的是，哪种 PostgreSQL 集群设置可以帮助您实现这些目标。
“9”是什么意思？
9 的数量描述了您的系统在一年中保持运行的时间：
90%（1个九） →上涨约328天；下跌36.5天
99%（2 个 9） →上涨约 361 天；下跌 3.5 天
99.9%（3 个 9） →约 365 天上升；8¾ 小时下降
99.99%（4 个 9） →上涨约 365 天；下跌 53 分钟
99.999%（5 个 9） →上涨约 365 天；下跌 5.5 分钟
每增加 9 个，您的正常运行时间就会增加，但也会增加设置的复杂性。最终，这是一个权衡：要么以后再处理停机问题，要么提前投入精力构建一个弹性系统。
将 PostgreSQL 集群映射到高可用性级别
在本节中，我们将探讨不同的 PostgreSQL 集群架构如何映射到不同级别的高可用性（HA），从提供大约90%正常运行时间的基本单节点设置，一直到能够提供99.999%正常运行时间的高级双向复制设置。
注意：每个集群提到的正常运行时间假设一切都按预期运行，没有任何意外故障或中断。
单实例
它是什么：一台 PostgreSQL 服务器完成所有工作。
正常运行时间：每年约90–98% 。
灾难发生时：如果该单台服务器因硬件问题或数据目录意外删除而发生故障，您的所有数据/应用程序都可能不可用。
为什么 它很棘手？
- 由于只有一台服务器，如果它崩溃，我们将需要配置一个新实例，安装 PostgreSQL，并恢复最新的备份（假设有一个可用的备份）。
- 如果 WAL（预写日志）文件未存档到备份位置，则存在数据丢失的风险，这意味着 RPO（恢复点目标）可能非常高。
- 同样，RTO（恢复时间目标）也处于较高水平，因为整个系统需要从头开始重建并重新上线。
恢复窗口
如果恢复时间超过36.5 天，您甚至不能声称可用性达到90%，因为90% 的正常运行时间意味着您的系统必须在任何中断发生后36½天内恢复。
即使速度很快，手动恢复也有可能出现人为错误并延长停机时间。
注意：虽然从技术角度来看，通过采取正确的措施，单节点可以实现 98% 的正常运行时间，但这是一个非常棘手且脆弱的设置。硬件故障、人为错误（例如，意外删除数据目录）或操作系统级崩溃等事件可能会显著延长恢复时间。因此，您始终面临低于 98% 正常运行时间阈值的风险，任何此类事件都可能对可用性造成显著影响。
主服务器 + 备用服务器（手动故障转移）
它是什么：一台在线主服务器加一台热备服务器，与pg_basebackup保持同步。
正常运行时间：每年约99–99.5%
灾难发生时：
- 当主节点发生故障时，通知操作团队。
- 人工将备用数据库提升为主数据库。
- 重新配置应用程序以指向新的主应用程序。
为什么 它很棘手？
- 需要有人全天候待命，手动将备用数据库提升为主数据库，并重新配置应用程序以指向新的主数据库。
- 此设置还需要可靠的监控和警报系统，以便快速检测故障并通知团队及时采取行动。
恢复窗口：
通常，检测故障、生成警报、安排人员执行手动故障转移以及将应用程序重定向到新的主服务器的整个过程可能需要大约 1.8 天到 3.6 天。这会导致应用程序可用性在大约 99% 到 99.5% 之间。
优点和缺点：
- RPO 可以接近于零
- RTO 是可控的
- 手动步骤可能很慢。
主服务器 + 2 个备用服务器（自动故障转移）
它是什么：一个 3 节点的设置，但配备了工具（Patroni 或带有 VIP 管理器的 pgpool），可以自动检测故障并提升备用服务器，这意味着无需人工干预。
正常运行时间： 每年99.9% → 99.95%
灾难发生时：
- Patroni 或 Pgpool 在 ETCD 或 Watchdog 的帮助下持续监控主节点。
- 如果发生故障，该工具会立即进入待机状态。
- 虚拟 IP 将应用程序连接重新路由到新的领导者。
恢复窗口：
通过此设置，由于无需人工干预，恢复窗口通常只需 8.7 小时至 4.3 小时以内。应用程序在故障转移期间仍可正常运行，确保高达 99.9% 或 99.95% 的高可用性。
优点和缺点：
- 对于最终用户来说几乎看不见故障转移。
- 不存在后期人为干预的风险。
- 如果整个区域或数据中心发生故障，仍然容易受到攻击。
多可用区/多区域设置
它是什么：节点分布在多个可用区 (AZ) 或数据中心。可以进行托管（例如 AWS RDS 多可用区），也可以使用 Patroni 或 Pgpool + pg_basebackup 进行自我管理。
正常运行时间： 99.99%（四个九）。
灾难发生时：
- 整个可用区或数据中心离线。
- 系统需要人工来推动另一个区域的待机。
恢复窗口：
- 如果区域内的主服务器发生故障，则无需采取任何措施，因为另一个备用服务器可以自动提升为新的主服务器。
- 然而，如果整个区域都瘫痪了，强大的监控和警报系统可以帮助检测到问题，但仍然需要人工干预，将另一个区域的热备用服务器提升为新的主服务器。为了满足“四个九”的可用性目标，此故障转移必须在 52 分钟内完成。
优点和缺点：
- 业务运营能够经受住区域性中断的影响。
- 许多托管服务已完全实现自动化。
- 更复杂的网络和跨区域复制。
- 在某些情况下，也可以通过引入奇数个可用区域来消除人工干预，以保持准确的共识。但这会增加管理和部署的复杂性。
多区域主动-主动
简介：跨不同区域运行多个主节点并保持同步，只有像 PGD 这样的专有解决方案才可行。这是由于冲突解决的复杂性、延迟挑战以及脑裂风险。
正常运行时间： 99.999%（五个九）。
灾难发生时：
- 如果某个区域内的主节点出现故障，则无需担心；由于代理服务器的存在，应用程序可以继续写入同一区域内的另一个主节点。
- 即使整个区域瘫痪，应用程序也能继续写入灾难恢复 (DR) 区域而不会中断。虽然这可能会带来一些延迟，但比完全宕机要好得多。
优点和缺点：
- 我们在大陆规模的灾难中幸存下来。
- 在每个区域本地写入可用内容。
- 由于采用多主架构，延迟通常较低
- 高昂的许可和运营成本。
- 设置和维护非常复杂。
不要忘记单点故障
堆栈中任何位置的单点故障 (SPOF)都可能破坏您的可用性声明。例如，在一个三节点的 Patroni 集群中，只有一个见证节点（etcd/Consul 节点）：如果该见证节点宕机，即使数据库节点一切正常，集群也会停止运行。重建该见证节点可能需要数天时间，甚至会损失 90% 或 99% 的可用性！
总结
根据您的业务可以容忍的停机时间来决定您的“九” 。
将您的架构从单一实例一直匹配到多区域主动-主动。
自动化、监控并删除您能找到的每个 SPOF。
原文地址：https://stormatics.tech/blogs/achieving-high-availability-in-postgresql-from-90-to-99-999
原文作者： Semab Tariq
