编写不易,转载请注明出处!!!
测试redis主从节点宕机后的变化,以及数据迁移情况
1 配置集群
网上很多教程,我就略过了。
2 编辑启动和关闭批处理文件
2.1 start.sh——启动集群的批处理文件
我们这里是配置了7001-7009端口的9台redis服务器

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

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

3 启动集群

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

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

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

然后又输出了节点信息,以及检查情况,最后16384个hash槽点全部分配完,集群组建成功
至此,我们画图表述一下主从节点的跟随情况

4 测试
4.1 插入数据
4.1.1 插入数据到7001


4.1.2 插入数据到7002


4.1.2 数据分布情况

4.2 宕机测试
4.2.1 宕掉7001


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

还是能正常访问数据。

同样能正常修改数据并同步
由此可见,集群通过master节点向slave节点同步数据,masster节点宕机后故障转移至slave节点来达到高可用的
4.2.2 继续宕掉7005


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

我们可以看到,7007继位后,0-5460阵营的test1仍然正常,也成功同步到7009节点。但是7009节点原来保存的7002的数据却悄然丢失。
由此,redis集群会通过转移多余的slave节点的方式,来尽量保证每个master节点都有slave节点跟随,同时,转移的slave节点会删除原来阵营的数据,而同步转移后阵营的数据。
4.2.3 继续宕掉7007


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

数据成功同步
4.2.4 继续宕掉7009


我们可以看到,7009宕掉以后,7006继位,但是别的阵营以及借无可借了,所以7006只能委屈当光杆司令,情况十分危急。
数据情况是一样的,我就不做测试了。
我们继续乘胜追击
4.2.5 继续宕掉7006


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


我们可以看到,集群奔溃,其余存活的阵营也无法使用, 我们已至少5台的战绩摧毁了redis集群。
太亏欠0-5460阵营了,我们送它个复活币
4.2.7 启动7001

它非常踏实稳重,愿意从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)
网友评论