RedisShake同步前必须确认4个配置点：地址格式（ip:port）、密码与ACL权限（allkeys+@all）、repl-backlog-size≥512MB且protected-mode关闭、sync_mode=sync；集群下需确保slot分配正确、支持断点续传且避免模块命令丢失。

RedisShake 同步前必须确认的 4 个配置点

不检查这些，同步大概率卡在 connect timeout 或写入失败。RedisShake 不是黑盒工具，它对源和目标的权限、协议、版本都敏感。

• source.address 和 target.address 必须写成 ip:port 格式，不能带 redis:// 前缀；集群模式下 target.address 填任意一个节点地址即可，但该节点必须可访问整个集群（即开启 cluster-enabled yes 且握手正常）
• 单机 Redis 若启用了密码，source.auth 必须填明文密码；集群若启用了密码（如通过 requirepass 或 ACL），target.auth 也必须匹配，且账号需有 allkeys +@all 权限（仅 allkeys 不够，ACL 模式下写操作需要显式授权 +set、+hset 等）
• 确保源 Redis 的 repl-backlog-size 足够大（建议 ≥ 512mb），否则长连接断开后无法增量续传；同时关闭 protected-mode yes 或配好 bind，否则 RedisShake 连不上
• RedisShake 默认使用 RDB + AOF 混合模式同步，但集群不支持 slaveof，所以必须设 sync_mode = sync（全量+增量），不能用 restore 模式（后者会尝试发 slaveof 命令，直接报错 ERR This instance has cluster support enabled）

如何避免 key slot 分配错误导致写入失败

集群模式下，key 必须落在对应 slot，而 RedisShake 默认不做 slot 映射——它原样转发 key，由目标集群按 CRC16 自动分配 slot。如果源数据里有含 {...} 的 hash tag，或用了 eval 脚本批量写多个 key，就容易触发 MOVED 或 ASK 重定向失败。

• 全量阶段：RedisShake 会自动把每个 key 用 CLUSTER KEYSLOT 计算 slot，再发给对应节点，这个过程不可跳过，也不可关；你不需要、也不能手动指定 slot
• 但如果你的源数据包含大量跨 slot 的 MSET 或 Lua 脚本（比如 redis.call('set', KEYS[1], ARGV[1]); redis.call('hset', KEYS[2], ...)），同步会失败，因为集群不允许跨 slot 原子操作；必须提前拆解成单 key 操作，或改用 pipeline 分批提交
• 验证方法：同步启动后，立刻查目标集群任一节点的 INFO cluster，看 cluster_stats_messages_sent 是否持续增长；再随机抽几个 key 执行 CLUSTER KEYSLOT keyname，确认 slot 分布符合预期

同步中断后怎么安全续传而不是重来

RedisShake 支持断点续传，但依赖两个关键状态文件：redis-shake.conf 中的 meta_file 路径必须可写，且不能被清理；同时源 Redis 的复制偏移量（master_repl_offset）不能被覆盖（即 RDB 不能被新全量刷掉）。

• 务必设置 meta_file = ./meta.log（绝对路径更稳），并确保该文件在进程重启后仍存在；每次同步开始时，RedisShake 会读这个文件找上次的 offset
• 不要在同步过程中对源 Redis 执行 BGREWRITEAOF 或 SAVE，否则 AOF 文件重写可能截断旧 offset；如果必须做，先停 Shake，等 RDB/AOF 写完再启
• 增量阶段若报错 ERR Master replication ID mismatch，说明源主从切换过，此时不能硬续传；需手动查新主库的 run_id 和当前 offset，更新 meta.log 里的对应字段（格式为 JSON，改 "run_id" 和 "offset" 字段即可）

为什么同步完成后仍有 key 缺失或 TTL 异常

不是所有 Redis 数据都能无损迁移。RedisShake 对某些边缘结构支持有限，尤其涉及过期策略和特殊编码时。

• 带 EXPIREAT 的 key，如果源时间戳已过期，RedisShake 会跳过同步（不会发 PEXPIREAT）；但带 EXPIRE 的 key 会被转成当前时间 + 秒数，TTL 可能变短
• 源是 Redis 6.0+ 启用 active-defrag 的实例，部分 value 可能被碎片整理过，导致 RDB 中的 LRU/LFU 信息丢失；这不影响数据一致性，但 OBJECT FREQ 或 OBJECT IDLETIME 在目标上不准
• 集群不支持 SCAN 全局遍历，所以 RedisShake 的全量扫描靠 KEYS *（仅用于调试）或更稳妥的 SCAN + CLUSTER NODES 分片拉取；如果你在同步中看到日志频繁出现 scan cursor timeout，说明某节点响应慢，需调大 scan_count 和 timeout 参数

真正麻烦的是混合了 Stream、GEOHASH、Module 类型的数据——RedisShake v2.8.x 对 XADD 支持完整，但对 RG.TRIGGER（RedisGears）或 FT.ADD（RediSearch）这类模块命令完全忽略。这种得单独导出再人工注入。