Azure Database for PostgreSQL 灵活服务器的主要版本升级

适用于：Azure Database for PostgreSQL 灵活服务器

Azure Database for PostgreSQL 灵活服务器支持 PostgreSQL 版本 17、16、15、14、13、12、11。 Postgres 社区约每年发布一次包含新功能的新主版本。 此外，每个主版本会定期收到 bug 修复（以次要版本的形式）。 次要版本升级包含向后兼容现有应用程序的更改。 Azure Database for PostgreSQL 灵活服器务在客户的维护时段内定期更新次要版本。

主版本升级比次要版本升级复杂得多。 其中可能包括有可能不向后兼容已发布的应用程序的内部更改和新功能。

Azure Database for PostgreSQL 灵活服务器 Postgres 有一项功能，只需单击一下即可对服务器执行就地升级。 此功能通过最大程度减少对访问服务器的用户和应用程序的中断来简化升级过程。

就地升级在主版本升级后会保留当前服务器的服务器名称和其他设置。 升级过程中不需要进行数据迁移或更改应用程序连接字符串。 与数据迁移相比，就地升级速度更快，故障时间更短。

升级过程

下面是就地主要版本升级的一些关键注意事项：

• 在开始升级之前，请确保服务器至少有 10 到 20% 的可用存储空间。 在升级过程中，临时日志文件和元数据作可能会增加磁盘使用率。 可用空间不足可能会导致升级失败或回滚问题。
• 在就地主要版本升级过程中，Azure Database for PostgreSQL 灵活服务器会运行预检查过程，以确定可能导致升级失败的任何潜在问题。
  • 如果预检查发现任何不兼容性问题，它会创建日志事件，其中将显示升级预检查失败以及错误消息。
  • 如果预检查成功，Azure Database for PostgreSQL 灵活服务器会在开始升级之前停止该服务并执行隐式备份。 如果出现升级错误，该服务会使用此备份将数据库实例还原到其以前的版本。
• Azure Database for PostgreSQL 灵活服务器使用 pg_upgrade 工具执行就地主版本升级。 使用该服务时可灵活跳过中间版本，直接升级到更新版本。
• 在为实现高可用性 (HA) 启用的服务器进行主版本就地升级期间，该服务会禁用 HA，在主服务器上执行升级，然后在升级完成后重新启用 HA。
• 大多数扩展会在主版本就地升级期间自动升级到更高版本，但存在一些例外情况。
• Azure Database for PostgreSQL 灵活服务器的主版本就地升级过程会自动部署受支持的最新次要版本。
• 就地重大版本升级是一个离线操作，这意味着服务器将在过程中不可用。 虽然大多数升级在 15 分钟内完成，但实际持续时间取决于数据库的大小和复杂性。 具体而言，所需的时间与 PostgreSQL 实例中的对象数（表、索引、架构）直接成正比。 较大的或更复杂的架构可能会遇到更长的升级时间。
• 升级前事务长时间运行或工作负载高可能会增加关闭数据库所需的时间和升级时间。
• 主版本就地升级成功后，无法自动还原到早期版本。 但你可以执行时间点还原 (PITR)，恢复到升级之前的某个时间，从而还原以前版本的数据库实例。
• Azure Database for PostgreSQL 灵活服务器在升级期间拍摄数据库的快照。 在升级开始之前创建快照。 如果升级失败，系统会自动将数据库从快照还原到其状态。
• PostgreSQL 16 引入了基于角色的安全性措施。 在对 Azure Database for PostgreSQL 灵活服务器进行主版本升级后，第一个在服务器上创建的用户（被授予 ADMIN 选项）现在将对其他角色进行基本维护操作拥有管理权限。

升级注意事项和限制

如果在就地进行的主要版本升级期间预检查操作失败，升级会被阻止，并显示详细的错误消息。 下面是可能导致升级失败或行为意外的已知限制：

不支持的服务器配置

• 就地升级期间不支持只读副本。 在升级主服务器之前，必须删除读取副本。 升级后，可以重新创建副本。
• 网络流量规则可能会阻止升级操作。
  • 确保灵活服务器可以在其虚拟网络中的端口 5432 和 6432 上发送/接收流量，以及发送到 Azure 存储（用于日志存档）。
  • 如果网络安全组（NSG）限制此流量，HA 将不会在升级后自动重新启用。 可能需要手动更新 NSG 规则并重新启用 HA。
• 就地主要版本升级期间不支持逻辑复制槽。
• 使用 SSDv2 存储的服务器不符合主要版本升级的条件。
• 在主版本升级期间，不支持依赖于 pg_stat_activity 的视图。

扩展限制

就地主要版本升级不支持所有 PostgreSQL 扩展。 如果找到不支持的扩展，升级将在预检查期间失败。

• 任何 PostgreSQL 版本都不支持以下扩展：timescaledb、、dblink、orafce、 pg_partmanpostgres_fdw
• 当升级目标为 PostgreSQL 16 或更高版本时，不支持以下扩展： pgrouting
• 升级到 PostgreSQL 17 时不支持以下扩展：pgrouting、、age、azure_ai、 hllpg_diskann
• 扩展（例如 pg_repack 和 hypopg）不支持就地升级，应在升级之前删除，并在之后重新创建。 这些扩展是非持久性的，可以安全地重新配置升级后。

在升级之前，必须从 azure.extensions 服务器参数中删除这些扩展。 如果存在，将阻止升级。

特定于 PostGIS 的注意事项

如果使用 PostGIS 或任何依赖扩展，则必须配置search_path服务器参数以包括：

• 与 PostGIS 相关的架构
• 依赖扩展，包括：postgis、postgis_raster、postgis_sfcgal、postgis_tiger_geocoder、postgis_topology、address_standardizer、address_standardizer_data_us、fuzzystrmatch
• 无法正确配置search_path可能会导致升级失败或升级后对象损坏。

其他升级注意事项

• 大型对象（LOs）：由于内存使用率高或日志量大，存储有数百万个大型对象的数据库（存储在pg_largeobject 中）可能会导致升级失败。 使用 vacuumlo 实用工具清理未使用的 LO，并考虑在升级之前将您的服务器扩容（如果许多 LO 仍在使用）。

升级后

主版本升级完成后，建议在每个数据库中运行 ANALYZE 命令以刷新 pg_statistic 表。 缺少或过时的统计信息可能会导致查询计划不佳，这反过来可能会降低性能并占用过多的内存。

postgres=> analyze;
ANALYZE

查看升级日志

主版本升级日志 (PG_Upgrade_Logs) 提供对详细服务器日志的直接访问。 将 PG_Upgrade_Logs 集成到升级过程中有助于确保更顺利、更透明地过渡到新的 PostgreSQL 版本。

可以使用服务器参数以与上面的服务器日志相同的方式配置主版本升级日志：

• 若要启用该功能，请将 logfiles.download_enable 设置为 ON。
• 要以天为单位定义日志文件的保留期，可使用 logfiles.retention_days。

设置升级日志

要开始使用 PG_Upgrade_Logs，可以配置 PostgreSQL 服务器日志和主版本升级日志的捕获。

可以通过服务器日志的 UI 来访问升级日志。 在那里，可以实时监视 PostgreSQL 主版本升级的进度和详细信息。 此 UI 提供用于查看日志的集中位置，用户可以更轻松地跟踪升级过程和排查相关问题。

使用升级日志的好处

• 见解诊断：PG_Upgrade_Logs 提供有关升级过程的宝贵见解。 它捕获有关所执行的操作的详细信息，并凸显任何发生的错误或收到的警告。 此级别的详细信息有助于诊断和解决升级期间可能出现的问题，确保更顺利地完成过渡。
• 简化的故障排除：通过直接访问这些日志，可以快速识别和解决潜在的升级障碍，从而减少停机时间并最大限度地减少对操作的影响。 日志是一个重要的故障排除具，可以更高效且有效地解决问题。

相关内容

• Azure Database for PostgreSQL 灵活服务器的重大版本升级。
• Azure Database for PostgreSQL 灵活服务器的高可用性。
• 在 Azure Database for PostgreSQL 灵活服务器中进行备份和还原。