快速的未来即将在您所在的城市举办活动。
加入我们在 Redis 发布会
分享
尤其是在协调分片 Redis 后端的迁移时，并且对应用程序停机时间有严格的要求。
这正是我们为解决一位希望从现有设置迁移到我们 Redis 云服务的用户的挑战而采取的措施，因此我们开发了自己的工具来简化此过程（以下将详细介绍）。许多数据库，包括 Redis，可以使用内置的备份和恢复机制以及一些文件复制操作，轻松地从一个地方迁移到另一个地方。
然而，这种方法要求数据库在迁移过程中停止并脱机。在某些情况下，您可以优化该过程以减少数据库的停机时间（例如，通过将迁移分成两个阶段来完成，第一个阶段用于数据主体的大部分，第二个阶段用于增量），但有些用例在技术上无法实现这种方法（即更新来得太快，对于 Redis 来说，可能意味着每秒数万个请求），或者根本不可接受（因为应用程序的至关重要性）。
另一种方法使用数据库复制（也受 Redis 支持），以在目标位置创建一个原始数据库（也称为主数据库）的精确副本（也称为从数据库）。然后，一旦复制完成，您就可以切换到副本。
与本机备份-复制-恢复方法相比，这种方法的优势在于，应用程序停机时间可以保持在绝对最低限度，因为数据库在迁移过程中不会停止。
一旦从数据库准备就绪，应用程序只需要从使用主数据库切换到使用从数据库即可——这是一个几乎不需要时间并且对现代应用程序架构没有明显影响的更改。
为了成功地使用复制进行迁移，我们建议的流程是
复制作为迁移的一种方式是一个很好的工具，但它也带来了一些复杂性。您需要确切地知道何时从一个步骤前进到另一个步骤，因为如果您过早地切换到从数据库，可能会发生各种意外情况。
例如，考虑这样一个情况：更新速率足够高，以至于主数据库的复制缓冲区从未完全清空，甚至像无限 Redis 复制循环中所描述的那样溢出。在这些情况下，确定在主数据库和从数据库之间切换的正确时间点可能是一项具有挑战性的任务。
如果迁移范围包含多个服务器（例如，在分片场景中），该过程会变得更加复杂。遗憾的是，这对于 Redis 用户来说一直是一个持续存在的问题，直到包括 v2.6 版本。好消息是，Redis v2.8 改进了——PSYNC 将在 SHOW INFO 输出的复制部分中引入延迟信息，但这并不能消除时间挑战。
引用该人的原话
更好的消息是，从今天开始，无论您使用哪个 Redis 版本，都可以使用我们自己开发的 redis-migrate 工具来执行一个或多个 Redis 服务器的复制迁移，甚至无需费力。
从我们的 github 上 这里 获得的 redis-migrate 是一个交互式 Python 脚本，它使用类似顶部的 UI 显示实时复制状态信息。该脚本通过 –src 和 –dst 参数作为输入，接受两个大小为 N 的 Redis URL 列表。
一旦调用，它会首先提示您在显示要迁移的数据总大小、密钥数量和 Redis 服务器数量后继续（通过输入“c”）。如果您选择继续，它将通过在主数据库 (src 列表) 和它们各自的从数据库 (dst 列表) 之间设置和启动复制来执行上述迁移过程的步骤 1。执行步骤 1 时，您会看到有关每个主数据库-从数据库复制链接进度更新的信息。
一旦您验证了一切都已准备就绪（即初始同步已完成并且更新正在流动），就可以通过输入“e”提示工具继续执行步骤 2。在步骤 2 中，该工具将等待您将应用程序指向已复制的从数据库。当 replication buf 为 0 时，您可以使用脚本输出的实时信息来验证您的主数据库是否不再使用。
与之前一样，该脚本将等待您的许可才能进入步骤 3——只需说“m”。一旦步骤 3 执行完毕（将从数据库提升为主数据库），该工具就会悄无声息地退出。
现在您只需处理旧的主数据库即可。
注意：斧头不包含在内
