• Redis(七) 主从复制(二)哨兵模式


    前景回顾:

    在上篇文章中,我们搭建的主从复制模式是下面这样的:

    在这里插入图片描述
    实际上,一主二仆的主从复制,我们可以搭建成下面这种结构:

    在这里插入图片描述

    一. 为什么更推荐使用哨兵模式:

    结合上篇文章,我们一共介绍了两种主从模式了,但是这两种,不管是哪一种,都会存在这样一个问题,那就是当主机宕机时,就会发生群龙无首的情况,如果在主机宕机时,能够从从机中选出一个来充当主机,那么就不用我们每次去手动重启主机了,这就涉及到一个新的话题,那就是哨兵模式

    因为主从模式有一个致命的缺点:主机挂了整个系统就死了,所以一般情况下我们会弄一个一个监控出来时刻监控着主机,这就是我们的哨兵模式
    票数规则:因为哨兵也是可能宕机的,所以我们制造了一种选票机制,当主机宕机的时候,我们的哨兵会和所有的从机发消息,进行选票确定新的主机,即谁的性能快,谁得到的票数多

    在这里插入图片描述

    linux 中查看进程

    ps

    linux 中查看进程,并且把进程都列出来

    ps -aux

    linux 中查看过滤且列出来redis的进程

    ps -aux|grep redis
    在这里插入图片描述

    linux 中如何杀死进程

    kill id

    二 如何配置哨兵模式

    在这里插入图片描述

    我们还是在我们前面的基础上来搭建哨兵模式。

    先搭建好主从模式

    1.假设现在我的master是6379,两个从机分别是6380和6381,两个从机都是从6379上复制数据。先按照上文的步骤,我们配置好一主二仆,

    在这里插入图片描述

    配置我们的哨兵模式的配置文件

    2.在redis目录下打开sentinel.conf文件,做如下配置:

    sentinel monitor mymaster 127.0.0.1 6379 1
    sentinel auth-pass mymaster 123

    在这里插入图片描述

    第一项配置:
    ``修改为:sentinel monitor mymaster 127.0.0.1 6379 1

    结尾跟的数字:投票的数量,一会要是master宕机了,我们需要重新选举一个master,由于我们这里应该设置一个sentinel,所以待会投出去的票数量一个为1。而sentinel本身也应该是一个集群,如果我们的sentinel是一个集群的话应该是奇数个,如果设置为偶数个那么sentinel可能会出现选不出来的情况,所以我们一会只设置一个sentinel,我们也可以设置sentinel为三个,那么待会投票的时候票数量就为2,即结尾的数字要改为2。
    在这里插入图片描述

    第二项配置
    在这里插入图片描述

    1.因为一个哨兵可以监控很多个master,所以要设置mastername
    在这里插入图片描述

    三 启动我们的哨兵模式

    在这里插入图片描述
    在这里插入图片描述

    四.关闭我们的主机,看从机和sentinel做了什么

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    查看6381配置
    在这里插入图片描述

    查看6379配置
    在这里插入图片描述

    查看6379配置文件
    cat redis6379.conf
    在这里插入图片描述

    发现他在redis6379.conf后自动加了这么几行来更改6379的配置,使他从主机变成了从机。

  • 相关阅读:
    软考高项——47个过程的输入、输出、工具技术汇总
    k8s--storageClass自动创建PV
    RabbitMQ开启消息发送确认和消费手动确认
    MySQL 基础
    gRPC-go 元数据
    CSS隐藏滚动条
    学习Maven Web 应用
    Ollama 配置多并发和多模型
    就近值 reduce用法 时间戳与时间点对比循环查找
    利用t.ppf&t.interval分别计算T分布置信区间[实例]
  • 原文地址:https://blog.csdn.net/weixin_43189971/article/details/126221674