平滑升级Redis主从架构的核心是确保不丢数据、不断服务、不卡同步，采用轮询升级从库再切换主节点的路径最可控；升级前须验证replicaof配置与密码兼容性、检查master_link_status及避免slaveof残留，SLAVEOF NO ONE前需确认repl_backlog_active且offset差值在安全范围内。
平滑升级 Redis 主从架构，核心不是“能不能升”，而是“升完会不会丢数据、断服务、同步卡住”。轮询升级从库再切换主节点，是生产环境最可控的路径——但每一步都有明确的约束条件和容易被跳过的检查点。
升级前必须确认 replicaof 配置与密码兼容性
新版 Redis（尤其是 7.0+）对 replicaof 指令和认证逻辑做了调整：如果主节点启用了 requirepass，而从节点配置中用的是旧式 masterauth，升级后可能无法重建复制连接；更隐蔽的是，某些版本会静默忽略错误，表现为 INFO replication 中 master_link_status:down 却无日志报错。
- 升级前在每个从节点上执行
redis-cli -h info replication | grep -E "(role|master_link_status|master_host)"，确认当前状态正常 - 检查从节点配置文件中是否同时存在
replicaof和已废弃的slaveof——后者在 5.0+ 已被标记为 warning，7.0+ 直接拒绝启动 - 若主节点有密码，确保从节点配置中使用
masteruser+masterauth（6.0+ 支持 ACL 用户）或统一改用requirepass配合replica-announce-ip避免地址解析失败
SLAVEOF NO ONE 切换前要清空复制缓冲区风险
直接执行 SLAVEOF NO ONE 不等于“立刻可用”。如果该从节点之前长期滞后（lag > 10s），它的 repl_backlog 可能已覆盖旧增量，切换后若原主恢复并试图重连，会因 offset 不匹配触发全量同步（FULLRESYNC），而新主此时已不接受 PSYNC 请求——结果就是原主卡在 connecting 状态，新主写入不受影响，但整个集群失去容错能力。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 切换前先在从节点运行
redis-cli info replication | grep -E "(offset|repl_backlog_active|repl_backlog_size)"，确认repl_backlog_active:1且offset与主节点master_repl_offset差值 - 如滞后严重，先在原主节点上临时增大
repl-backlog-size（例如设为 128mb），等待从节点追平后再操作 - 执行
SLAVEOF NO ONE后，立刻用CONFIG REWRITE持久化配置，否则重启后自动回退为从节点
轮询升级时要注意 bgsave 与 AOF rewrite 的资源冲突
逐台升级从节点看似安全，但如果某台从节点正在执行 bgsave（比如它刚完成一次全量同步），此时升级进程会中断后台子进程，导致 RDB 文件损坏；更危险的是，若开启 AOF 且配置了 auto-aof-rewrite-percentage，升级瞬间可能触发 rewrite，与 bgsave 争抢磁盘 IO，造成超时甚至实例僵死。
- 升级前在目标从节点执行
redis-cli info persistence | grep -E "(bgsave_in_progress|aof_rewrite_in_progress)"，两项都必须为0 - 如任一为 1，用
redis-cli BGREWRITEAOF或redis-cli SAVE主动触发一次，等其完成再升级 - Docker 环境下尤其注意：升级镜像时不要直接
docker restart，应先docker stop等redis-server进程干净退出，避免 SIGTERM 被忽略
真正难的不是命令敲得对不对，而是每次切换前你有没有花 30 秒看一眼 INFO replication 里那几行数字——偏移量、链接状态、缓冲区大小，它们不会主动报错，但会默默决定你接下来十分钟是顺利收工，还是半夜被告警电话叫醒。
