Redis集群_哨兵模式
主从复制存在的问题
- 主从复制模式的集群里,当主服务器出现故障后,需要手动进行恢复
- 基于主从复制模式的集群在发生故障时可能会出现数据丢失的情况,对此引入“哨兵模式”
- 一方面用哨兵进程监控主从服务器是否可用,另一方面当主服务器故障发生时,通过哨兵机制可以实现故障自动恢复的效果
哨兵模式概述
- 一般来说,哨兵机制会和主从复制模式整合使用,在基于哨兵的模式里会在一台或者多台服务器上引入哨兵进程,这些节点也叫做哨兵节点
- 哨兵节点一般不存储数据,它的作用是监控主从复制模式的主服务器节点,当哨兵节点监控的主服务器发生故障时,哨兵节点会主导“故障自动修复”的流程
- 哨兵节点会在该主服务器下属的从服务器里面选举一个新的主服务器,并完成相应的数据和配置更改等动作
- 如果采用这种模式,可以让故障自动修复,从而提升系统的可用性
哨兵模式集群
搭建哨兵模式集群
先搭建一主两从集群
主节点
docker run -itd --name redis-master -p 6379:6379 redis:latest
tips:这里需要看一下主节点的ip,从节点的配置文件中的ip需要和这里对应
[root@localhost redis-slave1]# docker inspect redis-master |grep IPAddress
"SecondaryIPAddresses": null,
"IPAddress": "172.17.0.2",
"IPAddress": "172.17.0.2",
从节点一
docker run -itd --name redis-slave1 -p 6380:6380 -v /root/redis/redis-slave1/redis.conf:/redisConfig/redisSlave1.conf redis:latest redis-server /redisConfig/redisSlave1.conf
从节点二
docker run -itd --name redis-slave2 -p 6381:6381 -v /root/redis/redis-slave2/redis.conf:/redisConfig/redisSlave2.conf redis:latest redis-server /redisConfig/redisSlave2.conf
进入主节点查看从属关系
[root@localhost redis-slave1]# docker exec -it redis-master /bin/bash
root@4d382397134e:/data# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.17.0.3,port=6379,state=online,offset=210,lag=1
slave1:ip=172.17.0.4,port=6379,state=online,offset=224,lag=0
master_failover_state:no-failover
master_replid:e8540c67fadd83296f349602ce5a774782939f74
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:224
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:224
创建两个哨兵容器
创建哨兵文件一
sentinel1.conf
port 16379
sentinel monitor master 172.17.0.2 6379 2
logfile "sentinel1.log"
创建哨兵文件二
sentinel2.conf
port 16380
sentinel monitor master 172.17.0.2 6379 2
logfile "sentinel2.log"
解释:
第一行是哨兵容器运行的端口
第二行是哨兵监控的主节点 ip 端口 以及如果2个哨兵认定主节点失效才会进行重新选举主节点
第三行是日志文件
给sentinel.conf配置文件所在的目录设置777权限
chmod -R 777 /root/redis/sentinel
启动redis-sentinel1容器
docker run -itd --name redis-sentinel1 -v /root/redis/sentinel:/redisConfig:z -p 16379:16379 redis:latest redis-server /redisConfig/sentinel1.conf --sentinel
启动redis-sentinel2容器
docker run -itd --name redis-sentinel2 -v /root/redis/sentinel:/redisConfig:z -p 16380:16380 redis:latest redis-server /redisConfig/sentinel2.conf --sentinel
解释:
在Docker命令中,:z选项允许你为挂载的文件或目录指定一个SELinux安全上下文标签。这在你需要确保容器内的进程能够按照特定的SELinux策略访问宿主机上的文件时非常有用。
进入哨兵容器1查看信息
[root@localhost sentinel]# docker exec -it redis-sentinel2 /bin/bash
root@57bef6ceac1b:/data# redis-cli -p 16380
127.0.0.1:16380> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=master,status=ok,address=172.17.0.2:6379,slaves=2,sentinels=2
可以看出监控的主节点状态时ok,并且有两个从节点
哨兵节点的常用配置
sentinel down-after-millseconds master 60000
表示60秒内没有收到master节点的响应就会认为该master节点失效
sentinel failover-timeout master 180000
表示180秒内没有完成主从服务器的切换动作,就会认定这次恢复动作失败
模拟故障场景
将主节点下线
docker stop redis-master
此时哨兵选举了一台从节点作为主节点
127.0.0.1:16380> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=master,status=ok,address=172.17.0.4:6379,slaves=2,sentinels=2
进入刚刚转成主节点的机器
[root@localhost sentinel]# docker exec -it redis-slave2 /bin/bash
root@8def24bf820a:/data# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=172.17.0.3,port=6379,state=online,offset=74491,lag=0
master_failover_state:no-failover
master_replid:ceb5f00095f1ba71b89df7f15eda819e383d95f2
master_replid2:e8540c67fadd83296f349602ce5a774782939f74
master_repl_offset:74491
second_repl_offset:64130
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:155
repl_backlog_histlen:74337
发现已经成为主节点,并且从节点是另一台从节点
这时候上线之前的主节点
[root@localhost sentinel]# docker start redis-master
继续查看刚刚转成主节点的容器信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.17.0.3,port=6379,state=online,offset=98972,lag=0
slave1:ip=172.17.0.2,port=6379,state=online,offset=98972,lag=0
master_failover_state:no-failover
master_replid:ceb5f00095f1ba71b89df7f15eda819e383d95f2
master_replid2:e8540c67fadd83296f349602ce5a774782939f74
master_repl_offset:98972
second_repl_offset:64130
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:155
repl_backlog_histlen:98818
发现曾经的主节点在重新上线后成为了从节点