执行主要版本升级

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

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

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

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

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

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

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

检查 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。

删除逻辑复制槽。

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

SELECT * FROM pg_replication_slots;

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

SELECT pg_drop_replication_slot(slot_name);

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

执行备份。

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

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

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

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

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

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

删除 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');

执行空运行升级。

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

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

升级您的生产实例。

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

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

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