redis-shake的sync模式是跨版本、跨部署形态redis集群迁移最快最稳妥方案，支持全量+增量同步、自动适配集群拓扑、持续追平数据、失败可重试，并需显式配置cluster=true、完整nodes列表及auth_password/auth_user以规避moved错误。
redis-shake sync 模式是最快且最稳妥的选择
对生产环境的 Redis 集群（尤其是跨版本、跨部署形态）来说，redis-shake 的 sync 模式是目前实际落地中最快、最省心的方案。它不是“快在单次传输速度”，而是快在“无需停机、自动适配集群拓扑、增量持续追平、失败可重试”。相比手写脚本或 redis-cli --rdb，它省去了 slot 映射、ACL 鉴权、MOVED 重定向、节点发现等大量易错逻辑。
为什么不能直接用 redis-cli --rdb 导出再导入
常见错误现象：redis-cli --rdb 连任意一个集群节点导出 RDB，恢复后所有 key 都落在同一个分片，客户端访问时持续报 MOVED 错误；或者因目标集群启用了 ACL，但 RDB 恢复不带用户上下文，导致部分 key 写入失败。
-
--rdb是单机视角工具，完全无视集群 slot 分布，导出的是“扁平化快照” - 它不解析源集群的
CLUSTER SLOTS，也不按 slot 分片拉取数据 - 无法处理目标集群密码不在 URL 中（如 ACL 用户）、SSL、Proxy 等真实配置
- 全量完成后无法继续同步增量，必须手动切流，窗口期内数据丢失风险高
配置 redis-shake sync 时三个关键陷阱
多数迁移失败不是因为工具不行，而是配置跳过了集群识别逻辑。以下三点必须显式声明：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 源和目标的
cluster = true必须设为true，否则当成单机处理 -
nodes字段要填全部 master 节点地址（如["10.0.1.1:7000", "10.0.1.2:7001"]），只填一个会跳过拓扑发现 - 密码不能写在 URL 里（如
redis://:pwd@host:port），而要用auth_password（ACL 场景还需auth_user）
示例片段：
source: cluster: true nodes: ["192.168.1.10:7000", "192.168.1.11:7000", "192.168.1.12:7000"] auth_password: "src-pass" target: cluster: true nodes: ["192.168.2.10:7000", "192.168.2.11:7000", "192.168.2.12:7000"] auth_password: "dst-pass" auth_user: "default
迁移过程中 MOVED/ASK 报错怎么快速定位
这不是网络问题，基本指向 slot 映射失效：源集群某个 key 计算出的 slot，在目标集群没有对应 master 负责，或该节点状态异常（比如正在 failover、slot 迁移未完成、节点未握手成功）。
- 先确认目标集群
CLUSTER NODES输出中所有 master 的connected状态为connected，且 slot 范围覆盖 0–16383 - 用
CLUSTER KEYSLOT keyname查 key 对应 slot，再查CLUSTER NODES看该 slot 是否被分配给某个在线 master - 如果目标集群刚创建，检查是否执行了
redis-cli --cluster add-node或--cluster reshard完成槽位分配
真正耗时的从来不是传输本身，而是 slot 分布不一致导致的写入失败和重试卡顿——这点容易被忽略，但直接影响迁移是否“快”。
