迁移卡在importing/migrating状态时，需在对应节点分别执行cluster setslot X stable：在标有importing的节点（目标节点）执行一次，在标有migrating的节点（源节点）也执行一次，两者均返回OK后状态清除，再用redis-cli --cluster check验证一致性。
迁移卡在 importing/migrating 状态怎么清？
槽位迁移中断后，最典型的现象就是 redis-cli -c cluster nodes 输出里出现 importing 或 migrating 标记，比如 192.168.206.129:7004 has slots in importing state 0 —— 这说明槽 0 卡在导入状态，集群无法达成一致。
直接执行 cluster setslot 0 stable 是最快恢复手段，但必须在对应节点上操作：
- 在标有
importing的节点（接收方）执行cluster setslot 0 stable - 在标有
migrating的节点（发送方）也执行一遍cluster setslot 0 stable - 两个命令都成功返回
OK后，再跑redis-cli --cluster check host:port验证
注意：不能只在一边执行，否则状态不一致仍会报 Nodes don't agree about configuration!
用 redis-cli --cluster reshard 半途失败怎么办？
自动迁移工具中断后，往往残留部分槽处于迁移中，且 --cluster fix 在新版 Redis 中基本无效（它只修配置不修状态）。
此时别重跑 reshard，先人工定位问题槽：
- 运行
redis-cli -c cluster slots，找那些被拆分显示的槽段（比如某槽只出现在一个节点的 slots 列表里，另一节点却标着 importing） - 对每个异常槽号，分别连到它的 source 和 target 节点，各执行一次
cluster setslot X stable - 确认无
importing/migrating后，再用redis-cli --cluster rebalance重新分配（加--cluster-timeout 15000避免超时）
切忌跳过 stable 步骤直接 rebalance，否则新迁移又会撞上旧残留状态。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
迁移失败后数据还在原节点吗？
只要没执行 cluster setslot X node-id 最终绑定，数据就始终只在源节点 —— MIGRATE 命令是原子操作，失败即回滚，不会丢数据，也不会双写。
但要注意两点：
- 迁移过程中客户端可能收到
MOVED或ASK重定向，若应用没正确处理，会误以为数据已迁移 - 如果曾手动用
MIGRATE命令搬过 key，而没清空源节点的 key，就会出现“两边都有数据”的假象，得用redis-cli --cluster check+redis-full-check对比校验
真正危险的是状态卡住导致集群不可用，而不是数据丢失 —— Redis 的槽位状态机设计决定了迁移失败本身不破坏数据一致性。
为什么 cluster setslot X stable 不生效？
常见原因就三个：
- 连错了节点：必须连到实际标着
importing或migrating的那个端口，不是随便连个主节点 - 节点未就绪：目标节点内存不足、
maxmemory触顶、或cluster-require-full-coverage no没开，导致拒绝接受稳定指令 - ACL 权限不足：Redis 6+ 默认禁用
cluster类命令，需显式授权ACL SETUSER ... on +cluster
执行前先 redis-cli -p xxx info cluster 看 cluster_state:ok 是否为 ok，不是就先解决网络或握手问题，再动槽位。
