升级 Amazon Aurora PostgreSQL 数据库集群

仅当经过广泛的测试后，Amazon Aurora 才会在 AWS 区域中推出 PostgreSQL 数据库引擎的新版本。当您的区域中推出新版本时，您可以将 Aurora PostgreSQL 数据库集群升级到新版本。

根据数据库集群当前运行的 Aurora PostgreSQL 版本，升级到新版本可能是次要版本升级，也可能是主要版本升级。例如，将 Aurora PostgreSQL 11.15 数据库集群升级到 Aurora PostgreSQL 13.6 就是主要版本升级。将 Aurora PostgreSQL 13.3 数据库集群升级到 Aurora PostgreSQL 13.7 是次要版本升级。在以下主题中，您可以了解有关如何执行这两种升级类型的信息。

目录

• Aurora PostgreSQL 升级过程概述
• 获取您的 AWS 区域中可用版本的列表
• 如何执行主要版本升级
  • 测试将生产数据库集群升级到新的主要版本
  • 将 Aurora PostgreSQL 引擎升级到新的主要版本
    • 全局数据库的主要版本升级
• 在执行次要版本升级之前
• 如何执行次要版本升级和应用补丁
  • 次要版本升级和零停机时间修补
  • 将 Aurora PostgreSQL 引擎升级到新的次要版本
• 升级 PostgreSQL 扩展
• 备选的蓝绿升级技术

Aurora PostgreSQL 升级过程概述

主要版本升级和次要版本升级之间的区别如下：

次要版本升级和补丁

次要版本升级和补丁仅包含与现有应用程序向后兼容的更改。只有在经过 Aurora PostgreSQL 测试并批准后，您才可以使用次要版本升级和补丁。

Aurora 可以自动为您应用次要版本升级。在您创建新的 Aurora PostgreSQL 数据库集群时，已预先选择 Enable minor version upgrade（启用次要版本升级）选项。除非关闭此选项，否则将在计划的维护时段期间自动应用次要版本升级。有关自动次要版本升级（AmVU）选项以及如何修改 Aurora 数据库集群以使用该选项的更多信息，请参阅 Aurora 数据库集群的自动次要版本升级。

如果没有为 Aurora PostgreSQL 数据库集群设置自动次要版本升级选项，则 Aurora PostgreSQL 不会自动升级到新的次要版本。相反，当您的 AWS 区域中发布了新的次要版本，但您的 Aurora PostgreSQL 数据库集群运行的是较旧的次要版本时，Aurora 会提示您进行升级。它通过向集群的维护任务添加建议来实现。

补丁不被视为升级，不会自动应用。Aurora PostgreSQL 通过向 Aurora PostgreSQL 数据库集群的维护任务添加建议，提示您应用任何补丁。有关更多信息，请参阅 如何执行次要版本升级和应用补丁。

注意

解决安全或其他严重问题的补丁也会添加为维护任务。但是，这些补丁是必需的。确保当安全补丁在待定的维护任务中变为可用时，将它们应用于 Aurora PostgreSQL 数据库集群。

随着集群中的每个实例都升级到新版本，升级过程可能会导致短暂的中断。但是，在 Aurora PostgreSQL 版本 14.3.3、13.7.3、12.11.3、11.16.3、10.21.3 以及这些次要版本的其他更高版本和更高的主要版本之后，升级过程使用零停机修补（ZDP）特征。此特征可最大限度地减少中断，并在大多数情况下彻底消除中断。有关更多信息，请参阅 次要版本升级和零停机时间修补。

注意

在以下情况下，不支持 ZDP：

• 当 Aurora PostgreSQL 数据库集群配置为 Aurora Serverless v1 时。

• 当 Aurora PostgreSQL 数据库集群配置为辅助 AWS 区域中的 Aurora 全局数据库时。

• 在升级 Aurora 全局数据库中的读取器实例期间。

• 在操作系统修补和操作系统升级期间。

配置为 Aurora Serverless v2 的 Aurora PostgreSQL 数据库集群支持 ZDP。

主要版本升级

与次要版本升级和补丁不同，Aurora PostgreSQL 没有自动主要版本升级选项。新的主要 PostgreSQL 版本可能包含未与现有应用程序向后兼容的数据库更改。新功能会导致现有应用程序停止正常工作。

为了避免出现任何问题，我们强烈建议您在升级 Aurora PostgreSQL 数据库集群中的数据库实例之前，按照测试将生产数据库集群升级到新的主要版本中概括的过程操作。首先，请按照该过程确保您的应用程序可以在新版本上运行。然后，您可以手动将 Aurora PostgreSQL 数据库集群升级到新版本。

随着集群中的所有实例都升级到新版本，升级过程可能会导致短暂停机。初步计划过程也需要时间。我们建议您始终在集群的维护时段或操作极少时执行升级任务。有关更多信息，请参阅 如何执行主要版本升级。

注意

次要版本升级和主要版本升级都可能会导致短暂的中断。因此，我们强烈建议您在维护时段或利用率低的其他时段执行或安排升级。

Aurora PostgreSQL 数据库集群偶尔需要操作系统更新。这些更新可能包含较新版本的 glibc 库。在此类更新期间，我们建议您遵循 Aurora PostgreSQL 中支持的排序规则中所述的指南。

获取您的 AWS 区域中可用版本的列表

通过查询 AWS 区域并使用 AWS CLI 命令 describe-db-engine-versions，您可以获得可用作 Aurora PostgreSQL 数据库集群的升级目标的所有引擎版本列表，如下所示。

对于 Linux、macOS 或 Unix：

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

对于 Windows：

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

例如，要确定 Aurora PostgreSQL 版本 12.10 数据库集群的有效升级目标，请运行以下 AWS CLI 命令：

对于 Linux、macOS 或 Unix：

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version 12.10 \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

对于 Windows：

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version 12.10 ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

在该表中，您可以找到适用于各种 Aurora PostgreSQL 数据库版本的主要和次要版本升级目标。

当前源版本	升级目标
15.5	16.1
15.4	16.1	15.5
15.3	16.1	15.5	15.4
15.2	16.1	15.5	15.4	15.3
14.10	16.1	15.5
14.9	16.1	15.5	15.4	14.10
14.8	16.1	15.5	15.4	15.3	15.2	14.10	14.9
14.7	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8
14.6	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7
14.5	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6
14.4	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	14.5
14.3	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	14.5	14.4
13.13	16.1	15.5	14.10
13.12	16.1	15.5	15.4	14.10	14.9
13.11	16.1	15.5	15.4	15.3	14.10	14.9	14.8
13.10	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	13.13	13.12	13.11
13.9	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	13.11	13.10
13.8	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	14.5	13.13	13.12	13.11	13.10	13.9
13.7	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	14.5	14.4	14.3	13.13	13.12	13.11	13.10	13.9	13.8
12.17	16.1	15.5	14.10	13.13
12.16	16.1	15.5	15.4	14.10	14.9	13.13	13.12
12.15	16.1	15.5	15.4	15.3	14.10	14.9	14.8	13.13	13.12	13.11
12.14	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	13.13	13.12	13.11	13.10	12.15
12.13	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	12.14
12.12	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	14.5	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	13.8	12.15	12.14	12.13
12.11	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.5	14.4	14.3	13.13	13.12	13.11	13.10	13.9	13.8	13.7	12.15	12.14	12.13	12.12
12.9	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	13.13	13.12	13.11	13.10	13.9	13.8	13.7	12.17	12.16	12.15	12.14	12.13	12.12	12.11
11.21	16.1	15.5	15.4	14.10	14.9	13.13	13.12	12.17	12.16
11.9	16.1	15.5	15.4	15.3	15.2	14.10	14.9	14.8	14.7	14.6	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	12.14	12.13	12.12	12.11	12.09	11.21

对于您正在考虑的任何版本，请始终检查集群数据库实例类的可用性。例如，Aurora PostgreSQL 13 不支持 db.r4。如果您的 Aurora PostgreSQL 数据库集群当前使用 db.r4 实例类，则在尝试升级之前需要移至 db.r5。有关数据库实例类的更多信息，包括哪些实例类基于 Graviton2 以及哪些实例基于英特尔，请参阅 Aurora 数据库实例类。

如何执行主要版本升级

主要版本升级可能包含不与数据库的以前版本向后兼容的数据库更改。新版本中的新功能会导致现有应用程序停止正常工作。为避免出现问题，Amazon Aurora 不会自动应用主要版本升级。相反，我们建议您按照以下步骤仔细规划主要版本升级：

1. 从表中为您的版本列出的可用目标列表中选择所需的主要版本。通过使用 AWS CLI，您可以获得您的 AWS 区域中针对当前版本推出的版本的精确列表。有关详细信息，请参阅获取您的 AWS 区域中可用版本的列表。

2. 验证您的应用程序在新版本的试用部署中是否按预期工作。有关完整过程的信息，请参阅测试将生产数据库集群升级到新的主要版本。

3. 在验证应用程序在试用部署中按预期工作后，您可以升级集群。有关详细信息，请参阅将 Aurora PostgreSQL 引擎升级到新的主要版本。

注意

您可以执行主要版本升级，以从基于适用于 Aurora PostgreSQL 的 Babelfish 13 的版本（从 13.6 开始）升级到基于 Aurora PostgreSQL 14 的版本（从 14.6 开始）。适用于 Aurora PostgreSQL 的 Babelfish 13.4 和 13.5 不支持主要版本升级。

通过查询 AWS 区域并使用 AWS CLI 命令 describe-db-engine-versions，您可以获得可用作 Aurora PostgreSQL 数据库集群的主要版本升级目标的引擎版本列表，如下所示。

对于 Linux、macOS 或 Unix：

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text

对于 Windows：

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
  --output text

在某些情况下，要升级到的版本不是当前版本的目标。在这种情况下，请使用versions table中的信息执行次要版本升级，直到您的集群处于其目标行中包含所选目标的版本。

测试将生产数据库集群升级到新的主要版本

每个新的主要版本都包括对查询优化程序的增强，旨在提高性能。但是，您的工作负载可能包括导致新版本中计划性能较差的查询。正因如此，我们建议您在生产环境中进行升级之前，先测试和审查性能。您可以使用查询计划管理 (QPM) 扩展来管理跨版本的查询计划稳定性，详情请参阅 确保主要版本升级后的计划稳定性。

在将生产 Aurora PostgreSQL 数据库集群升级到新的主要版本之前，我们强烈建议您测试升级，以验证所有应用程序是否正常工作：

1. 准备好一个版本兼容的参数组。

   如果您使用的是自定义数据库实例或数据库集群参数组，您可以从两个选项中进行选择：

   1. 为新的数据库引擎版本指定默认数据库实例和/或数据库集群参数组。

   2. 为新的数据库引擎版本创建您自己的自定义参数组。

   如果在升级请求中关联了新的数据库实例或数据库集群参数组，则确保在升级完成后重新启动数据库才能应用参数。如果需要重新启动数据库实例来应用参数组更改，则该实例的参数组状态将显示 pending-reboot。您可以在控制台中查看实例的参数组状态，也可以使用 CLI 命令（例如，describe-db-instances 或 describe-db-clusters）来查看。

2. 检查是否有不支持的使用方式：

   • 在尝试升级前，提交或回滚所有打开的已准备事务。您可以使用以下查询确认您的实例上是否没有打开的已准备事务。

     SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

   • 在尝试升级前取消使用所有 reg* 数据类型。除了 regtype 和 regclass 以外，您不能升级 reg* 数据类型。pg_upgrade 实用工具（Amazon Aurora 用来执行升级）不能保留这个数据类型。要了解有关此实用程序的更多信息，请参阅 PostgreSQL 文档中的 pg_upgrade。

     要验证是否没有使用不支持的 reg* 数据类型，请对每个数据库使用以下查询。

     SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a 
       WHERE c.oid = a.attrelid 
           AND NOT a.attisdropped 
           AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 
                              'pg_catalog.regprocedure'::pg_catalog.regtype, 
                              'pg_catalog.regoper'::pg_catalog.regtype, 
                              'pg_catalog.regoperator'::pg_catalog.regtype, 
                              'pg_catalog.regconfig'::pg_catalog.regtype, 
                              'pg_catalog.regdictionary'::pg_catalog.regtype) 
           AND c.relnamespace = n.oid 
           AND n.nspname NOT IN ('pg_catalog', 'information_schema');

   • 如果对已安装 pgRouting 扩展的 Aurora PostgreSQL 10.18 版本或更高版本进行升级，请删除此扩展，然后再升级到 12.4 或更高版本。

     如果您正在升级安装了扩展 pg_repack 版本 1.4.3 的 Aurora PostgreSQL 10.x 版本，请在升级到任何更高版本之前删除该扩展。

3. 检查 template1 和 template0 数据库。

   要成功升级，template1 和 template 0 数据库必须存在且应作为模板列出。要对此进行检查，请使用以下命令：

   SELECT datname, datistemplate FROM pg_database; 
                           
   datname    | datistemplate
   -----------+---------------
   template0  | t
   rdsadmin   | f
   template1  | t
   postgres   | f
   

   在命令输出中，template1 和 template0 数据库的 datistemplate 值应为 t。

4. 删除逻辑复制槽。

   如果 Aurora PostgreSQL 数据库集群正在使用任何逻辑复制槽，则升级过程无法继续。逻辑复制槽通常用于短期数据迁移任务，例如使用 AWS DMS 迁移数据或将表从数据库复制到数据湖、BI 工具或其他目标。升级之前，请确保您知道存在的任何逻辑复制槽的用途，并确认可以删除它们。您可以使用以下查询来检查逻辑复制槽：

   SELECT * FROM pg_replication_slots;

   如果逻辑复制槽仍在使用中，则不应将其删除，但也无法继续升级。但是，如果不需要逻辑复制槽，则可以使用以下 SQL 将其删除：

   SELECT pg_drop_replication_slot(slot_name);

   使用 pglogical 扩展的逻辑复制方案还需要从发布者节点上删除插槽，才能在该节点上成功升级主要版本。但是，可以在升级后从订阅者节点重新启动复制过程。有关更多信息，请参阅 在主要升级后重新建立逻辑复制。

5. 执行备份。

   在升级期间，升级进程创建数据库集群的数据库集群快照。如果您还希望在升级进程之前执行手动备份，有关更多信息，请参阅创建数据库集群快照。

6. 在执行主要版本升级之前，将某些扩展升级到最新的可用版本。要更新的扩展包括以下各项：

   • pgRouting

   • postgis_raster

   • postgis_tiger_geocoder

   • postgis_topology

   • address_standardizer

   • address_standardizer_data_us

   对当前安装的每个扩展运行以下命令。

   ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

   有关更多信息，请参阅 升级 PostgreSQL 扩展。要了解有关升级 PostGIS 的更多信息，请参阅步骤 6：升级 PostGIS 扩展。

7. 如果要升级到版本 11.x，请在执行主要版本升级之前删除它不支持的扩展。要删除的扩展包括：

   • chkpass

   • tsearch2

8. 删除 unknown 数据类型，具体取决于您的目标版本。

   PostgreSQL 版本 10 不支持 unknown 数据类型。如果版本 9.6 数据库使用 unknown 数据类型，升级到版本 10 将显示错误消息，如下所示。

   Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: 
   The instance could not be upgraded because the 'unknown' data type is used in user tables. 
   Please remove all usages of the 'unknown' data type and try again."

   要在数据库中查找 unknown 数据类型，以便删除上述列或将其更改为支持的数据类型，请为每个数据库使用以下 SQL 代码。

   SELECT n.nspname, c.relname, a.attname
       FROM pg_catalog.pg_class c,
       pg_catalog.pg_namespace n,
       pg_catalog.pg_attribute a
       WHERE c.oid = a.attrelid AND NOT a.attisdropped AND
       a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND
       c.relkind IN ('r','m','c') AND
       c.relnamespace = n.oid AND
       n.nspname !~ '^pg_temp_' AND
       n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');

9. 执行空运行升级。

   我们强烈建议您先使用生产数据库的副本测试主要版本升级，然后再对生产数据库真正执行升级。您可以监控重复测试实例上的执行计划，以了解任何可能的执行计划回归，并评估其性能。要创建副本测试实例，您可以从最近的快照还原数据库，或者克隆数据库。有关更多信息，请参阅 从快照还原 或 克隆 Amazon Aurora 数据库集群卷。

   有关更多信息，请参阅“将 Aurora PostgreSQL 引擎升级到新的主要版本”。

10. 升级您的生产实例。

    当试验性运行主要版本升级获得成功时，您应该可以放心地升级您的生产数据库。有关更多信息，请参阅 将 Aurora PostgreSQL 引擎升级到新的主要版本。

    注意

    在升级过程中，如果数据库集群的备份保留期大于 0，Aurora PostgreSQL 会获取集群快照。在此过程中，您无法执行集群的时间点还原。之后，您可以执行时间点还原，以将实例还原到实例自动快照完成之后、升级操作开始之前的时间。但是，您不能通过执行时间点还原来还原到以前的次要版本。

    有关进行中的升级的信息，您可以使用 Amazon RDS 来查看 pg_upgrade 实用工具生成的两个日志。它们是 pg_upgrade_internal.log 和 pg_upgrade_server.log。Amazon Aurora 会在这些日志的文件名中附加时间戳。您可以像查看其他任何日志一样查看这些日志。有关更多信息，请参阅“监控 Amazon Aurora 日志文件”。

11. 升级 PostgreSQL 扩展。PostgreSQL 升级过程不会升级任何 PostgreSQL 扩展。有关更多信息，请参阅“升级 PostgreSQL 扩展”。

完成主要版本升级后，我们建议您执行以下操作：

• 运行 ANALYZE 操作以刷新 pg_statistic 表。您应该为所有 PostgreSQL 数据库实例上的每个数据库执行此操作。在主要版本升级期间不会传输优化程序统计数据，因此您需要重新生成所有统计数据，避免出现性能问题。运行不带任何参数的命令，为当前数据库中的所有常规表生成统计数据，如下所示：

  ANALYZE VERBOSE;

  VERBOSE 标记为可选项，可用于显示进度。有关更多信息，请参阅 PostgreSQL 文档中的 ANALYZE。

  注意

  升级后在系统上运行 ANALYZE，避免出现性能问题。

• 如果您升级到 PostgreSQL 版本 10，请在您拥有的任何哈希索引上运行 REINDEX。哈希索引在版本 10 中已更改，必须重新构建。要查找无效的哈希索引，请针对包含哈希索引的每个数据库运行以下 SQL。

  SELECT idx.indrelid::regclass AS table_name, 
     idx.indexrelid::regclass AS index_name 
  FROM pg_catalog.pg_index idx
     JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid 
     JOIN pg_catalog.pg_am am ON am.oid = cls.relam 
  WHERE am.amname = 'hash' 
  AND NOT idx.indisvalid;

• 建议您在升级的数据库上使用类似的工作负载测试应用程序，以验证是否一切正常。验证升级之后，您可以删除此测试实例。

将 Aurora PostgreSQL 引擎升级到新的主要版本

当您启动升级到新的主要版本的过程时，Aurora PostgreSQL 会在对集群进行任何更改之前拍摄 Aurora DB 集群的快照。此快照仅针对主要版本升级（而不是次要版本升级）而创建。升级过程完成后，您可以在 RDS 控制台的 Snapshots（快照）下列出的手动快照中找到此快照。快照名称包括 preupgrade（作为其前缀）、Aurora PostgreSQL 数据库集群的名称、源版本、目标版本以及日期和时间戳，如以下示例所示。

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

升级完成后，如有必要，您可以使用 Aurora 创建并存储在手动快照列表中的快照，将数据库集群还原到其以前的版本。

提示

一般来说，快照提供了许多将 Aurora 数据库集群还原到不同时间点的方法。要了解更多信息，请参阅从数据库集群快照还原和将数据库集群还原到指定时间。但是，Aurora PostgreSQL 不支持使用快照还原到以前的次要版本。

在主要版本升级过程中，Aurora 将分配卷并克隆源 Aurora PostgreSQL 数据库集群。如果升级由于任何原因而失败，Aurora PostgreSQL 将使用克隆回滚升级。当分配的源卷克隆超过 15 个之后，后续克隆将成为完整副本并且需要更长的时间。这可能导致升级过程也要花费更长的时间。如果 Aurora PostgreSQL 回滚升级，请注意以下事项：

• 您可能会看到在升级期间分配的原始卷和克隆卷的账单条目和指标。在集群备份保留时段超过升级时间之后，Aurora PostgreSQL 会清理额外的卷。

• 此集群中的下一个跨区域快照副本将为完整副本，而不是增量副本。

为了安全地升级构成集群的数据库实例，Aurora PostgreSQL 使用 pg_upgrade 实用程序。写入器升级完成后，每个读取器实例在升级到新的主要版本时都会出现短暂中断。要了解有关此 PostgreSQL 实用程序的更多信息，请参阅 PostgreSQL 文档中的 pg_upgrade。

您可以使用以下方法将 Aurora PostgreSQL 数据库集群升级到新版本：AWS Management Console、AWS CLI 或 RDS API。

控制台

升级数据库集群的引擎版本

1. 登录AWS Management Console并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/。

2. 在导航窗格中，选择 Databases (数据库)，然后选择要升级的数据库集群。

3. 选择修改。此时会显示修改数据库集群页面。

4. 对于数据库引擎版本，选择新版本。

5. 选择继续，查看修改摘要。

6. 要立即应用更改，请选择立即应用。选择此选项在某些情况下可能导致中断。有关更多信息，请参阅“修改 Amazon Aurora 数据库集群”。

7. 在确认页面上，检查您的更改。如果更改正确无误，请选择修改集群以保存更改。

   也可以选择 Back 编辑您的更改，或选择 Cancel 取消更改。

AWS CLI

要升级数据库集群的引擎版本，请使用 AWS CLI 命令 modify-db-cluster。指定以下参数：

• --db-cluster-identifier – 数据库集群的名称。

• --engine-version – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息，请使用 AWS CLI describe-db-engine-versions 命令。

• --allow-major-version-upgrade – 当 --engine-version 参数是不同于数据库集群当前主要版本的主要版本时，这是必需的标志。

• --no-apply-immediately – 在下一维护时段内应用更改。要立即应用更改，请使用 --apply-immediately。

例

对于 Linux、macOS 或 Unix：

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --allow-major-version-upgrade \
    --no-apply-immediately

对于 Windows：

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --allow-major-version-upgrade ^
    --no-apply-immediately

RDS API

要升级数据库集群的引擎版本，请使用 ModifyDBCluster 操作。指定以下参数：

• DBClusterIdentifier – 数据库集群的名称，例如 mydbcluster。

• EngineVersion – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息，请使用 DescribeDBEngineVersions 操作。

• AllowMajorVersionUpgrade – 当 EngineVersion 参数是不同于数据库集群当前主要版本的主要版本时，这是必需的标志。

• ApplyImmediately – 是立即应用更改还是在下一个维护时段内应用更改。要立即应用更改，请将该值设置为 true。要在下一个维护时段内应用更改，请将该值设置为 false。

全局数据库的主要版本升级

对于 Aurora 全局数据库集群，升级过程会同时升级构成 Aurora 全局数据库的所有数据库集群。这样做是为了确保每个数据库集群都运行相同的 Aurora PostgreSQL 版本。它还可确保对系统表、数据文件格式等所做的任何更改都会自动复制到所有辅助集群。

要将全局数据库集群升级到 Aurora PostgreSQL 的新主要版本，我们建议您在升级的版本上测试应用程序，如测试将生产数据库集群升级到新的主要版本中所述。请确保在升级之前为 Aurora 全局数据库中的每个 AWS 区域准备好数据库集群参数组和数据库参数组设置，详见测试将生产数据库集群升级到新的主要版本中的step 1. 。

如果 Aurora PostgreSQL 全局数据库集群为其 rds.global_db_rpo 参数设置了恢复点目标 (RPO)，请确保在升级之前重置此参数。如果开启了 RPO，主要版本升级过程将不起作用。默认情况下，该参数处于停用状态。有关 Aurora PostgreSQL 全局数据库和 RPO 的更多信息，请参阅管理基于 Aurora PostgreSQL 的全局数据库的 RPO。

如果您验证应用程序可以在新版本的试用部署时按预期运行，则可以启动升级过程。为此，请参阅 将 Aurora PostgreSQL 引擎升级到新的主要版本。请确保从 RDS 控制台的 Databases（数据库）列表中选择顶级项，即 Global database（全局数据库），如下图所示。

与任何修改一样，当出现提示时，您可以确认您希望继续执行该过程。

您可以使用 AWS CLI 或 RDS API 启动升级过程，而不是使用控制台。与控制台一样，您在 Aurora 全局数据库集群而不是其任何组件上运行，如下所示：

• 使用 AWS CLI 命令 modify-global-cluster，通过使用 AWS CLI 启动 Aurora 全局数据库的升级。

• 使用 ModifyGlobalCluster API 启动升级。

在执行次要版本升级之前

建议您执行以下操作以缩短次要版本升级期间的停机时间：

• 应在流量较低的时段执行 Aurora 数据库集群维护。使用性能详情来识别这些时间段，以便正确配置维护时段。有关性能详情的更多信息，请参阅在 Amazon RDS 上使用性能详情监控数据库负载。有关数据库集群维护时段的更多信息，请参阅调整首选数据库集群维护时段。

• 使用支持指数回退和抖动的 AWS SDK 作为最佳实践。有关更多信息，请参阅 Exponential Backoff And Jitter。

如何执行次要版本升级和应用补丁

次要版本升级和补丁只有在经过严格的测试后才会在 AWS 区域中推出。在发布升级和补丁之前，Aurora PostgreSQL 将进行测试，以确保次要社群版本发布后出现的已知安全问题、错误和其他问题不会破坏 Aurora PostgreSQL 实例集的整体稳定性。

当 Aurora PostgreSQL 推出了新的次要版本时，构成 Aurora PostgreSQL 数据库集群的实例可以在指定的维护时段内自动升级。要实现此操作，Aurora PostgreSQL 数据库集群必须已开启 Enable auto minor version upgrade（启用自动次要版本升级）选项。构成 Aurora PostgreSQL 数据库集群的所有数据库实例都必须已开启自动次要版本升级（AmVU）选项，以便在整个集群中应用次要版本升级。

提示

确保对于构成 Aurora PostgreSQL 数据库集群的所有 PostgreSQL 数据库实例开启 Enable auto minor version upgrade（启用自动次要版本升级）选项。必须开启此选项，才能使数据库集群中的每个实例正常工作。有关如何设置自动次要版本升级以及该设置在集群和实例级别应用时的工作原理的信息，请参阅 Aurora 数据库集群的自动次要版本升级。

通过使用 AWS CLI 命令 describe-db-instances 和以下查询，可以针对所有 Aurora PostgreSQL 数据库集群检查 Enable auto minor version upgrade（启用自动次要版本升级）选项的值。

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

此查询返回其 AutoMinorVersionUpgrade 设置的状态值为 true 或 false 的所有 Aurora DB 集群及其实例的列表。所示的命令假设您已将 AWS CLI 配置为以默认的 AWS 区域为目标。

有关 AmVU 选项以及如何修改 Aurora 数据库集群以使用该选项的更多信息，请参阅 Aurora 数据库集群的自动次要版本升级。

您可以通过响应维护任务或修改集群以使用新版本，将 Aurora PostgreSQL 数据库集群升级到新的次要版本。

通过使用 RDS 控制台并打开 Recommendations（建议）菜单，您可以确定 Aurora PostgreSQL 数据库集群的任何可用升级或补丁。在此处，您可以找到各种维护问题的列表，例如 Old minor versions（旧的次要版本）。根据您的生产环境，您可以选择 Schedule（计划）升级，或通过选择 Apply now（立即应用）立即采取行动，如下所示。

要了解有关如何维护 Aurora 数据库集群的更多信息，包括如何手动应用补丁和次要版本升级，请参阅维护 Amazon Aurora 数据库集群。

次要版本升级和零停机时间修补

升级 Aurora PostgreSQL 数据库集群可能会导致中断。在升级过程中，数据库会在升级时关闭。如果在数据库忙碌时开始升级，则会丢失数据库集群正在处理的所有连接和事务。如果等到数据库处于空闲状态再执行升级，则可能需要等待很长时间。

零停机修补 (ZDP) 特征改进了升级过程。使用 ZDP，可以应用次要版本升级和补丁，且对 Aurora PostgreSQL 数据库集群的影响最小。当对 Aurora PostgreSQL 版本以及这些次要版本的其他更高版本和更高的主要版本应用补丁或更高次要版本升级时，使用 ZDP。也就是说，从这些版本中的任何一个升级到新的次要版本都使用 ZDP。

下表显示提供了 ZDP 的 Aurora PostgreSQL 版本和数据库实例类：

版本	db.r* 实例类	db.t* 实例类	db.x* 实例类	db.serverless 实例类
10.21.0 及更高的 10.21 版本	支持	是	支持	不适用
11.16.0 及更高的 11.16 版本	支持	是	支持	不适用
11.17 及更高版本	支持	是	支持	不适用
12.11.0 及更高的 12.11 版本	支持	是	支持	不适用
12.12 及更高版本	支持	是	支持	不适用
13.7.0 及更高的 13.7 版本	支持	是	支持	不适用
13.8 及更高版本	支持	是	是	支持
14.3.1 及更高的 14.3 版本	支持	是	支持	不适用
14.4.0 及更高的 14.4 版本	支持	是	支持	不适用
14.5 及更高版本	支持	是	是	支持
15.3 及更高版本	支持	是	是	支持

ZDP 的工作原理是在整个 Aurora PostgreSQL 升级过程中保留与 Aurora PostgreSQL 数据库集群的当前客户端连接。但在以下情况下，连接将断开，以便 ZDP 完成：

• 正在执行长时间运行的查询或事务。

• 数据定义语言（DDL）语句正在运行。

• 正在使用临时表或表锁定。

• 所有会话都在侦听通知渠道。

• 处于“WITH HOLD”状态的光标正在使用中。

• TLSv1.3 或 TLSv1.1 连接正在使用中。

在使用 ZDP 的升级过程中，数据库引擎会寻找一个安静点来暂停所有新事务。此操作可在应用补丁和升级期间保护数据库。为了确保您的应用程序在事务暂停的情况下平稳运行，我们建议将重试逻辑集成到您的代码中。这种方法可确保系统能够管理任何短暂的停机时间而不会出现故障，并且可以在升级后重试新事务。

当 ZDP 成功完成时，应用程序会话将保持（但断开连接的会话除外），并且数据库引擎将在升级仍在进行时重新启动。尽管数据库引擎重新启动可能会导致吞吐量临时下降，但这通常只持续几秒钟，最多约一分钟。

在某些情况下，零停机修补 (ZDP) 可能无法成功。例如，Aurora PostgreSQL 数据库集群或其实例上处于 pending 状态的参数更改会干扰 ZDP。

您可以在控制台的 Events（事件）页面中找到 ZDP 操作的指标和事件。这些事件包括 ZDP 升级的开始和升级完成。在这种情况下，您可以了解该过程所用的时长，以及在重新启动过程中发生的保留连接和断开连接的数量。您可以在数据库错误日志中找到详细信息。

将 Aurora PostgreSQL 引擎升级到新的次要版本

您可以使用以下方法将 Aurora PostgreSQL 数据库集群升级到新的次要版本：控制台、AWS CLI 或 RDS API。在执行升级之前，我们建议您遵循我们针对主要版本升级推荐的最佳实践。与新的主要版本一样，新的次要版本也可以对优化器进行改进（例如修复），这可能会导致查询计划回归。为确保计划稳定性，我们建议您使用查询计划管理（QPM）扩展，详情请参阅确保主要版本升级后的计划稳定性。

控制台

升级 Aurora PostgreSQL 数据库集群的引擎版本

1. 登录AWS Management Console并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/。

2. 在导航窗格中，选择 Databases (数据库)，然后选择要升级的数据库集群。

3. 选择修改。此时会显示修改数据库集群页面。

4. 对于数据库引擎版本，选择新版本。

5. 选择继续，查看修改摘要。

6. 要立即应用更改，请选择立即应用。选择此选项在某些情况下可能导致中断。有关更多信息，请参阅“修改 Amazon Aurora 数据库集群”。

7. 在确认页面上，检查您的更改。如果更改正确无误，请选择修改集群以保存更改。

   也可以选择 Back 编辑您的更改，或选择 Cancel 取消更改。

AWS CLI

要升级数据库集群的引擎版本，请结合使用 AWS CLI 命令 modify-db-cluster 与以下参数：

• --db-cluster-identifier – Aurora PostgreSQL 数据库集群的名称。

• --engine-version – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息，请使用 AWS CLI describe-db-engine-versions 命令。

• --no-apply-immediately – 在下一维护时段内应用更改。要立即应用更改，请改用 --apply-immediately。

对于 Linux、macOS 或 Unix：

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

对于 Windows：

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately

RDS API

要升级数据库集群的引擎版本，请使用 ModifyDBCluster 操作。指定以下参数：

• DBClusterIdentifier – 数据库集群的名称，例如 mydbcluster。

• EngineVersion – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息，请使用 DescribeDBEngineVersions 操作。

• ApplyImmediately – 是立即应用更改还是在下一个维护时段内应用更改。要立即应用更改，请将该值设置为 true。要在下一个维护时段内应用更改，请将该值设置为 false。

升级 PostgreSQL 扩展

将 Aurora PostgreSQL 数据库集群升级到新的主要或次要版本不会同时升级 PostgreSQL 扩展。对于大多数扩展，您可以在主要或次要版本升级完成后升级扩展。但是，在某些情况下，应在升级 Aurora PostgreSQL 数据库引擎之前升级扩展。有关更多信息，请参阅测试将生产数据库集群升级到新的主要版本中的list of extensions to update。

安装 PostgreSQL 扩展需要具备 rds_superuser 权限。通常，rds_superuser 将对于特定扩展的权限委派给相关用户（角色），以便于管理给定扩展。这意味着，升级 Aurora PostgreSQL 数据库集群中所有扩展的任务可能涉及许多不同用户（角色）。如果要使用脚本自动执行升级过程，请尤其注意这一点。有关 PostgreSQL 权限和角色的更多信息，请参阅 使用 Amazon Aurora PostgreSQL 实现高安全性。

注意

有关更新 PostGIS 扩展的信息，请参阅使用 PostGIS 扩展管理空间数据（步骤 6：升级 PostGIS 扩展）。

要升级 pg_repack 扩展，先删除该扩展，然后在升级后的数据库实例中创建新版本。有关更多信息，请参阅 pg_repack 文档中的安装 pg_repack。

要在引擎升级后更新扩展，请使用 ALTER EXTENSION UPDATE 命令。

ALTER EXTENSION extension_name UPDATE TO 'new_version';

要列出当前安装的扩展，请在以下命令中使用 PostgreSQL pg_extension 目录。

SELECT * FROM pg_extension;

要查看可用于安装的特定扩展版本的列表，请在以下命令中使用 PostgreSQL pg_available_extension_versions 视图。

SELECT * FROM pg_available_extension_versions;

备选的蓝绿升级技术

在某些情况下，您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下，您可以使用多步骤流程，并排运行新旧集群。此处，您可以将数据从旧集群复制到新集群，直到您准备好接管新集群。有关详细信息，请参阅使用 Amazon RDS 蓝绿部署进行数据库更新。