从库宕机后能自动恢复，是因为Redis主从复制协议自身具备重试机制：从库重启后，若配置了正确的slaveof或通过哨兵动态获取主节点地址，便会主动发起连接与同步；哨兵不负责该过程，仅监控与故障转移。
从库宕机后无需人工干预，只要配置正确、网络通，它自己就能重新加入主从复制；但修复后必须确认同步状态，否则可能读到脏数据。
从库宕机后为什么能自动恢复？
哨兵本身不负责从库的自动重连，真正起作用的是 Redis 主从复制协议自身的重试机制。只要从库进程重启、配置里 slaveof 指向正确的主节点地址（或通过 sentinel get-master-addr-by-name 动态获取），它就会主动发起连接和同步。
- 从库启动时若配置了
slaveof master-ip master-port，会立即尝试连接并同步 - 如果使用哨兵模式，客户端应通过
sentinel get-master-addr-by-name获取当前主节点，再让从库指向该地址（避免硬编码） - 从库日志中出现
Connecting to MASTER和MASTER REPLICA sync started表示同步已触发 - 注意：若主库开启了
requirepass，从库配置中必须设置masterauth，否则同步失败且无明显报错
修复从库前必须检查的 3 个关键点
盲目重启从库可能导致全量同步（slowlog 明显变长、主库 CPU 突增、网络打满），甚至因配置错误变成孤立节点。
- 确认主库是否健康：用
redis-cli -h master-ip -p master-port ping测试连通性，再查info replication中connected_slaves数量是否异常减少 - 核对从库配置文件中的
slaveof是否仍指向旧主（比如故障前的 IP/端口），尤其在发生过故障转移后，主节点可能已变更 - 检查从库本地
redis.conf是否启用了slave-read-only yes（推荐保持开启），防止误写入导致主从不一致
重启后如何验证同步是否真正生效？
光看 INFO replication 显示 master_link_status:up 不够，得确认数据一致性。
- 在从库执行
INFO replication，重点看master_sync_in_progress:0（表示同步完成）、slave_repl_offset接近主库的master_repl_offset - 对比主从库的
redis-cli info keyspace，检查各 db 的 key 数量是否基本一致（允许短暂延迟） - 用
redis-cli --rdb /dev/stdout | sha256sum分别导出主从 RDB 快照做哈希比对（仅限小数据量场景，生产慎用） - 若发现
slave_read_only:0或从库有写操作，立刻排查是否有应用直连从库并误写 —— 这是常见脏数据源头
最容易被忽略的是：从库重启后即使同步成功，如果应用层没做读写分离路由更新（比如还在用旧的 DNS 或配置缓存），请求可能继续打到已下线的节点，或者绕过哨兵直连旧地址。务必确保客户端使用哨兵 API 获取主节点，而不是写死连接串。
