Redis主从备份怎么检测才靠谱，实操经验分享和一些坑提醒

光看info replication远远不够，得会看门道

很多人检测主从状态，第一步就是连上主节点或者从节点，执行info replication命令，这个方向是对的，但很多人只看role和slave0这几个显眼的字段，觉得role:master下面挂了slave0就万事大吉了,这其实是个大坑。

你得重点看这几个关键指标：

1. slave0:ip=...,port=...,state=...,offset=...,lag=... 这一行里的state和lag。 state必须要是online，如果是sync或者wait_bgsave，说明正在做全量同步，这时候数据是不一致的。lag表示从库落后主库的秒数。（来源：实际故障排查经验） 理想情况下lag应该是0或者1，如果lag值持续很高（比如几十上百），那就有问题了，可能是网络瓶颈或者从库机器负载太高,数据同步根本追不上。

2. 主从双方的master_repl_offset。 在主节点和从节点上分别执行info replication，对比两者的master_repl_offset值，这个值代表复制的进度，如果两个值相等，或者非常接近（在低写入量时），才能说明数据是实时同步的，如果从库的offset远小于主库，且不再增长，那说明复制链路可能已经断了，即使state还显示online（一种假死状态）。（来源：Redis官方文档解读及实践验证）

   

一定要做数据一致性校验，这是终极手段

info replication只是看了个“表面健康”，就像医生说你的心跳呼吸正常，但没说你内脏有没有问题，最靠谱的检测,是直接检查主从库里的数据是否完全一致。

早期我们用的是redis-check-aof工具，但操作麻烦而且有风险，后来官方提供了redis-cli --cluster check命令,但它主要针对集群模式。

在实际生产中，我们采用了一种更直接的方法：使用redis-cli的--slave模式模拟一个从库。 具体命令是：

redis-cli -h <主库IP> -p <端口> -a <密码> --slave

这个命令会让你临时成为一个“从库”，主库会把你当成一个新的slave，开始给你推送所有的数据更新命令，你可以在终端上看到实时的数据流。（来源：社区运维高手分享） 这样做有两个好处：一是能最真实地感受到主库是否在正常推送数据；二是可以观察在你有业务写入时，这个数据流是否持续不断，如果数据流中断，或者出现错误信息,那复制肯定有问题。

但这个方法只能定性检查，不能定量，想要精确知道数据是否一致，可以使用一些开源工具，比如redis-full-check（阿里云开源的工具），它能对主从两个实例进行键对键、值对值的全量对比，并给出报告。注意：这个操作非常消耗资源，一定要在业务低峰期做，否则可能把数据库拖垮。 （来源：生产环境踩坑教训）

模拟故障切换，看应用端表现

上面说的都是在数据库层面的检测，但备份的最终目的是为了能用，最最靠谱的检测，是定期做真实的故障切换演练。

找个业务低峰期（比如深夜），按照预案，手动把从库提升为主库（使用slaveof no one命令），然后把应用的连接地址指向新的主库。（来源：高可用架构要求）

这个过程能暴露出很多问题：

• 从库提升为主库的速度有多快？ 如果数据量很大，slaveof no one命令可能会有一个短暂的阻塞。
• 应用端能否无缝切换？ 应用连接池会不会报错？有没有重连机制？会不会出现大量业务失败？
• 你的监控系统能否及时告警？ 切换过程中,监控大盘能不能正确显示新的拓扑关系？

只有经过真实切换的检验，你才能说你的备份方案是靠谱的，我们曾经就遇到过，从库info replication一切正常，但一切换就失败，后来发现是某个持久化配置项主从不一致导致的。（来源：一次惊心动魄的演练故障）

一些常见的坑提醒

1. 密码和配置一致性坑： 主库设置了密码requirepass，从库的配置masterauth必须配成一样的，主从的maxmemory政策最好也一致,否则可能导致从库内存先写满被淘汰。
2. 版本不一致坑： 主从Redis版本最好一致，或者从库版本略高于主库，低版本的从库可能无法兼容高版本主库的某些命令,导致复制中断。
3. 磁盘空间坑： 主库做RDB快照传输给从库时，如果从库磁盘空间不足，整个同步过程会失败，而且不会自己恢复,需要人工干预。
4. 网络带宽坑： 如果主库写入量巨大，而主从之间的网络带宽不足，就会导致lag值一直很高，从库永远在追赶,永远处于不一致的状态。
5. 忽视只读模式坑： 默认情况下，从库是只读的，有些应用误操作直接往从库写数据，会导致主从数据彻底不一致,且很难发现。

别偷懒，检测主从备份不能只跑一个命令就完事，要多层次检查：先看info replication的关键指标，再定期做数据一致性校验，最后一定要通过真实的故障切换演练来检验整个链条（从数据库到应用）的健壮性，把这件事当成一个常规运维流程固定下来,才能真正睡个安稳觉。