Aurora PostgreSQL 大版本升级指南

摘要：Amazon Aurora PostgreSQL 是亚马逊云科技基于云原生架构打造的托管型关系数据库服务，兼容PostgreSQL。根据 Amazon Aurora版本控制，大版本结束标准支持(EOL)前至少 6 个月通知，小版本至少 3 个月。 EOL 后未升级的集群将面临被自动升级，本篇主要介绍升级的方案和最佳实践。

01 一、概述

02 二、升级前置准备

03 三、升级与回滚方案

04 四、Kiro CLI 助力Aurora PostgreSQL 大版本升级

05 五、注意事项

06 六、相关内容推荐

一、概述

Amazon Aurora PostgreSQL 是亚马逊云科技基于云原生架构打造的托管型关系数据库服务，兼容PostgreSQL。根据 Amazon Aurora 版本控制，大版本结束标准支持(EOL)前至少 6 个月通知，小版本至少 3 个月。 EOL 后未升级的集群将面临被自动升级，建议提前规划升级窗口，避免被动升级导致的业务中断。

二、升级前置准备

2.1 版本生命周期考量

EOL 时间表：Aurora PostgreSQL Release Note 会列出大/小版本的标准支持结束日期，建议各版本支持的生命周期主动规划升级窗口，降低升级风险的同时减少升级频率。
长期支持版本(LTS): 每个 Aurora 主要版本中都有特定的次要版本被指定为长期支持（LTS）版本,支持期至少三年。LTS 版本仅包含关键修复,不包含新功能,适合追求长期稳定的生产环境。可通过Aurora PostgreSQL Release Note 查看各主要版本的 LTS 版本。
Extended Support 选项：理论上仅适用于大版本 EOL，借助 RDS 扩展支持，您可以在 Aurora 标准支持终止日期后，继续在主要引擎版本上运行数据库，可提供长达 3 年的服务，但需要额外付费。只能通过在首次创建或还原数据库实例时启用 RDS 扩展支持。在 Aurora 标准支持终止日期之后，Amazon Aurora 会自动将数据库实例注册到 RDS 扩展支持。

2.2 兼容性测试

Amazon Aurora PostgreSQL 兼容版的发布说明提供了可用于 Amazon Aurora PostgreSQL 版本和扩展的详细信息。除了本身原生PostgreSQL大版本带来的功能，SQL语法，性能层面的变化外，Aurora PostgreSQL也会有一些额外的功能变化，包括支持插件版本等，所以在升级大版本前一定要做好业务兼容性测试。

2.2.1 常用驱动的版本更新建议

[图1]

2.3 性能测试

（1）建立性能基线

在升级前，先在当前版本上收集性能基线数据：

-- 开启 pg_stat_statements 扩展（如果尚未开启）
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、缓存命中率

（2）执行计划对比

对 Top SQL 逐一对比新旧版本的执行计划，这是发现潜在性能问题最有效的方法：

-- 在旧版本和新版本上分别执行，对比输出
EXPLAIN (ANALYZE, BUFFERS) 
SELECT ... -- 你的关键业务 SQL

重点关注：

执行计划是否发生变化（如从 Index Scan 变为 Seq Scan）
预估行数（rows）与实际行数是否偏差过大
是否出现新的 Sort 或 Hash 操作
Buffers 的 shared hit/read 比例是否变化

另外，也可以使用Aurora PostgreSQL 提供的apg_plan_mgmt扩展，apg_plan_mgmt 本身支持存储多个计划版本，可以用来对比升级前后的执行计划。

（3）压力测试

可以使用 pgbench 或压测工具（JMeter）模拟生产负载。

# 初始化测试数据
pgbench -i -s 100 -h your-test-endpoint -U postgres testdb
# 运行混合读写压测（10 个客户端，持续 5 分钟）
pgbench -c 10 -j 4 -T 300 -h your-test-endpoint -U postgres testdb
# 使用自定义 SQL 脚本压测（更贴近真实业务）
pgbench -c 20 -j 8 -T 600 -f your_custom_workload.sql \
  -h your-test-endpoint -U postgres testdb

三、升级与回滚方案

3.1 升级方案概述

	基本原理	停机时间预估	优点	缺点
原地升级	直接原地进行大版本升级，升级时间和实例大小有关。	分钟到小时级不等	不依赖主键/唯一键等。应用不需要修改地址。下游CDC不需要修改订阅地址。	升级后不可回滚。中断时间相对较长并且和数据库大小有关。下游的pglogical订阅或者DMS同步任务需要重建。
蓝绿部署	通过蓝绿部署，新建一套相同配置的环境，然后自动升级绿环境到目标版本，蓝环境和绿环境之间通过publish/subcribe 逻辑复制进行数据实时同步。	通常在 1 分钟以内	在控制台一键部署，一键切换。应用不需要修改连接地址。 PG原生的逻辑复制，一般情况下不存在数据不一致问题。	PG 16版本以下，每个Database 默认分配一个slot单线程在目标库apply，当写入量较大时 lag无法追平。存在一些限制条件，具体见官方文档链接。
手动蓝绿部署	快照恢复/Clone +CDC	分钟级	DMS灵活度高，支持数据校验，对下游的数据CDC订阅中断时间短。手动pub/sub，使用原生逻辑复制能力，可以支持表级拆分任务，对数据校验依赖相对DMS较低。	需要应用和下游CDC订阅修改连接地址。可能需要拆分多个任务。一般需要表有主键/唯一键。
业务双写	通过双写进行低版本到高版本数据库的流量复制，实现大版本升级。	秒级	不依赖复制槽进行逻辑复制，没有主键/唯一键等的限制。应用端控制切流，不需要修改应用连接地址。	比如通过kafka消费到不同版本数据库，需要对业务进行一定的改造。通过开源proxy进行双写，但不能保证其稳定性和数据一致性，需要业务做充分的测试验证。

3.1.1 蓝绿部署

[图2]

蓝绿部署会创建一个复制生产环境的绿环境。其中,蓝环境是当前生产环境,绿环境是暂存环境。可以在绿环境中更改 Aurora 数据库集群而不影响生产工作负载—如修改数据库版本，配置参数，或将机型替换为更高性价比的 Graviton4。确认升级窗口后,在控制台实施蓝绿切换,将绿环境转换为新蓝环境。切换时间通常不到一分钟，无数据丢失，无需更改应用程序。但蓝绿部署存在使用限制,详见 Amazon Aurora 蓝绿部署的限制和注意事项：

1. 准备阶段（以升级到17.7 LTS版本为例）

（1）创建新版本参数组

[图3]

（2）修改蓝集群参数

Aurora PostgreSQL 通过蓝绿部署进行大版本升级时，通过PostgreSQL原生的Publisher/Subscriber实现实时数据同步，所以要调整rds.logical_replication=1参数（需要重启数据库实例）。

另外需要关注max_replication_slots，max_wal_senders, max_logical_replication_workers, and max_worker_processes等参数,逻辑复制过程中会默认给每个database 创建一个复制slot，所以最大slot数和worker数需要大于database数量。

（3）删除蓝集群 slot，蓝环境数据库集群不能是publisher或者subscriber。下游CDC订阅需要在升级后重建slot。

select pg_drop_replication_slot('slot_name');
--或者批量删除
SELECT pg_drop_replication_slot(slot_name) 
FROM pg_replication_slots WHERE active = false;

2. 创建蓝绿部署

在创建蓝绿部署时，需要指定绿集群的版本为 17.7。蓝绿部署会先创建与绿集群版本相同的实例，然后再升级到目标版本 17.7。更多创建过程见官方文档在 Amazon Aurora 中创建蓝绿部署。

[图4]

3. 蓝绿切换

在蓝绿增量数据复制状态正常的情况下，您可以选择在合适的运维窗口执行蓝绿切换操作。升级完成后由后台自动完成数据库的 Endpoint 映射，理论上业务端无需修改，更多内容见切换 Amazon Aurora 中的蓝绿部署。

（1）观察蓝绿复制延时

可以在蓝环境通过下面SQL查看同步延时，当同步延迟较低时可以开始停止业务。

postgres=> 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';
                   slot_name                    | slot_type | active |   lag
------------------------------------------------+-----------+--------+---------
 rds_us_east_1_4z4vvndhdoj3vkm6onwtapcrga_16384 | logical   | t      | 0 bytes
 rds_us_east_1_4z4vvndhdoj3vkm6onwtapcrga_14717 | logical   | t      | 0 bytes
 rds_us_east_1_4z4vvndhdoj3vkm6onwtapcrga_24616 | logical   | t      | 0 bytes

也可以在CloudWatch观察同步延迟。

[图5]

（2）执行蓝绿切换

可以在控制台执行Switch over：

[图6]

成功标志：蓝绿部署状态显示Switchover complete。

[图7]

另外，Recent events看到有Blue/green deployment tasks completed日志。

[图8]

（3）升级 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;

4. 重新创建下游CDC同步：在蓝绿切换完成后，需要基于当前数据库的 slot 位点，重建下游消费的 CDC 数据同步任务。具体步骤:

1. 在新蓝环境创建slot时会提供新的LSN。
2. 使用该 LSN 作为起始点重建下游 CDC 订阅。
3. 验证数据同步正常后删除旧订阅。

5. 升级验证：启动应用服务后，业务方进行测试验证。

3.1.2 手动蓝绿部署：Clone + DMS （以升级到17.7 LTS版本为例）

[图9]

1. 环境准备

（1）创建新版本参数组：需要分别创建cluster parameter group和 instance parameter group。

（2）修改旧版本集群参数：同蓝绿部署，此次不再赘述。

2. Clone 数据

（1）老版本数据库创建复制槽与WAL保护

-- ⚠️ 关键步骤：创建复制槽保护WAL
SELECT pg_create_logical_replication_slot('dms_cdc_slot', 'test_decoding');

-- 验证复制槽创建成功
SELECT 
    slot_name,
    restart_lsn,
    pg_current_wal_lsn() as current_lsn,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) as protected_wal_size
FROM pg_replication_slots 
WHERE slot_name = 'dms_cdc_slot';

复制槽的作用是保护WAL日志不被删除，确保快照恢复后同步数据完整性。

（2）通过Aurora Fast Clone创建Clone数据库。

[图10]

（3）获取Clone数据库LSN位点。

-- 连接升级后的 clone 库，获取DMS CDC起始位置
SELECT aurora_volume_logical_start_lsn() as target_lsn;

（4）清理Clone数据库内的复制槽

select pg_drop_replication_slot('slot_name');
--或者批量删除
SELECT pg_drop_replication_slot(slot_name) 
FROM pg_replication_slots WHERE active = false;

（5）Clone 库执行原地 17.7 大版本升级操作

[图11]

（6）Clone 数据库升级 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;

3. DMS 搭建增量复制链路

（1）创建 DMS 实例并配置源和目标端 Endpoint

DMS 可以通过在Clone库 Endpoint设置 session_replication_role=replica 跳过外键检查和普通 Trigger 触发。另外可以通过在源和目标数据库Endpoint设置MapUnboundedNumericAsString=true;避免numeric类型数据精度损失的问题。

（2) 创建DMS任务（使用已配置的Endpoint）

DMS 任务创建过程中选择只做CDC同步，并且指定步骤2 中获取的Clone数据库LSN位点。另外需要注意LOB字段同步相关的参数设置。

（3）观察 DMS 数据同步延时

4. 数据校验

DMS 支持在创建任务时开启数据校验功能，也可以单独创建 DMS 数据校验任务（ValidationOnly 模式）。校验通过按主键/唯一键在源和 Clone 数据库顺序逐行读取进行对比，所以对于数据量较大的情况下数据校验的时间会非常久，建议在切换前提前开启校验，并且需要注意校验任务对源库和目标库的性能影响。

5. 升级切换

（1）选择合适的停机窗口停止业务，确保没有写流量。

（2）观察DMS没有延迟，停止DMS任务。

（3）重置 Clone 数据库 Sequence nextval 值，在源数据库执行下面 SQL，拼接后 SQL，在Clone 数据库执行目标库 Max value+1，避免后续插入数据时出现主键冲突：

SELECT 'SELECT setval(''' || ns.nspname || '.' || seq.relname || ''',
 COALESCE(MAX(' || a.attname || '), 1)) FROM ' || ns.nspname || '.' || t.relname || ';'
FROM pg_class seq
JOIN pg_namespace ns ON seq.relnamespace = ns.oid
JOIN pg_depend d ON d.objid = seq.oid
JOIN pg_class t ON d.refobjid = t.oid
JOIN pg_attribute a ON a.attrelid = t.oid AND a.attnum = d.refobjsubid
WHERE seq.relkind = 'S'
  AND ns.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY ns.nspname, seq.relname;

6. 业务侧升级验证

（1）业务侧更改 Endpoint。

（2）启动业务，测试验证。

3.2 回滚方案

对于核心数据库建议有升级后回滚方案，比如在升级到新的大版本后一定的时间内，如果遇到新版本无法解决的问题，可以回滚到旧版本的实例，那么就需要CDC同步链路在升级后能够将新版本的数据实时同步到旧版本数据库。

[图12]

DMS回滚任务搭建和升级任务基本一致，此次指保留以下需要特别关注的关键步骤：

1. 获取 DMS 反向同步数据起始 LSN 位点

业务侧启动前，在升级目标库(Clone 库/新蓝环境)执行下述 SQL 获取 LSN 位点：

-- 关键步骤：创建复制槽保护WAL，防止WAL被自动清理
SELECT pg_create_logical_replication_slot('dms_cdc_slot', 'test_decoding');

-- 验证复制槽创建成功
SELECT 
    slot_name,
    restart_lsn,
    pg_current_wal_lsn() as current_lsn,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) as protected_wal_size
FROM pg_replication_slots 
WHERE slot_name = 'dms_cdc_slot';

2. 启动DMS反向数据同步

参照 3.2.3搭建回滚链路（DMS 实例、源和目标端Endpoint以及反向数据同步task可以提前创建好，但不启动，减少回滚时间），修改DMS任务为第1步升级目标库(Clone 库/新蓝环境)业务停写后的 LSN 位点。

四、Kiro CLI 助力Aurora PostgreSQL 大版本升级

Amazon Kiro CLI是一个由人工智能驱动的命令行界面工具，专为开发者和DevOps工程师设计。它基于Claude大语言模型，能够帮助用户通过自然语言对话的方式与AWS服务进行交互，执行各种开发和运维任务。该工具支持数百种流行的CLI命令（如git、npm、docker、aws等）的智能补全，可以理解用户的代码库环境，协助读写本地文件、查询AWS资源、编写代码以及自动调试问题，从而显著提升开发效率和简化AWS资源管理流程。比如可以帮助客户在手动蓝绿升级过程中创建任务，错误诊断，性能分析等。

[图13]

升级条件检查结果和生成的蓝绿部署创建、切换脚本如下：

[图14]

五、注意事项

Aurora PostgreSQL蓝绿部署是否支持无主键表？不完全支持，有限制条件。Aurora PostgreSQL蓝绿部署进行大版本升级时使用逻辑复制的方式进行蓝绿集群间数据实时同步，蓝绿部署创建后无主键表后无法进行update和delete，需要添加REPLICA IDENTITY FULL后才可以正常更新和删除，但是会对性能有一定影响，所以建议提前添加主键。对于只有insert操作的表，不影响同步正常运行。蓝绿部署限制
PostgreSQL 是否支持在绿环境实例作为源创建DMS任务或者复制槽？Aurora 蓝绿部署的绿环境在切换前不支持创建复制槽或作为逻辑复制源。只能在蓝绿切换完成后，在新的蓝环境上创建复制槽并启动 DMS 任务（DMS 任务可以提前创建，切换后再启动）。
如何基于PostgreSQL位点进行DMS同步？如果是蓝绿切换过程中，应用停写后即可通过SELECT pg_current_wal_lsn();获取绿环境当前的LSN位点，然后进行反向回滚链路搭建。
如果DMS指定的位点早于蓝绿部署切换时间，DMS是否能够正常运行，主键冲突如何处理？如果目标库没有主键/唯一键，数据会重复。有主键/唯一键的情况下DMS会报错，但任务不会中断。
升级过程中或者升级后不同类型对象是否需要做特殊处理？蓝绿部署需要在升级后手动升级扩展插件。手动蓝绿Clone+ DMS 升级过程中需要对FK、Trigger、Sequence、大字段等做特殊处理，比如CDC同步可以在DMS目标库Endpoint设置 session_replication_role=replica 跳过外键检查和普通Trigger触发、切换过程中需手动重置Sequence nextval 值等。
大版本升级完成后建议手动在新版本的数据库做一次整库的analyze，避免统计信息没有更新导致SQL执行计划产生偏差，进而引发生产问题。

六、相关内容推荐

相关产品：

Amazon Aurora — 适用于 PostgreSQL、MySQL 和 DSQL 的无服务器关系数据库服务
Amazon DMS — 数据库迁移服务
Amazon RDS — 完全托管的关系数据库服务
Amazon CloudWatch — 可观测性工具

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客