直接停掉从节点进程会丢数据或触发误判；需先禁用复制连接、执行slaveof no one、通知哨兵重置并确认移除，再安全shutdown，避免kill-9。

直接停掉从节点进程会丢数据或触发误判

Redis 5.0 的从节点（replica）本身不参与写操作，但若在主从同步中被强制 kill 或未通知哨兵就下线，会导致两个风险：一是主节点的 repl_backlog 缓冲区可能被后续 replica 消费失败；二是哨兵（Sentinel）检测到该 replica 连接断开后，若配置不当，可能误判为主节点异常（尤其当 quorum 设置过低、且多个 replica 同时抖动时）。所以“优雅下线”核心是：让主节点和哨兵都明确知道这是计划内行为，而非故障。

先禁用 replica 的自动重连与同步行为

在目标从节点上执行以下命令，避免它在下线过程中反复尝试连接已计划下线的主节点（或被误认为失联）：

• CONFIG SET repl-disable-tcp-nodelay yes（可选，降低重连敏感度）
• CLIENT KILL TYPE replica（主动断开所有复制连接，包括对主节点的 sync 请求）
• DEBUG RELOAD（慎用！仅用于测试环境快速清空状态；生产环境跳过）
• 最关键的一步：CONFIG SET slave-serve-stale-data no，再立即执行 SLAVEOF NO ONE —— 这会让该节点停止作为 replica，也不再响应客户端读请求，避免脏读

通知哨兵并确认其不再将其纳入判断

如果集群使用了 Redis Sentinel，需确保哨兵不会因该 replica 下线而发起无谓的故障转移投票。操作顺序必须是：

Redis Skill - 高性能缓存管理

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

下载

• 先在哨兵节点上执行：SENTINEL RESET <master-name></master-name>（刷新哨兵对主节点的 replica 列表缓存）
• 再检查哨兵日志或运行：SENTINEL REPLICAS <master-name></master-name>，确认目标节点已不在返回列表中
• 若仍存在，等待 sentinel monitor 配置中的 down-after-milliseconds 超时（默认 30000ms），或手动触发一次 SENTINEL CKQUORUM <master-name></master-name> 验证法定票数是否仍满足

注意：SENTINEL FAILOVER 不可用于下线 replica，它只针对主节点强制触发切换，对 replica 无效且会报错 NOGOODSLAVE。

最后 shutdown 从节点服务

确认以上步骤完成后，再执行标准关闭流程：

• 在从节点机器上运行：redis-cli -p <port> shutdown</port>（推荐带 save 参数，如 shutdown save，确保 RDB 持久化完成）
• 若使用 systemd，可用：systemctl stop redis@<instance-name></instance-name>（取决于你的实例管理方式）
• 切勿直接 kill -9 进程，否则可能丢失最后几秒的 AOF 缓冲或导致 RDB 文件损坏

真正容易被忽略的是：很多团队只做了 SLAVEOF NO ONE 就以为万事大吉，结果哨兵仍在后台计数该节点的“主观下线”次数，直到超时才清理元数据——这期间一旦主节点真出问题，哨兵可能因法定人数不足而无法完成故障转移。