实时数据库迁移

数据库迁移是将数据从一个数据库系统传输到另一个数据库系统的过程，这可能涉及更改数据库架构、数据库管理系统或两者。这样做是为了提高性能、可伸缩性和可靠性，或者利用目标数据库系统中的新特性和功能。 

就系统可用性而言，数据库迁移有两种形式：停机迁移和实时迁移。

停机时间

该系统已关闭进行维护，开发人员发布了一个显示“正在维护中”的启动页面。在幕后，数据被复制到新数据库，并且连接字符串从旧数据库更新到新数据库。一旦一切都被验证可以正常工作，系统就会再次上线。此方法有一定的优点，因为无需过多关心迁移过程中的系统可用性和/或数据丢失。当然，缺点是系统 SLA 会下降，这可能不适合所有类型的应用程序。

实时

在这种方法中，系统永远不会崩溃。相反，迁移设计使得迁移可以在没有任何停机时间的情况下完成，即系统在整个迁移过程中保持活动状态。尽管这需要更复杂的设计，但这种方法保证对服务可用性 SLA 没有影响或影响最小，并且对于许多场景来说可能是更有吸引力的选择。

本文将介绍实时数据库迁移设计的案例研究。

阶段

实时数据库迁移设计分为几个阶段：

第一阶段：数据隐藏

此步骤是一个代码密集的步骤，其中服务以某种形式编写，使得位于数据层之上的服务层与服务所使用的数据库无关。该步骤包括：

• 在数据库层之外使用与数据库实现无关的对象（并且绝对不使用模型对象！）。
• 使用转换函数将数据库模型对象与数据库实现无关的对象相互转换

完成第一阶段后，我们可以安全地开始对迁移模块进行编码，而不会影响当前的功能。

第二阶段：新数据层

此步骤在现有数据层旁边引入新数据层。大多数时候，这将是一个新的存储库类，每个表/集合都有一个从现有数据层 1:1 映射的 CRUD 函数的新副本。 

此步骤还引入了 MigrationFlag (True/False) 并确保新的数据层代码仅位于 True 标志后面。这样，一旦部署代码，配置最初部署为 False，并且代码仅写入旧数据层。我们将在稍后阶段看到当配置变为 True 时会发生什么。

第三阶段：数据同步

此步骤涉及一些数据工程和创建数据管道，将数据从旧数据库复制到新数据库。这包括：

• 在某处保存一个datetime标记列，它跟踪任何记录的最近更改，并帮助跟踪需要同步到新数据库的记录的最新版本。
• 此外，有时，数据会从旧数据库转换到新数据库，以防迁移过程中发生任何架构/模型更改。

值得注意的是，通过定期运行此数据同步，正在构建旧数据库的实时副本，理想情况下，该副本能够在切换到旧数据库时吸收流量。这将我们带入下一阶段。

第四阶段：配置切换

现在，此处使用在步骤 2 中开发的迁移标志从 False 切换到 True。然后代码开始双重写入新旧数据库并从新数据库读取 。这有两个方面的帮助：

• 如果步骤3中开发的数据同步正确，则双写到旧数据库的数据会同步到新数据库，但该数据已经存在于新数据库中，并且配置更改为True。因此，该操作不会对功能进行任何更改。然而...
• 如果出现问题，双写系统可确保随时将 MigrationFlag 配置标志设置为 False，以停止双写和从新数据库读取，并有效返回到仅从旧数据库读取和写入像之前一样。

如果没有问题，那么我们将继续最后的步骤。

第五阶段：切断旧数据库

此步骤中的代码已更新，以停止对旧数据库的双重写入，而仅从新数据库进行读写。在双写停止并验证没有新数据通过管道同步后，数据同步也可以安全停止。

在第 5 阶段结束时，可以有一个可选的清理阶段来删除所有未使用的代码和数据同步源。 

结论