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

Question

Amazon Web Services根据您的需求提供许多持续部署和管理工具,如Elastic Beanstalk,OpsWorks,Cloud Formation和Code Deploy.基本思想是在零停机时间内促进代码部署和升级.它们还有助于使用AWS资源管理最佳架构实践.

为简单起见,我们假设一个基本的架构,你有一个2撕裂结构; 负载均衡器后面的应用程序服务器集合,然后是使用多区域RDS DB的持久层.

跨一组实例(app服务器)的实际代码升级很容易理解.对于非常简单的概述,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 年，甚至在接下来的几年里，这种做法都是不可接受的。您的用户期望 24/7 运行，因此必须有更好的方法。当然有，答案是数据库重构的一系列模式。

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