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）这类模块命令完全忽略。这种得单独导出再人工注入。
