怎样在生产环境中进行Redis 6.0到Redis 7.0的版本平滑升级-Redis-PHP中文网

redis 6.0 升级至 7.0 不可“停一个、起一个”，必须验证 rdb 实际加载、闭环迁移集群节点、同步客户端拓扑刷新及 cluster-require-full-coverage 配置，否则将导致槽位丢失、连接震荡或数据错乱。

怎样在生产环境中进行redis 6.0到redis 7.0的版本平滑升级

能平滑升级，但必须放弃“停一个、起一个”的直觉操作——Redis 6.0 和 7.0 之间存在集群握手协议、RDB 格式、AOF 结构三处不兼容点，任何跳步都会导致槽位丢失、连接震荡或数据加载失败。

先验证 RDB 文件能否被 Redis 7.0 正确加载

别信文档说的“6.x → 7.x 兼容”，得用你生产环境的真实 dump.rdb 文件实测。Redis 7.0 虽保留了对 6.x RDB 的解析能力，但只保证基础结构可读；若你的数据含 stream 消费组元数据、带过期时间的 listpack 小对象等细节，旧 RDB 可能加载后类型错乱或字段截断。

停掉当前 Redis 6.0 实例（确保无写入）
复制出真实的 dump.rdb 和对应 redis.conf
用 Redis 7.0 二进制静默加载：redis-server /path/to/redis.conf --dbfilename dump.rdb --dir /tmp/test-dir --port 0 --daemonize no
重点看日志是否出现 DB loaded from disk，而非 Failed trying to load the RDB format
连接后执行 DBSIZE、KEYS * 抽样、TYPE keyname 和 XINFO GROUPS streamname，比对与旧实例完全一致

集群节点替换必须走「加新—迁槽—下旧」闭环

Redis 集群不支持跨版本节点共存：6.0 和 7.0 的 CLUSTER NODES 响应格式不同（字段顺序、空格分隔）、故障检测超时逻辑变更、ASK/MOVED 重定向行为有差异。混跑超过 30 秒，就会触发部分 slot 标记为 fail，客户端持续收到 MOVED 重试，QPS 毛刺明显。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

新节点启动前，统一修改配置项：cluster-require-full-coverage 在 6.x 默认为 yes，7.x 默认为 no；不统一会导致新节点拒绝服务
加节点命令必须指向集群中任一存活节点，不是目标旧节点：redis-cli --cluster add-node 192.168.1.11:7005 192.168.1.10:7001
迁移槽位时，--from 参数必须填旧节点的 node id（从 CLUSTER NODES 输出里抄），不能写 IP+端口
等待新节点状态变为 master 且 CLUSTER NODES 显示槽位数正确、旧节点状态为 fail 后，再执行 redis-cli --cluster del-node 192.168.1.10:7001 <old-node-id></old-node-id>

客户端必须同步刷新拓扑缓存，不能靠自动重试扛

Jedis、Lettuce 等客户端默认会缓存集群拓扑 10～60 秒，并在连接失败后重试已下线节点，直到超时（常为 2s）。这意味着即使服务端节点已下线，客户端仍会持续向它发请求，造成 RT 毛刺和连接堆积。

升级前检查客户端是否启用拓扑刷新：Lettuce 看 refreshPeriod，Jedis 看 clusterRefreshInterval；建议临时调小至 500 ms
替换每个节点期间，在应用侧主动调用 redis-cli -c -p 7001 CLUSTER SLOTS 获取最新拓扑，与客户端本地缓存比对，不一致立即触发强制刷新
禁止用静态 IP 列表初始化连接池（如 ["192.168.1.10:7001", "192.168.1.10:7002"]），改用任意一个活跃节点自动发现：RedisURI.create("redis://192.168.1.10:7001")

AOF 升级后行为变化容易被忽略

Redis 7.0 默认启用 multi-part AOF（base.aof + incr_*.aof + manifest.aof），不再有传统意义上的 appendonly.aof 文件。如果你的应用或监控脚本硬编码依赖 appendonly.aof 文件名或大小判断，升级后会失效。

旧配置中 appendfilename "appendonly.aof" 仍可存在，但实际写入的是 base.aof 和增量文件
CONFIG GET appendfilename 返回值不变，但磁盘上看不到该文件；真正要监控的是 manifest.aof 是否更新、incr_*.aof 文件数量是否异常增长
如果关闭了 RDB，仅靠 AOF 持久化，Redis 7.0 崩溃恢复时依赖 manifest.aof 定位有效文件，该文件损坏即无法恢复

最易被跳过的动作是客户端拓扑刷新和 cluster-require-full-coverage 配置对齐——这两项不出错时一切正常，一出错就是集群不可用级别问题，且现象隐蔽：看起来连接都通，但部分 key 始终 MOVED 循环或返回空响应。