Redis哨兵模式

目录

一:介绍

二:资源列表

三:部署Redis主从

1.部署Redis服务

2.编写服务脚本

3.修改配置文件

4.主从配置

5.验证主从

四:部署哨兵节点

1.部署哨兵

2.修改配置文件

3.编写脚本服务

5.故障转移


一:介绍

在一主多从的 Redis 架构中,从节点可以起到数据冗余备份和读写分离的作用。如果主节点遇到故障导致无法提供服务时,可以采用手动方式将其一个从节点提升为主节点,保证 Redis 主从能够正常工作。主从切换通过手动完成比较耗时、费力,并且影响 Redis 正常服务。为此,Reids 提供了哨兵功能,实现了自动化的系统监控和故障恢复功能

1.概述

哨兵(Sentinel),主要负责监控主从节点运行是否正常,以及当主节点出现故障时自动将一个从节点转换为新的主节点。哨兵是一个独立的进程。,最基础的通用哨兵架构如下所示:

哨兵最基础架构由两部分组成,包括哨兵节点和数据节点。其中,哨兵节点是特殊的 Redis 节点,并不存储数据,出于高可用方面考虑,哨兵架构中通常都是多个哨兵节点共同提供服务。数据节点用于存储 Redis 数据。包括主节点和从节点

2.实现原理

哨兵节点的配置文件中需要添加如下配置:

其中,sentinel monitor 是配置哨兵的命令,接着是主节点的名称、IP 地址和端口号,最后的 quorum 用来表示执行故障恢复操作之前至少需要几个哨兵节点同意。一个哨兵节点可以同时监控多个 Reids 主从系统,多个哨兵节点也可以同时监控同一个 Redis 主从系统。

配置修改好之后,就可以启动哨兵节点了。当哨兵节点启动时,会与要监控的主数据库(master)建立连接,连接建立之后,哨兵会定时地执行以下3个任务:

  • 每 10 秒哨兵会向主节点和从节点发送 info 命令。
  • 每2秒哨兵会向主节点和从节点发送自己的信息。
  • 每1秒哨兵会向主节点、从节点和其他哨兵发送 ping 命令

这3个定时任务贯穿哨兵进程的整个生命周期,非常重要。

当哨兵节点启动后,会向主节点发送 info 命令,通过解析返回的结果可以获得从节点的列表,然后与每个从节点建立连接。

之后,哨兵会每隔 10 秒定时向所有已知主从节点发送 info 命令来获取西悉尼更新并进行相应的操作。

接下来哨兵会向主从节点发送信息与同样监控主从节点的哨兵分享自己的信息。当其他哨兵节点收到信息后,会判断发送信息的哨兵是不是新发现的哨兵,如果是则将其加入已发现的哨兵列表中并创建到该节点的连接,这样就实现了自动发现从节点和其他哨兵节点。

之后哨兵要做的就是监控主从节点是否停止服务,通过发送ping命令来实现的。

ping 命令是每隔1秒发送一次,如果被 ping 的节点超时一定的时间没有回复,哨兵就会认为其主观下线,是哨兵节点"主观地"判断下线。

如果该节点是主节点,则哨兵会进一步判断是否需要对其进行故障恢复,具体过程如下:该哨兵节点会询问其他哨兵节点来了解它们是否也认为该主节点已经主观下线,如果达到指定数量,则哨兵会认为其客观下线,此时各哨兵节点会进行协商,选举出一个领导者哨兵节点,并由该领导者哨兵节点对其进行故障转移操作。

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

领导者哨兵节点执行故障恢复可以保证同一时间内只有一个哨兵节点在执行故障恢复,避免多个节点同时操作。选举领导者哨兵的过程适用了 Raft 算法,具体的过程如下:

(1)在所有从节点中挑选一个节点作为新的主节点。挑选的基准是,首先过滤掉不健康的从节点;然后选择优先级最高的从节点;如果优先级无法区分,则选择赋值偏移量最大的从节点,如果仍无法区分,则选择runid 最小的从节点。

(2)更新主从状态。通过 slaveof no one 命令,让选出来的从节点成为主节点,通过 slaveof 命令让其他节点成为其从节点。

(3)将已经停止服务的旧的主节点更新为新的主节点的从节点,当此节点恢复后,能够自动以从节点的身份继续服务。

二:资源列表

|-----------|------|----------------|--------|------|
| 操作系统 | 配置 | ip | 主机名 | 角色 |
| openeuler | 2C4G | 192.168.10.101 | master | 主节点 |
| openeuler | 2C4G | 192.168.10.102 | slave1 | 从节点 |
| openeuler | 2C4G | 192.168.10.103 | slave2 | 从节点 |
| openeuler | 2C4G | 192.168.10.104 | | 哨兵节点 |
| openeuler | 2C4G | 192.168.10.105 | | 哨兵节点 |
| openeuler | 2C4G | 192.168.10.106 | | 哨兵节点 |

三:部署Redis主从

基础环境配置

关闭防火墙

修改主机名

1.部署Redis服务

master slave1 slave2 上执行

make && make PREFIX=/usr/local/redis install 只是安装了二进制文件到系统中,并没有启动脚本和配置文件。Redis 提供了默认的配置文件,将配置文件复制到/etc/目录下,然后编写服务脚本用于启动 Redis 及设置开机启动。当Redis 启动完成后,默认监听 6379 端口。

创建配置文件目录

使用默认配置文件

2.编写服务脚本

3.修改配置文件

(1)master节点

启动服务

(2)slave1节点

其他配置参考master

启动服务

(3)slave2节点

其他配置参考master

启动服务

4.主从配置

slave1 slave2上执行

5.验证主从

主节点执行

从节点执行

四:部署哨兵节点

1.部署哨兵

2.修改配置文件

sentinel monitor:哨兵命令

master:主节点名字

192.168.10.101 6379 2:主节点ip和端口,最后的2表示,当主节点出现故障,至少需要两个哨兵节点同意,才能判断主节点故障

3.编写脚本服务

启动服务

4.查看哨兵状态信息

5.故障转移

当主节点出现故障时,故障发现和转移是由哨兵来控制的,此时会将主节点切换到其他从节点上

下面手动模拟主节点出现故障,停止主节点上的 Redis 服务。具体操作如下:

关掉主节点之后,等待一会时间,在slave上查看哨兵系统状态将会发现,原来的主节点进行了切换。

当主节点进行切换后,一个从节点变成了主节点。此时从节点数量仍然是 2,是因为在进行主从切换时,原来的故障的节点会被设置为新主的从节点,哨兵系统并不会对故障节点进行客观下线,而是认为该从节点一致存在。当故障修复之后,将会变为新的从节点投入适用。

相关推荐
科技小花4 小时前
数据治理平台架构演进观察:AI原生设计如何重构企业数据管理范式
数据库·重构·架构·数据治理·ai-native·ai原生
一江寒逸4 小时前
零基础从入门到精通MySQL(中篇):进阶篇——吃透多表查询、事务核心与高级特性,搞定复杂业务SQL
数据库·sql·mysql
D4c-lovetrain4 小时前
linux个人心得22 (mysql)
数据库·mysql
阿里小阿希5 小时前
CentOS7 PostgreSQL 9.2 升级到 15 完整教程
数据库·postgresql
荒川之神5 小时前
Oracle 数据仓库雪花模型设计(完整实战方案)
数据库·数据仓库·oracle
做个文艺程序员5 小时前
MySQL安全加固十大硬核操作
数据库·mysql·安全
不吃香菜学java5 小时前
Redis简单应用
数据库·spring boot·tomcat·maven
一个天蝎座 白勺 程序猿6 小时前
Apache IoTDB(15):IoTDB查询写回(INTO子句)深度解析——从语法到实战的ETL全链路指南
数据库·apache·etl·iotdb
不知名的老吴6 小时前
Redis的延迟瓶颈:TCP栈开销无法避免
数据库·redis·缓存
YOU OU6 小时前
三大范式和E-R图
数据库