本文介绍: 经过一系列的排查未发现 redis 及内存方面的原因导致这种情况出现，最后describe pod 的时候发现存活性检测失败的问题，进一步排查发现从库在 Flushing old data 的时候会阻塞那个存活性检测脚本，导致失败，然后 kill 掉 pod，固日志中会有 Received SIGTERM scheduling shutdown 这个信号。将 livenessProbe 中 timeoutSeconds 调大即可。从报错可知，是开启了无盘复制参数 repl-diskless–sync。
环境
主从报错日志
1:M 29 Nov 2023 07:00:19.277 # Diskless rdb transfer, done reading from pipe, 1 replicas still up.
1:M 29 Nov 2023 07:00:20.058 * Background RDB transfer terminated with success
1:M 29 Nov 2023 07:00:20.058 * Streamed RDB transfer with replica 10.97.141.243:6379 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming
1:M 29 Nov 2023 07:00:20.058 * Synchronization with replica 10.97.141.243:6379 succeeded
1:M 29 Nov 2023 07:00:20.058 * Starting BGSAVE for SYNC with target: replicas sockets
1:M 29 Nov 2023 07:00:20.691 * Background RDB transfer started by pid 897
1:M 29 Nov 2023 07:02:50.161 # Connection with replica 10.97.141.243:6379 lost.
从报错可知，是开启了无盘复制参数 repl-diskless–sync
1:S 29 Nov 2023 06:54:45.961 * MASTER <-> REPLICA sync: receiving streamed RDB from master with EOF to disk
1:S 29 Nov 2023 07:00:18.665 * MASTER <-> REPLICA sync: Flushing old data
1:signal-handler (1701241365) Received SIGTERM scheduling shutdown...
经过一系列的排查未发现 redis 及内存方面的原因导致这种情况出现，最后describe pod 的时候发现存活性检测失败的问题，进一步排查发现从库在 Flushing old data 的时候会阻塞那个存活性检测脚本，导致失败，然后 kill 掉 pod，固日志中会有 Received SIGTERM scheduling shutdown 这个信号。
解决方法
将 livenessProbe 中 timeoutSeconds 调大即可。
livenessProbe:
initialDelaySeconds: 30
periodSeconds: 15
timeoutSeconds: 900
successThreshold: 1
failureThreshold: 5
原文地址:https://blog.csdn.net/weixin_40548182/article/details/134690505
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_13581.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
