当前位置: 首页 > redis, 分布式系统, 缓存系统 > 正文

redis 升级2.8.8经验

关键字:
1 星2 星3 星4 星5 星 (1 次投票, 评分: 2.00, 总分: 5)
Loading ... Loading ...
baidu_share

最近把实时标签5个redis实例全部升级到2.8.8版本,在这过程中主要遇到以下两个问题。

一:2.4.18到2.8.8主从复制失败,并且处于不断重试的过程中。

通过debug redis源码在测试环境复现该问题找到解决该问题的方法:根据dbsize的大小把repl-timeout调整为合理的值即可。

二:主从同步结束后发现slave中的key的数量比master少很多

按照线上redis数据规模和expire key数量在测试环境重演该问题,跟踪源码发现导致该问题的原因是在同步数据的过程中 master rdb的时候会把已经过期的key排除在外把非过期的key copy到slave,但master自己对于这些过期的key还是要等计划任务来判断超时和等到读key的时候判读超时,这样当redis中带过期时间的key比较多的时候,主从中的key的数量就会有比较大的差距。该问题通过咨询redis作者antirez得到了相同的结论。

升级2.8.8注意事项

Redis 2.8 中增量复制相关参数必须要根据具体业务做相应的调整,否则很可能不会起到增量复制的效果。

repl-backlog-ttl 900 该参数表示当master和slave断开后master为slave保存多长时间的数据,超过该时间段缓冲区会被释放。

repl-backlog-size 1mb该参数表示 master为slave保存多大的数据,超过这个大小后也会导致全量复制。
该参数默认值是1mb 对于大部分业务来说太小了必须要修改。

client-output-buffer-limitslave 256mb 64mb 60 该参数表示为slave保留的缓冲区大小超过阈值后强制断开,在2.4版本该值是没有限制的
但是在2.8.8有了默认值根据实验结果在做主从同步的时候,如果master短时间写入量比较大也会导致同步失败。建议取消该限制。

发现redis的bug

继上次发现redis 2.4版本key过期时间设置过长(如in32.max)导致slave中丢数据之后,又发现redis的slave过期策略的bug。

在当前所有redis版本中,在slave中会出现读到已经过期的key的现象。特别是用redis做读写分离的业务,当redis实例中含有大量带过期时间的key
的时候,在slave上面很可能读到几分钟,几个小时甚至几天前就已经过期的key。

导致该问题的原因是 slave不做任何过期策略全部依赖master来实现过期,然而master中是靠定时随机选key判读过期+读取key的时候判读过期。
如果对master只做写操作会大大加重slave读取到已经过期数据的可能性,redis不对执行判读key过期操作作保底策略。

针对该bug我在github提了个issues链接地址https://github.com/antirez/redis/issues/1766
该bug已经得到redis作者antirez的确认,作者就该问题提出了可能的解决方案见https://github.com/antirez/redis/issues/1768
估计会在后续版本中修复该问题。

针对该问题,做具体业务的时候,一定不能靠从slave中能否读取到数据判读业务开始和终止情况,要在key的value里面增加岂止时间参数。

本文固定链接: http://www.chepoo.com/redis-upgrade-2-8-8-experience.html | IT技术精华网

redis 升级2.8.8经验:等您坐沙发呢!

发表评论