Redis集群删除后重建后报错:unrecoverable erro:corrupted cluster config file问题及解决
现象
redis某节点出现宕机,删除后重新部署出现如下问题：
unrecoverable erro:corrupted cluster config file
原因分析
/var/lib/redis/nodes.conf，频繁重启虚机的过程中文件破坏，信息不完整或数据不一致造成。
解决方案
步骤1：数据平台中停止Redis服务
步骤2：删除Redis。
步骤3：删除每个节点上的dump.rdb文件和nodes.conf文件
删除方法：
利用xcall.sh脚本删掉 /var/lib/redis/下的 nodes.conf及dump.rdb文件。（xcall.sh已编写放在了系统/usr/local/bin下）
xcall.sh 'rm -rf /var/lib/redis/nodes.conf' xcall.sh 'rm -rf /var/lib/redis/dump.rdb'
xcall.sh 脚本如下：
#!/bin/bash
# for循环
for((i=1; i<=7; i++)) ; do
# 更改文本颜色
tput setaf 2
# 输出以下文本
echo ==================== bg-$i $@ ===================
# 更改文本颜色
tput setaf 9
# ssh 远程登陆主机 bg-$i ,执行输入的参数的命令
ssh bg-$i $@
done步骤4：平台管理组件库和版本中找到Redis添加redis服务。（或重新部署redis服务）
步骤5：重启Redis,查看Redis节点中是否有挂掉的节点。如果启动过程中有某个节点启动失败，执行步骤8.
如下图所示：
步骤6：通过命令创建Redis集群
/usr/idp/current/redis-server/bin/redis-trib.rb create --replicas 1 10.1.3.13:6379 10.1.3.14:6379 10.1.3.15:6379 10.1.3.16:6379 10.1.3.17:6379 10.1.3.18:6379。
执行结果样例如下：
步骤7：验证集群是否安装成功
cd /usr/idp/current/redis-server/bin ./redis-cli -c -h bigdata-1 -p 6379
输入：cluster nodes
bigdata-1:6379> cluster nodes
执行结果样例如下：
都是connected说明集群中redis机器连接没有问题。
测试命令：
bigdata-1:6379> set hello world
ssh bigdata-2 cd /usr/idp/current/redis-server/bin ./redis-cli -c -h bigdata-2 -p 6379 bigdata-2:6379> get hello
样例结果如下：
如果命令出现ERROR情况则，使用redis-trib命令来检查集群
redis-trib.rb check ip:port
如：
./redis-trib.rb check 10.92.11.11:6379
- 如果报错：[ERR] Not all 16384 slots are covered by nodes.请执行：步骤9
- 如果报错：[ERR] Nodes don't agree about configuration!请执行：步骤10
步骤8：
redis节点启动失败
现象：
metrics_pid = int(sudo.read_file(redis_metrics_pid_file)) ValueError: invalid literal for int() with base 10: '8654\n11593\n19745\n8626\n15793\n24954\n30154\n'
解决：
比如bigdata-6节点损坏了，登录到bigdata-6节点上：
cd /var/run/redis [root@ bigdata-6 redis]# cat redis_metrics.pid
只保留第一行的pid
kill -9 11593 19745 8626 15793 24954 30154 vi redis_metrics.pid
删除多余的pid信息。如：11593 19745 8626 15793 24954 30154
保存退出。
步骤9：
原因：这个往往是由于主node移除了，但是并没有移除node上面的slot，从而导致了slot总数没有达到16384，其实也就是slots分布不正确。所以在删除节点的时候一定要注意删除的是否是Master主节点。
解决方案样例如下：
1)、官方是推荐使用redis-trib.rb fix 来修复集群…. …. 通过cluster nodes看到7001这个节点被 干掉了… 那么
[root@node01 src]# ./redis-trib.rb fix 172.168.63.201:7001
修复完成后再用check命令检查下是否正确
[root@node01 src]# ./redis-trib.rb check 172.168.63.202:7000
只要输入任意集群中节点即可，会自动检查所有相关节点。可以查看相应的输出看下是否是每个Master都有了slots，如果分布不均匀那可以使用下面的方式重新分配slot:
[root@node01 src]# ./redis-trib.rb reshard 172.168.63.201:7001
步骤10：
其他节点之前执行过cluster reset，重新握手一次
bg-1:6379> cluster meet 10.92.11.12 6379 bg-1:6379> cluster meet 10.92.11.13 6379 bg-1:6379> cluster meet 10.92.11.14 6379 bg-1:6379> cluster meet 10.92.11.15 6379 bg-1:6379> cluster meet 10.92.11.16 6379
再次检查一下损坏节点的信息
/usr/idp/current/redis-server/bin/ redis-trib.rb check 10.92.11.11：6379
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
这篇文章主要介绍了Redis cluster集群模式的原理解析，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2021-04-04
由于Redis需要依赖于操作系统环境,如果系统资源受限,比如过量的进程在挤占系统资源、系统死锁等情况,本文主要介绍了记录一次并发情况下的redis导致服务假死的问题解决,感兴趣的可以了解一下2023-09-09
这篇文章主要介绍了Redis+Caffeine如何构建高性能二级缓存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2025-05-05
Redis提供了几种持久化机制,可以在不同的应用场景中选择适合的方式来保存数据,以确保即使Redis服务器重启或发生故障,数据仍然不会丢失,下面就来一起了解一下2026-04-04
文章主要介绍了如何使用流程图来设计实现逻辑,并详细讲解了Service层的实现方法,本文结合示例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧2025-03-03
Key的过期机制是Redis保持高可用性的重要策略,过期策略分为惰性过期和定期过期,惰性过期在每次访问key时检查是否过期,定期过期则由serverCron方法定时清理过期key,本文就来详细的介绍一下,感兴趣的可以了解一下2024-09-09
在日常开发中有很多地方都有类似扣减库存的操作，本文主要介绍了Redis实现库存扣减的示例代码，具有一定的参考价值，感兴趣的可以了解一下2023-07-07
文章详细介绍了Redis的配置文件位置、如何编辑配置文件以实现远程访问,以及验证和监控Redis配置的方法,感兴趣的朋友一起看看吧2025-02-02
Redis特殊类型数据结构Bitmap、HyperLogLog、GEO的使用及场景分析
文章介绍了Redis的三种特殊数据类型:Bitmap、HyperLogLog和GEO,分别用于不同的场景,Bitmap适合存储大量二进制数据,HyperLogLog在大数据场景下能高效统计基数,而GEO则用于地理空间信息的管理和查询,本文介绍的非常详细,感兴趣的朋友跟随小编一起通过本文学习吧2025-12-12
排行榜在很多地方都能使用到，redis的zset可以很方便地用来实现排行榜功能，本文就来简单的介绍一下如何使用，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2021-05-05
最新评论