文章目录
- 一、概念
- 手动恢复redis主从复制的流程
- 自动回复redis主从复制的流程
- 二、部署
- 三、哨兵节点的作用演示
- 四、哨兵节点的原理
一、概念
Redis Sentinel 相关名词解释
我主要说一个场景，就是我们上一篇讲到的redis主从复制会遇到的问题，朱姐带你如果挂掉了，怎么办？
手动恢复redis主从复制的流程
我们的主从节点出现问题了，我们该如何解决呢？
步骤如下：
1.先看看主节点还能不能抢救？好不好抢救回来
2.如果短时间难以解决就，就需要手动挑选一个作为主节点。
a）把选中的从节点，通过slaveof no one 确定为主节点。
b)再把其他的从节点，修改slave of的主节点 ip port，连接上新的主节点。
c) 告知客户端，让客户端能够连接新的主节点，用来完成修改数据的操作。
自动回复redis主从复制的流程
我主要围绕着这里面的架构来说
这里提供了多个redise sentinel 进程。并且这三个哨兵进程会健康现有的redis master和slave。
我来解释一下如何进行主节点的回复流程了。
1.主节点挂之后，所有的哨兵节点都要确认一遍主节点是否已经挂了。
2.确认主节点挂之后，哨兵节点就会推选出一个leader ，这个leader就会作为一个新的节点。
3.挑选出新节点以后，哨兵节点，就会自动控制被选中节点，并且控制其他从节点，修改slaveof到新的主节点上。
4.最后哨兵会通知客户端程序，告知主节点是谁，并且后续客户端，再进行写操作，就会针对新的节点进行操作了。
二、部署
我们现在要给予docker部署一个哨兵和主从结合的拓扑结构
- 安装docker
# centos
yum install docker-compose
- 停止本机自带的redis
service redis-server stop
- 使用docker获取redis的镜像
docker pull redis:5.0.9
- 编辑redis的主从节点
- 在root/redis/redis-data/docker-compose.yml
version: '3.7'
services:
master:
image: 'redis:5.0.9'
container_name: redis-master
restart: always
command: redis-server --appendonly yes
ports:
- 6379:6379
slave1:
image: 'redis:5.0.9'
container_name: redis-slave1
restart: always
command: redis-server --appendonly yes --slaveof redis-master 6379
ports:
- 6380:6379
slave2:
image: 'redis:5.0.9'
container_name: redis-slave2
restart: always
command: redis-server --appendonly yes --slaveof redis-master 6379
ports:
- 6381:6379
- 启动所有容器
docker-compose up -d
- 查看运行日志
判断我们redis主从节点配置好没有
docker-compose logs
- 验证
redis-cli -p 6379
- 编辑redis-sentinel
- 在/root/redis/redis-sentinel 新建docker-compose.yml
version: '3.7'
services:
sentinel1:
image: 'redis:5.0.9'
container_name: redis-sentinel-1
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel1.conf:/etc/redis/sentinel.conf
ports:
- 26379:26379
sentinel2:
image: 'redis:5.0.9'
container_name: redis-sentinel-2
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel2.conf:/etc/redis/sentinel.conf
ports:
- 26380:26379
sentinel3:
image: 'redis:5.0.9'
container_name: redis-sentinel-3
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel3.conf:/etc/redis/sentinel.conf
ports:
- 26381:26379
networks:
default:
external:
name: redis-data_default
- 创建 sentinel1.conf sentinel2.conf sentinel3.conf . 三份⽂件的内容是完全相同
的.
1 bind 0.0.0.0
2 port 26379
3 sentinel myid 5b62d008ce5fcea273e2df911f5243319c9232ad
4 sentinel deny-scripts-reconfig yes
配置文件的解释
这个配置文件是为Redis Sentinel服务设置的。Redis Sentinel是一个分布式系统，用于管理Redis服务的高可用性（HA）和故障转移。下面是对配置文件中每行的解释：
1. `bind 0.0.0.0`：这行配置指定Redis Sentinel监听所有网络接口上的请求。`0.0.0.0`是一个特殊的IP地址，表示所有网络接口。
2. `port 26379`：这行配置指定Redis Sentinel服务监听的端口号为26379。这是默认的Redis Sentinel端口。
3. `sentinel myid 5b62d008ce5fcea273e2df911f5243319c9232ad`：这行配置为这个Redis Sentinel实例指定了一个唯一的标识符（ID）。在Redis Sentinel集群中，每个实例都需要有一个唯一的ID，以区分不同的实例。
4. `sentinel deny-scripts-reconfig yes`：这行配置禁止了通过脚本来重新配置Redis Sentinel实例。这是一个安全措施，用来防止未授权的更改。
通常，Redis Sentinel的配置文件还会包含其他指令，比如定义主从关系、设置故障转移的参数、指定其他Sentinel实例的地址等，但这些内容没有在您提供的配置文件片段中显示。
- 启动容器
docker-compose up -d
- 观察redis-sentinel 的文件
发现里面的文件已经发生变化了
三、哨兵节点的作用演示
哨兵存在的意义就是当主从节点出现问题的时候，此时哨兵节点就能自动帮我们选举出一个主节点出来，来代替之前挂了的节点，保证整个redis仍然是可用的状态。
- 我们主动把主节点干掉
docker stop redis-master
2. 查看日志，发现哨兵已经发挥作用。
•主观下线 (Subjectively Down, SDown): 哨兵感知到主节点没⼼跳了. 判定为主观下线.
•客观下线 (Objectively Down, ODown): 多个哨兵达成⼀致意⻅, 才能认为 master 确实下线了.
- 验证主节点是否发生变化
4.
四、哨兵节点的原理
假定当前环境如上⽅介绍, 三个哨兵(sentenal1, sentenal2, sentenal3), ⼀个主节点(redis-master), 两
个从节点(redis-slave1, redis-slave2).当主节点出现故障, 就会触发重新⼀系列过程.
、
此时分为两种下线方式
- 主节点下线操作
- 主观下线
当 redis-master 宕机, 此时 redis-master 和三个哨兵之间的⼼跳包就没有了.此时, 站在三个哨兵的⻆度来看, redis-master 出现严重故障. 因此三个哨兵均会把 redis-master 判定
为主观下线 (SDown) - 客观下线
此时, 哨兵 sentenal1, sentenal2, sentenal3 均会对主节点故障这件事情进⾏投票. 当故障得票数 >= 配置的法定票数之后,此时意味触发下线操作。
- 选举出哨兵的leader
接下来需要哨兵把剩余的 slave 中挑选出⼀个新的 master. 这个⼯作不需要所有的哨兵都参与. 只需要选出个代表 (称为 leader), 由 leader 负责进⾏ slave 升级到 master 的提拔过程 - leader 挑选出合适的slave 成为新的master
- 最后剩余的slave都是指向新的master的。
