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

AmazonWeb服务根据您的需要提供许多连续部署和管理工具，如ElasticBeanstalk、OpsWorks、云形成和代码部署。其基本思想是在零停机的情况下促进代码部署和升级。它们还使用AWS资源帮助管理最佳体系结构实践

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

跨实例群（应用程序服务器）的实际代码升级很容易理解。对于一个非常简单的概述，AWS服务依次升级每个节点，从而关闭连接，因此不使用有问题的实例

然而，我不明白DB升级是如何管理的。假设我们正在从应用程序的1.0.0版升级到2.0.0版，并且需要更改数据库结构。通常，您会使用脚本或类似Flyway的库来执行升级。但是，如果有一组服务器需要升级，那么在某一点上，整个服务器组中都存在1.0.0和2.0.0应用程序，每个应用程序都需要不同的数据库结构

我需要了解这实际上是如何实现的（高级别），以了解执行DB迁移的最佳方式/时间。我想他们有几种方法可以做到这一点，但我很难看到他们如何做到这一点，并允许1.0.0和2.0.0在不丢失数据的情况下保持数据

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

---

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

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

• 将应用程序替换为“系统维护，尽快返回”页面
• 执行数据库迁移（架构和/或数据）
• 部署新的应用程序代码
• 将应用程序重新联机

在2015年，实际上在几年内，这种方法是不可接受的。您的用户希望全天候运行，因此必须有更好的方法。当然有，答案是一系列的模式

---

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

你找到好答案了吗？