LiquiBase 和 Kubernetes 数据库滚动更新

Question

假设我有一个具有 v1 模式的数据库，以及一个与 v1 模式紧密耦合的应用程序。即如果数据库中的记录与实体类不匹配，则会抛出SQLException。

我应该如何部署更改数据库架构的更改，并部署具有竞争条件的应用程序。即用户在应用程序中查询不再存在的字段。

Answer 1

这个问题实际上并不是 kubernetes 所特有的，它发生在任何拥有多个服务器的系统中——kubernetes 只是因为翻转的自动性而使它变得更加重要。你的问题中的“紧密耦合”一词完全暴露了这里的真正问题。

也就是说，“答案”实际上取决于以下哪种思维模型更适合您的团队：

• 不要使两个连续的模式相互矛盾
• 使用“维护”页面来阻止 Pod 的流量，直到它们完全推出
• 只需接受SQLExceptions 并向消费者添加更好的重试逻辑

我们使用第一个，因为 kubernetes 的推出已融入我们的工程文化中，并且我们知道pod-old 和 pod-new 将同时运行，因此架构更改需要增量且向后兼容至少一代 pod。

然而，有时我们只是接受这样做的工程工作的成本比特定重大更改将产生的 500 秒更高，因此我们作弊并降低副本规模，然后将其推出并警告我们的监控团队将会出现例外情况但它们会被吹倒。我们可以做到这一点，部分原因是客户端内置了重试逻辑。