如何使用 AWS 部署工具处理数据库迁移

Question

Amazon Web Services 可根据您的需要提供多种持续部署和管理工具，例如 Elastic Beanstalk、OpsWorks、Cloud Formation 和 Code Deploy。基本思想是在零停机的情况下促进代码部署和升级。他们还使用 AWS 资源帮助管理最佳架构实践。

为简单起见，我们假设一个基本架构，其中您有一个 2 撕裂结构；负载均衡器后面的应用服务器集合，然后是使用多区域 RDS 数据库的持久层。

跨一组实例（应用服务器）的实际代码升级很容易理解。对于一个非常简单的概述，AWS 服务会依次升级每个节点并关闭连接，因此相关实例不会被使用。

但是，我不明白如何管理数据库升级。假设我们要从版本 1.0.0 升级到应用程序的 2.0.0，并且需要更改数据库结构。通常你会使用脚本或像 Flyway 这样的库来执行升级。但是，如果有一组服务器要升级，则存在一个点，即 1.0.0 和 2.0.0 应用程序存在于整个队列中，每个应用程序都需要不同的数据库结构。

我需要了解这实际上是如何实现的（高级），以了解执行数据库迁移的最佳方式/时间是什么。我想他们可以通过多种方式实现这一目标，但我正在努力了解他们如何做到这一点，并允许 1.0.0 和 2.0.0 保存数据而不会丢失。

如果他们通过第一个应用节点升级迁移数据库结构，同时创建 1.0.0.0 的缓存版本。连接到 1.0.0 应用程序的用户使用数据库的缓存版本保持不变，连接到 2.0.0 应用程序的用户保持到新迁移的数据库。迁移所有应用程序节点后，将缓存的数据合并到数据库中。

他们似乎不太可能做到这一点，因为合并会非常复杂，但我看不到其他方式。任何指针/帮助将不胜感激。

Answer 1

一旦您的应用程序基础架构进入多个应用程序节点，这是一个常见的问题。在过去，您可以将您的应用程序离线以等待“维护窗口”，在此期间您可以：

• 将应用程序替换为“系统维护，即将推出”页面。
• 执行数据库迁移（架构和/或数据）
• 部署新的应用程序代码
• 将应用程序重新上线

在 2015 年，真的好几年了，这种方法是不可接受的。您的用户期望 24/7 全天候运行，因此必须有更好的方法。当然有，答案是Database Refactorings的一系列模式。

要始终牢记的基本概念是假设您必须维护应用程序的两个并发版本，并且这两个版本之间不能有没有重大更改 .这意味着您有一个当前正在生产的应用程序 (v1.0.0) 和计划部署的 (v2.0.0)。这两个版本必须在相同的模式上工作。在所有应用程序服务器上完全部署 v2.0.0 后，您就可以开发 v3.0.0 以完成任何最终的数据库更改。