Redis高可用——哨兵模式

一、Redis 哨兵模式

主从切换技术的方法是:当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制。

哨兵的核心功能:在主从复制的基础上,哨兵引入了主节点的自动故障转移。

1.哨兵模式的作用

●监控:哨兵会不断地检查主节点和从节点是否运作正常。

●自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其它从节点改为复制新的主节点。

●通知(提醒):哨兵可以将故障转移的结果发送给客户端。

哨兵结构由两部分组成,哨兵节点和数据节点:
●哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的redis节点,不存储数据。
●数据节点:主节点和从节点都是数据节点。

2.故障转移机制

  1. 由哨兵节点定期监控发现主节点是否出现了故障
    每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息,那么这个哨兵就会认为这个主节点主观下线了(单方面的)。当超过半数哨兵节点认为该主节点主观下线了,这样就客观下线了。

  2. 当主节点出现故障,此时哨兵节点会通过Raft算法(选举算法)实现选举机制共同选举出一个哨兵节点为leader,来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。

  3. 由leader哨兵节点执行故障转移,过程如下:
    ●将某一个从节点升级为新的主节点,让其它从节点指向新的主节点;
    ●若原主节点恢复也变成从节点,并指向新的主节点;
    ●通知客户端主节点已经更换。

需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作。

3.主节点的选举

1.过滤掉不健康的(已下线的),没有回复哨兵 ping 响应的从节点。
2.选择配置文件中从节点优先级配置最高的。(replica-priority,默认值为100)
3.选择复制偏移量最大,也就是复制最完整的从节点。

哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式

二、搭建Redis 哨兵模式

Master节点:192.168.30.50
Slave1节点:192.168.30.40
Slave2节点:192.168.30.30

systemctl stop firewalld
setenforce 0

1.修改 Redis 哨兵模式的配置文件(所有节点操作)

cp /opt/redis-7.0.9/sentinel.conf /usr/local/redis/conf/
chown redis.redis /usr/local/redis/conf/sentinel.conf

vim /usr/local/redis/conf/sentinel.conf
protected-mode no									#6行,关闭保护模式
port 26379											#10行,Redis哨兵默认的监听端口
daemonize yes										#15行,指定sentinel为后台启动
pidfile /usr/local/redis/log/redis-sentinel.pid		#20行,指定 PID 文件
logfile "/usr/local/redis/log/sentinel.log"			#25行,指定日志存放路径
dir /usr/local/redis/data							#54行,指定数据库存放路径
sentinel monitor mymaster 192.168.30.50 6379 2		#73行,修改 指定该哨兵节点监控192.168.30.50:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移
#sentinel auth-pass mymaster abc123					#76行,可选,指定Master节点的密码,仅在Master节点设置了requirepass
sentinel down-after-milliseconds mymaster 3000		#114行,判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000			#214行,同一个sentinel对同一个master两次failover之间的间隔时间(180秒)

2.启动哨兵模式

先启master,再启slave
cd /usr/local/redis/conf/
redis-sentinel sentinel.conf &

在这里插入图片描述

3.查看哨兵信息

redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.30.50:6379,slaves=2,sentinels=3

在这里插入图片描述

4.故障模拟

查看redis-server进程号:
ps -ef | grep redis
root       65210      1  0 14:11 ?        00:00:04 redis-sentinel *:26379 [sentinel]
redis      65225      1  0 14:21 ?        00:00:02 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root       65241   4316  0 14:44 pts/2    00:00:00 grep --color=auto redis

杀死 Master 节点上redis-server的进程号
kill -9 65210			Master节点上redis-server的进程号

在这里插入图片描述

5.验证结果

tail -f /usr/local/redis/log/sentinel.log
7578:X 03 Jul 2023 14:51:40.505 * +slave-reconf-done slave 192.168.30.40:6379 192.168.30.40 6379 @ mymaster 192.168.30.50 6379
7578:X 03 Jul 2023 14:51:40.561 # +failover-end master mymaster 192.168.30.50 6379
7578:X 03 Jul 2023 14:51:40.561 # +switch-master mymaster 192.168.30.50 6379 192.168.30.30 6379
7578:X 03 Jul 2023 14:51:40.561 * +slave slave 192.168.30.40:6379 192.168.30.40 6379 @ mymaster 192.168.30.30 6379
7578:X 03 Jul 2023 14:51:40.561 * +slave slave 192.168.30.50:6379 192.168.30.50 6379 @ mymaster 192.168.30.30 6379
7578:X 03 Jul 2023 14:51:40.563 * Sentinel new configuration saved on disk
7578:X 03 Jul 2023 14:51:43.570 # +sdown slave 192.168.30.50:6379 192.168.30.50 6379 @ mymaster 192.168.30.30 6379
7578:X 03 Jul 2023 14:58:42.527 # -sdown slave 192.168.30.50:6379 192.168.30.50 6379 @ mymaster 192.168.30.30 6379
7578:X 03 Jul 2023 14:58:52.461 * +reboot slave 192.168.30.50:6379 192.168.30.50 6379 @ mymaster 192.168.30.30 6379
7578:X 03 Jul 2023 15:02:21.767 # +sdown slave 192.168.30.50:6379 192.168.30.50 6379 @ mymaster 192.168.30.30 6379

redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.30.30:6379,slaves=2,sentinels=3

在这里插入图片描述
在这里插入图片描述

  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis集群模式和哨兵模式有以下几个区别: 1. 数据存储方式:在哨兵模式下,多个Redis服务器存储的是相同的数据,这样会比较浪费存储空间。而在集群模式下,Redis的数据是被分布式存储的,可以更好地利用存储资源。 2. 主从同步架构:哨兵模式主要是为Redis主从同步架构服务的。当主节点宕机时,哨兵会进行监控、通知和选举,以确保系统的高可用性。而集群模式则是将数据分布到多个节点上,实现了数据的分布式存储和负载均衡。 3. 故障转移机制:在哨兵模式中,故障转移时需要大部分的哨兵节点都同意才能进行,涉及到了分布式选举的问题。即使部分哨兵节点挂掉了,哨兵集群仍然可以正常工作,保证了高可用性。而在集群模式中,节点之间通过Gossip协议进行通信,使用Raft一致性算法来实现故障转移,保证了数据的一致性和高可用性。 总结来说,哨兵模式适用于主从同步架构下的高可用性需求,而集群模式适用于需要分布式存储和负载均衡的场景。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [Redis 哨兵模式、集群模式](https://blog.csdn.net/weixin_43889841/article/details/117483197)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值