redis从节点slave,fail,noaddr问题处理

本文介绍了一个Redis集群中从节点出现故障的具体情况,并提供了详细的解决步骤,包括如何将故障节点从集群中移除、重新加入集群及配置主从关系。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一 问题描述

查看集群状态,发现其中一个从节点异常(是fail状态)
127.0.0.1:6383> cluster nodes

83780e418e90de6067a196d88a54fd2cfe719f86 192.168.109.134:6384@16384 slave 6a50a9c515acf3490e5a5256250d857d0812bc6a 0 1615173819865 17 connected

00dd345835790608dc062dd4742d853138f06b97 192.168.109.133:6384@16384 master - 0 1615173819000 9 connected 5462-10923

0e8fa73711c300f2da6f92df49b215d270021b14 192.168.109.134:6383@16383 slave 00dd345835790608dc062dd4742d853138f06b97 0 1615173818862 9 connected

f86464011d9f8ec605857255c0b67cff1e794c19 :0@0 slave,fail,noaddr 2cb35944b4492748a8c739fab63a0e90a56e414a 1614958275942 1614958275942 8 disconnected

6a50a9c515acf3490e5a5256250d857d0812bc6a 192.168.109.132:6384@16384 master - 0 1615173818000 17 connected 10924-16383

2cb35944b4492748a8c739fab63a0e90a56e414a 192.168.109.133:6383@16383 myself,master - 0 1615173819000 8 connected 0-5461

 

在问题节点上查看节点状态,发现它已脱离集群,且id都已发生了变化:

127.0.0.1:6383> cluster nodes

0cbf44ef3f9c3a8a473bcd303644388782e5ee78 192.168.109.132:6383@16383 myself,master - 0 0 0 connected 0-5461

/*若id没发生变化,直接重启下该从节点就能解决*/

二 解决办法

2.1 将该从节点剔出集群

#在集群每个正常节点上执行cluster forget 故障从节点id,示例:

echo 'cluster forget f86464011d9f8ec605857255c0b67cff1e794c19' | /usr/local/bin/redis-cli -p 6384 -a "密码"

echo 'cluster nodes' | /usr/local/bin/redis-cli -p 6384 -a "密码"

 

echo 'cluster forget f86464011d9f8ec605857255c0b67cff1e794c19' | /usr/local/bin/redis-cli -p 6383 -a "密码"

echo 'cluster nodes' | /usr/local/bin/redis-cli -p 6383 -a "密码"

2.2 重新将该节点加入集群

2.2.1 握手

在集群内任意节点上执行cluster meet命令加入新节点,握手状态会通过信息在集群内传播,这样其他节点会自动发现新节点并发起握手流程。

echo 'cluster meet 192.168.109.132 6383' | /usr/local/bin/redis-cli -p 6384 -a "密码"

2.2.2 配置主从关系

#在该从节上执行cluster replicate 主节点id

[root@centos7-mod ~]# echo 'cluster replicate 2cb35944b4492748a8c739fab63a0e90a56e414a' | /usr/local/bin/redis-cli -p 6383 -a "密码"

Warning: Using a password with '-a' option on the command line interface may not be safe.

OK

2.2.3 检查集群状态

[root@centos7-mod ~]# echo 'cluster nodes' | /usr/local/bin/redis-cli -p 6384 -a "密码"

Warning: Using a password with '-a' option on the command line interface may not be safe.

38287a7e715c358b5537a369646e9698a7583459 192.168.109.132:6383@16383 slave 2cb35944b4492748a8c739fab63a0e90a56e414a 0 1615233239757 8 connected

2cb35944b4492748a8c739fab63a0e90a56e414a 192.168.109.133:6383@16383 master - 0 1615233239000 8 connected 0-5461

0e8fa73711c300f2da6f92df49b215d270021b14 192.168.109.134:6383@16383 slave 00dd345835790608dc062dd4742d853138f06b97 0 1615233241763 9 connected

83780e418e90de6067a196d88a54fd2cfe719f86 192.168.109.134:6384@16384 slave 6a50a9c515acf3490e5a5256250d857d0812bc6a 0 1615233240760 17 connected

00dd345835790608dc062dd4742d853138f06b97 192.168.109.133:6384@16384 master - 0 1615233241000 9 connected 5462-10923

6a50a9c515acf3490e5a5256250d857d0812bc6a 192.168.109.132:6384@16384 myself,master - 0 1615233242000 17 connected 10924-16383

--本篇文章主要参考自https://blog.youkuaiyun.com/wojiuguowei/article/details/83511023

 

<think>嗯,我现在要了解一下如何查看Redis集群的节点状态以及如何手动进行备升主的操作。首先,我需要回忆一下Redis集群的基本结构。Redis集群是由多个节点组成的,每个节点可以是一个主节点或者从节点。主节点负责处理槽位的数据,而从节点则复制主节点的数据,当主节点宕机时,从节点可以升级为主节点,保证高可用性。 首先,用户的问题分为两部分:查看集群节点状态和手动备升主。对于第一部分,我应该记得Redis提供了相关的命令来查看集群的状态。常用的命令可能是CLUSTER NODES或者CLUSTER INFO。CLUSTER NODES应该能列出所有节点的详细信息,包括他们的角色(主或从)、连接状态、槽位分配等信息。而CLUSTER INFO可能提供更概览的信息,比如集群是否处于正常状态,节点数量等。 接下来是手动将备节点升级为主节点。这通常发生在主节点出现故障,但自动故障转移没有触发,或者需要手动维护的情况下。手动提升从节点为主节点,可能需要使用CLUSTER FAILOVER命令。不过,这个命令通常是在从节点上执行的,并且可能需要一定的条件,比如主节点确实不可用,或者需要强制进行故障转移。 不过,用户提到的是“手动备升主”,也就是手动将备节点(从节点)提升为主节点。这时候可能需要几个步骤:首先确认当前集群的状态,确认哪些节点是从节点,对应的主节点是谁。然后,可能需要让从节点执行故障转移,使其成为主节点。但如果是主节点仍然在线的情况下,可能需要使用强制故障转移的参数,比如CLUSTER FAILOVER FORCE或者CLUSTER FAILOVER TAKEOVER,这取决于具体情况。 另外,可能还需要考虑在故障转移之后,处理旧的主节点,如果它重新上线,可能会变成从节点。需要确保集群的配置正确,槽位分配正确,数据的一致性等问题。 在操作过程中,需要注意命令的正确使用,以及确保在集群配置发生变化时,其他节点的信息同步。例如,执行故障转移后,集群中的其他节点需要更新他们的节点信息,以反映新的主节点。这可能通过Redis集群的自动 Gossip 协议来完成,但可能需要一些时间,或者需要手动检查确认。 可能的步骤总结如下: 1. 使用CLUSTER NODES命令查看当前所有节点的状态,确认各个主从关系。 2. 确定需要提升的从节点ID以及其对应的主节点。 3. 如果主节点确实宕机,可以尝试在从节点上执行CLUSTER FAILOVER,或者根据情况使用FORCE或TAKEOVER选项。 4. 验证故障转移是否成功,再次使用CLUSTER NODES检查节点角色是否变更。 5. 处理旧的主节点,如果它重新加入集群,可能需要调整其角色或重新分配槽位。 不过,我需要验证这些步骤是否正确。比如,CLUSTER FAILOVER命令是否需要主节点不可达才会生效,或者是否可以在主节点在线时强制切换。另外,强制故障转移是否会导致数据丢失,或者是否有风险。这时候可能需要查阅Redis的官方文档,确认命令的具体行为。 根据Redis官方文档,CLUSTER FAILOVER命令有两种模式:一种是默认的,需要主节点认可才能进行故障转移;另一种是FORCE,即使主节点不可达也会进行;而TAKEOVER则是不考虑其他节点的意见,直接进行故障转移,可能会导致数据冲突,需要谨慎使用。 因此,正确的步骤可能是在从节点上执行CLUSTER FAILOVER FORCE,当主节点不可达时。或者,如果主节点还在线,但需要强制切换,可能需要使用TAKEOVER选项,但需要注意数据一致性问题。 另外,手动提升从节点为主节点后,还需要确保槽位的分配是正确的,因为主节点负责处理槽位的数据。可能需要重新分配槽位,但如果主节点已经宕机,其对应的从节点在提升后会自动接管原有的槽位,不需要手动调整? 这可能需要进一步确认。例如,当从节点提升为主节点后,原主节点的槽位是否会自动转移到新的主节点。根据Redis集群的设计,主节点和它的从节点负责相同的槽位,所以当从节点接管后,应该继续服务相同的槽位,不需要重新分配。但是需要确保其他节点知道这个变化。 总结一下,正确的操作步骤可能如下: 查看节点状态: - 使用redis-cli连接到集群中的任意节点。 - 执行CLUSTER NODES命令,查看各个节点的ID、角色、状态、槽位信息等。 手动备升主: 1. 确认主节点确实故障,无法自动恢复。 2. 连接到对应的从节点。 3. 执行CLUSTER FAILOVER FORCE或TAKEOVER命令,强制进行故障转移。 4. 检查集群状态,确认从节点已变为主节点,槽位正确。 5. 处理旧的主节点,如果需要重新加入,可能需要作为从节点加入。 需要注意的是,强制故障转移可能导致数据丢失,尤其是在主节点实际上还在运行的情况下,此时可能发生脑裂,需要谨慎处理。 此外,可能还需要使用其他命令,比如CLUSTER RESET来重置节点状态,或者在节点重新加入集群时进行配置,但具体操作需要根据情况而定。 在实施过程中,应该逐步验证每一步的结果,确保集群状态符合预期,避免操作失误导致服务中断或数据问题。</think>### Redis查看集群节点状态及手动备升主操作指南 #### 一、查看集群节点状态 1. **连接到Redis集群节点** 使用`redis-cli`连接至任意集群节点(建议连接已知正常节点): ```bash redis-cli -c -h <节点IP> -p <端口> ``` 2. **查看节点详细信息** 执行`CLUSTER NODES`命令,输出所有节点信息: ```bash CLUSTER NODES ``` **输出字段解析**: - **节点ID**:唯一标识符,如`e3d8a7b1...` - **角色**:`master`(主节点)或`slave`(从节点) - **状态**:`connected`(正常)、`fail?`(疑似故障)、`fail`(已故障) - **槽位分配**:主节点负责的哈希槽范围,如`0-5460` 3. **查看集群概要信息** 执行`CLUSTER INFO`,获取集群健康状态: ```bash CLUSTER INFO ``` **关键指标**: - `cluster_state:ok`(集群正常) - `cluster_slots_assigned:16384`(所有槽位已分配) --- #### 二、手动备升主操作(故障转移) ##### **前提条件** - 主节点已确认故障且无法自动恢复。 - 从节点数据同步正常(`slave_repl_offset`与主节点一致)。 --- ##### **操作步骤** 1. **确认从节点身份** 通过`CLUSTER NODES`找到目标从节点及其对应主节点ID: ```bash e3d8a7b1... 192.168.1.2:6379 slave c1a2b3c4... # 从节点信息 c1a2b3c4... 192.168.1.1:6379 master,fail # 主节点标记为fail ``` 2. **触发强制故障转移** 连接到目标从节点,执行以下命令之一: - **强制模式**(主节点不可达时): ```bash CLUSTER FAILOVER FORCE ``` - **接管模式**(无视集群状态,慎用): ```bash CLUSTER FAILOVER TAKEOVER ``` 3. **验证故障转移结果** 再次执行`CLUSTER NODES`,确认角色变更: ```bash e3d8a7b1... 192.168.1.2:6379 master # 从节点已升主 ``` 4. **处理旧主节点** - 若旧主节点恢复,需重新加入集群为从节点: ```bash CLUSTER REPLICATE <新主节点ID> ``` - 若需彻底下线,使用`CLUSTER FORGET <旧主节点ID>`移除。 --- #### 三、注意事项 1. **数据一致性风险** 强制故障转移可能导致**数据丢失**(如原主节点有未同步数据)。确保`slave_repl_offset`与主节点一致。 2. **脑裂问题** 若原主节点仍在运行,需手动下线,避免集群分裂。 3. **槽位验证** 故障转移后,检查槽位分配是否完整: ```bash redis-cli --cluster check <节点IP>:<端口> ``` --- #### 四、操作示例 ```bash # 1. 查看节点状态 $ redis-cli -c -h 192.168.1.2 -p 6379 CLUSTER NODES # 2. 连接到从节点执行故障转移 $ redis-cli -h 192.168.1.2 -p 6379 127.0.0.1:6379> CLUSTER FAILOVER FORCE # 3. 验证新主节点 127.0.0.1:6379> CLUSTER NODES ``` 通过以上步骤,可安全完成Redis集群状态查看及手动故障转移操作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

雅冰石

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值