Redis trouble14 -- signal-handler (1619081683) Received SIGTERM scheduling shutdown...

一、问题描述

异常1:
主从中断报错 
Unable to partial resync with the slave for lack of backlog (Slave request was: 2595405802583).

异常2:
Discarding previously cached master state

异常3:
1:signal-handler (1619081683) Received SIGTERM scheduling shutdown...
1:S 22 Apr 2021 16:54:43.610 # User requested shutdown...
1:S 22 Apr 2021 16:54:43.610 # Redis is now ready to exit, bye bye...

 二、解决方案

1.先将主从状态恢复,再查找前边shutdown的问题
config set client-output-buffer-limit 'slave 0 0 0'
config set repl-timeout 1200 (默认是60s,日志上显示加载一次7分钟就断开了)
config set repl-backlog-size 10485760 (默认1048576 1M,设置这个是为了避免psync的时候大小不足)
2.shutdown问题
这个目前定位是jedis的版本问题,可以升级jedis版本到2.4.x以上或者是更换成lettuce,或重写close方法,或在destroymethod=""

三、问题分析

1.主从断开的问题

replication buffer由client-output-buffer-limit slave设置，当这个值太小会导致主从复制链接断开: 当master-slave复制连接断开，server端会释放连接相关的数据结构。replication buffer中的数据也就丢失了，主从之间重新开始复制。
还有更严重问题，主从复制连接断开，导致主从上出现rdb bgsave和rdb重传操作无限循环。
看起来确实server(这里就是master)会因为缓冲区的大小问题主动关闭客户端(slave)链接。因为我们的数据变更量太大，超过了client-output-buffer-limit。导致主从同步连接被断开，然后slave要求psync，但是由于repl-backlog-size太小，导致psync失败，需要full sync，而full sync需要Discarding previously cached master state，重新load RDB文件到内存，而这个加载数据过程是阻塞式的。所以导致slave出现间歇式的不可用。而切换到master之后，master的整个同步操作都是fork一个子进程进行的，所以不影响父进程继续服务。所有的现象都能清清楚楚的解释上。

2.关于shutdown的问题

下边的这篇文章给出了详细的解释:  https://cloud.tencent.com/developer/article/1422207