Redis4.0从库复制报错"master_link_status:down"处理一例

本文详细记录了一次Redis主从复制过程中遇到的redissyncerror问题,主库在进行数据同步时因client-output-buffer-limit设置过小导致数据发送失败。通过调整缓冲区限制大小,成功解决了主从复制中断的问题。

环境描述:

Redis版本:4.0.2

主库:192.168.0.190

从库:192.168.0.191


今天Zabbix告警一直出现redis sync error的信息,于是登陆redis发现从库复制状态一直是master_link_status:down的状态。


从库日志报错信息如下:

17365:S 28 Dec 14:45:15.294 * Connecting to MASTER 192.168.0.190:6379

17365:S 28 Dec 14:45:15.294 * MASTER <-> SLAVE sync started

17365:S 28 Dec 14:45:15.294 * Non blocking connect for SYNC fired the event.

17365:S 28 Dec 14:45:15.295 * Master replied to PING, replication can continue...

17365:S 28 Dec 14:45:15.295 * Partial resynchronization not possible (no cached master)

17365:S 28 Dec 14:45:15.341 * Full resync from master: 3987160bba8279fe30b828fb339d1c0c6536a3ab:182474982617073

17365:S 28 Dec 14:45:17.293 # I/O error reading bulk count from MASTER: Resource temporarily unavailable



主库报错日志信息如下:

25573:M 28 Dec 15:38:53.255 * Background saving started by pid 12067

25573:M 28 Dec 15:38:53.258 # Client id=87019085 addr=192.168.0.191:1440 fd=110 name= age=0 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=6641 oll=1 omem=19125 events=r cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits.

25573:M 28 Dec 15:38:53.356 # Connection with slave 192.168.0.191:6379 lost.


从主库日志中我们可以看出在redis主库在接到从库要求重新同步数据的时候先生成一个rdb文件,再通过psync来做部分同步,可以看到问题就出在这一块,

持续报错”psync scheduled to be closed ASAP“,这个原因是由于client-output-buffer-limit值设置的太小从而导致数据发送失败。


解决方法:

登陆主库和从库修改缓冲区占用内容大小限制:


127.0.0.1:6379> config set client-output-buffer-limit "slave 8589934592 2147483648 0"

OK

同步到配置文件:

127.0.0.1:6379> config rewrite

OK

查看配置文件内容

# cat redis.conf |grep client-output-buffer-limit  

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 8gb 2gb 0


登陆从库192.168.0.191,再次观察主从复制状态,发现从库的的复制状态很快就变成了up:

# redis-cli info replication

# Replication

role:slave

master_host:192.168.0.190

master_port:6379

master_link_status:up


至此,问题处理完毕。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15498/viewspace-2286846/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/15498/viewspace-2286846/

Redis 哨兵模式的一主二从架构中,当主机宕机时,哨兵会自动选举一个从机作为新的主机,并通过发布订阅机制通知其他从机切换主机。然而,在修复原主机并重新启动后,可能会发现其状态仍为 `master_link_status:down`,并且无法自动恢复到正常状态。 ### 问题分析 当原来的主机宕机后,哨兵系统会将该节点标记为主观下线,并在多个哨兵达成一致后将其标记为客观下线。此时,系统会进行故障转移(failover),选出一个新的主节点。即使原主机被修复并重新上线,由于其已被标记为失效节点,哨兵不会主动将其重新加入集群作为从节点,除非手动干预或配置调整[^2]。 此外,Redis 哨兵模式的设计原则是“最终一致性”,即一旦发生主从切换,原主节点会被视为不再适合作为主节点使用。因此,即使原主节点恢复运行,它也会被转换为从节点,并且需要与新主节点建立连接。如果连接未能成功建立,则会出现 `master_link_status:down` 的状态[^4]。 ### 解决方案 1. **确认原主节点是否已自动转为从节点** 在修复原主节点后,执行以下命令查看其复制状态: ```bash redis-cli -p 6379 info replication ``` 如果输出显示 `role:slave`,则表示该节点已成功转为从节点,但可能尚未与新主节点建立连接。 2. **手动指定新主节点** 若原主节点未正确连接到新主节点,可以手动设置其复制目标: ```bash redis-cli -p 6379 slaveof <new_master_ip> <new_master_port> ``` 其中 `<new_master_ip>` 和 `<new_master_port>` 是当前主节点的 IP 地址和端口号。 3. **检查网络连接** 确保原主节点能够与新主节点通信,包括防火墙规则、端口开放情况等。若存在网络隔离,会导致复制链路无法建立,从而 `master_link_status` 保持为 `down`。 4. **重启原主节点服务** 如果上述方法无效,尝试重启原主节点的 Redis 服务以刷新复制状态: ```bash systemctl restart redis ``` 5. **更新哨兵配置** 在某些情况下,哨兵可能仍未识别原主节点的新角色。可以通过重启哨兵进程来更新其监控信息: ```bash sentinel_client_id=$(ps -ef | grep 'redis-sentinel' | grep -v 'grep' | awk '{print $2}') kill -HUP $sentinel_client_id ``` 6. **验证复制状态** 在完成上述操作后,再次检查原主节点的复制状态,确保其已成功连接到新主节点: ```bash redis-cli -p 6379 info replication ``` 此时应看到 `master_link_status:up`,并且数据同步正在进行或已完成。 ### 总结 Redis 哨兵模式虽然提供了高可用性保障,但在原主节点恢复后并不会自动将其重新纳入复制拓扑中。需通过手动干预或配置更新,确保其正确地作为从节点连接到新主节点。同时,应定期检查网络连通性和哨兵状态,以维护整个集群的稳定性[^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值