真正平滑的主库切换需分步验证：先确认从节点repl_backlog_active为1且offset差值≤backlog_size，滞后严重时临时增大原主repl-backlog-size；执行slaveof no one后立即config rewrite持久化配置，并确保replicaof行已清除、密码与redis 7.0+认证逻辑兼容。
不能靠“停主库→SLAVEOF NO ONE”硬切，否则大概率丢数据、卡同步、重启回退。真正平滑的主库切换，本质是让新主节点在接管前已具备完整数据视图、复制缓冲区未被覆盖、配置持久化且客户端能无感迁移——这需要分步验证和干预，不是一条命令的事。
SLAVEOF NO ONE 执行前必须确认 repl_backlog_active 和 offset 差值
直接执行 SLAVEOF NO ONE 不等于“立刻安全升主”。如果从节点 lag 过大（比如 >10s），它的 repl_backlog 可能已被新写入覆盖，导致切换后原主恢复时因 offset 不匹配触发全量同步（FULLRESYNC），而新主此时已不响应 PSYNC 请求，整个集群失去容错能力。
- 先在目标从节点运行：
redis-cli info replication | grep -E "(offset|repl_backlog_active|repl_backlog_size|master_repl_offset)" - 确认
repl_backlog_active:1，且master_repl_offset - offset差值 ≤ 当前repl_backlog_size（默认 1MB） - 若差值过大，临时在原主节点增大
repl-backlog-size（如设为134217728即 128MB），再等从节点追平
replicaof 配置与密码必须兼容新版 Redis 认证逻辑
Redis 7.0+ 对复制连接认证做了收紧：如果主节点启用了 requirepass，但从节点仍用旧式 masterauth（而非 masteruser+masterauth 或 ACL 用户），升级后复制链会静默断开——INFO replication 显示 master_link_status:down，但日志里可能没报错。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查从节点配置文件：禁止同时存在
replicaof和已废弃的slaveof（7.0+ 拒绝启动） - 主节点有密码时，从节点必须用
masteruser+masterauth（6.0+ 支持 ACL）；或统一用requirepass+replica-announce-ip避免地址解析失败 - 升级前在每个从节点执行：
redis-cli -h <ip> info replication | grep -E "(role|master_link_status|master_host)"</ip>，确保当前状态正常
SLAVEOF NO ONE 后必须立即 CONFIG REWRITE
执行 SLAVEOF NO ONE 是运行时操作，不会自动改写配置文件。如果不调用 CONFIG REWRITE，节点重启后会按 redis.conf 原配置重新拉起为从节点——等于白切。
- 执行完
SLAVEOF NO ONE后，立刻跟一句：redis-cli config rewrite - 检查配置文件是否已移除
replicaof行：grep replicaof /etc/redis/redis.conf应无输出 - 若使用 systemd 管理，确认
redis.service中未设置Environment=REDIS_CONF=...覆盖实际路径
哨兵模式下无法真正“主动平滑切流”
SENTINEL failover mymaster 不是平滑切换指令，而是强制模拟主节点宕机。它会触发主观下线（sdown）、投票、重配置、客户端重连全过程，期间写请求必然失败，延迟由 down-after-milliseconds 和网络稳定性决定。
- 哨兵只提供发现服务，不代理请求；客户端必须用支持哨兵自动刷新的连接池（如 Lettuce 的
RedisSentinelConfiguration） - 若只连单个哨兵地址，该哨兵挂了就查不到新主——必须配置多个哨兵 IP
- 应用层必须捕获
JedisConnectionException或RedisCommandTimeoutException并实现重试/降级，不能依赖哨兵“兜底”
最易被忽略的点：切流前没验证 min-replicas-to-write 和 min-replicas-max-lag 是否生效。这两个参数决定了主节点在从库延迟过大时是否拒绝写入——如果没配，切换瞬间可能把数据写到尚未同步完成的新主上，造成脏读或丢失。
