3

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

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

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

在这种情况下，您认为哪种方法可以？

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

4

3 回答 3

1

我过去使用的一种方法是使用复制。

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

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

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

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

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

例如：

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 表上的触发器填充此表以进行插入、删除和更新 - 对于这些操作中的每一个，您都设置了单独的状态。

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

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

于 2013-02-08T13:39:11.600 回答
0

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

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

于 2013-02-08T13:32:16.177 回答
0

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

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

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

您将有一段停机时间，但这只是最短的时间，因为在停机期间您只需迁移几个数据集（实际上是上次运行迁移脚本与现在之间的最后一个“增量”）。

于 2013-02-08T13:28:52.807 回答