min-slaves-to-write 是主从切换丢数据时首要排查项，它控制主节点在合格从节点不足时拒绝写入，但需配合 min-slaves-max-lag 和真实复制状态（state=online、lag≤阈值）才生效。
Redis主从切换后数据丢失，先看 min-slaves-to-write 是否生效
主从切换后丢数据，min-slaves-to-write 是第一个该查的配置项。它不保证“绝对不丢”，但能阻止写请求在从节点不可用时继续落盘——这是多数人为疏忽导致丢数据的起点。
检查方式很简单：redis-cli CONFIG GET min-slaves-to-write。如果返回 min-slaves-to-write 和 0，说明该机制完全没启用；若返回非零值（比如 1），还得继续确认 min-slaves-max-lag 是否合理、从节点是否真被主节点识别为“在线”。
-
min-slaves-to-write 1搭配min-slaves-max-lag 10，表示至少要有 1 个从节点复制延迟 ≤10 秒，主节点才接受写入 - 从节点必须处于
online状态（redis-cli INFO replication中slaveX:ip=...,state=online），断连或握手失败的从节点不计入计数 - 这个配置只影响主节点的写命令（
SET、INCR等），不影响DEL或EXPIRE等操作
为什么 min-slaves-to-write 明明设了却没拦住写入
常见原因是主节点压根没把从节点当“合格从库”。不是配置没加载，而是复制状态未达标。
执行 redis-cli INFO replication，重点关注这几项：
-
connected_slaves：显示当前连接数，但不等于“可用数” - 每个
slaveX...行里的state=online和lag=3（单位秒）才是关键 - 如果
lag超过min-slaves-max-lag，该从节点会被排除在合格列表外，即使connected_slaves是 2，实际计数可能为 0 - 从节点重启后首次同步期间（
state=sync）也不参与计数
主从切换时的写丢失真实路径还原
典型丢数据链路不是“主挂了就丢”，而是“主还没挂，但从全掉线 → 主继续写 → 切换新主时旧主数据未同步 → 旧主降级成从后被清空”。
排查时盯紧时间点和日志：
- 查主节点
redis.log，搜索"Writing to master disabled"—— 这是min-slaves-to-write触发拒绝写的标志；没这句，说明写一直畅通，风险已埋下 - 查哨兵日志（
sentinel.log），找"+odown"和"+switch-master"时间戳，对比主节点最后一次INFO replication中master_repl_offset和新主的slave_repl_offset - 如果新主的
slave_repl_offset明显小于旧主挂前的master_repl_offset，说明有写入没传过去
配置生效但仍有丢数据？检查持久化与故障窗口
min-slaves-to-write 只管“写入门槛”，不管“写入后是否落盘”。如果主节点用的是 RDB + save ""（即关闭持久化），又在写入后、同步前崩溃，照样丢。
真正抗切换丢数据，得组合使用：
- 开启
AOF并设appendfsync everysec（平衡性能与安全性） - 禁用
save命令自动触发（save ""），避免 fork 阻塞干扰复制 - 确保
repl-backlog-size足够大（默认 1MB 太小），防止从节点重连时因缓冲区溢出而触发全量同步 - 哨兵的
quorum和down-after-milliseconds要匹配业务容忍度，过短易误切，过长则故障窗口拉长
最常被忽略的一点：min-slaves-to-write 不防网络分区。当主节点被孤立（如机房断网），它仍认为自己是主，继续写，且因无从可连而放行所有写入——这时丢数据是设计使然，不是配置错了。
