SLAVEOF在Redis 5.0与6.2集群间失效，因二者集群协议不兼容：握手机制、CLUSTER NODES格式、Gossip解析、故障检测逻辑及cluster-require-full-coverage默认值均不同，导致混跑时槽位错乱、节点状态异常、数据丢失。
不能直接对 Redis 5.0 集群节点执行二进制替换并靠 slaveof 切换完成平滑升级——5.0 与 6.2 的集群协议不兼容，强制混跑会导致槽位错乱、连接频繁重连甚至数据丢失。
为什么 slaveof 在跨大版本集群间失效
Redis 5.0 的集群握手协议、CLUSTER NODES 响应格式、故障检测超时逻辑，和 6.2 存在底层差异。即使你用 slaveof 192.168.1.10:7001 把一个 6.2 实例设为 5.0 主节点的从库，它也无法正确解析 Gossip 消息，CLUSTER NODES 中会显示该节点状态为 fail 或字段缺失，且无法参与槽位迁移。
- 5.0 默认使用
redis.conf中未显式声明的cluster-require-full-coverage yes，而 6.2 默认是no；不统一会导致部分节点拒绝服务 -
redis-cli --cluster check在混合集群中会报FAIL或Slot mismatch错误，不是警告而是实际不可用信号 - 6.2 引入的
CLUSTER FAILOVER自动故障转移机制依赖新协议字段，5.0 节点无法响应
必须走「加新—迁槽—下旧」三步闭环
这是唯一被官方文档和生产环境验证过的路径。核心不是“复制”，而是“替代”：新节点以独立身份加入集群，接管槽位，再让旧节点退场。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先部署一台 Redis 6.2 实例（如
192.168.1.20:7007），配置与原集群一致（尤其cluster-enabled yes、cluster-config-file nodes-7007.conf、cluster-require-full-coverage no） - 用
redis-cli --cluster add-node 192.168.1.20:7007 192.168.1.10:7001加入现有 5.0 集群（任一活跃节点均可作入口） - 执行
redis-cli --cluster reshard 192.168.1.10:7001 --from <code>5.0-node-id--to6.2-node-id--slots N --yes 迁移指定数量槽位（注意：必须用 node ID，不是 IP） - 等
CLUSTER NODES显示新节点状态为master、槽位数正确、旧节点变为fail后，再执行redis-cli --cluster del-node 192.168.1.10:7001 <code>5.0-node-id
客户端必须同步刷新拓扑缓存
很多故障不是服务端出问题，而是客户端还在往已下线的 5.0 节点发请求。Jedis/Lettuce 默认不会主动拉取最新 CLUSTER SLOTS，直到连接超时（常达 2s）才重试，造成明显毛刺。
- 升级前检查客户端是否启用拓扑自动刷新：Lettuce 看
refreshPeriod，Jedis 看clusterRefreshInterval，建议调小至500毫秒 - 替换过程中，用
redis-cli -c -p 7001 CLUSTER SLOTS获取当前槽位映射，对比客户端日志中实际路由目标，发现不一致立即触发强制刷新 - 禁用静态 IP 列表初始化连接池，改用任意一个活跃节点地址（如
redis://192.168.1.10:7001）让客户端自动发现全量拓扑
回滚不是“换回旧二进制”那么简单
一旦新节点完成槽位迁移并被标记为 master，它的 nodes-*.conf 文件就已写入新版格式（含 6.2 特有字段）。此时若直接用 5.0 二进制启动该实例，会因配置解析失败而拒绝启动，或启动后无法加入原集群。
- 真正可落地的回滚方式，是提前备份每个节点的原始
nodes-*.conf和dump.rdb（非 AOF），并在下线旧节点前保留其进程不 kill - 若迁移中途失败，应立刻用
redis-cli --cluster failover --force将旧主节点手动提升，再删掉新节点 ID，而不是试图复用其配置文件 - 切记：6.2 的
RDB_VERSION是 10，5.0 只认到 9；RDB 文件不可跨此边界直读
