Wellingtone Luvonga：跨区域部署：如何搭建 CloudNativePG（CNPG）分布式拓扑
内容提要
本文介绍如何使用 CloudNativePG 在本地 minikube 和 MinIO 上搭建分布式 PostgreSQL 拓扑：主集群持续将 WAL 日志写入对象存储，副本集群位于另一 Kubernetes 集群或区域，从对象存储引导并轮询新 WAL 保持同步。通过 ObjectStore 资源、replica 声明和 externalClusters 配置实现角色匹配与故障切换。需注意对象存储延迟会影响复制滞后，并保持两集群镜像版本一致。
延伸解读
对象存储延迟决定复制滞后
该架构依赖对象存储进行WAL日志传输，而非直接流复制。因此，复制滞后取决于WAL归档到对象存储的速度以及副本轮询新WAL段的频率。如果对象存储网络性能不佳，滞后会显著增加。部署时需密切关注存储网络性能，确保满足恢复点目标（RPO）要求。
声明式角色匹配简化故障切换
CNPG通过spec.replica.primary和spec.replica.source实现声明式角色匹配。主集群的metadata.name与replica.primary值匹配时，操作器自动将其配置为读写主库。同时指定source: pg-standby，预先映射了降级时的日志查找路径。这种动态评估机制避免了手动切换，使拓扑逻辑更清晰，故障切换更自动化。
版本一致性是稳定运行的前提
主集群和副本集群必须运行完全相同的PostgreSQL和CNPG操作器版本，以避免兼容性问题。文中示例使用PostgreSQL 18.3。版本不一致可能导致副本无法正确引导或同步，甚至引发意外错误。在跨区域部署中，统一版本管理是确保分布式拓扑稳定运行的基础。
Q&A
CloudNativePG 分布式拓扑是如何实现跨区域复制的？
主集群持续将 WAL 日志流式写入对象存储（如 S3、MinIO），副本集群位于另一 Kubernetes 集群或区域，从对象存储引导自身并持续轮询新的 WAL 段来保持同步。
搭建 CNPG 分布式拓扑需要哪些关键配置？
需要定义 ObjectStore 自定义资源（通过 barman-cloud 插件）来连接对象存储；主集群配置 replica 声明以支持未来切换；副本集群通过 externalClusters 指向对象存储，并设置 spec.replica.primary 和 spec.replica.source 实现声明式角色匹配。
CNPG 分布式拓扑中如何实现故障切换？
通过声明式角色匹配：主集群的 metadata.name 与 replica.primary 值匹配时被配置为读写主库；副本集群指定 source 指向主集群，当主集群降级为备库时，它能自动知道从何处获取日志，无需修改拓扑逻辑。
使用对象存储进行复制时需要注意哪些性能问题？
复制延迟取决于 WAL 归档和处理的速度，因此需要密切关注存储网络性能，因为该架构依赖对象存储日志传输而非直接流复制。
主集群和副本集群的版本需要保持一致吗？
是的，必须确保主集群和副本集群运行完全相同的 PostgreSQL 和 CNPG operator 版本，以避免兼容性问题（示例中使用 PostgreSQL 18.3）。
CNPG 分布式拓扑相比传统方案有什么优势？
它无需复杂的跨集群网络网格设置，利用对象存储驱动框架即可实现数据弹性和灾难恢复，管理 PostgreSQL on Kubernetes 更强大。
