何小豆儿在此 发表于 3 天前

【Redis】redis主从哨兵

Redis 主从复制

在访问量极高的场景下,单台 Redis 已难以承载全部请求,且单点故障风险高。通过主从复制,可以实现读写分离、数据备份与高可用。
概念



[*]主节点(Master):负责写操作,将数据变动同步给从节点。
[*]从节点(Slave/Replica):负责读操作,主动从主节点拉取最新数据。
上风



[*]性能提升:读请求分摊到多个从节点
[*]数据备份:从节点持有一份完备数据副本
[*]读写分离:写入在主节点,读取在从节点
[*]进步可靠性:主节点故障后,从节点仍可提供读取服务
搭建主从复制集群

可以用两台机器,也可在一台机器上启动多个 Redis 实例,只需用不同设置文件。
通用设置(主从共用)

requirepass 123456
loglevel notice
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis/redis6379.log"
dbfilename dump.rdb
dir /var/lib/redis-slave6379
bind 0.0.0.0
port 6379
daemonize yes
从节点额外设置

masterauth 123456
replicaof 192.168.100.30 6379

[*] 先启动主节点,再启动从节点。
[*] 验证主从状态:
# 主节点
192.168.100.30:6379> info replication
role:master
connected_slaves:2
...

# 从节点
192.168.100.200:6389> info replication
role:slave
master_host:192.168.100.30
master_link_status:up
...

[*] 测试读写

[*]主节点:可读可写
[*]从节点:只读,写入会报 READONLY You can't write against a read only replica.

[*] 断线重连
如果从节点短暂断开,重新上线后会主动补同步这段时间的全部数据,不会丢失。
[*] 故障规复
主节点宕机,从节点不会主动“上位”。需人工或由哨兵进行故障转移。
主从从拓扑

当主节点被大量从节点挂载压力过大时,可使用“主→从→从”多级复制。
# 从节点命令示例,将当前实例从现有主切到新的主
192.168.100.200:6389> SLAVEOF 192.168.100.200 6379
   注意:多级复制会引入更高的耽误。
退出从模式(无停机)

如果临时必要让某个从节点切换为主:
192.168.100.200:6389> SLAVEOF no one
OK
192.168.100.200:6389> info replication
role:master
connected_slaves:0
...
日志中会看到从节点断开主节点毗连并开启主模式的记录。
主从复制工作流程


[*]从节点启动 → 毗连主节点 → 发送 SYNC(或 PSYNC)下令
[*]主节点

[*]收到同步请求后后台生成一次完备的 RDB 快照
[*]将快照数据发送给从节点
[*]在生成快照期间及之后,将新的写下令缓存在内存并实时转发给从节点

[*]心跳

[*]默认每 10 秒发送一次 PING 确保主从毗连正常,可通过 repl-ping-replica-period 调解

Redis 哨兵(Sentinel)

Sentinel 负责监控主从集群康健,主动故障转移并通知客户端。
Sentinel 核心功能



[*]主从监控:实时检测主、从节点是否可用
[*]故障通知:将故障及切换效果告知客户端
[*]主动故障转移:主节点挂掉时,选举新的主节点并重设置全部从节点
[*]设置中央:主动更新 Redis 和 Sentinel 的设置文件
部署示例


[*] 预备一主二从,分别启动:
redis-server /etc/redis6379.conf   # 主
redis-server /etc/redis6389.conf   # 从1
redis-server /etc/redis6399.conf   # 从2

[*] 设置并启动三台 Sentinel(发起奇数台):
bind 0.0.0.0
protected-mode no
port 26379
daemonize yes
pidfile /var/run/redis-sentinel26379.pid
logfile "/redisdata/sentinel26379.log"
dir /redisdata

sentinel monitor mymaster 192.168.100.131 6379 2
sentinel auth-pass mymaster 123456
启动下令任选其一:
redis-sentinel /etc/sentinel26379.conf
# 或
redis-server /etc/sentinel26379.conf --sentinel

[*] 查看 Sentinel 日志,确认监控已见效。
故障转移流程


[*]主观宕机判定(Sentinel 认为主不可达),标记 +sdown
[*]投票:至少 quorum 台 Sentinel 同意
[*]客观宕机确认,标记 +odown
[*]设置更新:Sentinel 更新自身及 Redis 实例设置
[*]切换主节点,+switch-master
[*]旧主规复:如果旧主重启,按设置会被设为从节点,不再主动成为主
186501:X 19 Apr 2025 12:13:52.675 # +sdown master mymaster 192.168.100.30 6379
186501:X 19 Apr 2025 12:13:52.736 # +new-epoch 1
186501:X 19 Apr 2025 12:13:52.737 # +vote-for-leader 8e9617be2327ed19c589ee819bc725eb892ad700 1
186501:X 19 Apr 2025 12:13:52.747 # +odown master mymaster 192.168.100.30 6379 #quorum 3/2
186501:X 19 Apr 2025 12:13:53.874 # +switch-master mymaster 192.168.100.30 6379 192.168.100.200 6389
这些日志行展示了完备的故障转移过程:

[*]首先检测到主节点宕机(+sdown)
[*]开始新的选举周期(+new-epoch)
[*]投票给指定的哨兵领导者(+vote-for-leader)
[*]确认主节点客观宕机(+odown)
[*]最终完成主节点切换(+switch-master),将主节点从192.168.100.30:6379切换到192.168.100.200:6389
常见题目排查


[*]网络连通:防火墙、端口、SELinux 是否放行/关闭
[*]认证密码:主从与 Sentinel 之间密码需同等
[*]日志检查:从节点或 Sentinel 日志中有无错误提示
[*]资源瓶颈:Redis 实例的 CPU、内存、磁盘 IO 是否到达上限
   小贴士:生产环境中发起团结 Redis Cluster 或者更美满的高可用方案,根据业务需求选择合适的架构。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 【Redis】redis主从哨兵