amazon-web-services - 如何使用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 的缓存版本。连接到 1.0.0 应用程序的用户将使用数据库的缓存版本保留，而连接到 2.0.0 应用程序的用户将保留到新迁移的数据库。一旦所有应用程序节点都迁移完毕，缓存的数据就会合并到数据库中。

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

Answer 1

当您的应用程序基础架构进入多个应用程序节点时，这是一个常见问题。在过去，您可以在“维护窗口”期间使应用程序脱机，在此期间您可以:

• 将应用程序替换为“系统维护，很快返回”页面。
• 执行数据库迁移(架构和/或数据)
• 部署新的应用代码
• 将应用程序重新上线

在 2015 年，实际上多年来这种方法都是 Not Acceptable 。您的用户期望 24/7 运行，因此必须有更好的方法。当然有，答案是Database Refactorings的一系列模式.

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