Hubert 'depesz' Lubaczewski：关于从PostgreSQL 12升级到14的（不完整）故事
💡
原文英文，约1600词，阅读约需6分钟。
📝
内容提要
本文介绍了作者在将PostgreSQL从14.x升级到14时遇到的问题及解决方案。作者的环境包括数百个集群，每个集群有至少四个服务器，每个集群只有一个数据库，但有400-500个表，使用了大量模式。作者尝试使用pg_upgrade和逻辑复制进行升级，但遇到了诸多问题，如语言环境变化、复制插槽过多、死锁等。最终，作者通过编写测试脚本解决了复制插槽过多的问题，并使用逻辑复制进行升级。虽然作者对此方法的可靠性不是100%确定，但仍然有希望。
🎯
关键要点
- 作者在将PostgreSQL从14.x升级到14时遇到的问题及解决方案。
- 环境包括数百个集群，每个集群至少有四个服务器，且每个集群只有一个数据库。
- 应用程序通常有400-500个表，使用大量模式，导致数据库对象总数超过200万。
- 升级过程中遇到的问题包括语言环境变化、复制插槽过多、死锁等。
- 最初尝试使用pg_upgrade进行升级，但由于对象数量过多，升级时间过长。
- 使用逻辑复制进行升级，但在测试中发现创建了过多的复制插槽。
- 通过调整计划，限制每次复制的表数量，解决了复制插槽过多的问题。
- 在添加索引和约束时，使用pg_restore时发生死锁，最终通过手动添加解决。
- 在WAL基础复制中，主节点需要保留WAL，导致某些情况下WAL被错误删除。
- 尝试使用pglogical进行初始同步，但发现无法并行处理，影响系统性能。
- 编写测试脚本以管理WAL文件，确保在不影响性能的情况下保持复制稳定。
- 尽管目前的解决方案看起来有效，但作者对最终结果仍持谨慎态度。
🏷️
标签
➡️
