redis集群 服务器重启测试
1、集群规划:2台服务器 每台服务器运行3个redis实例
192.168.2.129 7000 7001 7004
192.168.2.136 7002 7003 7005
主 | 从 |
---|---|
136:7002 | 129:7004 |
136:7005 | 129:7000 |
136:7003 | 129:7001 |
重启服务器后redis实例没有自动重启,查看集群各节点的配置文件
192.168.2.129 7000 7001 7004
192.168.2.136 7002 7003 7005
2、重启2台服务器后redis实例没有自动重启
手动重启redis实例
启动129:7000 后 查看日志 在不断刷新 同步集群信息失败,其余5个节点均没有新日志产生。
再启动129:7001
启动129:7001 后 查看日志 在不断刷新 同步集群信息失败,其余4个节点均没有新日志产生。
推测是因为没有启动对应的主从节点所以其余节点没有日志
下面启动129:7001的master 136:7003
查看129:7001日志
查看136:7003日志
确认129:7001和136:7003是1对主从节点
启动预设的129:7000的master 136:7005
129:7000日志仍在刷新,同步集群信息失败
136:7005的日志
启动136:7005
分配了新的从节点
至此其余2个节点没有新日志产生。
查看当前4个实例的主从分配状态
最后一对主从节点
129:7004当前日志
136:7002当前日志
启动136:7002
查看136:7002日志
129:7004日志 没有新日志
启动129:7004
查看136:7002日志 黄色部分是因为启动从节点129:7004后 新增的 此时主从产生了信息沟通交换
查看129:7004日志 新增日志如下
比较 重启实例后和之前的主从分配
查看重启实例后的集群状态
按预设主从分配重启节点前的主从节点分配
主 | 从 |
---|---|
136:7002 | 129:7004 |
136:7003 | 129:7001 |
136:7005 | 129:7000 |
按预设主从分配重启节点后的主从节点分配
主 | 从 |
---|---|
136:7002 | 129:7004 |
136:7003 | 129:7001 |
136:7005 | 129:7000 |
说明按预设主从分配(集群节点配置文件中的主从分配)启动实例后集群主从分配不会改变,还是之前的预设主从分配。但是变动了
查看集群节点配置文件
129
136
3、再次重启2台服务器
查看集群节点配置文件 和重启前相同
129
136
下面不按照集群节点配置文件的主从分配关系 乱序启动redis实例进行测试
主 | 从 |
---|---|
136:7002 | 129:7004 |
136:7003 | 129:7001 |
136:7005 | 129:7000 |
136:7002->129:7001->136:7003->129:7000->129:7004->136:7005
乱序交叉启动后查看redis主从分配,和服务器重启前是一样的。
主 | 从 |
---|---|
136:7002 | 129:7004 |
136:7003 | 129:7001 |
136:7005 | 129:7000 |
启动redis实例后,再次查看集群节点配置文件,和启动redis实例前比较,相同(只有数字串不同)
129
136
4、主从同步测试
在从节点192.168.2.129:7000上增加1个缓存
Redirected to slot [9794] :表示001这个缓存通过计算后,落在9794这个slot上;
located at 192.168.2.136:7002:最终定位在192.168.2.136:7002这个master节点上;(127.0.0.1:7000是slave,192.168.2.136:7002并不是192.168.2.129:7000对应的master,只有master才能写入)。
如果在192.168.2.136:7002重复上面的创建缓存过程,不会出现Redirected to…这行(192.168.2.136:7002是master,所以不存在redirect的过程 直接可以写入了)。