百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

Posted 百度QA

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》相关的知识,希望对你有一定的参考价值。

在百度质量部,QA的看家本领之一就是发现问题、定位问题、推动问题的妥善修复。本期《金BUG》专辑汇总了几例BUG发现分析解决的案例,欢迎各路英雄关注并讨论


一、背景

2015.7.31 某网段的TOR故障一小时,网络故障恢复后,redis 多个从主从同步异常:除slave0外,其他slave的offset均比master大。


注:redis的主从之间通过offset进行增量同步,即从向主发送它当前存储数据的offset,主将这个offset之后的增量数据同步给从,以保证主从数据一致。然而线上出现从的offset比主大,说明主从同步的逻辑存在问题。


二、问题影响

Redis主从同步分三种:

  1. 全量同步(主从首次连接或者增量同步失败) —— redis主dump出所有的数据发给从;

  2. 增量同步(主从连接瞬断)—— redis主将slave发送的offset之后的数据发给从;

  3. 长连接同步(正常情况) —— redis主从维护一个长连接,redis主将所有写请求发给从;


该问题只会影响redis主和从的增量同步,即网络瞬断时会影响同步,影响分为两种:

  1. 发生问题后,进行增量同步时从的offset比主大:增量同步失败,进行全量同步,对redis从中的数据不影响;

  2. 发生问题后,进行增量同步时从的offset比主小(出现问题时从的offset比主大,但是随着主写入数据,offset可能会超过从):主从增量同步异常,从中的数据比主少。


三、Bug定位

  • 异常原因

由问题背景可看出bug由从的replica_offset引起,分析代码中会修改从的offset的逻辑:


  • 初始化:从的offset是在向主请求增量同步失败后由主返回:百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

  • 从接受到”+FULLRESYNC”响应后,更新offset:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

  • Offset更新:全量同步完成后,主从长连接正常同步时,每次请求offset均自增:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

结合offset初始化和更新的代码逻辑,可以推断offset异常由主从全量同步引起,原因如下:

  1. 如背景所述,发生问题时主从连接断开,无法进行正常同步,因此不存在正常同步导致offset异常;

  2. 正常同步中offset只会比主少,不会比主多。


  • 源码分析


分析redis主处理增量同步的代码逻辑,画出简化的流程图如下:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

抽出master返回offset逻辑如下:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

Master会先设置psync_offset(要发给从的offset)为master当前的offset,然后判断是否有在做bgsave操作,如果已经有从在做bgsave,则复制已经在做bgsave的从的outputbuffer(这个buffer会作为dump同步完后的新增数据发送给从)——至此,问题已出现:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

当第一个从进行全量同步时,主将它当前的offseto1返回给从,并且开始做bgsave同时将新增的写请求数据写入第一个从的repl_buffer中,同步完dump数据后,从repl_buffer中发送增量数据,此时o1+增量数据刚好等于master的offset;而在第一个从的bgsave未完成时,若第一个从申请全量同步,则主返回它当前的offset o2(必然比o1大),判断到slave1已在做bgsave,此时不再做bgsave,直接复制s1的repl_buffer到s2的repl_buffer中,并且master新增的数据也开始写到s2的repl_buffer中,同步完dump数据后,从repl_buffer发送增量数据并同步offset。

注意:

  1. 此时s1和s2的增量数据完全相同;

  2. o2 > o1;

  3. o1 + 增量数据 = master的offset;

因此从2的offset比主大。


四、问题修复

确定问题后,RD对代码进行了修复:需要做全量同步时,master不再返回当前的offset,而是返回首次做bgsave时保存的offset:

百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》

缓存server.fullsync_repl_offset,每次全量同步时返回同样的offset。


五、测试

问题已修复,需要回归测试,测试做CR时仔细核对主从同步过程,发现有如下逻辑:


若第一个从申请全量同步时,主已经在做bgsave(请注意,这里的bgsave是主自动触发的),这时会将从的offset标记为主当前的,并且标记从为WAIT_BGSAVE_START,等待bgsave结束后再次开启bgsave,而这时从的offset比主小。


六、新的问题

这种情况下,若主已在做bgsave:

  1. 从请求做全量同步,则主会返回从一个offset o1,并且标记从为WAIT_BGSAVE_START;

  2. 等bgsave结束后再次开启bgsave,记此时主的offset为o2,并将主的增量数据写到从的buffer中;

  3. 同步完dump的数据后同步增量数据,此时主的offset为o2+增量数据,而从的offset为o1+增量数据;

  4. 显然,o1<o2,这就造成同样的数据,从的offset比主小。


事实上,这个问题若出现,将比上一个问题影响更大:从的offset比主小,只要网络瞬断,则从的数据必然异常,并且会重复写一部分数据(o2-o1对应的数据段),造成线上主从数据不一致。


七、修复方案

可幸的是,在我们发现第二个问题后,redis官方给出了这一系列问题的解决方法:https://github.com/antirez/redis/commit/bea1259190a9f3c3850b074ef7d0af0bc3ea36a7

官方的解决方法为:从申请做全量同步时,不再立即返回主的offset,而是放在buffer中作为增量数据发送。


八、总结

这个bug算是隐藏很深的一个超大bug了,在作者修复前,开源社区使用redis的公司应该都或多或少的受到了这个问题的影响。

目前来看,底层服务的这种bug很难发现:

  1. 功能测试实在无法覆盖层出不穷的异常场景,redis开源社区已有的自动化case数已达200多项,然而这个bug还是隐藏了很久;

  2. QA和RD没有足够的精力去CR整个服务的代码。


测试中应注意的问题


  1. 测试应加大CR力度,对代码足够了解才能写出足够完善的case;

  2. CR时应尽可能分析代码的所有逻辑,避免出现特殊情况;对QA来说,CR不只是阅读代码逻辑,也要检查代码逻辑的问题——CR代码时尽量画出一个流程图(至少大脑里要有一个),之后分析代码逻辑:

    1. 检查各个变量的初始化及调用位置,判断是否会有脏值;

    2. 检查动态内存的申请和释放位置,判断是否会内存泄漏或者使用野指针;

    3. 检查代码分支,不同的分支是否能做正确的响应;


问题定位应注意的问题:

  1. 分析bug产生的原因,尽可能详细到变量或者函数;

  2. 阅读代码逻辑,查看变量/函数的初始化位置/调用位置或改变位置;

  3. 分析变量/函数出错可能的原因,检查对应的代码逻辑;




以上是关于百度QA金BUG集锦之《Redis主从同步失败案例的步步深入》的主要内容,如果未能解决你的问题,请参考以下文章

Redis主从之全量复制和增量复制

记一次redis主从同步失败

redis主从复制入门案例

Redis高可用架构之主从同步

redis主从同步

Redis主从同步之主库挂死解决方案