Mysql实时数据库迁移

Question

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

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

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

你觉得哪种方法会出现这样的情况是好的？

比方说，你有表名为“用户”用1M行。它每秒都在变化。一些字段被更新，一些行被添加并且一些行被删除。这就是为什么我们无法在某个时间点制作快照的原因，因为迁移完成后，我们将有3小时的数据未确定。

Answer 1

有一种方法我曾经使用过，也适用于您，但是您需要修改您的生产数据集。只需简单地说：

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

这样您就可以随意运行迁移脚本。

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

Answer 2

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

我的意思是：当你给旧数据库写点东西时，你也必须将数据写入新数据。我已经在过去使用

Answer 3

一种方法是使用replication.

我们创建了旧的生产数据库，这是用于数据迁移的奴隶之间的复制方案。当我们开始迁移时，我们暂时关闭了复制，并使用从数据库作为迁移的数据源;旧的生产系统仍然运作。

迁移脚本完成并且我们的一致性检查已运行后，我们重新启用了从旧生产系统到复制从属系统的复制。复制完成后，我们在生产过程中挂上了“维护维护”标志，重新运行数据迁移脚本和一致性检查，将系统指向新数据库，并取下“维护”标志。

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

这取决于您的数据库模式，以便识别更改/新数据。

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

例如：

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 

你可以通过在用户表中的触发器插入填充此表，删除和更新 - 为每个动作，您可以设置一个独立的状态。

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

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