windows下搭建Redis群集，实现主从复制 和 故障转移_redis在windows上故障转移

主从复制模式

按照https://mp.csdn.net/editor/html/108600332先创建三个reids服务

Master节点使用默认的配置即可。slave节点，需要修改配置文件(redis.windows-service-6382.conf)中定义的ip、端口号和master 密码,如下图所示：

之前没有设置masterauth字段，当设置slaveof主从后,还是获取不到master的数据，就是应为该字段没设，日志会提示如下

如果配置文件里没有设置slaveof没有设置则需要通过命令手动设置，设置主从的步骤如下:

 

以上是redis的主从复制模式，即slave服务器一般只做备份和分担master服务器读写的负担，之所以说分担了写，是因为maseter读业务被分担了，写业务自然就提升了，但是做不到故障转移 且持续业务的能力

 

 

设置哨兵模式

https://blog.csdn.net/u010648555/article/details/79430105

从redis安装目录下取sentinel.conf，修改内容主要如下

其中port是哨兵服务器的端口一般是值会设置为 对应的监视的redis服务器的端口对应的服务器端口 加上 万位的2(保证端口没被占用), 然后是monitor中需要监视的redis服务器ip端口，

其中  最后的参数2 标识这个主实例判断为失效至少需要2个 Sentinel进程的同意， # 只要同意Sentinel的数量不达标，自动failover(故障转移)就不会执行

将该配置文件赋值n份放到对应的redis服务器目录下,只修改端口号即可，相当于多个哨兵进程监视master

添加启动sentinel的脚本文件，并启动

进一步测试如下，左侧master停服后右侧从节点成为了master节点，可以进行读写操作了

主从复制起效，6382成了master

 

此时比对之前的redis 从服务器redis.windows-service-6382.conf发现slaveof 字段没了，之前的主服务器6381没有变化

左侧之前的 右侧现在的

意思应该是：我不是6381的随从了

 

此时比对之前的redis 从服务器sentinel_26382.conf发现主要做了如下改动

意思应该是：监视对象从6381切换到6382,,即当前master

其中know-slave 字段应该是记录了当前所有从服务器的信息,因为这只开了一个slaver所以不清楚在开一个，这个字段会不会在添加一组信息，到时候可以试试

其中know-senitnel 字段应该是记录了当前其他所有哨兵的信息

此时比对之前的redis 主服务器sentinel_26381.conf发现主要做了如下改动

意思应该是:监视对象编程了6382，即当前的master

同上

结论,从服务器变为主服务器后，之前的主服务器就成了从服务器，从服务器变成主服务器,配置文件都会随之被改动，

 

 

吧6381.rdb删了，再开启之前的主服务器6381(现在变成了从服务器了),按道理会读到6382服务器的数据但是却没有数据，日志提示

发现之前因为6381是master没有设置masterauth造成的数据没有复制 过来，加了该字段后重启，没有问题了

且redis.windows-service-6381.conf也记录了新的slaveof

 

 

 

在此切换master

 

 

再开一个哨兵26383，和redis服务6393，此时停止当前的master6381

查看sentinel.conf，全部编程监视6383

最后的信息全部一致，slave都是 6381和6382

哨兵信息也是其他两个的信息

 

 

查看redis.windows-service.conf，slaveof都指向6383,6383自己的配置就没有该选项了，因为自己是master了

 

之前说到座位master的服务器停服后转为slave后重启服务，获得的数据还是之前的，所以需要先删除本地的.rdb,再重启，刚才在不删除 起服务器，获取确实是之前的，但是在master重新设置该数据后，slave上的数据就有被覆盖了，正确了

 

 

然后最后一点就是，选停redis服务器在关闭哨兵，不然相关信息不回被写进两个.conf里达不到故障转换后重启生效的效果了

 

linux 下和windows下搭建redis环境大同小异，几乎没什么差别