从库slave_read_only:1但数据为空，主因是未成功发起sync/psync，常因认证失败或网络不通；需检查masterauth、bind、protected-mode等配置，并验证连接与认证通路。
哨兵模式下从库显示 slave_read_only:1 但数据始终为空
这通常不是复制链路断开的表象，而是从库压根没成功发起 SYNC 或 PSYNC 请求——根本原因常藏在认证或连接层面。先确认从库日志里有没有反复出现 Unable to connect to MASTER: Connection refused 或 NOAUTH Authentication required。如果有，说明它连 master 的 TCP 连接都建立不了，更别说同步了。
重点检查三项：
-
masterauth是否配置在从库的redis.conf中（不是哨兵配置），且值与 master 的requirepass完全一致（注意空格、大小写） - master 是否启用了
bind且未包含从库所在网段（例如只绑了127.0.0.1） - master 的
protected-mode yes未被禁用时，若未配bind或requirepass，会拒绝所有外部连接——此时从库连不上是预期行为
哨兵自动故障转移后新主库无法被从库识别
哨兵把某个从库提升为新主后，老从库会尝试向它发起复制，但如果新主库没配 requirepass，而老从库的 masterauth 还保留着旧 master 的密码，就会卡在 Master does not understand PSYNC 或静默失败。
关键动作不是重启哨兵，而是立刻登录每个从库执行：
CONFIG SET masterauth "新主库的密码" SLAVEOF
再观察 INFO replication 中 master_link_status:up 和 master_last_io_seconds_ago 是否持续更新。如果仍失败，用 telnet 验证网络可达性，再用 redis-cli -h -p -a PING 确认认证通路。
哨兵日志报 +sdown master mymaster 10.0.1.5 6379 但从库一直连着旧 master
这不是同步问题，是哨兵自身发现机制失效。常见于哨兵节点间通信异常或 quorum 不足。检查每个哨兵进程的 sentinel.conf 是否都正确配置了 sentinel monitor mymaster 10.0.1.5 6379 2（最后一个数字必须 ≤ 哨兵总数且 ≥ ⌈N/2⌉+1）。
另外，哨兵默认每 30 秒向 master 发 INFO，若 master 响应超时（sentinel down-after-milliseconds mymaster 30000），才触发主观下线。如果你改小了这个值但没调低 sentinel failover-timeout，可能造成频繁误切。
验证哨兵视角一致性：
redis-cli -p 26379 SENTINEL masters redis-cli -p 26379 SENTINEL slaves mymaster
输出中若各哨兵对 flags（如 s_down、o_down）或 ip 字段不一致，说明它们没完成法定人数协商，故障转移不会发生。
从库能连上 master 但 repl_backlog_active 始终为 0
这意味着 master 根本没启用复制积压缓冲区——它只在配置了 repl-backlog-size 且至少有一个从库连接时才会分配内存。如果所有从库都因认证失败断连，master 就不会激活 backlog，后续哪怕修复了认证，新连上的从库也只能全量同步（SYNC），无法增量（PSYNC）。
解决方法：在 master 的 redis.conf 中显式设置
repl-backlog-size 1mb repl-backlog-ttl 3600
然后 CONFIG REWRITE 持久化，并重启 master 或执行 CONFIG SET repl-backlog-size 1mb。注意该缓冲区是环形的，过小会导致频繁全量同步；过大则浪费内存，一般按峰值写入量 × 期望容忍断连时间估算。
真正容易被忽略的是：即使配置了 repl-backlog-size，若 master 启动时没有任何从库连接，它也不会立即分配内存，要等第一个从库成功握手后才初始化。所以配置后务必确认 INFO replication 中 repl_backlog_active:1 已生效。
