适用范围与演练前提
本文是「Redis Sentinel 高可用」场景的上线检查单，针对已有主从复制、使用 Sentinel 感知客户端的非分片 Redis。先在隔离测试环境完成演练，再依据本环境变更流程安排业务窗口。准备实例清单、主组名、故障域说明、备份恢复方法、业务探针和停止标准。本文未宣称任何演练已经执行或达到可用性指标。
保存上线前的状态
在每个 Redis 节点记录角色、复制链路与持久化状态。大写字符串均为占位符；端口、认证与 TLS 选项需要按部署替换，不把密码写入共享命令记录。
redis-cli -h REPLACE_WITH_REDIS_HOST -p 6379 INFO replication
redis-cli -h REPLACE_WITH_REDIS_HOST -p 6379 INFO persistence检查副本 master_link_status、同步是否进行中，以及在同一复制历史下的 offset 差距趋势。确认角色符合拓扑、持久化错误已处理，并留出重新同步的资源余量。不能仅通过 PING 判断候选可接管业务；INFO 字段定义见文末官方资料。
验证 Sentinel 发现和仲裁条件
在每个 Sentinel 上核对同一主组的视图：
redis-cli -h REPLACE_WITH_SENTINEL_HOST -p 26379 SENTINEL MASTER REPLACE_WITH_MASTER_NAME
redis-cli -h REPLACE_WITH_SENTINEL_HOST -p 26379 SENTINEL REPLICAS REPLACE_WITH_MASTER_NAME
redis-cli -h REPLACE_WITH_SENTINEL_HOST -p 26379 SENTINEL CKQUORUM REPLACE_WITH_MASTER_NAME对比主地址、已发现副本、Sentinel 数量和异常标志。CKQUORUM 用于检查当前视图能否满足 quorum 与多数授权条件；单节点返回正常仍需结合其他节点的视图和实际网络路径。主组名拼写、通告地址或认证有差异时，先修正再继续。
从应用侧完成接入检查
验证每类应用使用多个 Sentinel 地址，能够连接发现得到的候选节点，并能在断连后重建连接池。准备独立测试键空间及请求标识，在演练窗口使用经授权的业务探针记录写后读、超时和重试行为。上线记录中分别填写 Sentinel 发现耗时与应用恢复耗时，避免只观察控制平面的切换事件。
对长连接服务、短任务和后台定时任务分别采样；不同客户端库的重试行为可能不同。提前确定测试数据的清理责任和保留期限，让探针结果可以复核，又不混入业务统计。
每次注入一种可恢复故障
按测试计划依次验证单个 Sentinel 暂停、主 Redis 进程停止及受控网络隔离，每轮先恢复稳定基线再进行下一轮。网络隔离需要明确影响方向和撤销方法，避免同时切断管理通道。观察候选提升、各 Sentinel 主地址收敛、应用重连及旧主恢复后的角色。
手动 SENTINEL FAILOVER 会强制发起切换，不等价于验证自动故障检测和多数授权路径；若单独使用它测试操作链路，应在报告中明确这一限制，不能以此替代网络分区测试。
验收、停止与恢复
验收需确认业务入口指向唯一有效写主，副本重新跟随、告警恢复且测试记录可以核对。检查超时重试是否导致重复业务效果，并填写实际数据偏差和中断时间。旧主回来后先确认其复制角色与追赶状态，不立即重新指向它。
若出现双侧持续写入、复制无法恢复、客户端固定旧地址或超出预设中断窗口，停止后续故障注入，撤销当前网络或进程故障并保持受控写入口。已经发生新写入后，回切必须先处理数据同步与分歧；恢复旧配置并不自动恢复数据一致性。