Linux CentOS7.9安装redis7.0.15以及部署主从架构和哨兵模式

淡墨青岚

305人浏览 · 2026-06-24 10:59:53

淡墨青岚 · 2026-06-24 10:59:53 发布

摘要：本文详细记录了在 CentOS 环境下部署 Redis 7.0.15 高可用集群的完整实验过程。实验采用一主二从（node1 为主节点，node2、node3 为从节点）的 Redis 主从架构，并配置三哨兵（Sentinel）集群实现自动故障转移。主要内容包括：1）实验环境规划与基础配置；2）Redis 主从同步配置与验证；3）Sentinel 哨兵集群部署与监控；4）故障转移实验验证。通过本实验，读者可以掌握 Redis 高可用集群的部署、配置与故障恢复机制。

📑 目录

1. 实验规划
2. Redis 主从架构实验(一主二从)
3. 配置哨兵监控集群
- 3.1 三哨兵集群配置
- 3.2 启动Sentinel集群并验证
4. 故障转移实验

实验规划

角色规划

主机	IP	初始角色
node1	19.16.2.162	master
node2	19.16.2.163	slave
node3	19.16.2.164	slave

环境规划

查看系统内核信息及网络通信情况

cat /etc/redhat-release
ip addr
ping  19.16.2.162 -c2  &> /dev/null ; echo $?
ping  node1 -c2  &> /dev/null ; echo $?
ping  19.16.2.163 -c2  &> /dev/null ; echo $?
ping  node2 -c2  &> /dev/null ; echo $?
ping  19.16.2.164 -c2  &> /dev/null ; echo $?
ping  node3 -c2  &> /dev/null ; echo $?

实验环境下关闭防火墙以及selinux

systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

内核参数优化

sysctl vm.overcommit_memory=1
echo never > /sys/kernel/mm/transparent_hugepage/enabled

所有节点实验前通用准备

配置主机名

cat >>/etc/hosts<<'EOF'
19.16.2.162 node1
19.16.2.163 node2
19.16.2.164 node3
EOF
cat /etc/hosts

安装依赖

yum install -y gcc gcc-c++ make

创建运行用户与目录规范

useradd -s /sbin/nologin -M redis
mkdir -pv /etc/redis /var/lib/redis/6379 /var/lib/redis/sentinel /var/log/redis /var/run
chown -R redis:redis /etc/redis /var/lib/redis /var/log/redis /var/run

上传及安装redis（为方便实验，源码包均上传至/opt下,资源包已随文上传）

cd /opt
tar zxf redis-7.0.15.tar.gz
cd redis-7.0.15
make -j$(nproc); echo $?
# 安装到系统路径，全局可用
make install PREFIX=/usr/local/redis;echo $?
ln -sv /usr/local/redis/bin/* /usr/local/bin/
readlink -f /usr/local/bin/redis-server # 查找软链接源文件
# 验证安装：执行 redis-server -v，redis-cli -v 输出版本号即安装成功。

在这里插入图片描述

Redis 主从架构实验(一主二从)

核心配置说明

所有Redis节点统一设置访问密码，保证安全
所有节点同时配置masterauth：故障转移后原主节点会自动变为从节点，无需手动修改配置
开启RDB+AOF双持久化，保证数据安全

主节点（node1）配置

在node1创建Redis配置文件：

cat > /etc/redis/redis_6379.conf << 'EOF'
# 监听地址，允许内网访问，生产建议替换为具体内网IP
bind 0.0.0.0
port 6379
# 后台守护进程运行
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis/redis_6379.log
# 数据持久化目录
dir /var/lib/redis/6379

# 访问密码，生产环境请修改为复杂密码
requirepass 123456
# 主从同步认证密码，与上面密码完全一致
masterauth 123456

# RDB持久化策略
save 900 1
save 300 10
save 60 10000
rdbcompression yes

# AOF持久化
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# 从节点默认只读
replica-read-only yes
EOF

从节点（node2/node3）配置

node2和node3配置与主节点几乎完全一致，仅新增一行指定主节点地址。以node2为例，node3操作完全相同：

cat > /etc/redis/redis_6379.conf << 'EOF'
bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis/redis_6379.log
dir /var/lib/redis/6379

requirepass 123456
masterauth 123456

save 900 1
save 300 10
save 60 10000
rdbcompression yes

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

replica-read-only yes
# 唯一新增：指定初始主节点的IP和端口
replicaof 19.16.2.162 6379
EOF

注意：将replicaof后的IP替换为你node1的实际IP。

配置Systemd服务（所有节点）

配置系统服务，实现开机自启、后台稳定运行：

cat > /usr/lib/systemd/system/redis_6379.service << 'EOF'
[Unit]
Description=Redis 6379 Service
After=network.target

[Service]
Type=forking
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-server /etc/redis/redis_6379.conf
ExecStop=/usr/local/bin/redis-cli -a 123456 -p 6379 shutdown
Restart=always
RestartSec=5
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF

启动Redis并验证主从同步

所有节点启动Redis服务

systemctl daemon-reload
systemctl start redis_6379
systemctl enable redis_6379
systemctl status redis_6379

验证主节点状态（node1执行）

redis-cli -a 123456 info replication

预期输出核心信息：

role:master
connected_slaves:2
slave0:ip=192.168.10.102,port=6379,state=online
slave1:ip=192.168.10.103,port=6379,state=online

输出信息如下:
在这里插入图片描述

验证从节点状态（node2/node3执行）

redis-cli -a 123456 info replication

预期输出核心信息：
role:slave
master_host:192.168.10.101
master_link_status:up

出现master_link_status:up说明主从同步成功，若为down请检查网络、防火墙、密码是否一致。
在这里插入图片描述
输出信息如下:
19.16.2.163
19.16.2.164

配置哨兵监控集群

三哨兵集群配置

sentinel哨兵核心参数说明

在这里插入图片描述

所有节点Sentinel配置

三台机器执行完全相同的配置，仅需修改主节点IP为你的node1地址：

cat > /etc/redis/sentinel_26379.conf << 'EOF'
# Sentinel端口
port 26379
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis-sentinel_26379.pid
logfile /var/log/redis/sentinel_26379.log
# 工作目录，存放运行时自动更新的配置
dir /var/lib/redis/sentinel

# 监控主节点：名称mymaster + 初始主节点IP端口 + quorum=2
sentinel monitor mymaster 19.16.2.162 6379 2
# 主节点认证密码
sentinel auth-pass mymaster 123456
# 主观下线超时：30秒无响应判定主观下线
sentinel down-after-milliseconds mymaster 30000
# 故障转移后并行同步从节点数
sentinel parallel-syncs mymaster 1
# 故障转移超时时间：3分钟
sentinel failover-timeout mymaster 180000

# 关闭保护模式，允许跨节点通信
protected-mode no
EOF

mymaster不是 node1 的主机名，也不是服务器的主机名/IP，它是 Sentinel 集群给「这一整套被监控的主从集群」起的自定义逻辑名称（集群标识名），和服务器 hostname 没有任何对应关系。

配置Sentinel系统服务（所有节点）

cat > /usr/lib/systemd/system/redis-sentinel_26379.service << 'EOF'
[Unit]
Description=Redis Sentinel 26379 Service
After=network.target redis_6379.service

[Service]
Type=forking
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/sentinel_26379.conf
ExecStop=/usr/local/bin/redis-cli -p 26379 shutdown
Restart=always
RestartSec=5
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF

修改目录属性

修正属主

chown redis:redis /etc/redis/sentinel_26379.conf

确保目录也对 redis 可写

chown -R redis:redis /var/log/redis
chown -R redis:redis /var/lib/redis/sentinel

保证pid 目录存在

mkdir -p /var/lib/redis/sentinel
chown redis:redis /var/lib/redis/sentinel

启动Sentinel集群并验证

所有节点启动哨兵服务

systemctl daemon-reload
systemctl start redis-sentinel_26379
systemctl enable redis-sentinel_26379
systemctl status redis-sentinel_26379

验证哨兵集群状态（任意节点执行）

redis-cli -p 26379 info sentinel

查询当前主节点地址

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

正常返回初始主节点的IP和端口6379。
在这里插入图片描述

三台设备轮流执行以上命令启动后,可以看到哨兵集群状态sentinels=1变成3

19.16.2.162上
在这里插入图片描述 19.16.2.163上
19.16.2.164上
至此哨兵集群部署成功且正常

故障转移实验

在初始node1上(19.16.2.162)关闭redis

systemctl stop redis_6379

在node2或node3上观察哨兵日志

tail -f /var/log/redis/sentinel_26379.log

日志输出如下:
[root@node2 ~]# tail -f /var/log/redis/sentinel_26379.log
1048:X 23 Jun 2026 14:15:30.451 * Sentinel new configuration saved on disk
1048:X 23 Jun 2026 14:15:30.452 # +new-epoch 1
1048:X 23 Jun 2026 14:15:30.453 * Sentinel new configuration saved on disk
1048:X 23 Jun 2026 14:15:30.453 # +vote-for-leader d283308e1190f66bc6438a9c075a796e600f24c0 1
1048:X 23 Jun 2026 14:15:31.411 # +config-update-from sentinel d283308e1190f66bc6438a9c075a796e600f24c0 19.16.2.162 26379 @ mymaster 19.16.2.162 6379
1048:X 23 Jun 2026 14:15:31.411 # +switch-master mymaster 19.16.2.162 6379 19.16.2.163 6379
1048:X 23 Jun 2026 14:15:31.411 * +slave slave 19.16.2.164:6379 19.16.2.164 6379 @ mymaster 19.16.2.163 6379
1048:X 23 Jun 2026 14:15:31.411 * +slave slave 19.16.2.162:6379 19.16.2.162 6379 @ mymaster 19.16.2.163 6379
1048:X 23 Jun 2026 14:15:31.414 * Sentinel new configuration saved on disk
1048:X 23 Jun 2026 14:16:01.421 # +sdown slave 19.16.2.162:6379 19.16.2.162 6379 @ mymaster 19.16.2.163 6379

日志逐行解读:

日志时间点	日志内容	含义说明
14:15:30	`+new-epoch 1`	哨兵集群进入新的纪元（版本号），表示一次新的故障转移周期开始
14:15:30	`+vote-for-leader ...`	哨兵开始投票选举故障转移执行 Leader
14:15:31	`+config-update-from sentinel ... 19.16.2.162`	node1 上的哨兵也参与了配置同步
14:15:31	`+switch-master mymaster 19.16.2.162 6379 → 19.16.2.163 6379`	核心结果：主节点正式切换为 node2
14:15:31	`+slave slave 19.16.2.164`	node3 自动成为新主的从节点
14:15:31	`+slave slave 19.16.2.162`	原主 node1 被标记为新主的一个从节点（即使当前未上线）
14:15:31	`Sentinel new configuration saved on disk`	哨兵自动重写并持久化了最新拓扑
14:16:01	`+sdown slave 19.16.2.162:6379`	原主仍停机，被哨兵判定为主观下线从节点

验证故障转移结果

验证新主节点状态

在新主节点（node2 19.16.2.163）执行：

redis-cli -a 123456 info replication

在这里插入图片描述

验证剩余从节点状态

在node3（19.16.2.164）执行：

redis-cli -a 123456 info replication

在这里插入图片描述

验证哨兵集群视角的主节点变更

任意节点执行：

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

在这里插入图片描述

原主节点恢复验证

在node1（原主节点）重启Redis服务：

systemctl start redis_6379
systemctl status redis_6379

在这里插入图片描述
等待30秒后验证：

redis-cli -a 123456 info replication

在这里插入图片描述
至此故障转移实验完全成功

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

Grok 里面的表格怎么复制？用 AI 导出鸭安卓版告别粘贴错乱难题

AI编程社区

前端AI工具链的下半年展望：Agent化、多模态能力与自主调试的演进方向

前端AI工具链的下半年，确定性最高的是Agent化——多步骤任务执行能力将显著提升。最值得关注但可能跳票的是设计稿到可交互组件的生成——视觉还原已经不是瓶颈，交互逻辑的生成才是。现在就做的事。让团队全员使用Cursor/Copilot级别的AI工具，建立"AI辅助编码"的基础习惯。不做这件事的团队，下半年会发现自己和竞争对手不在同一条基准线上。下半年评估的事。在1-2个非关键项目中尝试Agent模

AI编程社区

最新codex安装以及必装skill

本文介绍 Codex 的安装环境准备、详细安装步骤，以及 12 个必装 skill 的安装命令。

AI编程社区

所有评论(0)

查看更多评论

淡墨青岚

@2502_94124179

已为社区贡献2条内容

Linux CentOS7.9安装redis7.0.15以及部署主从架构和哨兵模式

淡墨青岚

📑 目录

实验规划

角色规划

环境规划

查看系统内核信息及网络通信情况

实验环境下关闭防火墙以及selinux

内核参数优化

所有节点实验前通用准备

配置主机名

安装依赖

创建运行用户与目录规范

上传及安装redis（为方便实验，源码包均上传至/opt下,资源包已随文上传）

Redis 主从架构实验(一主二从)

核心配置说明

主节点（node1）配置

从节点（node2/node3）配置

配置Systemd服务（所有节点）

启动Redis并验证主从同步

所有节点启动Redis服务

验证主节点状态（node1执行）

验证从节点状态（node2/node3执行）

配置哨兵监控集群

三哨兵集群配置

sentinel哨兵核心参数说明

所有节点Sentinel配置

配置Sentinel系统服务（所有节点）

修改目录属性

修正属主

确保目录也对 redis 可写

保证pid 目录存在

启动Sentinel集群并验证

所有节点启动哨兵服务

验证哨兵集群状态（任意节点执行）

查询当前主节点地址

三台设备轮流执行以上命令启动后,可以看到哨兵集群状态sentinels=1变成3

故障转移实验

在初始node1上(19.16.2.162)关闭redis

在node2或node3上观察哨兵日志

验证故障转移结果

验证新主节点状态

验证剩余从节点状态

验证哨兵集群视角的主节点变更

原主节点恢复验证

所有评论(0)

温馨提示：您尚未绑定手机号

淡墨青岚