您好,登錄后才能下訂單哦!
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 Id:0000003317})
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下即可解決。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。