当前位置: 首页 > news >正文

Redis 主从 + 哨兵集群部署

目录

一、 哨兵模式介绍

1. 概述

2. 实现原理

二、 实验步骤

1. 基础环境配置(所有节点)

2. 部署 Redis 主从集群

2.1 Redis 服务安装(通用步骤,三节点均执行)

2.2 编写 Systemd 服务脚本(通用步骤,三节点均执行)

2.3 修改 Redis 配置文件(分节点)

2.4 配置主从关系(从节点:slave01、slave02)

2.5 验证主从状态

3. 部署 Redis 哨兵集群

3.1 哨兵服务安装(通用步骤,三节点均执行)

3.2 修改哨兵配置文件(分节点,三节点均执行)

3.3 编写哨兵 Sytemd 服务脚本(通用步骤,三节点均执行)

3.4 启动哨兵服务(三节点均执行)

3.5 查看哨兵状态(任意哨兵节点执行)

3.6 故障转移测试 (模拟主节点故障)

关键注意事项


一、 哨兵模式介绍

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

1. 概述

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

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

2. 实现原理

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

sentinel monitor master-name ip port quorum

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

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

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

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

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

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

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

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

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

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

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

  • 发现主节点客观下线的哨兵节点(简称为A)向每个哨兵节点发送命令要求对方选自己成为领导者哨兵。
  • 如果目标哨兵节点没有选过其他哨兵,则会同意将A设置为领导者哨兵。
  • 如果A发现有超过一半并且超过 quorum 参数值的哨兵节点同意选自己成为领导者哨兵,那么A将成为领导者哨兵。
  • 当有多个哨兵同时参选时,有可能会出现没有任何节点当选的可能。如果出现此种情况,那么会等待一个随机时间重新开始下一轮参选,直到选出领导者哨兵为止。

选出领导者哨兵后,领导者哨兵会对主节点进行故障转移恢复。恢复过程可以分为以下3个步骤:

  • 在所有从节点中挑选一个节点作为新的主节点。挑选的基准是,首先过滤掉不健康的从节点;然后选择优先级最高的从节点;如果优先级无法区分,则选择赋值偏移量最大的从节点,如果仍无法区分,则选择runid 最小的从节点。
  • 更新主从状态。通过 slaveof no one 命令,让选出来的从节点成为主节点,通过 slaveof 命令让其他节点成为其从节点。
  • 将已经停止服务的旧的主节点更新为新的主节点的从节点,当此节点恢复后,能够自动以从节点的身份继续服务。

二、 实验步骤

实验需要环境

操作系统配置IP主机名角色
0penEuler242C4G192.168.10.104sentine101哨兵节点
0penEuler242C4G192.168.10.105sentine102哨兵节点
0penEuler242C4G192.168.10.106sentine103哨兵节点
0penEuler242C4G192.168.10.101master主节点
0penEuler242C4G192.168.10.102slave0l从节点
0penEuler242C4G192.168.10.103slave02从节点

1. 基础环境配置(所有节点)

(1) 关闭防火墙、SELinux。

systemctl stop firewalld  
systemctl disable firewalld  

(2) 设置主机名

  • 主节点
hostnamectl set-hostname master  
  • 从节点 1
hostnamectl set-hostname slave01  
  • 从节点 2
hostnamectl set-hostname slave02  
  • 哨兵节点 1
hostnamectl set-hostname sentine101  
  • 哨兵节点 2
hostnamectl set-hostname sentine102  
  • 哨兵节点 3
hostnamectl set-hostname sentine103  

2. 部署 Redis 主从集群

操作节点:master、slave01、slave02

2.1 Redis 服务安装(通用步骤,三节点均执行)

# 安装编译依赖  
yum -y install gcc zlib-devel# 解压&编译安装  
tar -zxvf redis-6.2.4.tar.gz -C /usr/src/  
cd /usr/src/redis-6.2.4/  
make && make PREFIX=/usr/local/redis install  # 配置软链接  
ln -s /usr/local/redis/bin/* /usr/local/bin/  # 准备配置文件目录  
mkdir /etc/redis  
cp /usr/src/redis-6.2.4/redis.conf /etc/redis/6379.conf  

2.2 编写 Systemd 服务脚本(通用步骤,三节点均执行)

cat > /etc/systemd/system/redis.service << EOF  
[Unit]  
Description=Redis  
After=network.target  [Service]  
Type=forking  
ExecStart=/usr/local/redis/bin/redis-server /etc/redis/6379.conf  [Install]  
WantedBy=multi-user.target  
EOF  

2.3 修改 Redis 配置文件(分节点)

(1)主节点

vim /etc/redis/6379.conf  
# 修改内容:  
bind 127.0.0.1 192.168.10.101  
port 6379  
daemonize yes  
pidfile /var/run/redis_6379.pid  
loglevel notice  
logfile "/var/log/redis_6379.log"  # 启动服务  
systemctl daemon-reload  
systemctl start redis  
systemctl enable redis  # 验证端口  
netstat -anpt | grep 6379  

(2)从节点 1

vim /etc/redis/6379.conf  
# 修改内容:  
bind 127.0.0.1 192.168.10.102  
port 6379  
daemonize yes  
pidfile /var/run/redis_6379.pid  
loglevel notice  
logfile "/var/log/redis_6379.log"  # 启动服务  
systemctl daemon-reload  
systemctl start redis  
systemctl enable redis  # 验证端口  
netstat -anpt | grep 6379  

(3)从节点 2

vim /etc/redis/6379.conf  
# 修改内容:  
bind 127.0.0.1 192.168.10.103  
port 6379  
daemonize yes  
pidfile /var/run/redis_6379.pid  
loglevel notice  
logfile "/var/log/redis_6379.log"  # 启动服务  
systemctl daemon-reload  
systemctl start redis  
systemctl enable redis  # 验证端口  
netstat -anpt | grep 6379  

2.4 配置主从关系(从节点:slave01、slave02)

vim /etc/redis/6379.conf  
# 添加:  
replicaof 192.168.10.101 6379  # 重启生效  
systemctl restart redis  

2.5 验证主从状态

(1) 主节点验证

redis-cli  
127.0.0.1:6379> info replication  
# 预期:role=master,connected_slaves=2(slave01、slave02)  

(2) 从节点验证

redis-cli  
127.0.0.1:6379> info replication  
# 预期:role=slave,master_host=192.168.10.101,master_link_status=up  

3. 部署 Redis 哨兵集群

操作节点:sentine101、sentine102、sentine103(步骤相同,以sentine101为例)

3.1 哨兵服务安装(通用步骤,三节点均执行)

# 安装依赖(若未装)  
yum -y install gcc gcc-c++ make  # 解压&编译(同主从)  
tar -zxvf redis-6.2.4.tar.gz -C /usr/src/  
cd /usr/src/redis-6.2.4/  
make && make install  # 准备配置文件  
mkdir /etc/redis  
cp /usr/src/redis-6.2.4/redis.conf /etc/redis/6379.conf  

3.2 修改哨兵配置文件(分节点,三节点均执行)

vim /etc/redis/6379.conf  
# 添加:  
sentinel monitor master 192.168.10.101 6379 2  # 监控主节点,quorum=2  
bind 0.0.0.0  # 允许所有IP通信  
daemonize yes  # 后台运行  

3.3 编写哨兵 Sytemd 服务脚本(通用步骤,三节点均执行)

cat > /etc/systemd/system/redis.service << EOF  
[Unit]  
Description=Redis  
After=network.target  [Service]  
Type=forking  
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/6379.conf  # 启动哨兵  [Install]  
WantedBy=multi-user.target  
EOF  

3.4 启动哨兵服务(三节点均执行)

systemctl daemon-reload  
systemctl start redis  
systemctl enable redis  # 验证进程(查看redis-sentinel)  
ps aux | grep redis  
# 预期:/usr/local/bin/redis-sentinel 0.0.0.0:6379 [sentinel]  

3.5 查看哨兵状态(任意哨兵节点执行)

redis-cli  
127.0.0.1:6379> info sentinel  
# 预期:sentinel_masters=1,master0=192.168.10.101:6379,slaves=2,sentinels=3  

3.6 故障转移测试 (模拟主节点故障)

(1) 停止主节点服务

systemctl stop redis  

(2) 观察哨兵自动切换

redis-cli  
127.0.0.1:6379> info sentinel  
# 预期:原主节点降级为从,某从节点(slave01/slave02)升级为主  

关键注意事项

  • 主机名一致性:确保所有哨兵节点的主机名严格为 sentine101sentine102sentine103,避免拼写错误。
  • IP 映射:所有配置中涉及主节点 IP 的地方(如 replicaofsentinel monitor),必须替换为 192.168.10.101
  • 服务脚本区分:Redis 主从和哨兵的 Systemd 脚本名称均为 redis.service,但启动命令不同(主从用 redis-server,哨兵用 redis-sentinel),需注意区分。

按此步骤执行,即可完成 主机名修正后 的 Redis 主从 + 哨兵集群部署。

http://www.xdnf.cn/news/909001.html

相关文章:

  • Python爬虫伪装
  • 校招 Java 面试基础题目解析学习指南含新技术实操要点
  • Android第十三次面试总结基础
  • 【工具变量】上市公司企业华证esg数据集(2009-2024年)
  • 在Window上安装和配置VTK9.x,并在QT项目中调试VTK是否可用
  • 2025远离Deno和Fresh
  • 5G 核心网中 NF 选择机制:基于优先级、权重与负载分担的策略解析
  • 靶场(十九)--靶场体会小白分享--Billyboss
  • Langgraph实战--在Agent中加入人工反馈
  • OLED(SSD306)移植全解-基于IIC
  • 零基础完成 Token 创建的全流程教学
  • 芋道源码 - 本地文件上传配置与实现
  • 【C++从零实现Json-Rpc框架】第六弹 —— 服务端模块划分
  • 配置sudo免密却不生效的问题
  • 【图论 强连通分量】P1653 [USACO04DEC] Cow Ski Area G|普及+
  • for(;;) 和while(1) 的无限循环用法对比,优缺点说明
  • PHP:Web 开发的强大基石与未来展望
  • 给网站添加live2d看板娘
  • 当主观认知遇上机器逻辑:减少大模型工程化中的“主观性”模糊
  • WHAT - script type=“module“
  • 通过Spring AI框架搭建mcp服务端说明
  • 【Block总结】DBlock,结合膨胀空间注意模块(Di-SpAM)和频域模块Gated-FFN|即插即用|CVPR2025
  • FineReport模板认证找不到模板
  • pyarmor加密python程序
  • 【DAY41】简单CNN
  • 深入浅出Java ParallelStream:高效并行利器还是隐藏的陷阱?
  • 【使用conda】安装pytorch
  • python:基于pyside6的桌宠源码分享
  • java面试场景提题:
  • 全球知名具身智能/AI机器人实验室介绍之AI FACTORY基于慕尼黑工业大学