一、Redis 哨兵模式:
哨兵的核心功能:在主从复制的基础上,哨兵引入了主节点的自动故障转移
1、哨兵模式原理:
哨兵:是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的Master 并将所有Slave 连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
2、哨兵模式的作用:
-
监控:哨兵会不断地检查主节点和从节点是否运作正常。
-
自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
-
通知提醒:哨兵可以将故障转移的结果发送给客户端
3、哨兵的结构:
-
哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点就是特殊的redis节点,不存储数据
-
数据节点:主节点和从节点都是数据节点
注意:
哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式,所有节点上都需要部署哨兵模式,哨兵模式会监控所有的Redis工作节点是否正常。
4、故障转移机制:
由哨兵节点定期监控主节点是否出现了故障,每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。 如果主节点在一定时间范围内不回复或者是回复一个错误消息,那么这个哨兵就会认为这个主节点主观下线了(单方面的),当超过半数哨兵节点认为该主节点下线了,这样就客观下线了。 此时哨兵节点会通过Raft算法〈选举算法)实现选举机制共同选举出一个哨兵节点为leader,来负责处理主节点的故障转移和通知。
故障转移过程如下:
● 将某一个从节点升级为新的主节点,让其它从节点指向新的主节点;
● 若原主节点恢复也变成从节点,并指向新的主节点;
● 通知客户端主节点已经更换。
主节点的选举条件:
-
过滤掉不健康的(已下线的),没有回复哨兵ping响应的从节点
-
选择配置文件中从节点优先级最高的(replication-priority,默认值为100)
-
选择复制偏移量最大的,也就是复制最完整的从节点。
二、案例环境
服务器 | |||
---|---|---|---|
master | Centos7.9 | 192.168.10.128 | redis-5.0.9.tar.gz |
slave1 | Centos7.9 | 192.168.10.129 | redis-5.0.9.tar.gz |
salve2 | Centos7.9 | 192.168.10.130 | redis-5.0.9.tar.gz |
1.关闭防火墙安全内核机制,所有节点全部执行
1 2 | [root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0 |
2.所有节点分别搭建网络yum源 ,需要联网
1 | [root@localhost ~] # yum clean all && yum makecache |
3.分别修改主机名
1 2 3 | [root@localhost ~]hostnamectl set - hostname master #192.168.10.128 [root@localhost ~]hostnamectl set - hostname slave1 #192.168.10.129 [root@localhost ~]hostnamectl set - hostname slave2 #192.168.10.130 |
4.所有节点修改hosts文件
1 | [root@localhost ~] # cat >>/etc/hosts |
三、实验部署
主从部署
1.所有节点安装redis
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #安装编译工具 yum -y install gcc gcc -c++ make cd /usr/src wget -P /usr/src http: //download .redis.io /releases/redis-5 .0.9. tar .gz tar -zxvf redis-5.0.9. tar .gz cd redis-5.0.9/ make && make PREFIX= /usr/local/redis install ln -s /usr/local/redis/bin/ * /usr/local/bin/ cd /usr/src/redis-5 .0.9 /utils/ . /install_server .sh #出现Please select the redis port for this instance: [6379]一直回车直达出现Please select the redis executable path [] 手动输入/usr/local/redis/bin/redis-server netstat -lnupt | grep redis cd /usr/lib/systemd/system/ cat >>redis.service |
2.修改Master节点的配置文件
1 2 3 4 5 6 7 8 9 10 11 12 | [root@master ~] # cp /etc/redis/6379.conf{,.bak} [root@master ~] # vim /etc/redis/6379.conf bind 0.0.0.0 #70行,注释掉bind项,或修改为0.0.0.0,默认监听所有网卡 daemonize yes #137行,开启守护进程 logfile /var/log/redis_6379 .log #172行,指定日志文件目录 dir /var/lib/redis/6379 #264行,指定工作目录 requirepass 123456 #7508行,指定redis登录密码,可不设置 appendonly yes #700行,开启AOF持久化功能 #重启redis [root@master ~] #systemctl start redis |
3.修改slave1和slave2两个从节点
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | [root@slave1 ~] # cp /etc/redis/6379.conf{,.bak} [root@slave1 ~] # vim /etc/redis/6379.conf 70 bind 0.0.0.0 #将监听端口改为任意端口 137 daemonize yes #开启守护进程 172 logfile /var/log/redis_6379 .log #指定日志文件目录 264 dir /var/lib/redis/6379 #指定工作目录 287 replicaof 192.168.111.10 6379 #指定主节点的ip 和端口 700 appendonly yes #开启 AOF持久化 #重启slave1节点和slave2节点redis服务 [root@slave1 ~] # systemctl restart reids [root@slave2 ~] # systemctl restart reids |
4.验证主从效果
在Master节点上看日志
1 2 3 4 5 6 7 8 | [root@master ~] #tail -f /var/log/redis_6379.log [root@master ~] #redis-cli #登录redis 127.0.0.1:6379> info replication #查看 127.0.0.1:6379> set k1 1 #在主库创建文件在从库查看 OK 127.0.0.1:6379> get k1 存在 "1" 127.0.0.1:6379> |
在master上动态查看日志:
在master上验证从节点
四、哨兵部署
1 | [root@master ~] # cd /usr/src/redis-5.0.9/ |
1.修改哨兵模式的配置文件(所有节点操作)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | [root@master redis-5.0.9] # cp sentinel.conf{,.bak} [root@master redis-5.0.9] # vim sentinel.conf #修改配置文件 17 protected-mode no #关闭保护模式 21 port 26379 #哨兵默认端口号 26379 26 daemonize yes #开启后台运行 36 logfile " /var/log/sentinel .log #指定日志目录 65 dir "/var/lib/redis/6379" #数据文件 84 sentinel monitor mymaster 192.168.10.128 6379 2 #改变master节点地址,指定该哨兵节点监控192.168.10。128:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移 113 sentinel down-after-milliseconds mymaster 30000 #可以修改时间,判定服务器down掉的时间周期,默认30000毫秒(30秒) 146 sentinel failover-timeout mymaster 180000 #故障切换时间,故障节点的最大超时时间为180000 (180秒 ) [root@master redis-5.0.9] # scp sentinel.conf root@192.168.10.129:`pwd` [root@master redis-5.0.9] # scp sentinel.conf root@192.168.10.130:`pwd` |
2.启动哨兵模式所有节点都要启动
#注意:先启主节点master,再启从节点slave
1 2 3 4 5 6 7 | cd /usr/src/redis-5 .0.9/ [root@master redis-5.0.9] # redis-sentinel sentinel.conf & [1] 15986 [root@slave1 redis-5.0.9] # redis-sentinel sentinel.conf & [1] 61088 [root@slave2 redis-5.0.9] # redis-sentinel sentinel.conf & [1] 66369 |
3.在master查看哨兵信息
所有节点都可以查看哨兵info sentinel
1 | [root@master redis-5.0.9] # redis-cli -p 26379 info Sentinel |
五、验证哨兵,模拟故障
1 2 3 | [root@master redis-5.0.9] # ps -ef | grep redis [root@master redis-5.0.9] # systemctl stop reids #也可以杀死 Master 节点上redis-server的进程号 [root@master ~] # tail -f /var/log/sentinel.log #验证master是转换至从服务器 |
在Slave1上查看是否转换成功
1 | [root@slave1 redis-5.0.9] # redis-cli -p 26379 INFO Sentinel |
在Slave2上查看是否转换成功
1 | [root@slave2 redis-5.0.9] # redis-cli -p 26379 INFO Sentinel |
当原来的master修复后会做为slave从新加入
1 2 | [root@master redis-5.0.9] # redis-cli -p 26379 127.0.0.1:26379> info |
将权重值调成默认方便下次选举
1 2 3 | [root@slave1 redis-5.0.9] # redis-cli -h 192.168.10.128 -p 6379 config set slave-priority 100 [root@slave1 redis-5.0.9] # redis-cli -h 192.168.10.129 -p 6379 config set slave-priority 100 [root@slave1 redis-5.0.9] # redis-cli -h 192.168.10.130 -p 6379 config set slave-priority 100 |
总结 哨兵系统的搭建过程,有几点需要注意:
哨兵系统中的主从节点,与普通的主从节点并没有什么区别,故障发现和转移是由哨兵来控制和完成的。
哨兵节点本质上是Redis节点.
每个哨兵节点,只需要配置监控主节点,便可以自动发现其他的哨兵节点和从节点.
在哨兵节点启动和故障转移阶段,各个节点的配置文件会被重写(Config Rewrite)。
故障转移分三步
1.从下线的主服务的所有从服务里面挑选一个从服务, 将其转成主服务
2.已下线主服务的所有从服务改为复制新的主服务 挑选出新的主服务之后,领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令,复制新master。
3.将已下线的主服务设置成新的主服务的从服务, 当其回复正常时,复制新的主服务,变成新的主服务的从服务 当已下线的服务重新上线时,sentinel会向其发送slaveof命令, 让其成为新主的从。
查看[root@master redis-5.0.9]下的master节点信息
1 | sentinel master imooc-master |
查看[root@master redis-5.0.9]下的slaves节点信息
1 | sentinel slaves imooc-master |
查看[root@master redis-5.0.9]下的哨兵节点信息
1 | sentinel sentinels imooc-master |
到此这篇关于redis搭建哨兵模式实现一主两从三哨兵的文章就介绍到这了,更多相关redis 一主两从三哨兵内容请搜索IT俱乐部以前的文章或继续浏览下面的相关文章希望大家以后多多支持IT俱乐部!