哨兵常见问题
哨兵体系最常见的问题可以归成四类：多哨兵之间的配置漂移、网络分区下的双主（脑裂）、抖动导致的误切换，以及客户端不跟着切换地址。前三类要靠合理的超时、票数与写保护来预防，最后一类要靠客户端实现地址发现。预防永远比补救划算，因为脑裂一旦发生，两边的写入必然有一边要丢。
基本信息
| 配置漂移 | 各哨兵记录的纪元与配置不一致，判定行为随之不同 |
|---|---|
| 脑裂 | 旧主仍可写，集群出现双主 |
| 误切换 | 网络抖动触发本不必要的故障转移 |
| 客户端不切 | 应用仍然连接旧主地址 |
| 缓解手段 | 写保护参数与合理的超时配置 |
典型使用场景
- 切换之后发现两边的数据对不上
- 哨兵状态看起来正常但服务行为异常
- 网络抖动后出现频繁切换
- 排查应用往旧库写入的问题
- 多机房部署下的网络分区演练
写保护配置片段
写保护配置片段
min-replicas-to-write 1
min-replicas-max-lag 10
# 健康从库不足或延迟过大时直接拒绝写入
# 宁可短期不可写，也不产生双主数据问题与处置
| 问题 | 现象 | 处置方向 |
|---|---|---|
| 配置漂移 | 各哨兵的纪元与配置不一致 | 统一模板与版本，必要时重置哨兵认知 |
| 脑裂 | 旧主仍被写入，出现双主 | 用写保护限制旧主，分区恢复后人工核对 |
| 误切换 | 抖动引发频繁故障转移 | 调大判定与切换的超时参数 |
| 客户端不切 | 应用仍连旧主地址 | 客户端重新发现并订阅切换事件 |
| 哨兵失联 | 发现到的其它哨兵数为 0 | 检查网络、端口与对外地址配置 |
脑裂一旦发生，恢复后两边的写入必然有一边要丢：只能人为选择以哪份数据为准，所以预防（合理的超时、票数与写保护）远比事后补救重要。
修改参数时务必同时改所有哨兵：只改一台会让判定行为不一致，出现「有的哨兵认为下线、有的认为正常」这种极难排查的状态。
写保护要在业务侧知情的前提下启用：它用可用性换取一致性，主库被隔离时会拒绝写入，应用必须能处理这种短期的不可写状态。