设为首页 收藏本站
查看: 1003|回复: 0

[经验分享] codis迁移槽位遇到value过大的数据导致redis进程堵塞问题

[复制链接]

尚未签到

发表于 2018-11-4 11:06:15 | 显示全部楼层 |阅读模式
  codis迁移槽位遇到value过大的数据导致redis进程堵塞问题
  问题背景:
  2016-11-08 下午,咨询codis开始迁移槽位。迁移过程中dba发现group1中redis无法连接,proxy进程异常退出且无法重启。
  当redis可以正常连接时dashboard展示为:

  而问题发生时此redis是不可连接的,Keys无法显示正确显示,只显示Nan。
  proxy进程异常退出会收到微信报警:
  [('NoneType' object has no attribute '__getitem__')10.20.4.1:19153(KDDI)](codis_proxy) [r_connection],threshold: 1,current:0,last:1 minutes.,info:failed [2016-11-08 15:32:35]
  处理方案:
  1.将备用proxy 服务器加入域名,待生效后移除异常proxy的域名。
  2.排查dashboard日志,问题如下:



  从日志可以看出迁移过程中slot_359迁移完成,solt_360迁移过程中报错,报错显示redis读取超时,持续一段时间后迁移任务报错([info] migration start: {SlotId:360 NewGroupId:4 Delay:1 CreateAt:1478588644 Percent:0 Status:error>  3.手动取消迁移任务
  登录zookeeper:/usr/local/xywy/zookeeper-3.4.6/bin/zkCli.sh -server 10.20.4.1:2181
  rmr /zk/codis/db_techzixun/migrate_tasks/0000003317
  4.重启proxy进程
  如果无法重启,那么说明取消迁移任务时可能影响了槽位的状态。排查日志可以看到报错为:


  从日志中可以看出槽位状态为pre_migrate。调整为online即可。
  调整方法:
  登录zookeeper后
  查看对应槽位的值:get /zk/codis/db_techzixun/slots/slot_392
  修改status为online:set /zk/codis/db_techzixun/slots/slot_392 {"product_name":"techzixun","id":392,"group_id":1,"state":{"status":"online","migrate_status":{"from":-1,"to":-1},"last_op_ts":"0"}}
  所有槽位状态都为online时即可重启proxy
  5.重启proxy后将其加入域名,此时故障已恢复
  后续排查:
  以上步骤为处理故障的操作,但迁移为什么出错,想要究其原因还需进一步排查。
  查看group1中报错redis的日志,问题如下:
  [113248] 08 Nov 15:16:20.764 # slotsmgrt: writing to target 10.20.2.4:6916, error 'accept: Resource temporarily unavailable', nkeys = 1, onekey = 'jbzt_nk_20219_arclist', cmd.len = 1418791367, pos = 65536, towrite = 65536
  使用redis命令扫描大key:
  redis-cli -p xxxx -h xxxx --bigkeys
  发现'jbzt_nk_20219_arclist'这个list容量达到3G左右
  由此可见问题的原因是迁移value过的的key或list导致
  解决方案:
  该问题为codis程序问题,在codis中暂时无法使用技术手段解决。只能对这种value过大的key或list进行压缩或者选择其他使用方式。
  遗留问题:
  问题描述:
  codis迁移槽位过程中出错时会导致槽位状态一直为迁移中,槽位状态为迁移中proxy不能上线,所以手动将槽位状态修改为上线。但此时未迁移成功的key路由信息还记录为迁移前group,而迁移前槽位的group信息已更新为迁移后的group,这就导致了查找未成功迁移的key时会无法连接的错误。
  解决方法:
  将无法连接的key所在槽位迁移至原所属group即可。查找key时可以通过proxy.log观察确认路由到哪个ip端口下从而确定原所属group,利用python下binascii.crc32算法 binascii.crc32('key_name')%1024 计算key所在槽位。
  举例说明:
  codis中有2个group。分别为group1,group2。group1中100槽位中有1,2,3,4,5,6。6个key,group2中没有key,此时将group1中100槽位迁移至group2中,迁移过程中1、2、3key已成功迁移4key由于value过大导致迁移出错,此时100槽位所属group2,槽位状态为迁移中,手动删除迁移任务将100槽位状态修改为上线后,连接proxy查找4、5、6key则出现无法连接错误。原因就是4、5、6key的的路由信息还是group1中的100槽位,但此时100槽位已经不在group1下了,那么将100槽位迁移回group1下即可解决。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-630584-1-1.html 上篇帖子: redis主从复制同步数据死循环问题 下篇帖子: Linux下Redis3.2的安装和部署
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表