印刻数据库

外观

PostgreSQL 高可用架构选型指南 ​

高可用性（High Availability，简称 HA）是生产环境中 PostgreSQL 数据库的核心需求之一。一个可靠的高可用架构可以确保数据库在面对各种故障时仍然能够持续提供服务，减少业务中断时间。本文将详细介绍 PostgreSQL 高可用架构的设计原则、常见方案和选型策略，帮助 DBA 选择最适合业务需求的架构。

高可用架构设计原则 ​

在设计 PostgreSQL 高可用架构时，需要遵循以下核心原则：

可靠性优先 ​

高可用架构的首要目标是确保数据库服务的可靠性，能够在各种故障情况下持续提供服务。这意味着架构设计必须考虑到单点故障，并采取相应的冗余措施。

故障自动检测与恢复 ​

架构应具备自动检测故障的能力，并能在故障发生时自动进行恢复，减少人工干预。自动化程度越高，故障恢复时间越短，对业务的影响越小。

数据一致性 ​

确保在故障转移过程中数据的一致性，避免数据丢失或损坏。对于金融、电商等关键业务，数据一致性是不可妥协的要求。

性能影响最小化 ​

高可用架构不应显著影响数据库的正常性能，包括读写性能和延迟。架构设计需要在可用性和性能之间找到平衡点。

可扩展性 ​

架构应支持横向扩展，能够随着业务增长轻松扩展节点数量和容量。这对于快速发展的业务尤为重要。

易于管理和监控 ​

架构应具备良好的可管理性和可监控性，便于运维人员进行日常管理和故障排查。复杂的架构会增加运维成本和出错风险。

成本效益 ​

在满足高可用需求的前提下，应考虑架构的成本效益，避免过度设计。不同规模的业务对可用性的要求不同，应根据实际需求选择合适的架构。

常见高可用架构方案 ​

主从复制架构 ​

主从复制是 PostgreSQL 中最基础的高可用架构，通过流式复制或逻辑复制将主库的数据同步到一个或多个从库。

架构特点 ​

  • 简单易用：配置和管理相对简单，适合初级 DBA 或小型团队
  • 成本较低：只需要额外的从库服务器，无需复杂的第三方工具
  • 读写分离：支持将读请求分发到从库，提高整体性能
  • 故障转移：需要手动或通过第三方工具实现，自动化程度较低

适用场景 ​

  • 对高可用要求不是特别严格的场景（RTO 可接受数分钟）
  • 读多写少的应用场景
  • 预算有限的小型应用
  • 开发和测试环境

优缺点 ​

优点缺点
配置简单，学习曲线平缓手动或半自动化故障转移，恢复时间长
支持读写分离，提高读性能主库故障会导致写入中断
成本较低，适合小型业务从库与主库存在数据延迟，可能导致数据不一致
易于扩展，可灵活增加从库不支持自动故障检测，依赖人工监控

版本支持 ​

  • PostgreSQL 9.0+ 支持流式复制
  • PostgreSQL 10+ 支持逻辑复制
  • PostgreSQL 12+ 增强了复制功能，提供了更丰富的监控指标

基于 Patroni 的高可用架构 ​

Patroni 是一个用于 PostgreSQL 高可用性的开源工具，基于 etcd、Consul 或 ZooKeeper 实现自动故障检测和故障转移。

架构特点 ​

  • 自动故障检测：通过 DCS（分布式一致性存储）实现节点状态检测，避免脑裂
  • 自动故障转移：主库故障时自动将从库提升为主库，RTO 可控制在秒级
  • 配置管理：集中管理 PostgreSQL 配置，支持动态更新
  • 支持多种 DCS：支持 etcd、Consul、ZooKeeper 等多种分布式一致性存储
  • 易于扩展：支持动态添加和移除节点，适应业务增长

适用场景 ​

  • 对高可用要求较高的生产环境（RTO < 30 秒）
  • 大规模 PostgreSQL 集群（5+ 节点）
  • 需要自动化管理的场景
  • 复杂的部署环境（跨可用区、跨地域）

优缺点 ​

优点缺点
完全自动化的故障检测和转移依赖外部 DCS 组件，增加了架构复杂度
集中式配置管理，便于维护需要额外的 DCS 服务器资源
支持水平扩展，适应业务增长学习曲线较陡，需要掌握 DCS 知识
良好的社区支持和活跃的开发配置相对复杂，需要仔细调优

版本支持 ​

  • Patroni 支持 PostgreSQL 9.4+
  • 推荐使用 PostgreSQL 11+ 以获得更好的性能和功能支持
  • PostgreSQL 13+ 支持并行查询和更高效的复制机制

基于 repmgr 的高可用架构 ​

repmgr 是一个用于 PostgreSQL 复制管理和故障转移的开源工具，专注于简化主从复制的管理和故障转移过程。

架构特点 ​

  • 复制管理：简化主从复制的部署和管理，提供直观的命令行界面
  • 自动故障检测：通过定期检查主库状态实现故障检测
  • 手动或自动故障转移：支持手动或自动将从库提升为主库
  • 节点监控：提供节点状态监控和报告，便于运维管理
  • 简单易用：配置和管理相对简单，适合中小型团队

适用场景 ​

  • 中小型 PostgreSQL 集群（2-5 节点）
  • 对高可用要求适中的场景（RTO < 1 分钟）
  • 希望简化复制管理的场景
  • 预算有限的中型企业

优缺点 ​

优点缺点
配置简单，易于管理自动故障转移功能相对简单，缺乏高级特性
轻量级，资源消耗少不支持分布式一致性存储，存在脑裂风险
良好的复制管理功能大规模集群管理能力有限（建议不超过 10 节点）
详细的节点状态报告社区支持相对较弱，更新频率较低

版本支持 ​

  • repmgr 支持 PostgreSQL 9.3+
  • repmgr 5.x 推荐使用 PostgreSQL 10+
  • PostgreSQL 12+ 提供了更好的集成支持

基于 pg_auto_failover 的高可用架构 ​

pg_auto_failover 是由 Crunchy Data 开发的 PostgreSQL 高可用解决方案，专注于提供简单易用的自动故障转移功能。

架构特点 ​

  • 简单易用：部署和配置非常简单，提供直观的命令行工具
  • 自动故障检测和转移：完全自动化的故障检测和转移，无需复杂配置
  • 内置监控：提供内置的监控功能和 Prometheus 指标
  • 支持 PostGIS：对 PostGIS 有良好的支持，适合地理信息系统
  • 活跃的开发：持续更新和改进，支持最新的 PostgreSQL 版本

适用场景 ​

  • 希望快速部署高可用集群的场景
  • 对 PostGIS 有需求的应用
  • 中小型 PostgreSQL 集群（2-5 节点）
  • 开发和测试环境

优缺点 ​

优点缺点
部署和配置简单，上手快功能相对单一，缺乏高级特性
完全自动化的故障转移扩展性有限，不支持复杂的集群拓扑
内置监控功能，便于运维社区支持相对较弱，文档不够完善
支持 PostGIS，适合地理信息系统不支持跨地域部署，适合单可用区场景

版本支持 ​

  • pg_auto_failover 1.6+ 支持 PostgreSQL 10+
  • 推荐使用 PostgreSQL 13+ 以获得最佳性能和功能支持
  • PostgreSQL 15+ 支持更高效的复制机制和监控指标

基于 Pacemaker + Corosync 的高可用架构 ​

Pacemaker + Corosync 是一个通用的高可用解决方案，可以用于管理 PostgreSQL 集群的高可用性。

架构特点 ​

  • 通用高可用框架：可以管理多种服务的高可用性，不仅仅是 PostgreSQL
  • 强大的资源管理：支持复杂的资源依赖和约束，适合复杂的部署场景
  • 多种故障检测机制：支持多种故障检测方法，提高故障检测的准确性
  • 灵活的配置：支持复杂的集群拓扑，包括多主架构

适用场景 ​

  • 已经在使用 Pacemaker + Corosync 的环境
  • 需要管理多种服务高可用性的场景
  • 复杂的集群拓扑需求
  • 对可用性要求极高的关键业务

优缺点 ​

优点缺点
通用的高可用框架，支持多种服务配置复杂，学习曲线陡峭
强大的资源管理能力，支持复杂场景资源消耗较大，对服务器要求高
灵活的配置选项，适应各种拓扑维护成本高，需要专业的运维团队
广泛的社区支持和丰富的文档不针对 PostgreSQL 优化，性能可能不如专用工具

版本支持 ​

  • 支持 PostgreSQL 9.x+
  • 推荐使用 PostgreSQL 11+ 以获得更好的集成支持
  • 不同版本的 Pacemaker 对 PostgreSQL 版本的支持有所不同，需要仔细验证

高可用架构选型考虑因素 ​

在选择 PostgreSQL 高可用架构时，需要考虑以下关键因素：

业务可用性要求 ​

  • RTO（恢复时间目标）：系统从故障中恢复的最大可接受时间，直接影响架构选择
  • RPO（恢复点目标）：故障发生后可接受的数据丢失量，决定了复制方式的选择
  • 业务关键程度：业务对数据库可用性的依赖程度，金融、电商等关键业务要求更高

技术复杂度 ​

  • 部署难度：架构的部署和配置难度，影响上线时间和初期成本
  • 管理复杂度：日常管理和维护的复杂度，影响长期运维成本
  • 学习曲线：团队掌握该架构所需的时间，影响团队效率
  • 社区支持：社区活跃度和可用资源，影响问题解决速度

成本考虑 ​

  • 硬件成本：服务器、存储等硬件资源成本，影响初期投资
  • 软件成本：商业软件或支持服务的成本，影响长期成本
  • 运维成本：日常运维所需的人力成本，影响运营效率

性能影响 ​

  • 写入性能：高可用架构对写入性能的影响，尤其是同步复制场景
  • 读取性能：是否支持读写分离，提高读取性能
  • 延迟影响：复制延迟对业务的影响，尤其是实时性要求高的场景

扩展性 ​

  • 横向扩展：是否支持动态添加节点，适应业务增长
  • 容量扩展：是否支持存储和计算资源的扩展
  • 地理分布：是否支持跨地域部署，提高容灾能力

监控和管理 ​

  • 监控能力：架构的监控和告警能力，影响故障发现和处理速度
  • 故障诊断：故障定位和诊断的难易程度，影响故障恢复时间
  • 日志管理：日志收集和分析能力，影响问题排查效率

不同规模应用的架构选型建议 ​

小型应用（并发 < 100，数据量 < 100GB） ​

  • 推荐架构：主从复制 + 手动故障转移 或 repmgr
  • 理由：
    • 配置简单，管理成本低，适合小型团队
    • 成本较低，适合预算有限的小型应用
    • 能够满足基本的高可用需求（RTO < 5 分钟）
  • 可选方案：pg_auto_failover
  • 版本建议：PostgreSQL 13+，获得更好的性能和监控支持

中型应用（并发 100-500，数据量 100GB-1TB） ​

  • 推荐架构：Patroni 或 repmgr + 自动故障转移
  • 理由：
    • 提供自动化的故障检测和转移，RTO < 30 秒
    • 支持读写分离，提高整体性能
    • 管理相对简单，适合中型团队
    • 支持动态扩展，适应业务增长
  • 可选方案：pg_auto_failover
  • 版本建议：PostgreSQL 14+，支持更高效的复制和并行查询

大型应用（并发 > 500，数据量 > 1TB） ​

  • 推荐架构：Patroni + 读写分离 + 异地灾备
  • 理由：
    • 完全自动化的故障检测和转移，RTO < 30 秒
    • 支持大规模集群管理，适应复杂的部署环境
    • 支持读写分离，提高整体性能
    • 支持异地灾备，提高灾难恢复能力
  • 可选方案：Pacemaker + Corosync（适合已经使用该框架的环境）
  • 版本建议：PostgreSQL 15+，获得最佳性能和功能支持

高可用架构部署最佳实践 ​

硬件和网络配置 ​

  • 服务器配置：主从服务器配置尽量一致，避免性能瓶颈
  • 网络配置：使用高速、低延迟的网络连接，尤其是主从节点之间
    • 推荐使用万兆以太网
    • 跨可用区部署时，确保网络延迟 < 5ms
  • 存储配置：使用可靠的存储设备，如 RAID 10 或分布式存储
    • 主库建议使用 NVMe SSD，提高写入性能
    • 从库可以使用 SATA SSD，平衡成本和性能
  • 电源备份：配备 UPS 或其他电源备份设备，避免电源故障导致的服务中断

复制配置优化 ​

  • 选择合适的复制方式：根据业务需求选择流式复制或逻辑复制
    • 对数据一致性要求高的场景，建议使用同步或半同步复制
    • 对写入性能要求高的场景，建议使用异步复制
  • 调整 wal_level：根据复制需求设置合适的 wal_level
    • 流式复制：设置为 replica
    • 逻辑复制：设置为 logical
  • 优化 checkpoint 配置：调整 checkpoint_timeout 和 checkpoint_completion_target，减少 I/O 峰值
    • 建议设置 checkpoint_timeout = 30min
    • 建议设置 checkpoint_completion_target = 0.9
  • 配置合适的 wal_keep_size：确保从库能够跟上主库的复制进度
    • 建议根据复制延迟和写入量设置，一般为 10GB-100GB

监控和告警 ​

  • 监控关键指标：
    • 复制延迟：使用 pg_stat_replication 视图监控
    • 主从状态：监控主库和从库的运行状态
    • 资源使用率：CPU、内存、磁盘 I/O、网络带宽
    • WAL 日志：监控 WAL 生成速率和归档情况
  • 设置合理的告警阈值：
    • 复制延迟 > 30 秒时告警
    • 主库不可用时紧急告警
    • 资源使用率 > 80% 时警告
  • 实现多级告警：根据告警级别采取不同的响应措施
  • 定期测试告警：确保告警系统能够正常工作，避免漏报

定期演练 ​

  • 定期进行故障转移演练：建议每季度至少进行一次，验证故障转移流程的正确性
  • 测试数据恢复流程：确保在数据丢失时能够快速恢复
  • 模拟各种故障场景：
    • 主库崩溃
    • 网络故障
    • 存储故障
    • 节点断电
  • 记录演练结果：分析演练中发现的问题，持续改进故障转移流程

文档和培训 ​

  • 编写详细的架构文档：
    • 部署架构图
    • 配置信息
    • 故障处理流程
    • 日常维护指南
  • 培训运维团队：确保团队成员掌握架构的管理和维护技能
  • 制定故障处理流程：明确故障发生时的处理步骤和责任分工
  • 定期更新文档：随着架构的变化及时更新文档，确保文档与实际部署一致

案例分析 ​

某电商网站的高可用架构 ​

背景：某电商网站，日活跃用户 100 万，峰值并发 5000，数据量 5TB。

挑战：

  • 对数据库可用性要求极高，RTO < 1 分钟，RPO = 0
  • 读多写少，需要支持读写分离
  • 数据量增长迅速，需要支持横向扩展
  • 跨地域部署，提高容灾能力

解决方案：

  • 采用 Patroni + etcd 的高可用架构
  • 部署 1 主 3 从的集群配置，分布在 2 个可用区
  • 使用 pgpool-II 实现读写分离，将 80% 的读请求分发到从库
  • 配置半同步复制，确保数据一致性
  • 使用 Prometheus + Grafana 监控集群状态

效果：

  • 实现了自动故障检测和转移，RTO < 30 秒
  • 读写分离提高了整体查询性能 30%
  • 跨可用区部署提高了架构的可靠性，避免单可用区故障
  • 支持动态添加节点，满足业务增长需求

某金融系统的高可用架构 ​

背景：某金融系统，处理大量交易数据，对数据一致性和可用性要求极高。

挑战：

  • 严格的监管要求，数据不能丢失
  • 7x24 小时连续服务，RTO < 30 秒
  • 复杂的部署环境，需要跨地域部署
  • 对性能要求高，写入延迟 < 10ms

解决方案：

  • 采用主从复制 + 逻辑复制的混合架构
  • 本地数据中心部署 1 主 2 从的流式复制集群，使用同步复制确保数据一致性
  • 异地数据中心部署逻辑复制从库，实现灾备
  • 使用自研的监控和故障转移工具，实现自动故障检测和转移
  • 配置多点写入机制，避免单点故障

效果：

  • 实现了零数据丢失，满足监管要求
  • 本地故障 RTO < 30 秒，异地灾备 RTO < 1 小时
  • 支持跨地域数据同步，提高了容灾能力
  • 自定义监控工具满足了复杂的监控需求

未来发展趋势 ​

云原生高可用架构 ​

随着云计算的发展，云原生高可用架构将成为主流：

  • 基于 Kubernetes 的 PostgreSQL 高可用解决方案，如 Crunchy Postgres for Kubernetes
  • 云厂商提供的托管 PostgreSQL 服务，如 AWS RDS、Azure Database for PostgreSQL
  • 容器化部署和管理，提高部署效率和资源利用率

智能故障检测和恢复 ​

利用人工智能和机器学习技术，实现更智能的故障检测和恢复：

  • 预测性故障检测，提前发现潜在问题
  • 自动根因分析，快速定位故障原因
  • 智能故障恢复策略，根据故障类型选择最佳恢复方案

分布式 PostgreSQL 架构 ​

传统的主从架构将逐渐向分布式架构演进：

  • 原生分布式 PostgreSQL 数据库，如 Citus、Greenplum
  • 支持水平扩展的分片架构，提高处理大规模数据的能力
  • 多主架构的广泛应用，提高写入性能和可用性

总结 ​

选择合适的 PostgreSQL 高可用架构是确保数据库服务可靠性的关键。在选型过程中，需要综合考虑业务可用性要求、技术复杂度、成本、性能影响和扩展性等因素。

对于不同规模的应用，推荐的架构也有所不同：

  • 小型应用：主从复制或 repmgr
  • 中型应用：Patroni 或 repmgr + 自动故障转移
  • 大型应用：Patroni + 读写分离 + 异地灾备

无论选择哪种架构，都需要遵循最佳实践，包括合理的硬件和网络配置、优化的复制配置、完善的监控和告警系统、定期的故障演练以及详细的文档和培训。

随着技术的发展，云原生高可用架构、智能故障检测和恢复以及分布式 PostgreSQL 架构将成为未来的发展趋势。DBA 团队需要持续学习和关注这些新技术，不断优化和改进高可用架构，以满足业务不断增长的需求。