Redis主从复制、哨兵、cluster集群原理+实验(好好等,会晚些,但会更好)(二)

简介: Redis主从复制、哨兵、cluster集群原理+实验(好好等,会晚些,但会更好)(二)

二、Redis哨兵模式


主从切换技术的方法是:当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制。


哨兵的核心功能:在主从复制的基础上,哨兵引入了主节点的自动故障转移。


2.1 哨兵模式的作用

监控:哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操,它会将失效主节点的其中一个从节点升级为新的主节点,并让其它从节点改为复制新的主节点。

通知(提醒):哨兵可以将故障转移的结果发送给客户端。

2.2 哨兵结构

哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的redis节点,不存储数据。

数据节点:主节点和从节点都是数据节点。

2.3 故障转移机制

1.由哨兵节点定期监控发现主节点是否出现了故障


每个哨兵节点每隔1秒会问主节点、从节点及其它哨兵节点发送一次ping命令做一次心检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息,那么这个哨兵就会认为这个主节点主观下线了(单方面的)。当超过半数哨兵节点认为该主节点主观下线了,这样就客观下线了。


2.当主节点出现故障,此时哨兵节点会通过Raft算法(选举算法)实现选举机制共同选举出一个哨兵节点为leader,来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。


3.由leader哨兵节点执行故障转移,过程如下:


将某一个从节点升级为新的主节点,让其它从节点指向新的主节点;

若原主节点恢复也变成从节点,并指向新的主节点;

通知客户端主节点已经更换。

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


2.4 主节点的选举

1.过滤掉不健康的(己下线的),没有回复哨兵ping响应的从节点。


2.选择配置文件中从节点优先级配置最高的。(replica-priority,默认值为100)


3.选择复制偏移量最大,也就是复制最完整的从节点。


哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式


2.5 搭建Redis哨兵模式


2.5.1 实验环境

主/从/哨兵 虚机 IP地址
master centos7-1 192.168.109.131
slave1 centos7-2 192.168.109.132
slave2 centos7-3 192.168.109.133
Sentinel-1 centos7-4 192.168.109.134
Sentinel-2 centos7-5 192.168.109.135
Sentinel-3 centos7-7 192.168.109.137

生产环境中哨兵节点再使用对应数量节点的服务器作为哨兵节点,实验环境中如果电脑性能不够可以把哨兵搭建在原虚机上


2.5.2 部署主从复制

参照1.3节部署


2.5.3 修改Redis哨兵模式的配置文件(所有哨兵节点操作)

vim /opt/redis-5.0.7/sentinel.conf
......
protected-mode no                #17行,关闭保护模式
port 26379                       #21行,Redis哨兵默认的监听端口
daemonize yes                    #26行,指定sentinel为后台启动
logfile "/var/log/sentinel.log"  #36行,指定日志存放路径
dir "/var/lib/redis/6379"        #65行,指定数据库存放路径
sentinel monitor mymaster 192.168.109.131 6379 2  #84行,修改
#指定该哨兵节点监控192.168.109.131:6379这个主节点,该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 3000  #113行,判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000  #146行,同一个sentinel对同一个master两次failover之间的间隔时间(180秒)






2.5.3 启动哨兵模式

#启动三台哨兵
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &



2.5.4 查看哨兵信息

redis-cli -p 26379 info Sentinel
#在哨兵节点查看
[root@localhost redis-5.0.7]# redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.109.131:6379,slaves=2,sentinels=3
[1]+  完成                  redis-sentinel sentinel.conf


2.5.5 模拟故障

#在Master 上查看redis-server进程号:
[root@localhost ~]# ps -ef | grep redis
root      56591      1  0 09:19 ?        00:00:29 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root      60440  13098  0 16:11 pts/1    00:00:00 grep --color=auto redis
#杀死 Master 节点上redis-server的进程号
[root@localhost ~]# kill -9 56591   #Master节点上redis-server的进程号
[root@localhost ~]# netstat -natp | grep redis
#在哨兵上验证master是转换至从服务器
tail -f /var/log/sentinel.log
[root@localhost redis-5.0.7]# tail -f /var/log/sentinel.log
20000:X 10 Jun 2022 16:12:49.635 # +failover-state-reconf-slaves master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:49.709 * +slave-reconf-sent slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.193 # -odown master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.665 * +slave-reconf-inprog slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.665 * +slave-reconf-done slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.741 # +failover-end master mymaster 192.168.109.131 6379
20000:X 10 Jun 2022 16:12:50.741 # +switch-master mymaster 192.168.109.131 6379 192.168.109.132 6379
20000:X 10 Jun 2022 16:12:50.742 * +slave slave 192.168.109.133:6379 192.168.109.133 6379 @ mymaster 192.168.109.132 6379
20000:X 10 Jun 2022 16:12:50.742 * +slave slave 192.168.109.131:6379 192.168.109.131 6379 @ mymaster 192.168.109.132 6379
20000:X 10 Jun 2022 16:13:20.781 # +sdown slave 192.168.109.131:6379 192.168.109.131 6379 @ mymaster 192.168.109.132 6379
#在哨兵上查看是否转换成功
[root@localhost redis-5.0.7]# redis-cli -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.109.132:6379,slaves=2,sentinels=3



目录
相关文章
|
11月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
770 2
|
9月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
930 6
|
10月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
11月前
|
存储 NoSQL 算法
Redis的集群架构与使用经验
本文介绍了Redis的集群架构与使用经验,包括主从复制、哨兵集群及Cluster分片集群的应用场景与实现原理。内容涵盖Redis主从同步机制、数据分片存储方式、事务支持及与Memcached的区别,并讨论了Redis内存用尽时的处理策略。适用于了解Redis高可用与性能优化方案。
|
NoSQL Redis 数据库
Redis 主从复制的核心原理
Redis 主从复制的核心原理
205 0
|
NoSQL Redis
Redis 主从复制架构配置及原理
Redis 主从复制架构配置及原理
328 5
|
消息中间件 存储 缓存
深入理解Redis集群主从复制原理
该文章主要探讨了Redis集群中的主从复制原理,包括为何需要主从复制、配置方法、复制流程以及一些高级特性。
深入理解Redis集群主从复制原理
|
负载均衡 NoSQL 容灾
|
负载均衡 NoSQL 关系型数据库
深入浅出Redis(六):Redis的主从架构与主从复制原理
深入浅出Redis(六):Redis的主从架构与主从复制原理
|
NoSQL Linux Redis
Linux中部署Redis主从复制,主从复制原理
Linux中部署Redis主从复制,主从复制原理
345 1