Redis集群_3.redis 主从自动切换Sentinel

Redis Sentinel

Sentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中

一、Sentinel作用:

1):Master状态检测

2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave

3):Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

二、Sentinel工作方式:

1):每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令

2):如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。

3):如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4):当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线

5):在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令

6):当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

7):若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。

主观下线和客观下线

主观下线:Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

客观下线:Objectively Down, 简称 ODOWN,指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的Master Server下线判断,然后开启failover.

SDOWN适合于Master和Slave,只要一个 Sentinel 发现Master进入了ODOWN, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对下线的主服务器执行自动故障迁移操作。

ODOWN只适用于Master,对于Slave的 Redis 实例,Sentinel 在将它们判断为下线前不需要进行协商, 所以Slave的 Sentinel 永远不会达到ODOWN。

三、配置:

1:指定监听Master(三个节点)

# vi /main/redis/sentinel.conf

port 26379

daemonize yes

sentinel monitor mymaster 192.168.100.211 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 900000

logfile "/main/redis/logs/sentinel.log"

#上面配置文件说明如下:

#第一行指定sentinel端口号

#第二行指定sentinel为后台启动

#第三行指定Sentinel去监视一个名为 mymaster 的Master,Master的IP地址为192.168.100.211,端口号为6379,最后的2表示当有2个Sentinel检测到Master异常时才会判定其失效,即只有当2个Sentinel都判定Master失效了才会自动迁移,如果Sentinel的数量不达标,则不会执行自动故障迁移。

#第四行指定Sentinel判定Master断线的时间。(单位为毫秒,判定为主观下线SDOWN)

#第五行指定在执行故障转移时,最多可以有多少个Slave同时对新的Master进行同步。这个数字设置为1,虽然完成故障转移所需的时间会变长,但是可以保证每次只有1个Slave处于不能处理命令请求的状态

2:启动sentinel(三个节点):

# /main/redis/src/redis-sentinel /main/redis/sentinel.conf

3:设置开机启动(三个节点)

# echo "/main/redis/src/redis-sentinel /main/redis/sentinel.conf" >> /etc/rc.local

四、注意点:

1):首次启动时,必须先启动Master

2):Sentinel 只在 server 端做主从切换,app端要自己开发(例如Jedis库的SentinelJedis,能够监控Sentinel的状态)

3):若Master已经被判定为下线,Sentinel已经选择了新的Master,也已经将old Master改成Slave,但是还没有将其改成new Master。若此时重启old Master,则Redis集群将处于无Master状态,此时只能手动修改配置文件,然后重新启动集群

到此redis集群配置完毕

时间: 2024-11-01 00:55:57

Redis集群_3.redis 主从自动切换Sentinel的相关文章

Redis集群redis主从自动切换Sentinel(哨兵模式)

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中 一.Sentinel作用:1):Master状态检测 2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave3):Master-Slave切换后,master_redis.conf.slave_redis.conf和sentinel.conf的内容都会发生改变,即mast

Redis集群~StackExchange.redis连接Twemproxy代理服务器

回到目录 本文是Redis集群系列的一篇文章,主要介绍使用StackExchange.Redis进行Twemproxy(文中简称TW)代理服务的连接过程,事务上,对于TW来说,我们需要理解一下它的物理架构,它类似于Nugix,主要实现的是请求转发,但它还有一个重要的功能,那就是自动分片,这对于大数据是很必要的,你的服务器需要横向扩展时,不需要告诉客户端,这是一种很理解化的设计模式,当然,也对于Redis来说,在配置TW之后,是可以被全美支持的! 关于tw和Redis集群的设计图 关于StackE

Redis集群~StackExchange.redis连接Sentinel服务器并订阅相关事件(原创)

回到目录 对于redis-sentinel我在之前的文章中已经说过,它是一个仲裁者,当主master挂了后,它将在所有slave服务器中进行选举,选举的原则当然可以看它的官方文章,这与我们使用者没有什么关系,而对于sentinel来说,它在进行主从切换时,会触发相关事件,这是和我们开发人员有关系的,如当+switch-master事件被触发时,说明当前Sentinal已经完成了一次主从的切换,并所有服务已经正常运转了. 下面是我这几天作的测试,对于Twemproxy代理和Sentinal哨兵都已

Redis集群_1.redis主从配置

Redis主从配置(Master-Slave) 一. Redis Replication的特点: 1):一个Master可以同步多个Slave 2):不仅Master可以同步多个Slave,Slave也可以同步其它Slave,可以构成一个图形结构,同时还能分担Master的同步压力 3):Redis Replication使用的是异步复制.从2.8开始,Slave会周期性发起一个Ack确认replication stream被处理进度 4):复制在Master Server是以非阻塞模式完成数据

redis集群:手动与自动

手动创建: 环境描述:一台机器启动六个节点,3个主节点,3个从节点.安装:tar -zxvf redis-3.2.10.tar.gzmv redis-3.2.10 /usr/local/redisyum install gcc* tcl -ymake && make test修改配置文件:vi /usr/local/redis/redis.conf **要改的地方** daemonize yes port 7000 cluster-enabled yes cluster-config-fi

Redis集群_1.redis安装

Redis介绍: redis是一个高性能的key-value存储系统.和Memcached类似,但它支持存储的value类型相对更多,包括string(字符串).list(链表).set(集合)和zset(有序集合).这些数据类型都支持push/pop.add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的.在此基础上,redis还支持各种不同方式的排序.与memcached一样,为了保证效率,数据都是缓存在内存中.区别的是redis会周期性的把更新的数据写入磁盘或者把修

Redis集群_4.redis 启动脚本

Redis启动脚本: # vi /etc/init.d/redis #!/usr/bin/env bash # # redis start up the redis server daemon # # chkconfig: 345 99 99 # description: redis service in /etc/init.d/redis # chkconfig --add redis or chkconfig --list redis # service redis start or ser

CentOS/Linux Redis集群安装

在此文章中,只介绍redis集群的安装步骤,若想知道详细过程,请参阅以下几篇文章: Redis集群_1.redis安装 Redis集群_2.redis主从配置 Redis集群_3.redis 主从自动切换Sentinel Redis集群_4.redis 启动脚本 系统环境:CentOS 6.5 mini 软件版本:redis-2.8.19 IP地址: 节点1:192.168.100.211 节点2:192.168.100.212 节点3:192.168.100.213 Redis安装(三个节点)

Redis集群节点主从关系调整

一.概述 Redis集群创建后,可能会出现互为主从关系的节点从属于同一台服务器的情况.在此种情况下,若 服务器故障宕机或需要停机维护,互为主从关系的节点同时停止运行,导致redis集群暂时失去一部 分slot插槽.此时,redis集群为fail状态,对其进行的数据读写操作均无法正常进行.为避免此种情 况的发生,应对redis集群节点的主从关系进行调整,使互为主从关系的节点分属于不同的服务器. 二.调整方法描述 1.使用redis-trib.rb脚本将待调整的从节点从redis集群中删除.(执行此