这篇文章主要讲解了如何使用Redis中的高可用组件sentinel,内容清晰明了,对此有兴趣的小伙伴可以学习一下,相信大家阅读完之后会有帮助。
今天我们来聊一下redis的高可用组件sentinel;首先来回顾下redis的主从同步,主从同步最主要的作用是让master的数据在其他服务器上实时存在副本,起到了备份的效果;对于redis的读写来说,主从架构能够让读的请求分散到多个从服务器上,从而降低了单台redis读请求的io压力,同时也提高了redis读请求的并发能力;通常为了数据的一致性,从服务器一旦成为某一台redis的slave,那么从服务器上之前有的数据会被清空,然后把master发送过来的数据应用到内存,从而实现和master数据一致;除此之外slave通常会是只读属性,也就说slave端只能执行读操作,写操作会被拒绝,所以写请求始终是由master来完成;那么问题来了,对于这种主从复制架构的环境中,如果master宕机了,master宕机意味着整个系统将不能够写数据到redis,很显然这种情况我们应该及时解决;怎么解决呢?有没有这样的一组件帮我们对master做实时的监控,一旦发现master宕机就提升一个slave当选新的master,如果原master还有其他slave,将其他slave都从属于新的master;除此之外它还应该让系统在发生切换master时触发报警通知,让管理员尽快把坏掉的master修复上线;对,sentinel就有我们上述的这些功能,它能够监控主从同步集群中的master节点,在master发生宕机后能够自动故障转移,将提升一台slave作为新的master,然后通知管理员;
Sentinel是一个分布式系统,我们可以在一个架构中运行多个sentinel,这些sentinel进程使用流言协议(gossipprotocols)来接收关于 Master是否下线的信息,并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个sentinel进程会向其他sentinel进程、master、slave定时发送消息,以确保对方是否”活”着,如果发现对方在指定配置时间(可配置的)内未得到回应,则暂时认为对方已掉线,也就是所谓的”主观认为宕机” ,英文名称:Subjective Down,简称 SDOWN。有主观宕机,肯定就有客观宕机。当多个sentinel进程中多数的sentinel进程在对 Master 做出 SDOWN 的判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的 Master Server 下线判断,这种方式就是“客观宕机”,英文名称是:Objectively Down, 简称 ODOWN。通过一定的 vote 算法,从剩下的 slave 从服务器节点中,选一台提升为 Master 服务器节点,然后自动修改相关配置,并开启故障转移(failover)。
配置使用sentinel
环境说明
角色 | ip地址 | 端口 |
master | 192.168.0.41 | 6379 |
slave01 | 192.168.0.42 | 6379 |
slave02 | 192.168.0.43 | 6379 |
sentinel01 | 192.168.0.41 | 26379 |
sentinel02 | 192.168.0.42 | 26379 |
sentinel03 | 192.168.0.43 | 26379 |
架构图
提示:从上面的架构图可以知道,首先我们必须要有一个主从架构的集群,然后在部署sentinel 来对主从同步集群做监控;
redis主从复制集群搭建
1、在192.168.0.41/42/43上安装redis,可以使用yum安装,也可以使用编译安装,redis安装请参考https://www.cnblogs.com/qiuhom-1874/p/13378138.html;
2、配置192.168.0.41/42/43上的redis监听在非本机127.0.0.1上并配置42/43上的redis从属于192.168.0.41
master
slave01
slave02
提示:redis支持在线修改配置,保存配置到配置文件;SLAVEOF 指令用于指定redismaster的ip地址和端口,表示把该redis配置成对应master的slave角色;CONFIG REWRITE是把我们的配置保存到配置文件;
在master上查看是否有两个从节点连接到master
验证:在master上写数据,看看是否能够及时同步到两个slave上?
提示:可以看到在主库上写数据,从库上能够及时的同步主库上的数据;到此redis的主从集群就搭建完毕了;
配置sentinel,让其监控master
提示:三个sentinel的配置都是一样的,这里需要明确指定监控主从同步集群的master的ip地址和端口,以及有效法定票数,有效法定票数指的是至少有多少个sentinel主观认为master down了,然后才触发选举新master操作;通常在这种流言协议中,一般都是大于集群半数,如果是3台sentinel,至少要2台主观认为master宕机,才开始触发选举新master;如果是5台,那至少要3台;如果master配置的有认证密码,我们还需要在sentinel中指定认证密码;
sentinel配置文件说明
bind:该指令和redis配置文件中的bind是同样的用法,用于指定sentinel的监听地址;默认不指定,监听本机所有可用地址;
protected-mode:指定是否开启保护模式;
port:用于指定sentinel的监听端口;默认是26379
daemonize:用于指定sentinel是否运行为守护进程,yes表示运行为后台守护进程;no表示不运行为守护进程,直接在前台运行;
pidfile:指定pid文件路径;
logfile:指定日志文件路径;
dir:指定sentinel的工作路径;
sentinel monitor <master-name> <ip> <redis-port> <quorum>:用于指定监控master节点的ip地址和端口以及有效法定票数;其中<master-name>是给监控的master一个名称,可以随便写,起标识的作用;<quorum>表示sentinel集群的quorum机制,即至少有quorum个sentinel节点同时判定主节点故障时,才认为其真的故障;
sentinel auth-pass <master-name> <password>:指定master认证密码;通常都需要设置密码,并且master的密码和slave的密码应该是一样;
sentinel down-after-milliseconds <master-name> <milliseconds>:配置监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”;
sentinel parallel-syncs <master-name> <numslaves>:指在failover过程中,能够被sentinel并行配置的从节点的数量;
sentinel failover-timeout <master-name> <milliseconds>:sentinel必须在此指定的时长内完成故障转移操作,否则,将视为故障转移操作失败;
sentinel notification-script <master-name> <script-path>:通知脚本,此脚本被自动传递多个参数;
了解了sentinel的配置文件,接下我们把3台sentinel都启动起来
master
slave01
slave02
提示:从上面的信息可以看到3个sentinel都监控master的ip地址和端口,其实他们3个的配置文件都是一样的;
查看sentinel日志
提示:从上面的日志信息可以了解到sentinel监控的master是192.168.0.41:6379;并且有两个slave分别是192.168.0.42:6379和192.168.0.43:6379;
查看sentinel状态
提示:它提示我们开启了保护模式;
关闭保护模式
重启sentinel,再次查看sentinel状态
[root@master ~]# systemctl restart redis-sentinel.service [root@master ~]# ss -tnl State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 511 *:26379 *:* LISTEN 0 511 *:6379 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 511 :::26379 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@master ~]# redis-cli -h 192.168.0.41 -p 26379 192.168.0.41: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.0.41:6379,slaves=2,sentinels=3 192.168.0.41:26379> info clients # Clients connected_clients:3 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 192.168.0.41:26379> CLIENT LIST id=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping id=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publish id=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 192.168.0.41:26379>
分享名称:如何使用Redis中的高可用组件sentinel-创新互联
文章网址:https://www.cdcxhl.com/article0/djdooo.html
成都网站建设公司_创新互联,为您提供ChatGPT、App开发、品牌网站建设、标签优化、外贸网站建设、Google
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联