让我们玩转主仆：用于 Redis 迁移的实时同步工具

时机就是一切……

尤其是在编排分片 Redis 后端的迁移时，需要严格限制应用程序停机时间。

这正是我们的一位用户希望从现有设置迁移到我们的 Redis Cloud 服务时所面临的挑战，因此我们开发了自己的工具来简化此过程（更多详细信息如下）。许多数据库（包括 Redis）都可以通过内置的备份和恢复机制以及一些文件复制操作轻松地从一个地方移动到另一个地方。

但是，这种方法需要数据库停止并在移动期间脱机。在某些情况下，您可以优化该过程以减少数据库的停机时间（例如，通过分两个阶段完成迁移，第一个阶段用于大部分数据体，第二个阶段用于增量），但在某些用例中，这种方法在技术上是不可能的（即，更新速度太快，在 Redis 的情况下，这可能意味着每秒数万个请求），或者根本无法接受（因为应用程序的关键性）。

另一种方法使用数据库复制，Redis 也支持该方法，以从原始数据库（又名主数据库）创建一个精确副本（又名从数据库）作为目标。 然后，一旦复制完成，您就可以切换到副本。

与本机备份-复制-恢复方法相比，此方法的优势在于，可以将应用程序的停机时间保持在绝对最低限度，因为在迁移期间不会停止数据库。

一旦从数据库准备就绪，应用程序只需要从使用主数据库切换到使用从数据库即可——这一更改几乎不需要时间，并且对现代应用程序架构没有明显影响。

要使用复制成功执行迁移，我们推荐的流程是

1. 设置复制

   1. 配置一个节点作为迁移的目标
   2. 启动从主数据库到从数据库的复制
   3. 等待复制初始化（核心数据被复制）并正常运行（更新从主数据库流向从数据库）

2. 进行切换

   1. 配置副本以接受应用程序写入请求（如果以只读模式启动）
   2. 配置应用程序[实例]以使用从数据库而不是主数据库
   3. 等待主数据库停止接收写入请求（因此停止更新从数据库）

3. 善后处理

   1. 停止复制并将从数据库提升为主数据库
   2. 废弃旧的主数据库

复制作为迁移的一种手段是一种很好的方式，但也引入了一些复杂性。您需要准确地知道何时从一个步骤进行到下一步骤，因为如果您过早切换到从数据库，可能会发生各种意外。

例如，考虑这样一种情况：更新速率非常高，以至于主数据库的复制缓冲区永远不会完全为空，甚至会如 无尽的 Redis 复制循环中所述那样溢出。在这种情况下，确定在主数据库和从数据库之间进行切换的正确时间可能是一项具有挑战性的任务。

如果迁移范围包含多个服务器（例如，在分片场景中），则该过程会变得更加复杂。遗憾的是，对于 Redis 用户来说，这一直是一个问题，直到并包括 v2.6。好消息是 Redis v2.8 改进了 – PSYNC 将在 SHOW INFO 输出的复制部分下引入滞后信息，但这并不能消除时间上的挑战。

引用他本人

• “这里的问题是要了解是否存在真正的不同步。也就是说，如果您停止客户端向您的主数据库写入数据，密钥计数和内容是否完全相同？”（今天早些时候，Redis 创建者 Salvatore Sanfilippo，又名 antirez）。

更好的消息是，截至今天，无论您使用哪个 Redis 版本，您都可以使用我们自己开发的 redis-migrate 工具来执行一个或多个 Redis 服务器的复制迁移，而无需费力。

可从我们的 github 此处 获取，redis-migrate 是一个交互式 Python 脚本，它使用类似 top 的 UI 显示实时复制状态信息。该脚本接受两个 N 大小的 Redis URL 列表，通过 –src 和 –dst 参数作为输入。

一旦被调用，它首先提示您在显示将被迁移的数据总大小、密钥数量和 Redis 服务器后，让它继续（通过输入 'c'）。如果您选择继续，它将执行上述迁移过程的步骤 1，通过设置和启动主数据库（src 列表）和它们各自的从数据库（dst 列表）之间的复制。当执行步骤 1 时，您会看到有关每个主从复制链接进度的最新信息。

一旦您确认一切准备就绪（即初始同步完成并且更新正在流动），您可以通过输入 'e' 提示该工具继续执行步骤 2。在步骤 2 中，该工具会等待您将应用程序指向复制的从数据库。当 replication buf 为 0 时，您可以使用脚本输出的实时信息来验证您的主数据库是否不再被使用。

与之前一样，脚本会等待您的许可才能移动到步骤 3 - 只需说 'm'。一旦步骤 3 已经执行 - 将从数据库提升为主数据库 - 该工具就会平淡地退出。
您现在要做的就是处理旧的主数据库。

注意：不包括斧头