合理设置redis主从buffer





已迁移至掘金社区合理设置redis主从buffer

背景

某次抢购时,一个redis集群的某个分片,从实例响应时间陡增到几十秒,报警后运维将其中一个本应该下线的slave下掉,问题减轻但没有解决,又把另一个正常的slave下线掉,问题消失。

master日志

09:59:11.842 # Client id=19768058 addr=xx.xxx.xx.xx:46599 fd=7 name= age=235951 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=10581 omem=268636408 events=rw cmd=replconf scheduled to be closed ASAP for overcoming of output buffer limits.

09:59:11.851 # Client id=19770026 addr=xx.xxx.xx.x:64139 fd=6 name= age=208571 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=10581 omem=268636408 events=rw cmd=replconf scheduled to be closed ASAP for overcoming of output buffer limits.

09:59:11.863 # Connection with slave xx.xxx.xx.x:xxxx lost.

09:59:11.878 # Connection with slave xx.xxx.xx.x:xxxx lost.

slave日志

09:59:11.866 # Connection with master lost.

09:59:43.057 # I/O error trying to sync with MASTER: connection lost

10:00:17.720 # I/O error trying to sync with MASTER: connection lost

10:00:48.585 # I/O error trying to sync with MASTER: connection lost

10:01:20.326 # I/O error trying to sync with MASTER: connection lost

过程描述

两个slave的日志是一样的,所以只摘取了其中一个。

通过master日志可以看出是master因为slave client buffer达到上限,主动关闭了连接,master当时的cpu达到100%,且不断进行bgsave操作,慢日志里有很多psync命令。

从slave日志来看,master连接被断开,然后slave不断进行连接建立和数据拷贝。

过程分析

通过grafana监控发现该业务的写流量第一次达到123MB,但是client-output-buffer-limit slave 256mb 64mb 60,所以主在流量超过60mb之后会将主动将slave连接关闭,这时候从通过psync命令请求数据同步,但是repl-backlog-size 64mb,此时按照现有的流量,增量同步需要的数据已经不在复制缓冲区里面了,master会进行全量复制,全量复制成功后,slave阻塞式加载rdb数据。

以上过程是一个循环,不断重复,导致从实例基本不能响应读请求(时间基本在30s),主实例受影响并不大,这也是为什么摘除从实例可以减轻甚至恢复问题的原因。

建议

对于写流量比较大的业务,主从复制有关的buffer包括repl-backlog-size、client-output-buffer-limit slave可以调成峰值流量的两倍甚至同普通客户端buffer一样不做限制。

你可能感兴趣的