滚动升级必须从从节点开始，直接升级主节点会触发槽位不可用和moved/clusterdown错误；需先确保从节点完全同步（master_repl_offset==slave_repl_offset），再替换二进制、沿用原配置启动，执行cluster meet和cluster replicate建立关系，最后cluster failover切换角色，并用redis-cli --cluster check验证槽位100%覆盖。
滚动升级必须从从节点开始
直接升级主节点会触发集群槽位不可用，客户端收到 MOVED 或 CLUSTERDOWN 错误的概率极高。必须先挑一个从节点（slave 角色）下手，确保它和主节点之间 master_repl_offset == slave_read_repl_offset，即无复制延迟。
- 用
redis-cli -h -p INFO REPLICATION检查偏移量差值是否为 0 - 若差值不为 0，等同步完成再操作，不要强行关服务
- 确认该从节点在
CLUSTER NODES输出中状态是connected且角色为slave
替换二进制文件后必须重用原配置启动
新版本 redis-server 不能直接用默认配置跑进集群——它会以单机模式启动，无法识别原有槽位分配。必须沿用旧版配置文件（含 cluster-enabled yes、cluster-config-file、cluster-node-timeout 等关键项）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 备份原配置：
cp /app/redis7/etc/redis6383.conf /app/redis7/etc/redis6383.conf.bak - 启动时指定同一配置：
/app/redis8/bin/redis-server /app/redis7/etc/redis6383.conf - 切勿修改
cluster-config-file路径，否则节点 ID 会变，集群认为是全新节点
CLUSTER MEET 和 CLUSTER REPLICATE 顺序不能颠倒
新版从节点启动后不会自动加入集群，必须手动告知它“谁是它的主节点”。但 CLUSTER MEET 是让集群认识这个新节点，CLUSTER REPLICATE 才是建立主从关系——顺序错会导致节点状态卡在 noaddr 或 fail。
- 先执行
redis-cli -a -h -p CLUSTER MEET - 再连到新节点本身：
redis-cli -a -h -p CLUSTER REPLICATE -
CLUSTER NODES中看到该节点角色变为slave且状态为connected，才算成功
故障转移后原主节点降级需重新验证同步
CLUSTER FAILOVER 让刚升级的从节点升为主节点，原主节点自动降为从节点——但它不会立刻开始同步，可能卡在 connecting 状态，或同步偏移量停滞。
- 执行完
CLUSTER FAILOVER后，立刻检查原主节点的INFO REPLICATION - 若
master_link_status不是up，或slave_repl_offset长时间不增长，说明复制链路异常 - 此时需手动在原主节点上执行
CLUSTER REPLICATE强制重建复制关系
redis-cli --cluster check 连任意节点验证整个集群视角下的槽位覆盖是否 100%，而不是只看单个节点状态。哪怕只有一个槽位未分配，客户端写入就可能失败。
