精华内容
下载资源
问答
  • 哨兵简介-哨兵原理

    2018-03-30 16:21:00
    哨兵简介:由一个或多个Sentinel实例组成的Sentinel系统可监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器提升为新的主...

     

    哨兵简介:由一个或多个Sentinel实例组成的Sentinel系统可监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器提升为新的主服务器,然后由新的主服务器代替已下线的主服务器继续提供命令请求,但是Sentinel还会继续监视下线的原主,当它重新上线时,将它设置为新主的从服务器。

    Sentinel原理:

    1、当一个Sentinel启动时,它需要执行的步骤;

    1)初始化服务器;

    2)将普通Redis服务器使用的代码替换成Sentinel专用代码;

    3)初始化Sentinel状态;

    4)根据给定的配置文件,初始化Sentinel的监视主服务器列表;

    5)创建连向主服务器的网络连接:命令连接和订阅连接。

    命令连接专门用于向主服务器发送命令,并接收命令回复;订阅连接专门用于订阅主服务器的_sentinel_:hello频道。Sentinel_sentinel_:hello频道订阅会一直持续到Sentinel与服务器的连接断开为止,也就是说,对于每个与Sentinel连接的服务器,Sentinel既通过命令连接向服务器的_sentinel_:hello频道发送信息,又通过订阅连接从服务器的_sentinel_:hello频道接收消息。

    2Sentinel获取主服务器信息:Sentinel默认会以10秒一次的频率,通过命令连接向被监视的主服务器发送INFO命令并通过分析INFO命令的回复来获取主服务器的当前信息。

    Sentinel在分析INFO命令中包含的从服务器的信息时,会检查从服务器对应的实例结构是否已经存在于slaves字典中:如果从服务器对应的实例结构已经存在,那么Sentinel对它进行更新;如果从服务器对应的实例结构不存在,那么说明这是一个新发现的从服务器,Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。

    3、获取从服务器信息:当Sentinel发现主服务器有新的从服务器出现时,除了会为这个新的从服务器创建相应的实例结构外,还会创建连接到从服务器的命令连接和订阅连接。在船舰命令连接后,Sentinel会在默认情况下,以10秒一次的频率通过命令连接向从服务器发送INFO命令,并获得以下内容的回复:

    根据这些信息,Sentinel会对从服务器的实例结构进行更新。

    4、向主服务器和从服务器发送信息:默认情况下,Sentinel会以两秒一次的频率通过命令连接向所有被监视的主服务器和从服务器发送一下格式的命令:

    PUBLISH __sentinel__: hello

    “<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>”

    S_开头的记录是Sentinel本身的信息,epoch代表当前的配置纪元;

    M_开头的参数记录的则是主服务器的信息,如果Sentinel正在监视的是主服务器,则记录的是主服务器的信息,如果监视的是从服务器,记录的则是从服务器的信息。

    5、接受来自主服务器和从服务器的频道信息:当Sentinel与一个主服务器或者从服务器建立起订阅连接后,Sentinel会通过订阅连接,向服务器发送SUBSCRIBE _sentinel_:hello命令,Sentinel_sentinel_:hello频道订阅会一直持续到Sentinel与服务器的连接断开为止,也就是说,对于每个与Sentinel连接的服务器,Sentinel既通过命令连接向服务器的_sentinel_:hello频道发送信息,又通过订阅连接从服务器的_sentinel_:hello频道接收消息。

    对于监视同一个服务器的多个Sentinel来说,一个Sentinel发送的信息会被其它的Sentinel接受到,这些信息会更新其它的Sentinel对发送信息Sentinel的认知,也会用于更新其它Sentinel对被监视服务器的认知。

    当一个Sentinel_sentinel_:hello频道收到一条信息时,会对这条信息进行分析,如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID相同,则说明是自己发送的,丢弃不做进一步处理,相反的,接受到的运行ID与信息记录的运行ID不同,说明这条信息是监视同一个服务器的其它Sentinel发来的,接受信息的Sentinel将根据信息中的各个参数,对相应主服务器的实例结构进行更新。

    5.1各个Sentinel会通过建立命令连接相连,通过发送命令请求进行信息交换。各Sentinel之间不会创建订阅连接,Sentinel在连接主服务器或从服务器时,会同时创建命令连接和订阅连接,但是在连接其它Sentinel时,却只会创建命令连接。因为Sentinel需要通过接收主服务器或从服务器发来的频道信息来发现未知的新Sentinel,所以才需要建立订阅连接,而相互已知的Sentinel只要使用命令连接来进行通信就足够了。

    6、检测主观下线状态:默认情况下,Sentinel会以每秒一次的频率向所有与它建立了命令连接的实例(包括主服务器、从服务器、其它Sentinel在内)发送PING命令,并通过返回的PING命令回复来判断实例是否在线。有效回复:+PONG -LOADING -MASTERDOWN,其余回复都是无效回复。Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需要的时间长度:如果一个实例在down-after-milliseconds毫秒内,连续向Sentinel返回无效回复,那么Sentinel会修改这个实例对应的实例结构,在结构的flags属性中打开SRI_S_DOWN标识,以此来表示这个实例进入主观下线状态。

    (多个Sentinel设置的主观下线时间可能不同)

    7、检查客观下线状态:当一个Sentinel将一个主服务器判断为主观下线之后,同时向其它Sentinel询问判断主服务器是否真的下线,当Sentinel从其它Sentinel那里接收到足够数量的已下线判断后,Sentinel会将主服务器判定为客观下线,并对主服务器执行故障转移操作。

    (1) Sentinel发送SENTINEL is-master-down-by-addr<ip> <port> <current_epoch> <runid>命令询问其它Sentinel是否同意主服务器已下线。

    (2) 目标Sentinel接收SENTINEL is-master-down-by命令,分析命令检查主服务器是否已经下线,然后向源Sentinel返回一个包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复。(down_state:返回检查结果,1代表主服务器已下线,0代表主服务器未下线 leader_runid leader_epoch)比如1 * 0回复代表Sentinel也同意主服务器下线。

    (3) 接收SENTINEL is-master-down-by-addr命令的回复,统计同意主服务器已下线的数量,当数量达到配置指定的判断客观下线所需的数量时,Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开,表示主服务器已经进入客观下线状态。

     

    Sentinel monitor master 127.0.0.1 6379 2 当所有sentinel中有两个认为主服务器下线时,Sentinel就会将主服务器判断为客观下线。

    8、选举领头Sentinel:当一个主服务器被判断为客观下线时,监视这个主服务器的各个Sentinel会进行协商,选举出一个领头Sentinel对下线主服务器进行故障转移操作。

    9、故障转移:

    (1)选出新主服务器:领头Sentinel向被选出从服务器(新主)发送SLAVEOF no one命令,以每秒一次的频率向被升级的从服务器发送INFO命令,观察回复的角色信息,直到slave变成master

    (2)修改从服务器的复制目标;

    (3)将旧的主服务器变为新主的从服务器;

     

    指定配置文件开启redis:

     

    /usr/local/redis3/conf/redis_6379.conf  &

     

     开启sentinel

     

    ./redis-server /usr/local/redis3/conf/sentinel.conf  --sentinel  &

     

    开启复制 >slaveof 192.168.0.142 6379

     

    加登陆密码 >config set requirepass  up366.com

     

     

     

    转载于:https://www.cnblogs.com/any-way/p/8676919.html

    展开全文
  • redis sentinel 哨兵原理,配置和使用

    千次阅读 2017-09-19 10:26:46
    redis sentinel 哨兵原理介绍,安装配置,使用说明,sentinel整合spring配置和使用;以及redis sentinel 常用命令解析和配置文件详解
    一、Sentinel介绍
    Sentinel是Redis的高可用性(HA)解决方案,由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进行下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis提供的sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决
    监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
    提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
    自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
    二、Sentinel的主从原理
     

     


     
     
    三、测试环境
    windows10操作系统
    四、Redis版本
    3.2.100(注:redis官网仅发布了linux版本,windows版本需去github下载。下载地址:https://github.com/MSOpenTech/redis/releases)
    五、Redis安装
    下载如下msi文件,点击安装即可
     
     
    安装完后,目录如下:
     
     
    六、Redis Sentinel配置
    测试采用2个哨兵,1个主redis,2个从redis。
    复制5份redis.windows.conf文件并重命名如下(开发者可根据自己的开发习惯进行重命名):
     
     
    master.6379.conf配置(直接在原配置文件中修改):
    port:6379
    requirepass:grs
    masterauth:grs
    slave.6380.conf配置(直接在原配置文件中修改):
    port:6380
    requirepass:grs
    masterauth:grs
    dbfilename dump6380.rdb
    slaveof 127.0.0.1 6379
    master.6381.conf配置(直接在原配置文件中修改):
    port:6381
    requirepass:grs
    masterauth:grs
    dbfilename dump6381.rdb
    slaveof 127.0.0.1 6379
    sentinel.63791.conf 配置(将原配置文件清空后添加如下内容):
    port 63791
    sentinel monitor master-1 127.0.0.1 6379 2 //主master,2个sentinel选举成功后才有效
    sentinel down-after-milliseconds master-1 5000 //判断主master的挂机时间(毫秒),超时未返回正确信息后标记为sdown状态
    sentinel failover-timeout master-1 18000 //若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败。
    sentinel auth-pass master-1 grs //身份认证
    sentinel parallel-syncs master-1 1 //选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步,这个数字越小,完成故障转移所需的时间就越长
     
    sentinel.63792.conf 配置(将原配置文件清空后添加如下内容):
    port 63792
    sentinel monitor master-1 127.0.0.1 6379 2 //主master,2个sentinel选举成功后才有效
    sentinel down-after-milliseconds master-1 5000 //判断主master的挂机时间(毫秒),超时未返回正确信息后标记为sdown状态
    sentinel failover-timeout master-1 18000 //若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败。
    sentinel auth-pass master-1 grs //身份认证
    sentinel parallel-syncs master-1 1 //选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步,这个数字越小,完成故障转移所需的时间就越长
     
    这里有三个问题需要注意
    第一,若通过redis-cli -h 127.0.0.1 -p 6379连接,无需改变配置文件,配置文件默认配置为bind 127.0.0.1(只允许127.0.0.1连接访问)
    若通过redis-cli -h 192.168.180.78 -p 6379连接,需改变配置文件,配置信息为bind 127.0.0.1 192.168.180.78(只允许127.0.0.1和192.168.180.78访问)或者将bind 127.0.0.1注释掉(允许所有远程访问)
    第二,masterauth为所要连接的master服务器的requirepass,如果一个redis集群中有一个master服务器,两个slave服务器,当master服务器挂掉时,sentinel哨兵会随机选择一个slave服务器充当master服务器,鉴于这种机制,解决办法是将所有的主从服务器的requirepass和masterauth都设置为一样。
    第三,sentinel monitor master-1 127.0.0.1 6379 2 行尾最后的一个2代表什么意思呢?我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,当sentinel集群式,解决这个问题的方法就变得很简单,只需要多个sentinel互相沟通来确认某个master是否真的死了,这个2代表,当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。(sentinel集群中各个sentinel也有互相通信,通过gossip协议)。
    按如下循序依次启动服务
    1、redis-server master.6379.conf
     
    2、redis-server slave.6380.conf
     
    3、redis-server slave.6381.conf
     
    4、redis-server sentinel.63791.conf --sentinel(linux:redis-sentinel sentinel.63791.conf)
     
    5、redis-server sentinel.63792.conf --sentinel(linux:redis-sentinel sentinel.63792.conf)
     
    查看master状态:
     
    查看slave状态:
     
    查看sentinel状态:

    验证redis sentinel的主从切换:
    1、首先关闭主redis(6379)服务(shutdown)。
    2、查看哨兵,发现端口号为6380的从服务变成了主服务,sentinel自动完成了故障切换。
     
    3、启动刚才被shutdown的6379服务并查看,发现它变成了从服务。
     
    七、Jedis Sentinel教程
    Maven依赖:
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>2.8.0</version>
        </dependency>
        <!-- spring-redis -->
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-redis</artifactId>
            <version>1.6.4.RELEASE</version>
        </dependency>
    redis的配置文件:
    #redis config
    redis.pass=grs
    redis.pool.maxTotal=105
    redis.pool.maxIdle=10
    redis.pool.maxWaitMillis=60000
    redis.pool.testOnBorrow=true
     
    sentinel1.ip=127.0.0.1
    sentinel1.port=63791
     
    sentinel2.ip=127.0.0.1
    sentinel2.port=63792
    Spring的配置文件:
    <!-- Redis 配置 -->
    <bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
        <property name="maxTotal" value="${redis.pool.maxTotal}" />
        <property name="maxIdle" value="${redis.pool.maxIdle}" />
        <property name="maxWaitMillis" value="${redis.pool.maxWaitMillis}" />
        <property name="testOnBorrow" value="${redis.pool.testOnBorrow}" />
    </bean>
     
    <bean id="sentinelConfiguration"
        class="org.springframework.data.redis.connection.RedisSentinelConfiguration">
        <property name="master">
            <bean class="org.springframework.data.redis.connection.RedisNode">
                <property name="name" value="master-1"></property>
            </bean>
        </property>
        <property name="sentinels">
            <set>
                <bean class="org.springframework.data.redis.connection.RedisNode">
                    <constructor-arg name="host" value="${sentinel1.ip}"></constructor-arg>
                    <constructor-arg name="port" value="${sentinel1.port}"></constructor-arg>
                </bean>
                <bean class="org.springframework.data.redis.connection.RedisNode">
                    <constructor-arg name="host" value="${sentinel2.ip}"></constructor-arg>
                    <constructor-arg name="port" value="${sentinel2.port}"></constructor-arg>
                </bean>
            </set>
        </property>
    </bean>
     
    <!-- Jedis ConnectionFactory连接配置 -->
    <bean id="jedisConnectionFactory"
        class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
        <property name="password" value="${redis.pass}"></property>
        <property name="poolConfig" >
            <ref bean="jedisPoolConfig"/>
        </property>
        <constructor-arg name="sentinelConfig" ref="sentinelConfiguration"></constructor-arg>
    </bean>
     
    <!-- redisTemplate配置,redisTemplate是对Jedis的对redis操作的扩展,有更多的操作,封装使操作更便捷 -->
    <bean id="redisTemplate" class="org.springframework.data.redis.core.StringRedisTemplate">
        <property name="connectionFactory" ref="jedisConnectionFactory" />
    </bean>
    代码中直接用redisTemplate调用:
    @Override
    public boolean add(final KeyToken tkey) {
    boolean result = redisTemplate.execute(new RedisCallback<Boolean>() {
         @Override
         public Boolean doInRedis(RedisConnection connection) throws DataAccessException {
         RedisSerializer<String> serializer = getRedisSerializer();
         byte[] key = serializer.serialize(tkey.getIndex());
         byte[] name = serializer.serialize(tkey.getExpire_time());
         return connection.setNX(key, name);
         }
     
        });
        return result;
    }

    Sentinel常用命令
    1.  ping  //返回 PONG 
    2.  sentinel masters  //列出所有被监视的主服务器,以及这些主服务器的当前状态。
    3.  sentinel slaves <master name>  //列出给定主服务器的所有从服务器,以及这些从服务器的当前状态。
    4.  sentinel get-master-addr-by-name <master name>  //返回给定名字的主服务器的 IP 地址和端口号。如果这个主服务器正在执行故障转移操作,或者针对这个主服务器的故障转移操作已经完成,那么这个命令返回新的主服务器的IP 地址和端口号。
    5.  sentinel reset <pattern>  //重置所有名字和给定模式 pattern 相匹配的主服务器。pattern参数是一个 Glob风格的模式。重置操作清除主服务器目前的所有状态,包括正在执行中的故障转移,并移除目前已经发现和关联的,主服务器的所有从服务器和Sentinel
     sentinel failover <master name>  //当主服务器失效时,在不询问其他 Sentinel意见的情况下,强制开始一次自动故障迁移(不过发起故障转移的 Sentinel 会向其他Sentinel 发送一个新的配置,其他Sentinel 会根据这个配置进行相应的更新)。

    Sentinel配置详解
    1. port 26379  //sentinel监听端口,默认是26379,可以修改。
    2.  sentinel monitor <master-name> <ip> <redis-port> <quorum>  //告诉 sentinel去监听地址为ip:port的一个master,这里的master-name可以自定义,quorum是一个数字,指明当有多少个sentinel认为一个master失效时,master才算真正失效。master-name只能包含英文字母,数字,和“.-_这三个字符。
    配置示例:sentinel monitor master-1 127.0.0.1 6379 2
    3. sentinel down-after-milliseconds <master-name> <milliseconds>   //sentinel会向master发送心跳PING来确认master是否存活,如果 master在“一定时间范围”内不回应PONG或者是回复了一个错误消息,那么这个sentinel会主观地 (单方面地)认为这个master已经不可用了 (subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的,单位是毫秒。
    配置示例:sentinel down-after-milliseconds master-1 5000
    4.  sentinel failover-timeout <master-name> <milliseconds>  //如果在该时间(ms)内未能完成failover操作,则认为该failover失败。
    配置示例:sentinel failover-timeout master-1 18000
    5. sentinel parallel-syncs <master-name> <numslaves>  //在发生 failover主备切换时,这个选项指定了最多可以有多少个slave同时对新的 master进行同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越多的slave因为replication而不可用。可以通过将这个值设为 1来保证每次只有一个slave处于不能处理命令请求的状态。
    配置示例:sentinel parallel-syncs master-1 1
     
    6.  sentinel notification-script <master-name> <script-path>  //通知型脚:sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。
     
    配置示例:sentinel notification-script master-1 D:\script.bat
     
    7.  sentinel client-reconfig-script <master-name> <script-path>  //当一个 master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>目前<state>总是“failover, <role>是“leader”或者“observer中的一个。参数 from-ip, from-port, to-ip, to-port是用来和旧的master新的master(即旧的slave)通信的。这个脚本应该是通用的,能被多次调用,不是针对性的。
     
    配置示例:sentinel client-reconfig-script mymaster D:\script.bat
    8.  sentinel auth-pass <master-name> <password>  //设置连接master slave时的密码,注意的是sentinel不能分别为masterslave设置不同的密码,因此masterslave的密码应该设置相同。
    配置示例:sentinel auth-pass master-1 grs
    展开全文
  • redis 哨兵原理

    2020-05-26 21:28:13
    5、quorum(最终要达到的票数)和majority 每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换 如果quorum ,比如5...

    三个定时监控任务

    1.每隔十秒,每隔sentinel节点会向主节点和从节点发送info命令,获取最新的拓扑结构

    2.每隔两秒,每个sentinal节点会向redis数据节点的_sentinel_:hello频道上发送sentinel节点对主节点的判断以及sentinel节点的信息,同时每个sentinel也会订阅该频道(发现新节点,sentinel节点之间交换主节点的状态)

    3.每隔一秒,每个sentinel节点会向主节点,从节点,其余sentinel节点发送一条ping命令,做一次心跳检测,来确定这些节点是否可达。

     

    1、sdown(主观下线)和odown(客观下线)转换机制

    sdown和odown两种失败状态

    sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机

    odown是客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,那么就是客观宕机

    sdown达成的条件很简单,如果一个哨兵ping一个master,超过了is-master-down-after-milliseconds指定的毫秒数之后,就主观认为master宕机

    sdown到odown转换的条件很简单,如果一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机

     

    领导者sentinel节点选举

    redis使用rafr算法实现领导选举 https://raft.github.io/

    redis sentinel领导者选举的思路:

    1.每个在线的sentinel节点都有资格成为领导者,当它确认主节点主观下线时,会向其他sentinel节点发送sentinel is-master-down-by-addr命令,要求将自己设置为领导者

    2.收到命令的Sentinel节点,如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝

    3.如果该Sentinel节点发现自己的票数已经大于等于Max(quorum,num(sentinels)/2+1),那么它将成为领导者

    4.如果此过程没有选举出领导者,将进入下一次选举

     

    2、哨兵集群的自动发现机制

    哨兵互相之间的发现,是通过redis的pub/sub系统实现的,每个哨兵都会往__sentinel__:hello这个channel里发送一个消息,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在

    每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息,内容是自己的host、ip和runid还有对这个master的监控配置

    每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在

    每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步

     

    3、slave配置的自动纠正

    哨兵会负责自动纠正slave的一些配置,比如slave如果要成为潜在的master候选人,哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接到正确的master上

     

    4、slave->master选举算法(故障转移)

    如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,

    1 此时首先要选举一个slave来

    会考虑slave的一些信息

    (1)跟master断开连接的时长

    (2)slave优先级最高的从节点列表

    (3)复制offset最大的从节点(复制的最完整)

    (4)runid最小的从节点

    如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍,外加master宕机的时长,那么slave就被认为不适合选举为master

    (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

    接下来会对slave进行排序

    (1)按照slave优先级进行排序,slave priority越低,优先级就越高

    (2)如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高

    (3)如果上面两个条件都相同,那么选择一个run id比较小的那个slave

    2 Sentinel领导者节点会对第一步选举出来的从节点执行slaveof no one 命令让其成为主节点

    3 Sentinel领导者节点会向剩余的从节点发送命令,让他们成为新主节点的从节点,复制规则和parallel-syncs参数有关

    4 Sentinel节点集合会将原来的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点

     

    5、quorum(最终要达到的票数)和majority

    每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换

    如果quorum < majority,比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换

    但是如果quorum >= majority,那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换

     

    6、configuration epoch

    哨兵会对一套redis master+slave进行监控,有相应的监控的配置

    执行切换的那个哨兵,会从要切换到的新master(salve->master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的

    如果第一个选举出的哨兵切换失败了,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号

     

    7、configuraiton传播

    哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制

    这里之前的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的

    其他的哨兵都是根据版本号的大小来更新自己的master配置的

     

     

     

     

     

    展开全文
  • Redis 哨兵原理分析

    2020-11-06 16:34:51
    文章目录哨兵选举主节点 哨兵选举主节点 当一个master服务器被某sentinel视为下线状态后,该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。 每个发现master服务器进入下线状态的sentinel都...

    博文目录


    哨兵选举主节点

    当一个master服务器被某sentinel视为下线状态后,该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。

    每个发现master服务器进入下线状态的sentinel都可以要求其他sentinel选自己为sentinel的leader,选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作,从存活的slave中选举出新的master,这个选举过程跟集群的master选举很类似。

    哨兵模式就算只有一个哨兵节点,redis的主从也能正常运行以及选举master,如果master挂了,那唯一的那个哨兵节点就是哨兵leader了,可以正常选举新master。

    不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。

    当redis主节点如果挂了,哨兵集群会重新选举出新的redis主节点,同时会修改所有sentinel节点配置文件的集群元数据信息,比如6379的redis如果挂了,假设选举出的新主节点是6380,则sentinel文件里的集群元数据信息会变成如下所示:

    redis.sentinel.config.26379

    sentinel known-replica mymaster 116.62.162.48 6379
    sentinel known-replica mymaster 116.62.162.48 6381
    sentinel known-sentinel mymaster 172.16.138.202 26380 1012f4eb61156494a10eec863b4f698c160487c6
    sentinel known-sentinel mymaster 172.16.138.202 26381 aba18c9c846e272ad147cfac9245554801aa8701
    

    同时还会修改sentinel文件里之前配置的mymaster对应的6379端口,改为6380

    redis.sentinel.config.26379

    sentinel monitor mymaster 116.62.162.48 6380 2
    

    当6379的redis实例再次启动时,哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群

    也可从哨兵日志中看到选举过程

    logfile.redis.sentinel.26379.log

    14899:X 04 Nov 2020 13:39:40.901 # Configuration loaded
    14900:X 04 Nov 2020 13:39:40.908 * Running mode=sentinel, port=26379.
    14900:X 04 Nov 2020 13:39:40.908 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    14900:X 04 Nov 2020 13:39:40.912 # Sentinel ID is 8902bc48943a310b9877ce7705fe6fdf05427e78
    14900:X 04 Nov 2020 13:39:40.912 # +monitor master mymaster 116.62.162.48 6379 quorum 2
    14900:X 04 Nov 2020 13:39:40.913 * +slave slave 116.62.162.48:6380 116.62.162.48 6380 @ mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:39:40.915 * +slave slave 116.62.162.48:6381 116.62.162.48 6381 @ mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:39:42.912 * +sentinel sentinel 1012f4eb61156494a10eec863b4f698c160487c6 172.16.138.202 26380 @ mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:39:42.933 * +sentinel sentinel aba18c9c846e272ad147cfac9245554801aa8701 172.16.138.202 26381 @ mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:41:26.744 # +sdown master mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:41:26.891 # +new-epoch 1
    14900:X 04 Nov 2020 13:41:26.894 # +vote-for-leader 1012f4eb61156494a10eec863b4f698c160487c6 1
    14900:X 04 Nov 2020 13:41:27.286 # +config-update-from sentinel 1012f4eb61156494a10eec863b4f698c160487c6 172.16.138.202 26380 @ mymaster 116.62.162.48 6379
    14900:X 04 Nov 2020 13:41:27.287 # +switch-master mymaster 116.62.162.48 6379 116.62.162.48 6380
    14900:X 04 Nov 2020 13:41:27.287 * +slave slave 116.62.162.48:6381 116.62.162.48 6381 @ mymaster 116.62.162.48 6380
    14900:X 04 Nov 2020 13:41:27.287 * +slave slave 116.62.162.48:6379 116.62.162.48 6379 @ mymaster 116.62.162.48 6380
    
    展开全文
  • Redis哨兵原理详解

    2019-10-03 22:40:44
    Redis哨兵(以下称哨兵)是为Redis提供一个高可靠解决方案,对一定程序上的错误,可以不需要人工干预自行解决。 哨兵功能还有监视、事件通知、配置功能。以下是哨兵的功能列表: 监控:不间断的检查主从服务是否如...
  • 哨兵原理及适用场景

    2020-09-05 17:27:52
    这里写目录标题1哨兵的技巧 1哨兵的技巧 使用哨兵,避免特殊情况的讨论 其它作用:单链表虚拟头结点,插入排序
  • Redis 哨兵原理浅析

    2020-12-28 22:54:00
    aaasa
  • redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis 会挂那怎么保证 redis 是高可用的?...
  • 一、哨兵机制 1、哨兵的概念 Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器...
  • Redis的Sentinel哨兵原理

    2019-07-06 11:39:46
    sentinal,中文名哨兵 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 集群监控 监控Redis master和slave进程的正常工作 消息通知 如果某个Redis实例有故障,那么哨兵负责发送报警消息给管理员 故障转移 ...
  • 本文将要介绍的哨兵,它基于Redis主从复制,主要作用便是解决主节点故障恢复的自动化问题,进一步提高系统的高可用性。(注:文章内容基于Redis3.0版本)在介绍哨兵之前,首先从宏观角度回顾一下Redis实现高可用相关...
  • Redis 的哨兵原理能介绍一下么?   面试题 如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis ...
  • Redis哨兵原理,我忍你很久了!

    千次阅读 多人点赞 2020-06-06 20:46:19
    Redis哨兵搭建以及工作流程一、什么是哨兵二、哨兵的作用二、如何配置哨兵三、哨兵工作原理(笑看) 一、什么是哨兵 先啰嗦几句我们在配置主从复制时有一种情况就是主节点宕机了,谁来提供服务呢! 当主节点宕机后主...
  • REDIS高可用哨兵原理

    2019-07-23 17:46:04
    Redis 中为了实现高可用... 采用哨兵监控数据节点的运行情况,一旦主节点出现问题由从节点顶上继续进行服务。 主从复制 Redis 中主从节点复制数据有全量复制和部分复制之分。 旧版本全量复制功能的实现 全...
  • Redis高可用哨兵原理

    2019-05-16 15:27:00
    采用哨兵监控数据节点的运行情况,一旦主节点出现问题由从节点顶上继续进行服务。 主从复制 Redis 中主从节点复制数据有全量复制和部分复制之分。 旧版本全量复制功能的实现 全量复制使用 ...
  • 目录   三、如何使用哨兵? 3.1、哨兵环境部署 3.2、主节点、从节点、哨兵节点配置文件解释  ...3.3、哨兵节点日志分析 ...四、Redis Sentinel客户端实现的原理是什么?Java如何操作Redis Sentinel?  ...
  • Redis哨兵原理 (五)

    2019-12-10 15:51:01
    sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机 odown是客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,那么就是客观宕机 sdown达成的条件很简单,如果一个哨兵ping一个...
  • 目录 二、哨兵是如何解决“问题一”的? 2.1 、主从模式哨兵部署 2.2、三个定时监控任务  2.3、主观下线与客观下线 ...2.4、领导者哨兵节点选举 ...四、Redis Sentinel客户端实现的原理是什么?Jav...
  • [redis]哨兵原理解析.

    2021-01-29 16:00:16
    在 Redis 主从集群中,哨兵机制是实现主从库自动切换的关键机制,它有效地解决了主从复制模式下故障转移的这三个问题。 主库真的挂了吗? 该选择哪个从库作为主库? 怎么把新主库的相关信息通知给从库和客户端呢? ...
  • 四、Redis Sentinel客户端实现的原理是什么?Java如何操作Redis Sentinel?   一、哨兵解决了什么问题? 这个问题要从Redis主从模式说起。Redis的主从模式可以将主节点的数据改变同步给从节点,从节点就可以起.....
  • redis 的哨兵原理能介绍一下么? 面试官心理分析 其实问这个问题,主要是考考你,redis 单机能承载多高并发?如果单机扛不住如何扩容扛更多的并发?redis 会不会挂?既然 redis 会挂那怎么保证 redis 是高可用的?...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,840
精华内容 736
关键字:

哨兵原理