PostgreSQL升级很难！

我与Lætitia Avrot和Nikolay Samokhvalov一起受邀参加了Postgres Vision 2022关于PostgreSQL可升级性的社区小组（YouTube视频）。该小组由Bruce Momjian主持，由Jimmy Angelakos发起和组织。Bruce以前确实和我们每个人都谈过，这对引导讨论朝着正确的方向发展有很大帮助。小组讨论的记录可在Postgres Vision网站上获得。

在这次座谈会上，我们每个人都举例说明了PostgreSQL升级是多么简单或复杂。

次要版本升级

我们讨论的一个结果是，较小的升级（例如从v14.0到v14.1）相对容易，但对于那些不注意细节（例如发行说明）的人来说，可能会有一些惊喜。一个很好的例子是最近发布的PostgreSQL版本14.4。这是一个小升级，因此没有新功能。但它需要对B树索引进行大量的研究。对于DBA来说，很难计算出这需要做多少工作，或者维护窗口需要多长时间。

Lætitia指出，人们喜欢PostgreSQL方法，即在较小的升级中不添加新功能。这使得无需重新测试应用程序即可轻松安装新版本。

主要版本升级

主要升级（例如v13到v14）是一个完全不同的类别。每个人都同意，这些升级是复杂的，需要大量的准备和测试，无论是在数据库方面还是在应用程序方面。PostgreSQL有一个pg_升级工具，可以在同一台服务器上运行主要的版本升级，但即使是这个工具也缺乏对当今商业世界至关重要的功能。例如，–check选项对数据库进行初步检查，但这并没有涵盖所有细节，没有给出时间估计，也没有捕获所有错误。

在Adjust的升级测试中，我们发现我们正在使用的一些扩展无法自动迁移，但pg_upgrade没有对此进行检查。

对于我们20-30 TB范围内的数据库，或者有上万个表（因此有一个非常大的目录），最好至少能得到运行pg_升级所需时间的估计值。

支持政策

目前PostgreSQL项目支持5个主要版本。与商业产品相比，这是一个大量的支持版本。这对一些用户来说是一个问题：当产品的支持用完时，更改的数量如此之大，以至于重大升级不再可行，也不容易实现。讨论的一种方法是LTS版本，并且在5年内不支持每个主要版本，但这不会消除实际问题。

群集感知

在当今的商业世界中，许多PostgreSQL安装以复制的方式运行。通过使用物理或逻辑复制。然而，PostgreSQL本身并不知道集群，也不支持这种开箱即用的方式。

主数据库可以向下一级副本显示复制状态，但无法在更复杂的集群设置中收集关于每个系统的所有信息。故障转移到副本是一个手动步骤，或者由诸如Patenti之类的工具处理。要使PostgreSQL在应用程序中看起来像一个系统，同时仍然提供HA，需要在集群前面使用其他工具，如PgBouncer或Pgpool II。管理这些工具是额外的工作，要找出哪个数据库是当前领先的主要数据库，需要采取变通方法。

升级所需的停机时间

尼古拉指出，零停机升级是不可能的。升级所需的时间可以最小化，但不能为零。其中一个主要原因是升级时必须重新启动服务器，这会中断正在进行的连接。重新启动需要一个检查点，该检查点将所有脏缓冲区写入磁盘。使用高级检查点准备数据库是可能的，但写量大的数据库仍需要一些时间来写出其余的更改，然后重新启动服务器。在此期间，不接受新连接，尝试连接的应用程序将收到错误。即使是连接池也只能保存传入的连接，但在服务器升级时不可能保持连接和查询的运行。

升级策略

随着时间的推移，PostgreSQL世界开发了几种不同的升级策略，仅举几例：

• 在–link模式下运行pg_升级：这相对比较快（通常是几分钟），但一旦启动新版本，就不可能回滚（除了使用文件系统快照之类的其他工具）。

• 在复制模式下运行pg_升级（默认）：这需要两倍的磁盘空间，因为升级过程会创建每个文件的副本。它也很慢，运行时取决于数据库的大小和硬件的性能。可以是小时。

• 逻辑复制：这种方法在主服务器上创建复制槽，使用pg_转储备份设置具有新版本的新副本，然后逻辑更改流到副本中，直到它赶上主服务器。然后，应用程序切换到新副本，运行新版本。这种方法可能会使主服务器过载，因为它需要存储WAL，存储时间从备份开始到复制副本完成所有更改。在这段时间内，写容量大的数据库可能会创建数TB或WAL。

• Slony-I:Slony使用触发器收集表中的更改，并将其发送到副本。这是一种消耗资源的方法，无法处理DDL更改。Slony-I的开发不久前就停止了。

• pg_dump和pg_restore：使用新版本的pg_dump工具对数据库进行快照，并将其安装到新版本中。这种方法适用于多台服务器，但需要两倍的磁盘空间和大量时间。在恢复过程中，需要重建每个索引，然后需要更新统计信息。升级期间不可能更改数据，但是应用程序可以以只读模式访问旧数据库。

可能的改进

在小组讨论期间，我们讨论了一些可能的变化和改进：

• 所有升级都使用pg_升级，并且有一个选项显示升级之间以及小升级之间的必要更改和步骤

• 更好地验证升级过程，提前发现更多可能的问题

• 计算升级的时间和空间估计

• 使PostgreSQL集群感知：显示所有节点中每个节点的信息

• 使一次升级整个集群成为可能

致谢

感谢Lætitia、Nikolay、Bruce和Jimmy帮助撰写本文，并组织和参与小组讨论。

原文标题：PostgreSQL Upgrades are hard!
原文作者：Andreas ‘ads’ Scherbaum
原文链接：https://andreas.scherbaum.la/blog/archives/1116-PostgreSQL-Upgrades-are-hard!.html