CLUSTERDOWN 集群在redis中宕机答案

【问题标题】：CLUSTERDOWN The cluster is down in redisCLUSTERDOWN 集群在redis中宕机
【发布时间】：2019-05-04 18:38:39
【问题描述】：

我正在运行 6 个 redis 节点，3 个主节点和 3 个从节点，每个主节点都有 1 个从节点。

Master[0] -> Slots 0 - 5460

Master[1] -> Slots 5461 - 10922

Master[2] -> Slots 10923 - 16383

Adding replica 172.17.0.5:6382 to 172.17.0.2:6379

Adding replica 172.17.0.6:6383 to 172.17.0.3:6380

Adding replica 172.17.0.7:6384 to 172.17.0.4:6381

集群正在运行，我可以设置和获取密钥。

我关闭了master1 172.17.0.2:6379，slave1（172.17.0.5:6382）已经成为master，集群还在运行。

我关闭 slave1 (172.17.0.5:6382) ，我尝试设置键我得到了这个错误

（错误）CLUSTERDOWN 集群已关闭

当我关闭 master1 和 slave1 时，我所期望的，集群仍将运行并接受 redis 操作，但发生了相反的情况。

这背后的原因是什么？

不重新启动master1或slave1是否可以解决这个问题？

【问题讨论】：

标签： caching redis

【解决方案1】：

因为master1和slave1中都存储了一些slot，如果两个都down了，这些slot将不再被集群中的任何节点覆盖。发生这种情况时，默认情况下，集群已关闭。您可以通过更改 cluster-require-full-coverage 选项来修改行为。

引用redis.conf:

默认情况下，如果 Redis Cluster 节点检测到至少有一个未覆盖的哈希槽（没有可用的节点正在服务它）。这样，如果集群部分关闭（例如哈希槽不再被覆盖）所有集群最终变成不可用。它会在所有可用时自动返回插槽再次被覆盖。

但是，有时您希望集群的子集正在运行，继续接受对密钥空间部分的查询仍然覆盖。为此，只需设置 cluster-require-full-coverage 选项为 no。

cluster-require-full-coverage 是的

更新：

为了保证所有的slots都被覆盖，一般情况下，你可以建立一个集群有Nmasters和N + 1slaves。然后为每个master分配一个slave，即N -> N。额外的从站可以从随机的主站复制数据。当你们中的一个主人宕机时，相应的奴隶将成为新的主人。然后你可以让额外的slave从新的master复制数据。

总之，你必须确保每个master在任何时候都至少有一个slave。

【讨论】：

非常感谢@for_stack，关于覆盖槽，我想我们会添加新节点作为主节点并为其分配槽，但是恢复需要时间，可能会影响从该主节点读取密钥的客户端.
通常你可以用N master和N + 1 slaves建立一个集群。查看我的更新以获取答案。
OK @for_stack ，第一次当一个master失败时，额外的slave将成为master，然后我们没有额外的slave，如果任何master再次失败，我们将返回之前的状态。

【解决方案2】：

我去了 redis-cluster 配置，在每个 redis.conf 中我将 cluster-enabled 更改为 no 而不是 yes。这对我有用。

示例：

port 7005
cluster-enabled no
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
logfile "redis.log"

【讨论】：