维护redis时的异常处理

现象一:

昨天DBA反应线上存在某个redis slave 状态为down,反复重启无效

观察slave日志:

1

发现出现多次全同步,并且报出connect lost同步失败。

Master日志没有任何记录。

原因分析:

根据netstat显示的slave未出现timewait状态,判断是master主动关闭了连接

而master只有在缓冲区达到限制(默认的参数client-output-buffer-limit 256mb 64mb 60)后才会主动关闭连接。

原因是slave接受到master发送的rdb全量文件后,疯狂的往内存加载,此时slave会阻塞。

然后因为业务的change key频繁达到bgsave的触发瓶颈,master又进行数据增量同步,这些数据会放在client output buffer缓冲区内等待TCP发送

当这个缓冲区在60秒内有64MB大小,或者一下达到256MB,就会使得master立刻关闭该连接。

这是redis的自我保护机制。

应对方式:

平时可以在master执行 redis-cli client list指令,找那个cmd=sync,flag=S的client,注意OMem的变化。比这个值略大一些,来设置非常规情况的参数。

2

昨天晚上使用了config set参数将默认的slave 256mb 64mb 60改为512mb 256mb 300,而后重启slave进行观察

现象二:

3

同步成功

然而此时抛出第二个错误,no data nor PING received,而后居然又重新同步了。

原因分析:

昨天晚上也没想明白,后来操作fastdfs迁移也没空想了,直到刚才看了下代码

原来slave会每隔repl-ping-slave-period(默认10秒)ping master,如果超过repl-timeout(默认60秒)都没有响应,就会判定Master宕机。

如Master没挂但被阻塞住了也会报这个错。而后重连master。所以DBA会莫名其妙的发现slave老是进行全量同步。

应对方式:

此时可以通过config set指令在线适当调大repl-timeout。

未完待续