通过次要版本更新改进，以最少的停机时间进行 Amazon Aurora PostgreSQL 次要版本升级

使用与 Amazon Aurora PostgreSQL 兼容版本 时 ，管理更新是数据库管理员的持续管理过程。次要版本更新是此过程的组成部分——它们包含数据库补丁，而错误修复是一项更常见的管理任务。亚马逊云科技 提供了协助应用更新的机制，但您可以决定何时应用更新。这些更新发生在指定的维护时段（或可以手动应用），并且在许多情况下需要重启实例。

在这篇文章中，我们讨论了对次要版本更新过程的一系列改进，这些改进可以减少停机时间并减少对工作负载的干扰。

用例

根据 PostgreSQL全球开发小组 的说法 ，“包含新功能的新主要版本将大约每年发布一次。每个主要版本都会收到错误修复，如果需要，还会收到安全补丁，这些补丁至少每2个月发布一次，我们称之为'次要版本'。”

当PostgreSQL版本需要关键安全补丁时，这些更新将在PostgreSQL全球开发小组发布后尽快发布，通常是在发布后的几个小时内。此外，当发布次要版本更新时，目前无法确定次要版本更新是否会导致实例重启（尽管并非总是需要重启）。应用次要版本更新时，可以肯定地假设更新需要重新启动才能将其完全应用于集群。

在改进 Amazon Aurora PostgreSQL 次要版本更新流程之前，次要版本更新导致重启计算实例的连接丢失，这是开源 PostgreSQL 当前的默认行为。更新的行为（适用于较早的 Amazon Aurora PostgreSQL 兼容版本版本）会导致数据库重启，这与开源 PostgreSQL 体验一致，需要更多时间才能使数据库计算实例恢复联机。

次要版本更新改进

Amazon Aurora PostgreSQL 兼容版的次要版本更新改进为更新过程提供了多项改进。这些改进提供的主要好处包括保留数据库和文件系统元数据，这允许在更新过程中更快地重启数据库。以前存在的数据库会话现在可以恢复到集群的读/写实例，从而最大限度地减少与应用次要版本更新相关的大部分停机时间。此外，与集群读/写实例的现有连接会被保留。在测试从 Aurora PostgreSQL v 11.17-> v11.18（改进前）到 11.18-> 11.19（有改进）的升级过程时，得出了以下观测结果：

Aurora Minor version update improvements benchmarked
Aurora PG Version Loss of writer connectivity Writer connectivity returns Writer instance unavailability
11.9 -> 11.13 18:53:52.062996 18:54:10.314688 16.15 seconds
11.17 -> 11.19 19:45:10 19:45:10 Less then 1 second

使用上述版本进行测试，观察到写入器实例停机时间总共减少了 15.15 秒。

局限性

尽管兼容 Amazon Aurora PostgreSQL 版本的零停机补丁减少了应用次要版本更新所涉及的总停机时间，但此更新过程仍然需要一小段停机时间。停机时间可能会有所不同，具体取决于单个集群或实例的大小。此外，此增强功能仅适用于兼容 Amazon Aurora PostgreSQL 的版本读/写终端节点，而不适用于集群中的所有计算实例。

结论

通过零停机补丁增强兼容 Amazon Aurora PostgreSQL 的版本次要版本更新可降低对工作负载的总体影响，同时仍允许您轻松应用次要版本更新（现在停机时间更少）。截至 2023年 1月23日 ，亚马逊Aurora PostgreSQL兼容版的所有次要版本更新均提供这些增强功能 ，客户无需采取进一步措施即可使用它。

如果您对本文所涵盖的内容有任何疑问、意见或建议，请将其留在评论部分。

作者简介

彼得·塞伦塔诺 是亚马逊网络服务的高级专业解决方案架构师，专注于托管PostgreSQL。他与 亚马逊云科技 客户合作，在云上设计可扩展、安全、高性能和强大的数据库架构。