Paxos 使用 Aurora Blue-Green 升级将 Postgres 停机时间减少 50 倍
realtime news Apr 23, 2026 17:37
Paxos 通过 Aurora Blue-Green 升级将 Postgres 停机时间从 30-120 分钟减少到 1 分钟，提高了正常运行时间以满足 99.99% 的服务水平目标（SLOs）。
作为受监管的区块链基础设施提供商，Paxos 透露，通过实施 Aurora Blue-Green 升级，其 Postgres 停机时间减少了 50 倍——从每个集群 30-120 分钟缩短到仅约 1 分钟。这一改进帮助公司在其 24/7 运行的资产交易基础设施中维持严格的 99.99% 正常运行时间服务水平目标（SLOs）。对于拥有超过 60 个 Postgres 集群的 Paxos，这一升级策略还消除了与传统升级流程相关的一个月的协调工作量。
数据库停机时间是 Paxos 面临的一个重大运营挑战，该公司为机构和消费者提供受监管的数字资产服务。即使是计划内的维护也会对交易和交易的可靠性带来重大风险。Aurora Blue-Green 升级是 AWS 提供的一种解决方案，通过 PostgreSQL 逻辑复制创建一个与生产环境“蓝”同步的并行“绿”环境。切换可以在不到一分钟内完成，从而最大限度地减少流量中断。
主要挑战和经验教训
尽管收益显著，但 Paxos 在实施过程中遇到了几个技术难题：
- 临时角色： Paxos 使用 Vault 管理临时数据库凭证，这会生成
CREATE ROLE语句。这些语句与 Blue-Green 升级发生冲突，要求 Paxos 在升级窗口期间禁用动态角色创建。 - 复制槽删除： 在 PostgreSQL 17 之前，逻辑复制槽在升级期间必须被删除，这导致 Change Data Capture（CDC）系统中出现临时数据丢失。Paxos 依赖回填策略来恢复丢失的数据，这一过程每个集群可能需要长达 30 小时。
- 集群 ID 更改： 升级后，绿色集群成为主集群并接收新的集群 ID，这会影响 RDS IAM 身份验证。调整客户端配置为每个集群增加了额外 1-2 小时的工作量。
尽管存在这些挑战，但结果令人信服。传统的升级方法每个集群通常需要 30-120 分钟，常常威胁到公司满足 99.9% 月正常运行时间的能力。而通过 Blue-Green 升级，这些数字轻松落在 99.99% 正常运行时间范围内，大幅提高了服务的可靠性。
对高正常运行时间系统的广泛影响
Aurora Blue-Green 升级并非新技术——AWS 在 2025 年为 MySQL 和 PostgreSQL 引入了这一方法——但 Paxos 的采用突显了其在金融服务领域的重要性。数字资产等行业的高可用性需求，使得即使是短暂的中断也可能对市场造成干扰，因此这些策略至关重要。AWS 承诺的不到一分钟的切换时间完美契合此类需求，降低了运营风险，同时维护了用户信任。
类似的应用场景也在涌现，例如 Wiz 在 2025 年 8 月实现的几乎零停机 Aurora PostgreSQL 升级，以及同年早些时候 InstantDB 对逻辑复制问题的实验。随着 PostgreSQL 17 解决了诸如复制槽删除等关键限制，未来的升级有望更加顺畅。
Paxos 的下一步计划是什么？
Paxos 正优先考虑升级到 PostgreSQL 17，该版本消除了在未来迁移期间删除复制槽的需求。这一变化本身可以防止 CDC 系统中的数据缺口，免去大量回填工作的需求。此外，Paxos 正在推动 AWS 支持从只读节点的复制槽连续性，这将进一步简化 Blue-Green 流程。
对于运行大规模 Postgres 集群的公司来说，Paxos 的经验提供了宝贵的见解：尽早解决像 Vault 这样的动态授权系统问题，规划 CDC 中断，并为 IAM 更新做好准备。通过正确的策略，即使是最复杂的升级也可以符合现代数字基础设施要求的高可用性标准。
Image source: Shutterstock.jpg)