肖恩·M·托马斯：PG星期五：重新定义Postgres高可用性
内容提要
Postgres缺乏本地高可用性（HA），现有的HA技术存在限制。然而，Postgres云供应商正在采用一种方法，将Postgres转变为真正的HA数据库引擎。存储层是一个关键考虑因素，复制存储系统提供了潜在的解决方案。将存储引擎与处理层解耦，并使用基于仲裁的分布式文件系统可以在系统之间提供一致性。分片和协调器/工作节点模型可以帮助扩展计算层。Postgres有潜力成为Web3组件，具有分布式块算法和共识实现。虽然这可能不会被Postgres社区采纳，但对于HA来说具有潜在的好处。目前，Patroni和Kubernetes操作员是管理Postgres集群的最新技术。Postgres变体如Aurora、NeonDB和AlloyDB也在取代存储层方面取得进展。
延伸解读
存储层解耦：高可用的关键突破
文章指出，Postgres缺乏原生高可用性，传统方案依赖流复制，存在配置复杂和切换风险。云厂商如Aurora、NeonDB和AlloyDB通过替换存储层，将存储与计算解耦，利用分布式文件系统（如Ceph、MinIO、SimplyBlock）的纠删码和仲裁机制，实现数据一致性。这消除了显式副本的需求，使多个Postgres实例可共享存储，故障切换缩短至秒级，为高可用奠定基础。
协调器/工作节点模型：扩展计算层
为扩展计算层，文章提出采用分片和协调器/工作节点模型，类似Citus和Postgres-XL。协调器负责路由和聚合，工作节点处理数据。结合分布式存储，可动态创建协调器克隆和工作节点，避免传统流复制中的脑裂问题，并支持微服务架构下每个服务拥有专用协调器。这解决了Postgres自9.0以来多主机连接字符串的危险性，提升了可扩展性和可靠性。
Web3愿景：Postgres作为分布式集群
文章探讨了将Postgres转变为Web3组件的可能性，即内置分布式块算法和共识机制（如Paxos或Raft）。节点可自动组成子组进行O(log n)投票，存储自动再平衡，读写由仲裁驱动以确保持久性。虽然社区Postgres可能不会采纳，但企业可能看到其潜力并尝试构建。这种集群感知的自组织分布式Postgres集群，有望实现真正的高可用，但需保持与根Postgres的兼容性。
当前实践与未来展望
目前，Patroni和Kubernetes操作员（如CloudNativePG）是管理传统Postgres集群的最佳实践，但文章认为它们只是权宜之计。多主集群如pgEdge和EDB Postgres Distributed简化了升级，却面临写冲突。存储层变体如Aurora、NeonDB和AlloyDB正逐步接近真正的高可用。未来，解耦存储与计算、采用协调器/工作节点模型，甚至融入Web3共识，可能引领Postgres高可用的新方向。
Q&A
Postgres的高可用性（HA）面临哪些主要问题？
Postgres缺乏本地高可用性，现有的HA技术依赖流复制，容易出错，且配置复杂。
如何将Postgres转变为真正的高可用性数据库引擎？
通过解耦存储引擎与处理层，并使用基于仲裁的分布式文件系统，可以实现一致性和高可用性。
当前有哪些技术用于管理Postgres集群？
目前，Patroni和Kubernetes操作员是管理Postgres集群的最佳实践。
Postgres的存储层改进对高可用性有什么影响？
存储层的改进使得不再需要显式的数据库副本，支持更多Postgres实例，提高了资源利用率。
Postgres如何适应Web3的需求？
Postgres有潜力成为Web3组件，具备分布式块算法和共识机制，尽管社区可能不会采纳这些概念。
多主集群在Postgres中面临哪些挑战？
多主集群如pgEdge和EDB Postgres Distributed简化了版本升级，但面临写冲突问题。
