升级适用于 Aurora PostgreSQL 的 PostgreSQL 数据库引擎 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

升级适用于 Aurora PostgreSQL 的 PostgreSQL 数据库引擎

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

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

Aurora PostgreSQL 升级过程概述

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

次要版本升级和补丁

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

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

如果没有为 Aurora PostgreSQL 数据库集群设置自动次要版本升级选项,则 Aurora PostgreSQL 不会自动升级到新的次要版本。相反,当您的 Amazon Web Services 区域中发布了新的次要版本,但您的 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)功能。此功能可最大限度地减少中断,并在大多数情况下彻底消除中断。有关更多信息,请参阅次要版本升级和零停机时间修补

注意

配置为 Aurora Serverless v2、Aurora Serverless v1、Aurora 全局数据库或 Babelfish 的 Aurora PostgreSQL 数据库集群不支持 ZDP。

主要版本升级。

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

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

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

注意

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

如何执行主要版本升级

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

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

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

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

注意

目前,您无法将运行 Babelfish 的 Aurora PostgreSQL 数据库集群升级到新的主要版本。

在表中,您可以找到适用于各种 Aurora PostgreSQL 数据库版本的主要版本升级。

对于您正在考虑的任何版本,请始终检查集群数据库实例类的可用性。有关数据库实例类的更多信息,包括哪些实例类基于 Graviton2 以及哪些实例基于英特尔,请参阅 Aurora 数据库实例类

获取您的 Amazon Web Services 区域中可用版本的列表

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

对于 Linux、macOS 或 Unix:

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

对于 Windows:

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

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

在将生产数据库集群升级到新的主要版本之前

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

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

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

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

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

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

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

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

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

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
    • 在尝试升级前取消使用所有 reg* 数据类型。除了 regtyperegclass 以外,您不能升级 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 或更高版本。

  3. 删除逻辑复制槽。

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

    SELECT * FROM pg_replication_slots;

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

    SELECT pg_drop_replication_slot(slot_name);
  4. 执行备份。

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

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

    • 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 扩展

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

    • chkpass

    • tsearch2

  7. 删除 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');
  8. 执行空运行升级。

    我们强烈建议您先使用生产数据库的副本测试主要版本升级,然后再对生产数据库真正执行升级。要创建副本测试实例,您可以从最近的快照还原数据库,或者克隆数据库。有关更多信息,请参阅 从快照还原克隆 Amazon Aurora 数据库集群卷

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

  9. 升级您的生产实例。

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

    注意

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

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

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

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

  • 运行 ANALYZE 操作以刷新 pg_statistic 表。

  • 如果您升级到 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 数据库集群升级到新版本:Amazon Web Services Management Console、Amazon CLI 或 RDS API。

升级数据库集群的引擎版本
  1. 登录Amazon Web Services Management Console并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

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

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

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

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

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

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

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

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

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

  • --engine-version – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息,请使用 Amazon 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

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

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

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

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

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

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

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

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

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

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


                    控制台图像,其中显示 Aurora 全局数据库、Aurora Serverless 数据库集群和另一个 Aurora PostgreSQL 数据库集群

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


                    控制台图像,其中显示用于确认 Aurora PostgreSQL 数据库集群升级过程的提示

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

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

次要版本升级和补丁只有在经过严格的测试后才会在 Amazon Web Services 区域中推出。在发布升级和补丁之前,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(启用自动次要版本升级)选项。必须开启此选项,才能使数据库集群中的每个实例正常工作。

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

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

此查询返回其 AutoMinorVersionUpgrade 设置的状态值为 truefalse 的所有 Aurora DB 集群及其实例的列表。所示的命令假设您已将 Amazon CLI 配置为以原定设置的 Amazon Web Services 区域为目标。

有关 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 版本 14.3.3、13.7.3、12.11.3、11.16.3、10.21.3 以及这些次要版本的其他更高版本和更高的主要版本应用补丁或更高次要版本升级时,使用 ZDP。也就是说,从这些版本中的任何一个升级到新的次要版本都使用 ZDP。

注意

配置为 Aurora Serverless v2、Aurora Serverless v1、Aurora 全局数据库或 Babelfish 的 Aurora PostgreSQL 数据库集群不支持 ZDP。

ZDP 的工作原理是在整个 Aurora PostgreSQL 升级过程中保留与 Aurora PostgreSQL 数据库集群的当前客户端连接。当 ZDP 成功完成时,应用程序会话将保留,并且数据库引擎将在升级过程中重新启动。尽管数据库引擎重新启动可能会导致吞吐量下降,但这通常只持续几秒钟,最多约一分钟。

在某些情况下,零停机修补 (ZDP) 可能无法成功。例如,如果长时间运行的查询或事务正在进行中,ZDP 可能需要取消它们才能完成。如果正在运行数据定义语言 (DL) 语句,或者由于任何其他原因而使用临时表或表锁定,ZDP 可能需要取消打开的事务。Aurora PostgreSQL 数据库集群或其实例上处于 pending 状态的参数更改也会干扰 ZDP。

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

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

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

升级 Aurora PostgreSQL 数据库集群的引擎版本
  1. 登录Amazon Web Services Management Console并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

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

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

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

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

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

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

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

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

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

  • --engine-version – 数据库引擎要升级到的版本号。有关有效的引擎版本的信息,请使用 Amazon 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

要升级数据库集群的引擎版本,请使用 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 扩展)。

要在引擎升级后更新扩展,请使用 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;