Gabriele Bartolini：通过PostgreSQL让世界成为我的单点故障
内容提要
CloudNativePG 1.24引入了一个新功能，允许在云区域或Kubernetes集群之间进行声明性管理的PostgreSQL集群切换。这提高了多区域和多集群环境的效率和可靠性。该功能实现了主集群的无缝降级和副本集群的晋升，无需重新克隆前者。该设置在Kubernetes中维护了操作连续性，并改善了PostgreSQL部署的高可用性和灾难恢复。本文详细解释了跨多个区域的分布式PostgreSQL集群的设置和配置。
延伸解读
切换机制：降级与晋升的协同
CloudNativePG 1.24 的声明式切换通过两个关键步骤实现：首先更新原主集群的 replica.primary 字段，将其降级为副本集群，并生成包含检查点信息的 demotionToken；然后使用该 token 更新副本集群的 replica.primary 和 promotionToken 字段，将其晋升为主集群。整个过程无需重新克隆原主集群，但需注意，若遗漏 promotionToken，将触发故障转移并导致原主集群重建。
RPO 与数据同步：基于 WAL 归档的跨区域复制
在默认配置下，副本集群通过持续备份存储（如对象存储）从主集群同步 WAL 归档，可实现约 5 分钟的恢复点目标（RPO）。若需更低 RPO，建议在数据中心间建立安全通道并启用异步流式复制。此外，副本集群在重放 WAL 后还会将其归档到本地对象存储，从而天然形成跨区域的连续备份，提升数据保护能力。
实践场景：银行业务连续性中的受控切换
文章以欧洲银行业为例，展示了主数据中心每 3 到 6 个月在中欧和西欧之间轮换的受控切换流程。两个区域各有一个 Kubernetes 集群，每个集群跨三个可用区，并采用共享无架构。通过声明式配置，组织可以按计划将主角色从一个区域切换到另一个区域，确保客户面向应用的服务连续性，同时最小化停机时间。
扩展与集成：多集群拓扑与 GitOps 支持
该功能支持扩展至三个或更多 Kubernetes 集群，形成环形拓扑，例如增加南欧集群。所有集群的 externalClusters 配置需保持一致，并通过 replica.source 定义复制来源。切换操作完全通过声明式配置完成，可无缝集成到 GitOps 和基础设施即代码（IaC）实践中，确保管理的一致性和可靠性。未来，Kubernetes 集群管理工具有望原生支持此切换能力。
Q&A
CloudNativePG 1.24的新功能是什么？
CloudNativePG 1.24引入了声明性管理PostgreSQL集群切换的新功能，允许在云区域或Kubernetes集群之间无缝降级主集群并晋升副本集群。
如何在Kubernetes中实现PostgreSQL集群的高可用性？
通过CloudNativePG的声明性配置，可以实现PostgreSQL集群的高可用性，确保在多区域和多集群环境中降低单点故障的风险。
在银行业中如何应用CloudNativePG的控制切换功能？
在银行业中，CloudNativePG的控制切换功能可以在不同区域之间进行数据中心的计划切换，确保服务的连续性和业务的正常运行。
CloudNativePG如何改善灾难恢复能力？
CloudNativePG通过支持跨多个区域的分布式PostgreSQL拓扑，增强了灾难恢复能力，降低了单点故障的风险。
如何配置PostgreSQL集群的分布式拓扑？
可以通过在CloudNativePG中定义externalClusters部分，明确数据库的分布式拓扑，以确保长期的清晰性和可维护性。
CloudNativePG的控制切换能力对Kubernetes环境有什么影响？
CloudNativePG的控制切换能力增强了Kubernetes环境中的操作能力，使得管理PostgreSQL集群更加高效和可靠。
