当前位置: 首页 > 知识库问答 >
问题:

Redis集群:主故障不自动故障转移

潘学民
2023-03-14

我正在尝试用6台机器实现一个Redis集群。我有一个由六台机器组成的流浪集群:

192.168.56.101
192.168.56.102
192.168.56.103
192.168.56.104
192.168.56.105
192.168.56.106

运行redis服务器

我编辑了上述所有服务器的/etc/redis/redis.conf文件,添加了这个

cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-slave-validity-factor 0
appendonly yes

然后我在六台机器中的一台上运行了这个程序;

./redis-trib.rb create --replicas 1 192.168.56.101:6379 192.168.56.102:6379 192.168.56.103:6379 192.168.56.104:6379 192.168.56.105:6379 192.168.56.106:6379

Redis集群已启动并运行。我通过在一台机器上设置值手动检查它显示在其他机器上。

$ redis-cli -p 6379 cluster nodes
3c6ffdddfec4e726f29d06a6da550f94d976f859 192.168.56.105:6379 master - 0 1450088598212 5 connected
47d04bc98ab42fc793f9f382855e5c54ab8f2e20 192.168.56.102:6379 slave caf2cec45114dc8f4cbc6d96c6dbb20b62a39f90 0 1450088598716 7 connected
040d4bb6a00569fc44eec05440a5fe0796952ccf 192.168.56.101:6379 myself,slave 5318e48e9ef0fc68d2dc723a336b791fc43e23c8 0 0 4 connected
caf2cec45114dc8f4cbc6d96c6dbb20b62a39f90 192.168.56.104:6379 master - 0 1450088599720 7 connected 0-10922
d78293d0821de3ab3d2bca82b24525e976e7ab63 192.168.56.106:6379 slave 5318e48e9ef0fc68d2dc723a336b791fc43e23c8 0 1450088599316 8 connected
5318e48e9ef0fc68d2dc723a336b791fc43e23c8 192.168.56.103:6379 master - 0 1450088599218 8 connected 10923-16383

我的问题是,当我关闭或停止任何一台主机上的redis server时,整个集群都会停止运行,但如果所有三个从机都死掉,集群仍能正常工作。

如果主设备出现故障(容错),我应该如何做才能使从设备变成主设备?

我假设redis处理所有这些事情,部署集群后我不需要担心它。我是对的还是我必须自己做这件事?

另一个问题是,假设我有6台16GB内存的机器。这个Redis集群有三个主服务器和三个从服务器,我能处理多少总数据?

谢谢你。

共有1个答案

程鸿波
2023-03-14

设置群集-从属-有效性-因子0可能是这里的罪魁祸首。

来自redis.conf

# A slave of a failing master will avoid to start a failover if its data
# looks too old.

在您的设置中,终止主机的从机认为自己不适合被选为主机,因为它最后一次接触主机的时间大于以下计算值:

(节点超时*从属有效系数)复制从属周期

因此,即使使用冗余从机,群集状态也会更改为“关闭”,并变得不可用。

您可以尝试使用不同的值,例如,建议的默认值

集群-从-有效性-因子10

这将确保集群能够容忍一个随机redis实例故障。(它可以是从属实例或主实例)

关于第二个问题:六台16GB RAM的机器将能够作为一个包含3个主实例和3个从实例的Redis集群运行。因此,理论最大值为16GB x 3数据。如果启用了cluster require full coverage,这样的集群最多可以容忍一个节点故障。否则,它可能仍然能够提供功能实例中仍然可用的碎片中的数据。

 类似资料:
  • 问题内容: 在简单情况下,如果3台服务器具有1个主服务器和2个从属服务器而没有分片。是否有使用Java和Jedis的经过验证的解决方案,该解决方案没有单点故障,并且将自动处理单个服务器(无论是主服务器还是从服务器)(自动故障转移)。例如,提升主机并在故障后重置,而不会丢失任何数据。 在我看来,这似乎应该是一个已解决的问题,但是我找不到关于它的任何代码,而仅是对实现此方法的高级描述。 谁实际覆盖并在

  • 故障自动转移是指在 TiDB 集群的某些节点出现故障时,TiDB Operator 会自动添加一个节点,保证 TiDB 集群的高可用,类似于 K8s 的 Deployment 行为。 由于 TiDB Operator 基于 StatefulSet 来管理 Pod,但 StatefulSet 在某些 Pod 发生故障时不会自动创建新节点来替换旧节点,所以,TiDB Operator 扩展了 Stat

  • 我们在生产环境中广泛使用redis集群。我们目前有一个30个节点的集群(15个主服务器,15个从服务器)我们正在尝试增加集群,为此我们创建了新的服务器 接下来-我们试图重新加载插槽到新的主人。我们编写了一个脚本来实现这一点,使用命令。 但是-迁移中途失败(但距离开始不远),出现以下错误:

  • 因此,如果我理解正确的话,在检测并重新启动失败代理的环境中运行Artemis代理集群将提供与运行每个活动服务器都与备份配对的集群相同的语义(以及类似的可用性)。对吗?

  • 配置:三个redis集群分区,跨越三组一主一从。当主机停机时,莴苣立即检测到停机并开始重试。然而,莴苣没有检测到关联的从属服务器已将自己升级为主服务器,并继续使用无法访问且最终超时的旧主服务器重试。尝试将各种拓扑刷新选项设置为无效。 建议的解决方案:在第一次重试失败(这是一行中第二次重试失败)后,使用提供的任何节点的拓扑(因为它们都具有相同的拓扑信息)重新运行拓扑刷新(用于在初始化期间导出拓扑)。

  • 我注意到,当连接的Artemis节点宕机时,连接到节点2-4的客户机不会故障转移到其他3个可用的主节点,基本上不会发现其他节点。即使在原始节点恢复之后,客户端仍然无法建立连接。我从一个单独的堆栈溢出帖子中看到,不支持主到主故障转移。这是否意味着对于每个主节点,我也需要创建一个从节点来处理故障转移?这是否会导致两个实例点失败,而不是集群中有许多节点? 在一个单独的基本测试中,使用一个主从两个节点的集