[译] PostgreSQL 生产级高可用系统部署指南

在当今的数字时代，宕机不仅会带来不便，而且代价高昂。无论您运营的是何种业务，电商网站、SaaS 平台还是关键的内部系统，您的 PostgreSQL 数据库都必须具备弹性、可恢复性和持续可用性。简而言之高可用性 (HA) 不是您启用的功能；而是您设计的系统。

在此博客中，我们将介绍为您的应用程序设置可靠、可用于生产的 HA PostgreSQL 系统时需要考虑的重要事项。

消除单点故障（SPOF）

单点故障 (SPOF) 是指系统中任何组件的故障都会导致整个系统停止运行。在 PostgreSQL 部署中，常见的 SPOF 包括：

• 单一电源或网络路径
• 单个见证节点
• 单个代理服务器和
• 单个连接池等

如果其中任何一个发生故障并且没有后备措施，您的应用程序就会崩溃。

在某些情况下，例如，您只有一个备份节点或一个监控节点。如果其中一个或两个节点都发生故障，应用程序可能会继续正常运行，而不会受到任何直接影响。因此，从技术上讲，这些组件并非 PostgreSQL 集群的单点故障。但是，尽快恢复备份和监控功能仍然至关重要，因为它们在长期可靠性、恢复和可观察性方面发挥着重要作用。

要识别集群中的单点故障 (SPOF)，首先要规划整个架构。列出支持 PostgreSQL 数据库存储、计算、网络、见证、监控、备份等功能的每个组件。对于每个组件，问问自己：如果该组件发生故障，会发生什么？如果答案是整个集群将停止运行，那么该组件就是 SPOF，需要制定适当的回退或冗余计划。

为您的企业选择合适的集群套件

PostgreSQL 生态系统非常丰富，提供众多工具。您可以根据业务需求灵活选择合适的高可用性解决方案。

以下是一些流行的选择：

• 双活设置——使用 PGD 或 PGEdge 等工具来设置多主集群。这些是专有工具，这意味着你需要购买许可证。
• Patroni – 适用于动态设置，并且可以与 etcd 或 Consul 等工具很好地配合使用以管理故障转移。
• Repmgr – 易于设置，支持手动或半自动故障转移。（注：现已停止维护。）
• Pgpool-II – 提供连接池、负载平衡和故障转移，但需要仔细设置。
• Kubernetes (CNPG) – 一种在 Kubernetes 环境中管理 PostgreSQL 的云原生方式。

在选择工具之前，请问自己：

• 您需要自动故障转移还是手动控制？
• RTO 和 RPO 是什么？
• 是否需要部署在多个区域？
• 您是在云端部署还是在本地部署？
• 您的团队拥有多少运营专业知识？
• 读取扩展对于您的工作负载重要吗？

选择错误的解决方案可能会导致故障转移缓慢、性能问题甚至数据不一致，因此请确保您的选择符合您的需求。

安全至关重要：遵循最佳实践

在设计 HA 系统时，考虑集群的安全性同样重要，因为它在整体可靠性和保护方面发挥着关键作用。

以下是需要关注的重点：

• 加密所有内容：用于客户端连接和复制流量的 TLS，或与备份/见证服务器的连接。
• 强化访问：使用pg_hba.conf基于角色的权限，并使用 Scram-SHA-256 身份验证进行通信。
• 安全机密：将密码和密钥存储在保险库中，或者如果存储在平面文件中，请确保这些文件的权限是严格的。
• 审计和日志：密切关注集群内部发生的情况。
• 限制权限：避免向每个人授予超级用户权限；仅在绝对必要时授予他们权限。
• 安全备份：加密您的备份或保存备份的存储驱动器以保护敏感数据。
• 限制访问：确保只有授权的个人才能直接访问数据库集群实例。

备份：最后一道防线

即使是最强大的高可用性设置也无法取代可靠的备份策略。复制可以保护您免受硬件故障的影响，但无法防止人为错误、数据损坏或恶意活动。

备份是保险。没有备份，任何高可用性系统都无法保证数据恢复。

使用以下工具：

• pgBackRest：非常适合大型生产环境中的完整备份、压缩、加密和可靠的 PITR。
• Barman：非常适合管理备份和灾难恢复，特别是对于多服务器设置。
• pg_dump：最适合较小的数据库或需要选择性表级导出的情况。

如果无法快速恢复，备份就毫无意义。务必测试您的恢复过程：

• 实践时间点恢复 (PITR)
• 从生产备份运行暂存恢复
• 使用校验和或试运行恢复来验证备份完整性

明确定义 RTO 和 RP

在制定 HA 策略之前，请先使其与业务预期保持一致。

• RTO（恢复时间目标）：发生故障后必须多快恢复。
• RPO（恢复点目标）：您可以承受丢失多少数据？
  例如：如果您的 RTO 为 1 分钟，但备份或自动故障转移需要 2 分钟才能恢复，则您不符合合规性。如果您的 RPO 为 5 秒，但复制延迟为 2 分钟，则您存在风险。

这些不仅仅是技术决策；它们必须来自业务优先级和客户期望。

复制延迟并不总是坏事

复制延迟通常被视为一个问题。但在某些情况下，故意延迟是一个明智之举。

为什么？

• 它为您提供了针对破坏性命令的缓冲区（例如DELETE FROM users;）
• 您可以取消复制或延迟恢复以防止损坏
• 充当近乎即时的备份，但落后几分钟

用例包括：

• 延迟数据删除的法律要求
• 防止开发人员操作不当或自动化脚本

PostgreSQL 中的延迟待机等设置可让您轻松配置此功能（recovery_min_apply_delay）。

上线前的基准测试

在没有模拟生产条件的情况下，切勿投入生产。

基准测试有助于回答：

• 系统能否处理高峰流量？
• 故障转移如何影响用户体验？
• 复制速度是否足够快？

使用以下工具：

• pgbench
• hammerdb 和
• sysbench 等

还测试：

• 故障转移事件
• 备份+恢复速度
• 监控警报阈值

监控一切

监控不是事后才想到的。它是你的早期预警系统。

需要监控的内容：

• 复制健康状况（pg_stat_replication）
• 查询性能（pg_stat_statements）
• WAL 归档状态
• 磁盘空间和 IOPS
• 备份成功/失败日志
• 故障转移事件

需要考虑的工具：

• 普罗米修斯+格拉法纳
• pg_exporter 和
• pgMonitor 等

不要等到用户报告停机时间；在问题影响任何人之前就发现问题。

结束语

PostgreSQL 的高可用性并非盲目地添加副本或运行脚本。它关乎周到的设计、明确的恢复目标以及严格的测试。安全性、备份、复制、基准测试和监控都在构建高弹性系统方面发挥着作用。

停机时间可能永远不会消失，但只要采取正确的策略，停机时间是可预测、可管理和可恢复的。

如果您对高可用性设计有任何疑问或想法，欢迎在评论区留言。让我们携手构建高弹性的 PostgreSQL 系统。

原文作者：Semab Tariq
原文地址：https://stormatics.tech/blogs/postgresql-production-grade-high-availability