美文网首页Java
redis 集群 高可用 测试

redis 集群 高可用 测试

作者: 阿fong | 来源:发表于2020-03-25 19:53 被阅读0次

编写不易,转载请注明出处!!!

测试redis主从节点宕机后的变化,以及数据迁移情况

1 配置集群

网上很多教程,我就略过了。

2 编辑启动和关闭批处理文件

2.1 start.sh——启动集群的批处理文件

我们这里是配置了7001-7009端口的9台redis服务器

vim start.sh

2.2 createCluster.sh——组建集群的批处理文件

vim createCluster.sh

2.3 shutdown.sh——关闭集群的批处理文件

vim shutdown.sh

3 启动集群

sh start.sh

后面还有,没有显示完全,我就不截完了

sh createCluster.sh

组建集群,我们可以看到他分为三个master节点,平均管理0-16384的三个范围。并将三个master节点分别指定给7001,7002,7003端口的redis节点,

yes

然后输出了每个节点的信息,以及从节点跟随情况,并询问我是否使用默认分配。我这里选择yes,使用。

然后又输出了节点信息,以及检查情况,最后16384个hash槽点全部分配完,集群组建成功

至此,我们画图表述一下主从节点的跟随情况

redis集群初始分布情况

4 测试

4.1 插入数据

4.1.1 插入数据到7001

成功插入数据到7001 成功同步到从节点7005

4.1.2 插入数据到7002

成功插入数据到7002 成功同步到从节点7009

4.1.2 数据分布情况

分布情况

4.2 宕机测试

4.2.1 宕掉7001

shutdown CLUSTER NODES

我们可以看到,7001是宕机了,状态变为fail。由从机其7005继位,而7007改为跟随7005。下面测试数据的高可用情况

get test1

还是能正常访问数据。

set test1 2

同样能正常修改数据并同步

由此可见,集群通过master节点向slave节点同步数据,masster节点宕机后故障转移至slave节点来达到高可用的

4.2.2 继续宕掉7005

shutdown CLUSTER NODES

我们可以看到7005也变为fail状态,又另一个slave节点7007,继位,此时0-5460阵营以没有slave节点,情况危急,7002慷慨大义,借了多余的slave节点7009给7007,而7002就只有7004节点跟随它了。如此,又能保证每个master节点都有slave节点跟随。

我们继续测试一下数据的情况

get test1     get test2

我们可以看到,7007继位后,0-5460阵营的test1仍然正常,也成功同步到7009节点。但是7009节点原来保存的7002的数据却悄然丢失。

由此,redis集群会通过转移多余的slave节点的方式,来尽量保证每个master节点都有slave节点跟随,同时,转移的slave节点会删除原来阵营的数据,而同步转移后阵营的数据。

4.2.3 继续宕掉7007

shutdown CLUSTER NODES

我们可以看到,7007变为fail状态,slave节点7009继位,slave节点7006从7003转移至7009

get test1

数据成功同步

4.2.4 继续宕掉7009

shutdown CLUSTER NODES

我们可以看到,7009宕掉以后,7006继位,但是别的阵营以及借无可借了,所以7006只能委屈当光杆司令,情况十分危急。

数据情况是一样的,我就不做测试了。

我们继续乘胜追击

4.2.5 继续宕掉7006

shutdown CLUSTER NODES

我们可以看到0-5460阵营全军覆没,0-5460的hash槽点丢失,数据丢失,也无法在存入数据,若有数据经过哈希槽运算落在此范围,则无法存入,每次都需要去数据库取数据,集群的高可用宣告破裂,

我们看看其余两个阵营能否正常使用

4.2.6 测试存活阵营

get test2 set test3 1

我们可以看到,集群奔溃,其余存活的阵营也无法使用, 我们已至少5台的战绩摧毁了redis集群。

太亏欠0-5460阵营了,我们送它个复活币

4.2.7 启动7001

redis-server 7001/redis.conf

它非常踏实稳重,愿意从slave节点做起

一段时间过后再看,我们发现7001再也回不到从前了

我们尝试启动7006

我们可以发现,7006成功启动成为master节点,而7001一开始跟随的节点就是7006。

看看数据

成功恢复,这是因为7006的文件里存有dump.rdb快照文件

看看其他阵营

我们可以看到,能正常使用。

5 总结

1.redis集群通过master节点向slave节点同步数据,masster节点宕机后故障转移至slave节点来达到高可用

2.redis集群会通过转移多余的slave节点的方式,来尽量保证每个master节点都有slave节点跟随

3.redis集群奔溃的条件是,当有hash槽范围丢失的时候,集群奔溃

4.让集群奔溃,至少需要当掉的节点数量x为

            阵营数 m     每个阵营的节点数  n 

            x = n + (n-2)*(m-1)

5.集群奔溃,其余存活的阵营也无法使用

6.要成功再次启动redis集群,必须启动掌握了丢失的hash槽 的节点

本人水平有限,欢迎大牛指正。

看在我写了这么多的份上,如果觉得内容好可以请点个赞和关注哦。

编写不易,转载请注明出处!!!谢谢!

相关文章

网友评论

    本文标题:redis 集群 高可用 测试

    本文链接:https://www.haomeiwen.com/subject/lpytuhtx.html