深入浅出Redis-redis哨兵集群

发布时间:2018-11-15  栏目:NoSQL  评论:0 Comments

五、Sentinel状态持久化

  snetinel的状态会给持久化地写入sentinel的布局文件中。每次当接受一个新的布置时,或者新创办一个配备时,配置会让持久化到硬盘中,并带来及安排的版本戳。这意味着,可以高枕无忧之息同重启sentinel进程。下面是于还写的布置文件截图:

图片 1

晋升Server2 为新的主服务器:
  

七、配置传播

  一旦一个sentinel成功地对准一个master进行了failover,它用会管关于master的最新安排通过播放形式通知其他sentinel,其它的sentinel则更新对应master的布,一个faiover要惦记让成功施行,sentinel必须能为选为master的slave发送SLAVE
OF NO ONE命令,然后能够透过INFO命令看到新master的布置信息。

  当以一个slave选举为master并发送SLAVE OF NO
ONE`晚,即使其它的slave还从未针对新master重新配置自己,failover也受看是成了底,然后所有sentinels将见面公布新的布置信息。

新配在汇众多中相互传播之章程,就是胡我们需要当一个sentinel进行failover时得被授权一个本号的因由。

每个sentinel使用发布/订阅的措施不断地传播master的配备版本信息,配置传播之宣布/订阅管道是:__sentinel__:hello,我们可通过订阅其频道查看频道中之音讯,如下:

图片 2

  因为各个一个布置都发出一个本子号,所以以版本号最可怜的老为业内。例如:假设有一个曰吧mymaster的地点为10.1.210.69:6379。一开始,集众多被兼有的sentinel都知是地点,于是也mymaster的布局从上本号1。一截时后mymaster死了,有一个sentinel被授权用本号2对其开展failover。如果failover成功了,假设地址变更以10.1.210.69:6380,此时布局的版本号为2,进行failover的sentinel会将新安排广播于任何的sentinel,由于其他sentinel维护的版本号为1,发现新布局的版本号为2常常,版本号变死了,说明配置更新了,于是就会见下新型的版本号为2底布局。

2、Redis 主从离别
 在教学Sentinel
哨兵集群之前,我们事先来增加建筑一个简的主导分离(读写分离)。
先是,我们默认大家还已经安装了redis,然后我们用 **redis.conf
**拷贝多客,并且创造多个目录,用于区分多单redis 服务:
   

二、哨兵(Sentinel)简介

   哨兵(后文统称sentinel)是合法推荐的之赛可用(HA)解决方案。在之前的篇章被介绍过redis的中心高可用解决方案,这种方案的弱项在于当master故障时候,需要手动进行故障恢复,而sentinel是一个独自运转的长河,它亦可监控一个或者多个核心集群,并会在master故障时候自动进行故障转移,更为理想的凡sentinel本身是一个分布式系统,其分布式设计思想有点类似于zookeeper,当某个时候Master故障后,sentinel集群采用Raft算法来选择Leader,故障转移由Leader完成。而于客户端的话,操作redis的主节点,我们特需要了解sentinel,sentinel返回时可用之master,这样一来客户端不欲关怀的切换而引发的客户端配置变更。一个天下无双的sentinel架构使下图:

图片 3

 

 

sentinel的最主要成效:

  • 督察(Monitoring): sentinel 会不断地检讨Master和Slave是否运作如常。
  • 通报(Notification):当被监控之有Redis实例出现问题经常, 哨兵(sentinel) 可以经 API 向管理员要其他应用程序发送通知。
  • 活动故障迁移(Automatic
    failover):当一个Master不可知健康干活时,sentinel)会初步同不良机关故障迁移操作,它会用失效Master的里边一个Slave升级也新的Master, 并让失效Master的另Slave改吗复制新的Master; 当客户端试图连接失效的Master时,集群为会见向客户端返回新Master的地址,使得集群可以用Master代替失效Master。
  • 布置基本(Configuration
    provider):如果故障转移产生了,sentinel会返回新的master地址。

深入浅出Redis-redis哨兵集群

老三、Sentinel集群部署

图片 4

带头哨兵选举

  在常理中提及到了,当sentinel发现主库客观下线上会进展领头哨兵选举进行故障恢复,其举算法采用Raft算法,这为为什么说那个计划思想相近与zookpeer,选举过程大概如下:

  1. 意识主库客观下线的哨兵节点(这里称为A)向每个哨兵节点发送命令要求对方选举自己吗牵头哨兵(leader);
  2. 假若目标哨兵没有选了其他人,则同意将A选举为牵头哨兵;
  3. 假如A发现有超过一半还过quorum参数值的哨兵节点同意选好成领头哨兵,则A哨兵成功选举为牵头哨兵。
  4. 当起多独哨兵节点同时与领头哨兵选举时,出现没有外节点当选或者,此时每个参选节点等一个自由时间开展下一样轱辘推,直到选出领头哨兵。

配置版本号作用

  同样,在常理介绍时提及到了master的布置版本号,当一个sentinel被授权后,它将会见获取宕掉的master的如出一辙客最新部署版本号,当failover执行了后,这个版本号将会见于用来最新的布局。因为多数sentinel都已明白该版本号已经深受设尽failover的sentinel拿走了,所以任何的sentinel都非克重新失去采用这版本号。这表示,每次failover都见面顺便有一个举世无双之版本号。我们以见面视这样做的基本点。

而且,sentinel集群都遵从一个平整:如果sentinel A推荐sentinel
B去实践failover,A会等待一段时间后,自行再次去对同一个master执行failover,这个等待的年华是经failover-timeout配置起去安排的。从夫规则可见见,sentinel集众多被的sentinel不见面重复同时刻并发去failover同一个master,第一独进行failover的sentinel如果失败了,另外一个将会晤以必时间内展开再次展开failover,以此类推。

sentinel保证了活跃性:如果大多数sentinel能够互为通信,最终以见面起一个被授权去开展failover.
sentinel也保证了安全性:每个试图去failover同一个master的sentinel都见面赢得一个无比的版本号。

 

 这个中,每个目录中都出谈得来的redis.conf
配置文件,接下去,我们先设置主服务器的配置文件。

SDOWN和ODOWN

  以介绍sentinel原理之前,需要了解的片单概念SDOWN和ODOWN:

  • SDOWN:全拼Subjectively
    Down,称为主观下线,指的是单科sentinel对redis实例作出的底线状态判断。
  • ODOWN:全拼Objectively Down,称为客户端下线,指多只 Sentinel
    实例在对同一个redis做出 SDOWN 判断,并且通过 SENTINEL
    is-master-down-by-addr
    命令互相交流下,得出的redis实例下线判断。(一个 Sentinel
    可以经向外一个 Sentinel 发送 SENTINEL is-master-down-by-addr
    命令来询问对方是否当给定的redis实例已生线。)

由sentinel的角度来拘禁,如果发送了PING心跳后,在定时间外没收合法的回升,就上了SDOWN的标准。这个日子在配备中经过master-down-after-milliseconds参数配置。

当sentinel发送PING后,以下回复有且叫看是官的:

PING replied with +PONG.
PING replied with -LOADING error.
PING replied with -MASTERDOWN error.

别任何回复(或者根本无回复)都是休合法的。

自打SDOWN切换到ODOWN不需要外一致性算法,只待一个gossip协议:如果一个sentinel收到了足多之sentinel发来消息告知其有master已经down掉了,SDOWN状态就会见成ODOWN状态。如果之后master可用了,这个状态就会相应地为清理掉。

确开展failover需要一个授权的历程,这个授权的长河就是是leader选取过程,但是有的failover都开始让一个ODOWN状态。ODOWN状态才适用于master,对于未是master的redis节点sentinel之间不需要另协议,slaves和sentinel不会见发生ODOWN状态。

 

一、配置Master

1、修改端口

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

redis 的默认端口是6379,这里我们把主服务器的端口设置也6380

2、修改pidfile

# If a pid file is specified, Redis writes it where specified at startup
# and removes it at exit.
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
pidfile /var/run/redis_6380.pid

pidfile 是我们启动redis 的时光,linux 也咱分配的一个pid
进程号,如果这里不发改,会潜移默化后面redis服务的启动

3、启动 redis

图片 5

  启动redis,我们可见见,redis已经攻占了6380 端口
  进入客户端

redis-cli -p 6380
127.0.0.1:6380> info
...
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
...

咱得望,redis 现在底角色是一个master 启动之劳动。

sentinel相关命令

  和redis一样,sentinel可以通过客户端应用命令操作,例如查看master状态SENTINEL
masters,
示例:

图片 6

以下是具备命令和分解:

SENTINEL masters  #列出所有被监视的master,以及当前master状态
SENTINEL master <master name>  #列出指定的master
SENTINEL slaves <master name>  #列出给定master的所有slave以及slave状态
SENTINEL sentinels <master name>  #列出监控指定的master的所有sentinel
SENTINEL get-master-addr-by-name <master name>  #返回给定master名字的服务器的IP地址和端口号
SENTINEL reset <pattern>  #重置所有匹配pattern表达式的master状态
SENTINEL failover <master name>  #当msater失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移,但是它会给其他sentinel发送一个最新的配置,其他sentinel会根据这个配置进行更新
SENTINEL ckquorum <master name> #检查当前sentinel的配置能否达到故障切换master所需的数量,此命令可用于检测sentinel部署是否正常,正常返回ok
SENTINEL flushconfig #强制sentinel将运行时配置写入磁盘,包括当前sentinel状态

图片 7

环境设计

  本次部署过程中将分别配备三独哨兵节点来监督一主二于之redis集群,主从的搭建过程可以参见笔者博文《redis系列–主从复制以及redis复制演进》,以下是环境规则:

  • 哨兵节点:10.1.210.32:26379、10.1.210.33:26379、10.1.210.34:26379
  • redis实例:10.1.210.69:6379(主)、10.1.210.69:6380(从)、10.1.210.69:6381(从)

图片 8

运行Sentinel

  启动sentinel的点子有三三两两种植,两种方式都须指定安排文件:

#第一种(推荐)
redis-sentinel /path/to/sentinel.conf

#第二种
redis-server /path/to/sentinel.conf --sentinel

以下是笔者三只节点的配置文件,并以拷贝到三个节点开展启动:

图片 9图片 10

bind 10.1.210.32 #IP地址

port 26379   #端口

dir /opt/db/redis  # 数据存储目录

daemonize yes  #后台运行

logfile /opt/db/redis/sentinel.log  #日志

sentinel monitor mymaster 10.1.210.69 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

10.1.210.32

图片 11图片 12

bind 10.1.210.33 #IP地址

port 26379   #端口

dir /opt/db/redis  # 数据存储目录

daemonize yes  #后台运行

logfile /opt/db/redis/sentinel.log  #日志

sentinel monitor mymaster 10.1.210.69 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

10.1.210.33

图片 13图片 14

bind 10.1.210.34 #IP地址

port 26379   #端口

dir /opt/db/redis  # 数据存储目录

daemonize yes  #后台运行

logfile /opt/db/redis/sentinel.log  #日志

sentinel monitor mymaster 10.1.210.69 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

10.1.210.34

通过redis-sentinel
/opt/db/redis/sentinel.conf启动每个sentinel,以下是开行日志(可以发现sentinel自动通过master发现slave和其它sentinel):

图片 15

 此时,一个sentinel集群就搭建好。

 

图片 16

心想事成原理  

  一个sentinel启动时会读取配置文件,并透过sentinel monitor
<master-name> <ip> <port>
<quorum>配置寻找要监督之主数据库,这个布局在事先已进展详细说明,其中master-name是由一个可怜小写字母、数字、和“._-”组成的数据库主库名字,为了考虑到主库的IP地址和端口可能以故障切换后发出转移,所以还得ip和port来标示这个主库。一个哨兵可监控多独着力系统就此形成网状结构,正而在前简介的图示一样。

  sentinel启动后,会暨监督的数据库建立两长长的连接,如下图(主库10.1.210.69:6379以及10.1.210.32的sentinel节点两长链接):

图片 17

眼看半单连续和一般客户端一样,其中同样修连接用来订阅master的__sentinel__:hello频道用于取其它监察该数据库的sentinel节点信息,另外一长用于哨兵定期为主数据库发送INFO等一声令下获取主库本身信息,原因在当客户端进入订阅模式下只能接受信息,不能够发送命令,所以还用树立平等久连接。

  与监督之主库建立连接成功后,sentinel定时实行以下操作:

  1. 诸10s会向主数据库和由数据库发送INFO命令;
  2. 各国1s朝向master、slave以及任何哨兵节点发送PING命令;
  3. 每2s向master和slave的__sentiel__:hello频道发送温馨的信来公布自己之存在,同时该过程为是促成哨兵之间自动发现的基本功;

马上三个操作贯穿了哨兵整个生命周期,非常重要,也是那个原理的骨干,所以以下将详细介绍该操作过程。

  首先,sentinel启动后,向主库发送INFO命令使得sentinel可以拿走当前主库的相关消息(包括运转的ID,复制信息、以及属于该主库的从库节点信息),这吗是怎么当配备监控上只是待安排监控之主库信息sentinel就活动找到那相应的从库,进而实现自仓库底督察。而后与每个从库同样成立两只连,这半只连续和上文介绍的及主库的并个连了平等,在此之后,哨兵会各10s定时为业已知晓所有骨干发送INFO命令获取信息更新并展开对应操作,比如针对新增的从库建立连接并进入监控班、又要是主库信息发生变化(由failover引起的)进行信息更新等。

  接下去哨兵向master和slave的__sentinel__:hello频道发送信息与平等监控该redis示例的任何哨兵分享自己的音信。发送的音讯内容呢:

<哨兵地址>
,<哨兵端口>,<哨兵运行的ID>,<哨兵配置的版>,<主库名称>,<主库地址>,<主库端口>,<主库配置版本>,该消息包含了哨兵基本信息以及监督之主库信息,当其他sentinel收到信息继会见咬定发信息之哨兵是不是新的哨兵,如果是则将该进入已意识的哨兵列表,并创建一个暨那的连年(与数据库不同)哨兵及哨兵之间仅会创造同长连接用于发送PING命令,同时sentinel会判断主数据库的部署版本,如果该版比记录数据库版本高,则更新主数据库的数额,其意图在继承介绍。

  实现了机动发现于数据库与其它sentinel节点后,sentinel后续要开的任务是定时监控这些就发现的核心节点和sentinel节点是否在线。这种监督落实方式是当经自然时间间隔发送PING命令实现,时间距离安排通过down-after-milliseconds指定,当跨越down-after-milliseconds配置的日晚,如果被PING的数据库或者sentinel未恢复,则哨兵认为其莫名其妙下线(主观下线在上面已经介绍了),如果该节点是主库sentinel会越加进行判断是否用针对该展开故障恢复(failover):sentinel会发送SENTINEL
is-master-down-by-addr命令询问其他sentinel节点是否为当该主库主观下线,如果达到指定数量(在示范配置中也进行了证,示例配置的凡2)时,哨兵会看其理所当然下线,连精选领头的哨兵(leader)进行故障恢复,选举过程持续介绍。

  选举结束零头哨兵后,领头哨兵会开始对主数据库进行故障恢复,这同经过叫failover,在挑选新的master时候,sentinel会考虑以下状况:

  • 跟master断开连接的常常长 
  • slave的先期级 (由slave-priority配置指定)
  • 复制偏移量offset 
  • 实例运行的id(run id)

具体的挑各个如下:

万一一个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相同,那么比复制偏移量,offset越靠后(越充分)则表明和原来的主库数据并越接近,优先级就一发高
  3. 设若地方两单原则且同一,那么选择一个run id最小之从库;

选出从仓库后,零头哨兵将于于数据库发送SLAVEOF NO
ONE命令升级其为新的主库,然后于通往其它从库发送SLAVEOF命令将从之主库升级到新型的主库,最后更新中记录将早已停的主库更新也新的主库的从库,使得当该故障的主库再次卷土重来时候自动为由仓库角色继续提供劳动,从起步至故障恢复好这有些列过程即是哨兵的办事之总体流程也是彼规律所在。

三、Sentinel 哨兵

1、配置端口
    在sentinel.conf 配置文件被, 我们得以找到port
属性,这里是故来设置sentinel
的端口,一般情形下,至少会待三个哨兵对redis
进行监督,我们可以通过改动端口启动多只sentinel 服务。

# port <sentinel-port>
# The port that this sentinel instance will run on
port 26379

2、配置主服务器的ip 和端口
   我们管监听的端口修改成6380,并且增长权值为2,这里的权值,是故来计量我们用拿哪一样高服务器升级升主服务器

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# Tells Sentinel to monitor this master, and to consider it in O_DOWN
# (Objectively Down) state only if at least <quorum> sentinels agree.
#
# Note that whatever is the ODOWN quorum, a Sentinel will require to
# be elected by the majority of the known Sentinels in order to
# start a failover, so no failover can be performed in minority.
#
# Slaves are auto-discovered, so you don't need to specify slaves in
# any way. Sentinel itself will rewrite this configuration file adding
# the slaves using additional configuration options.
# Also note that the configuration file is rewritten when a
# slave is promoted to master.
#
# Note: master name should not include special characters or spaces.
# The valid charset is A-z 0-9 and the three characters ".-_".
sentinel monitor mymaster 127.0.0.1 6380 2

3、启动Sentinel

/sentinel$ redis-sentinel sentinel.conf

图片 18

  sentinel 启动之后,就会见监视到今日起一个主服务器,两独从服务器
  当我们把里面一个于服务器器关闭后,我们好看看日志:

10894:X 30 Dec 16:27:03.670 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

日记表示,6381以此从服务器都从主服务器受到脱离了出去,我们再次把6381
接回到。

10894:X 30 Dec 16:28:43.288 * +reboot slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 638010894:X 30 Dec 16:28:43.365 # -sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

4、关闭Master
    我们手动关闭Master 之后,sentinel 在监听master
确实是断线了后头,将会晤起算计权值,然后重新分配主服务器

图片 19

    我们可以看,6380主服务器断了之后,sentinel
帮咱选择了6382当做新的主服务器
    我们前行至6382之客户端,查看他的状态:

# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=13751,lag=0
master_repl_offset:13751
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:13750

我们可以看到 6382,重slave 荣升为master

127.0.0.1:6382> set name jaycekon
OK

原来的远非权限写,也获得了相应的权柄

5、重连Master
    大家可能会见惊奇,如果master
重连下,会无会见快掉属于他的职务,答案是否定的,就按您给一个兄弟抢了卿非常的职,他乐意吃回你这个职位吗。因此当master
回来之后,他呢只能当只兄弟  

图片 20

安配置

  sentinel安装和redis安装过程一样,请参见redis系列文章,而当源码中,redis提供了参考布局示范sentinel.conf(可以以命令grep
-E -v ^# sentinel.conf 查看),如下:

port 26379

dir /tmp

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

布说明:

sentinel monitor mymaster 127.0.0.1 6379 2

 这行安排代表sentinel监控之master名字叫做mymaster(可以好沾),地址是127.0.0.1,端口是6379。最后一个2代表当sentinel集众多被来2单sentinel认为master故障时候才看清master真正不可用。官方把欠参数称为quorum,在连续选举领头哨兵时候会因此到,在下文将开展介绍。

sentinel down-after-milliseconds mymaster 30000

sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间限制”内无转应PONG
或者是过来了一个破绽百出信息,那么这个sentinel会主观地(单方面地)认为这master已经休可用了(subjectively
down,
也简称也SDOWN)。而之down-after-milliseconds就是因此来指定这个“一定时间范围”的,单位凡毫秒,在这里表示30秒时外master不回应PONG则主观不可用。

sentinel parallel-syncs mymaster 1

拖欠配置表明在有failover主备切换时,最多允许多少个slave同时一并新的master。这个数字更是聊,完成failover所需的岁月即愈加长,但是如果这数字越充分,就代表越多的slave因为replication而未可用。可以由此以此值设为
1 来保管每次就生一个slave处于不克处理命令请求的状态。

sentinel failover-timeout mymaster 180000

failover-time超时时间,当failover开始后,在这个日外仍没有接触任何failover操作,当前sentinel将见面觉得本次failover失败,单位毫秒。

轻易察觉有关sentinel的安排都是固定格式如下:

sentinel <option_name> <master_name> <option_value>

 

四、Sentinel 总结

一、Sentinel的作用:

  • A、Master 状态监测
  • B、如果Master 异常,则会开展Master-slave
    换,将中一个Slave作为Master,将事先的Master作为Slave
  • C、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
    的无理下线状态就会见于移除。

 四、Sentinel原理

二、配置Slave

跟方面配置 master一样,我们得修改端口号及pid
文件,在修改了之后,我们来点儿种植办法配置起劳动
  1、在安排文件中安排从劳动

################################# REPLICATION #################################

# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
# 1) Redis replication is asynchronous, but you can configure a master to
#    stop accepting writes if it appears to be not connected with at least
#    a given number of slaves.
# 2) Redis slaves are able to perform a partial resynchronization with the
#    master if the replication link is lost for a relatively small amount of
#    time. You may want to configure the replication backlog size (see the next
#    sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
#    network partition slaves automatically try to reconnect to masters
#    and resynchronize with them.
#
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6380

我们得以于布局文件中一直改动 slaveof 属性,我们一直配置主服务器的ip
地址,和端口号,如果这里主服务器发布置密码
  可以经过部署masterauth 来设置链接密码

# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
#
# masterauth <master-password>

启动redis 服务:

图片 21

  我们好看看,现在时有发生少只现行当运行,我们上6381之客户端,看一下客的状态,

# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:71
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

咱们好观看,现在之redis 是一个由劳动的角色,连继6380的劳动。

2、在服务启动后安装
咱们修改6382端口的服务器配置文件后,启动服务

图片 22

进入客户端,查看时服务器的状态:

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

咱们好观看,当前服务器的状态时作为一个主服务的角色当运行,我们接下修改外的状态:

127.0.0.1:6382> slaveof 127.0.0.1 6380

//修改后状态
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:617
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3、总结
咱们先押一下时master 的状态:

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=785,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=785,lag=0
master_repl_offset:785
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:784

我们可以可以看,两个自服务都以并正在主服务器,上面两栽配备的分在,当salve
断线重连下,
   如果我们是修改类配置文件,重连之后会友善链接上去master,并且并master
上面的数目,
   如果我们是手动连接上的主服务器,重连之后,从服务器会宣读博好本地的
rdb 回复数,而未会见失去自动链接主服务

我们设需要设置读写分离,只待以主服务器中安:

# Note: read only slaves are not designed to be exposed to untrusted clients
# on the internet. It's just a protection layer against misuse of the instance.
# Still a read only slave exports by default all the administrative commands
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
# security of read only slaves using 'rename-command' to shadow all the
# administrative / dangerous commands.
slave-read-only yes

一、前言

  在前的比比皆是文章被介绍了redis的入门、持久化以及复制功能,如果不打听请动到redis系列进展阅读,当然我为是取在读的知识分享,如果出什么问题欢迎指正,也接大家转载。而本次用介绍哨兵集群相关文化,包括哨兵集群部署、哨兵原理、相关安排、故障转移等情节,正缘redis有了哨兵机制,而在诸多企业(包括笔者自我之号)采用的凡哨兵模式下之redis主从。

    
在Server1 掉线后:

 八、结束语

  从redis的入门再届哨兵模式,再届平时使用那API进行相关操作,通过一段时间的研究对redis也毕竟有矣迟早层次的认识,所以把这些经过都记录下来,分享给其他人,希望发生再次多的丁不惟知晓哪使,更能了解其中的法则,在生问题下会便的定位问题。当然或许在文章中或者在无得法的地方吧欢迎大家指正,毕竟没有源码级别之知道。最后可能需要研究的有的就是是redis的集群,后续在研究了后写文章介绍,这为毕竟对redis有一个比全面的认识。

  

Sentinel(哨兵)是Redis 的高可用性解决方案:由一个还是多只Sentinel 实例
组成的Sentinel
系统可监视任意多单主服务器,以及这些主服务器属下的享有自服务器,并当受监视的主服务器进入下线状态时,自动将下线主服务器属下的有从服务器升级为新的主服务器。
例如:

1、Sentinel 哨兵

留下评论

网站地图xml地图