我们最近从 Postgres 11.9 升级到 15.3 通过使用逻辑复制、一套支持脚本实现零停机， Elixir & 中的工具和工具Erlang 的 BEAM 虚拟机。
这篇文章将详细解释我们是如何做到的， 以及如果您尝试做同样的事情，您可能需要考虑的事项。
Knock 依靠 Postgres 为我们的通知工作流引擎提供支持。从存储 工作流程配置和消息模板，以摄取数百万条日志 和排队后台作业，Postgres 是我们系统所做的一切工作的核心。 我们在 AWS RDS Aurora 上运行的 Postgres 数据库始终可靠， 高性能且可扩展。 Knock 服务的基础让我们能够提供支持 每一位加入我们平台的客户都充满信心。
您拥有的数据越多，升级所需的时间就越长。
准备任何 Postgres 升级
最重要的是，寻求以任何方式升级 Postgres 的团队应该重点关注 降低风险尽可能降低升级过程的风险：
- 列出迁移过程中涉及的风险。例如：
- 停机时间长得令人无法接受
- 数据丢失
- 应用程序工作负载的数据库性能变化
- 真空频率或行为的变化
- 是否有任何复制槽需要迁移（这可能很棘手 - 参见下文）
对列表进行排序，使影响最大但最容易解决的风险位于顶部。
- 有没有完全排除风险的解决方案？
- 哪些解决方案可以随着时间的推移分散风险？ （所以我们可以逐渐 解决迁移的每个步骤，而无需立即承担太多风险。）
为了规划升级，我们从Postgres 的发行说明 开始 了解数据库版本之间将发生什么变化。 这帮助我们识别更多风险（例如 Postgres 真空工作原理的变化， 要求在执行某些升级时重新索引数据库），同时排除其他升级。
当我们进行规划过程时，我们保留了这份风险清单， 随着我们收集更多信息，添加新的问题并更新旧的问题。 在升级过程中，我们系统地解决了每个问题 直到我们确信我们可以实现我们的项目目标而无需 危及我们的可靠性。
关于监控
拥有完善的仪器（感谢 DataDog！）来监控您的健康状况 系统和数据库使得监控迁移的每个步骤成为可能。
需要关注的几个关键指标：
- 要避免的最大 TXN ID事务环绕 - 如果该值过高，您的数据库可能会关闭并进入紧急维护模式一个>
- 数据库CPU利用率
- 您的 writer 实例上的等待会话
- 查询延迟
- 您的应用程序的 API 响应延迟
在 Knock，我们监控所有这些指标以及我们应用程序特有的一些指标， 就像将 API 请求转换为通知所需的时间一样。
详细点击标题