Amazon Aurora PostgreSQL 大版本升级：蓝绿部署技术深度解析

概述

Amazon Aurora PostgreSQL 遵循严格的版本生命周期管理：大版本 EOL 前至少 6 个月通知，超期未升级的集群将面临自动升级。本文基于亚马逊云科技官方博客的升级指南，深入分析蓝绿部署的技术实现细节和工程实践。

升级前置准备

版本生命周期规划

• LTS 版本：每个大版本有指定的长期支持版本，支持期至少三年，仅含关键修复
• Extended Support：EOL 后可额外付费延长最多 3 年，但属于权宜之计
• 目标版本选择：建议直接升级到新大版本的 LTS 版本（如 17.7）

性能基线建立

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- Top SQL 统计
SELECT queryid, substr(query,1,100) as query_preview,
       calls, mean_exec_time, total_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 50;

需要同时记录：

• Top 50 SQL 的执行时间分布
• P99 响应时间
• QPS/TPS
• CPU 使用率、IOPS、缓存命中率

执行计划对比

这是发现潜在性能回退最有效的手段。在新旧版本环境分别执行：

EXPLAIN (ANALYZE, BUFFERS)
SELECT ... -- 关键业务 SQL

重点关注：

• 执行计划变化（Index Scan → Seq Scan）
• 预估行数与实际行数偏差
• 新增 Sort/Hash 操作
• Buffers shared hit/read 比例变化

Aurora PG 的 apg_plan_mgmt 扩展可存储多个计划版本用于对比分析。

压力测试

# 标准混合读写
pgbench -c 10 -j 4 -T 300 -h test-endpoint -U postgres testdb

# 自定义业务负载
pgbench -c 20 -j 8 -T 600 -f custom_workload.sql -h test-endpoint -U postgres testdb

升级方案比较

方案	停机时间	复杂度	回滚能力	主键依赖
原地升级	分钟~小时	低	无法回滚	无
蓝绿部署	< 1 分钟	中	保留旧集群	逻辑复制需要
Clone+DMS	分钟级	高	保留旧集群	DMS 需要
业务双写	秒级	很高	应用层控制	无

蓝绿部署技术详解

原理

蓝绿部署基于 PostgreSQL 原生 Publication/Subscription 逻辑复制机制。系统自动为每个 Database 创建复制 slot，实现蓝→绿的实时数据同步。

步骤 1：启用逻辑复制

修改蓝集群参数组：

rds.logical_replication = 1

此参数修改需要重启数据库实例。同时确保以下参数足够（必须大于 Database 数量）：

• max_replication_slots
• max_wal_senders
• max_logical_replication_workers
• max_worker_processes

步骤 2：清理现有复制 Slot

蓝环境不能是已有的 publisher 或 subscriber：

SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots WHERE active = false;

步骤 3：创建蓝绿部署

在控制台指定绿集群目标版本。系统会创建与蓝集群相同配置的绿环境，然后自动升级并建立逻辑复制。

步骤 4：监控复制延迟

SELECT slot_name, slot_type, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots
WHERE slot_type = 'logical';

也可通过 CloudWatch 指标 AuroraReplicaLag 监控。

步骤 5：执行切换

延迟降至 0 → 停止业务写入 → 在控制台执行 Switch over → 状态显示 "Switchover complete"。

Endpoint 自动重新映射，应用无需修改连接地址。切换时间通常不到一分钟。

步骤 6：切换后操作

Extension 升级：

-- 检查需要升级的 Extension
SELECT e.extname, e.extversion AS current, a.default_version AS available
FROM pg_extension e
JOIN pg_available_extensions a ON e.extname = a.name
WHERE e.extversion != a.default_version;

-- 生成升级语句
SELECT 'ALTER EXTENSION ' || e.extname || ' UPDATE;'
FROM pg_extension e
JOIN pg_available_extensions a ON e.extname = a.name
WHERE e.extversion != a.default_version;

重建 CDC 同步：

1. 在新环境创建 slot，获取 LSN
2. 用新 LSN 重建下游订阅
3. 验证正常后删除旧订阅

技术限制与注意事项

1. PG 16 以下单线程 Apply：每个 Database 一个 slot 单线程 apply，高写入场景 lag 可能追不平
2. 逻辑复制限制：需要表有主键或 REPLICA IDENTITY FULL
3. DDL 不同步：蓝绿部署期间避免在蓝环境做 DDL 变更
4. 长事务影响：大批量操作会增加复制延迟，切换前应避免

详细限制条件参考 官方文档。

总结

Aurora PostgreSQL 蓝绿部署将大版本升级的停机时间压缩到一分钟以内，是大部分生产场景的推荐方案。升级的难点不在切换本身，而在前期的兼容性测试和性能基线对比。建议提前规划，用 Clone 集群做完整测试。

---

参考：

• Aurora PostgreSQL 大版本升级指南
• Aurora 蓝绿部署文档