Question

这可能是任何团队在某些时候都会遇到的，所以我依靠其他人的经验。

我们正在将旧MySQL数据库迁移到新数据库，其结构发生了很大变化。一些表被分成多个较小的表，一些数据从多个较小的表连接到一个较大的表。

我们进行了测试，将数据库迁移到新表单需要几个小时。问题是，旧数据库是我们的生产数据库，每分钟都在变化。我们不能有几个小时的停机时间。

你认为在这种情况下你会采取什么方法？

假设您有一个名为“users”的表，包含1M行。它每秒都在改变。某些字段已更新，添加了一些行并删除了一些行。这就是为什么我们无法在某个时间点制作快照的问题，因为在迁移完成后，我们将有3小时的数据未同步。

Answer 1

我过去使用的一种方法是使用replication.

我们在旧的生产数据库和用于数据迁移的从属设备之间创建了一个复制方案。当我们开始迁移时，我们暂时关闭了复制，并使用slave数据库作为迁移的数据源;旧的生产系统仍在运作。

迁移脚本完成后，我们的一致性检查已经运行，我们重新启用了从旧生产系统到复制从属的复制。复制完成后，我们在生产时挂起“down for maintenance”标志，重新运行数据迁移脚本和一致性检查，将系统指向新数据库，并取下“down for maintenance”标志。

有停机时间，但它是几分钟，而不是几小时。

这取决于您的数据库架构，以便于识别已更改/新数据。

如果您的架构不适合轻松查询以查找新记录或已更改记录，并且您不想添加新列以跟踪此情况，则最简单的解决方案是创建单独的表以跟踪迁移状态。

例如：

TABLE: USERS (your normal, replicated table)
----------------------
USER_ID
NAME
ADDRESS
.....


TABLE: USERS_STATUS (keeps track of changes, only exists on the "slave")
-----------------
USER_ID
STATUS
DATE

您通过USERS表上的触发器填充此表以进行插入，删除和更新 - 对于每个操作，您都设置了单独的状态。

这使您可以快速查找自运行第一个迁移脚本以来发生更改的所有记录，并且只迁移这些记录。

由于您没有修改生产环境，并且触发器仅在“从属”环境中触发，因此您不应在生产环境中引入任何性能或不稳定性问题。

Answer 2

我曾经使用过一种方法，这种方法对您也有用，但是您需要为此修改生产数据集。简单地说：

向要迁移的每个表添加名为“migrated”（或左侧）的新列。给它一个布尔类型。默认情况下将其设置为0.
当您的迁移脚本运行时，必须为已迁移到新数据库的每个条目将此标志设置为1。必须忽略所有已经为“1”的条目。这样你就不会遇到同步问题。

通过这种方式，您可以根据需要随时运行迁移脚本。

您将有一个停机时间，但它只是一个最小的停机时间，因为在停机期间您只需迁移一些数据集（实际上是最后一次运行迁移脚本和现在之间的最后一个“delta”）。

Answer 3

您可以与当前的数据库并行运行新数据库吗？这样，您可以稍后将旧数据库中的旧数据迁移到新数据库，并且已经在新数据库中捕获了“实时”情况。

我的意思是：当您向旧数据库写入内容时，您还必须将数据写入新数据库。

Mysql实时数据库迁移/转换

3 个答案: