将带有存储过程的数据库迁移转换为持续交付的策略

问题描述

我们公司已经将大部分的大型单体应用程序拆分为较小的微服务，并且我们有一个明确的计划，将新的服务引入到CI/CD流水线中。然而，由于数据库依赖和需要停机时间来部署的数据库迁移问题，我们仍然有一些应用程序的部分尚未拆分。问题的一部分是我们有大量包含业务逻辑的存储过程。
我看到了很多关于如何重构代码和API以实现蓝/绿/金丝雀部署的信息。但是，我们如何在没有停机时间的情况下进行数据库更改或迁移呢？

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

在进行数据库迁移时，要实现最小化停机时间，可以使用一些方法来几乎实现零停机时间。
主要思路是创建具有新模式的新数据库。然后在代码中进行更改。首先将数据从旧数据库迁移到新数据库。然后在代码中进行更改，使其同时写入旧数据库和新数据库。您需要选择一个时间（在该时间段内数据库的写入最少）。然后停止所有写入操作。删除旧数据库，并确保从现在开始所有写入操作都将发生在新数据库中。然后重新开始写入操作。
通过这种方式，您可以实现最小化停机时间的数据库迁移。
您可以查看以下链接，了解如何详细执行此操作：Safe Database Migration Pattern Without Downtime

方案2

使用新数据库的读取故障转移模式的库是否存在，需要根据您的数据库需求进行搜索。
这种方法可以说是一种常见的做法，因为这种策略可以提供非常少的停机时间。至于库的问题，我不完全确定。您可能需要根据您的数据库需求进行搜索。