redis sentinel 主从切换(failover)解决方案，详细配置
作者：oyhk&&& 23:55:49&&&&0 评论&&&&629浏览
博客分类：&
由于图片较大，缩放较为模糊，请双击打开查看原图 ^_^&
主从复制简单来说就是把一台redis数据库中的数据同步到另一台redis数据库，并且按照数据流向，数据的发送者我们称作master，数据的接受者我们称作slave（master/slave的划分并不是那么一定的，譬如B可以作为A的slave，但同时也可以作为C的master），下面就从slave和master的角度分别说明主从复制流程。&
首先是slave端，对于slave端来说，主从复制主要经历四个阶段：&
第一阶段：与master建立连接&
第二阶段：向master发起同步请求（SYNC）&
第三阶段：接受master发来的RDB数据&
第四阶段：载入RDB文件&
下面我们就通过一个图来概述在每一个阶段中，slave究竟做了些什么：&
关于上图，有一点说明下：redis接收到slaveof master_host master_port命令后并没有马上与master建立连接，而是当执行服务器例行任务serverCron，发现自己正处于REDIS_REPL_CONNECT状态，这时才真正的向maser发起连接，伪代码：&
Python代码&&
def&serverCron():&&
&&&&if&redisServer.repl_state&==&REDIS_REPL_CONNECT:&&
&&&&&&&&&&
&&&&&&&&connectWithMaster()&&
接着我们来看下主从复制过程中，master这边的流程是如何，在具体看细节之前，我们先综合来看master这边主要做的几件事情：&
看完这个图，你也许会有以下几个疑问：&
1. 为什么在master发送完RDB文件后，还要定期的向slave发送PING命令？&
2. 在发送完RDB文件之后，master发送的“变更”命令又是什么，有什么用？&
在回答问题之前1，我们先回答问题2：&
master保存RDB文件是通过一个子进程进行的，所以master依然可以处理客户端请求而不被阻塞，但这也导致了在保存RDB文件期间，“键空间”可能发生变化（譬如接收到一个客户端请求，执行&set name diaocow&命令），因此为了保证数据同步的一致性，master会在保存RDB文件期间，把接受到的这些可能变更数据库“键空间”的命令保存下来，然后放到每个slave的回复列表中，当RDB文件发送完master会发送这些回复列表中的内容，并且在这之后，如果数据库发生变更，master依然会把变更的命令追加到回复列表发送给slave，这样就可以保证master和slave数据的一致性！相关伪代码：&
Python代码&&
def&processCommand(cmd,&argc,&argv):&&
&&&&call(cmd,&argc,&argv)&&
&&&&if&redisServer.update_key_space&and&len(redisServer.slaves)&&&0:&&
&&&&&&&&replicationFeedSlaves(cmd,&argc,&argv)&&
def&replicationFeedSlaves(cmd,&argc,&argv):&&&
&&&&for&slave&in&redisServer.slaves:&&
&&&&&&&&if&slave.replstate&==&REDIS_REPL_WAIT_BGSAVE_START:&&
&&&&&&&&&&&&continue&&
&&&&&&&&slave.updateNotify(cmd,&argc,&argv)&&
由于在发送完RDB文件之后，master会不定时的给slave发送“变更”命令，可能过1s，也可能过1小时，所以为了防止slave无意义等待（譬如master已经挂掉的情况），master需要定时发送“保活”命令PING，以此告诉slave：我还活着，不要中断与我的连接&
现在我们就看下，当master接受到slave发送的sync同步命令后究竟发生了哪些事：&
上图看似分支复杂，但我们抓住以下几点即可：&
1.保存RDB文件是在一个子进程中进行的；&
2.如果master已经在保存RDB文件，但是没有客户端正在等待这次BGSAVE，新添加的slave需要等到下次BGSAVE，而不能直接使用这次生成的RDB文件（原因图中已经说明）&
3.master会定期检查RDB文件是否保存完毕（时间事件serverCron）；&
接下来我们看下，master是如何给每一个slave发送RDB文件的：&
好了，至此我们已经分析完在主从复制过程中，master和slave两边分别是怎么一个处理流程;最后，我绘制了一个图，综述了主从复制这一过程（我们可以边看图，边回忆其中的具体细节）：&
PS：在主从复制过程中，任何一步发生错误，都会导致整个过程重头开始，所以若RDB文件很大又或是此时正处在业务高峰期，对系统性能将会有非常大的影响！&
1. 了解主从复制master和slave的概念；&
2. 了解主从复制执行过程，特别是其中关键的几步；&
3. 了解目前主从复制过程中尚存的不足之处；&
oyhk 学习笔记
网站的访问量慢慢上来了。为了网站的性能方面，开始用了redis做缓存策略。刚开始的时候，redis是一个单点，当一台机器岩机的时候，redis的服务完全停止，这时就会影响其他服务的正常运行。费话不多说了，下面利用redis sentinel做一个主从切换的集群管理。做这个集群管理的时候，查过很多资料才完全了解，他是怎么做的。
java 客户端请看：
参考资料：&我也是看这篇文章。
环境配置：
由于我这次配置没有太多的机器，我用了vagrant 去开了多台虚拟机。然后搭好了环境。
redis的安装请参考：
集群配置最少需要三台机器，那么我就三台虚拟机,三台虚拟机分别安装同样的redis的环境
192.168.9.17 &（redis sentinel 集群监控）192.168.9.18 &（redis 主）192.168.9.19 &（redis 从）
redis配置:
主的redis配置文件,使用默认的配置文件就可以了，如果你需要设计其他参数
从的redis配置文件，添加
#从的redis配置文件，需要添加
vim /etc/redis/6379.conf
slaveof 192.168.9.18 6379
启动主从redis
#启动主redis（192.168.9.18）
/etc/init.d/redis_6379.conf start
#启动从redis（192.168.9.19）
/etc/init.d/redis_6379.conf start
查看主redis信息
#查看主redis的信息
redis-cli -h 192.168.9.18 info Replication
# Replication
role:master #代表192.168.9.18:6379 这台redis是主
connected_slaves:1
slave0:192.168.9.18,6379,online
查看从redis信息
#查看主redis的信息
redis-cli -h 192.168.9.19 info Replication
# Replication
role:slave #代表192.168.9.18:6379 这台redis是主
master_host:192.168.9.18
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_priority:100
slave_read_only:1
connected_slaves:0
配置redis sentinel集群监控服务
1.添加一份redis sentinel 配置文件
vim /etc/redis/sentinel.conf
##sentinel实例之间的通讯端口
port 26379
sentinel monitor master1 192.168.9.18 6379 1
sentinel down-after-milliseconds master1 5000
sentinel failover-timeout master1 900000
sentinel can-failover master1 yes
sentinel parallel-syncs master1 2
可以添加多组主从的redis监听
2.有配置文件了，那么启动redis sentinel做redis集群监听
redis-sentinel sentinel.conf --sentinel
好了，所有环境都搭好了。下面开始正式的演示
1.正常演示。
把主的redis启动把从的redis启动把redis sentinel 集群监听启动
观察redis sentinel 日志信息
这里很清楚地看到，从的redis加入了集群
[4925] 15 Oct 03:42:21.889 * +slave slave 192.168.9.19:6379 192.168.9.19 6379 @ master1 192.168.9.18 6379
执行以下命令，查看redis主从信息
[root@localhost vagrant]# redis-cli -h 192.168.9.17 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master1,status=ok,address=192.168.9.18:6379,slaves=1,sentinels=1
那么表示一切都正常了。你的redis sentinel集群已经配置成功！
2.故障演示
2.1当主的redis 服务器岩机了，会发生什么情况呢？
执行以下命令使用主的redis服务停止
redis-cli -h 192.168.9.18 -p 6379 shutdown #表示把192.168.9.18这台redis 关闭
关闭后，我们再查看redis sentinel 的日志情况
这张图片很清晰地反应到，redis sentinel 监控到主的redis服务停止，然后自动把从的redis切换到主。
再执行以下命令，查看redis主从信息
[root@localhost vagrant]# redis-cli -h 192.168.33.111 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master1,status=ok,address=192.168.9.19:6379,slaves=1,sentinels=1
把从已经升为主了。那么自动切换就已经成功了！
2.2 当我们已经发现，一台redis发生故障了，可能会收到一些故障信息，那么再把服务已关闭的redis恢复服务状态，会发生怎么样的情况呢？
redis sentinel 集群服务，会把上次主redis重新加入服务中，但是他再以不是主的redis了，变成从的reids。
哈.....完成了。。。下篇会写关于，客户端调用主从集群自动切换使用例子。我会以java为使用客户端.
本文已收录于以下专栏：
相关文章推荐
目前Redis Cluster仍处于Beta版本，Redis 3.0将会加入，在此可以先对其主要功能和原理进行一个预览。参考《Redis Cluster - a pragmatic approach ...
Redis 命令参考 »
本文档翻译自： http://redis.io/topics/sentinel 。
Redis 的 Sentine...
摘自：/stephen-liu74/archive//2364717.html
“下面的列表清楚的解释了Redis...
搭建好redis单机后，开始研究redis集群配置
两台VM虚拟机，都安装了redis程序，一台作为master 一台作为slave
首先配置redis主从配置
配置在redis.conf文件中
简介经过上次轻松搭建了一个Redis的环境并用Java代码调通后，这次我们要来看看Redis的一些坑以及Redis2.8以后带来的一个新的特性即支持高可用特性功能的Sentinel（哨兵）。Redis...
redis-sentinel是集群管理工具，主要负责主从切换。
下面是我对Redis 2.9.11－非稳定版作的测试总结，更新的版本可能没有下面的问题。
1.如果默认主从关系的主挂了，这时启动fail...
Redis哨兵为Redis提供了高可用性。实际上这意味着你可以使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。
哨兵模式还提供了其他的附加功能，如监控，通知，为客...
简单介绍下Redis-sentinel：
Redis-sentinel是Redis实例的监控管理、通知和实例失效备援服务，是Redis集群的管理工具。在一般的分布式中心节点数据库中，Redis-sen...
redis的主从（master-slave）就是为了数据冗余备份、保证数据的安全、提高性能，在这里主要讲解一下其主从切换的两种方式，有不对之处，还请各位指教。
  首先搭建一个简单的master-s...
redis主从+sentinel主从自动切换
版本:redis-2.8.19.tar.gz
说明:redis3.x默认不设置密码验证会启动保护模式
他的最新文章
讲师：刘文志
讲师：陈伟
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)Sentinel-Redis高可用方案（二）：主从切换 - 風語者·疾風 - 博客园
Agile Methodology, HeadStorm And MindMap, they will change me.
posts - 81, comments - 385, trackbacks - 14, articles - 19
Redis 2.8版开始正式提供名为Sentinel的主从切换方案，Sentinel用于管理多个Redis服务器实例，主要负责三个方面的任务：
1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
启动Sentinel
使用--sentinel参数启动，并必须指定一个对应的配置文件，系统会使用配置文件来保存 Sentinel 的当前状态， 并在 Sentinel 重启时通过载入配置文件来进行状态还原。
redis-server /path/to/sentinel.conf --sentinel
使用TCP端口26379，可以使用redis-cli或其他任何客户端与其通讯。
如果启动 Sentinel 时没有指定相应的配置文件， 或者指定的配置文件不可写（not writable）， 那么 Sentinel 会拒绝启动。
配置Sentinel
以下是一段配置文件的示例：
sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 60000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4sentinel down-after-milliseconds resque 10000sentinel failover-timeout resque 180000sentinel parallel-syncs resque 5
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
不过需要注意的是，无论你设置要多少个 Sentinel 同意才能判断一个服务器失效，一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持，才能发起一次自动故障迁移，并预留一个给定的配置纪元 （Configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。也就是说，如果只有少数（minority）Sentinel 进程正常运作的情况下，是不能执行自动故障迁移的。
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数（判定为主观下线SDOWN）。
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长，但越大就意味着越多的从服务器因为复制而不可用。可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
主观下线和客观下线
1. 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
2. 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
每个Sentinel实例都执行的定时任务
1. 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
3. 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
4. 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
5. 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
6. 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。
Sentinel API
有两种方式可以与Sentinel进行通讯：指令、发布与订阅。
Sentinel命令
PING ：返回 PONG 。
SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态；
SENTINEL slaves &master name& ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态；
SENTINEL get-master-addr-by-name &master name& ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个
命令返回新的主服务器的 IP 地址和端口号；
SENTINEL reset &pattern& ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel ；
SENTINEL failover &master name& ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移。
客户端可以通过SENTINEL get-master-addr-by-name &master name&获取当前的主服务器IP地址和端口号，以及SENTINEL slaves &master name&获取所有的Slaves信息
发布与订阅信息
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
+switch-master &master name& &oldip& &oldport& &newip& &newport& ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
可以看出，我们使用Sentinel命令和发布订阅两种机制就能很好的实现和客户端的集成整合：
使用get-master-addr-by-name和slaves指令可以获取当前的Master和Slaves的地址和信息；而当发生故障转移时，即Master发生切换，可以通过订阅的+switch-master事件获得最新的Master信息。
*PS:更多Sentinel的可订阅事件参见。
sentinel.conf中的notification-script
在sentinel.conf中可以配置多个sentinel notification-script &master name& &shell script-path&, 如sentinel notification-script mymaster ./check.sh
这个是在群集failover时会触发执行指定的脚本。脚本的执行结果若为1，即稍后重试（最大重试次数为10）；若为2，则执行结束。并且脚本最大执行时间为60秒，超时会被终止执行。
PS：目前会存在该脚本被执行多次的问题，查找资料有人解释是：
脚本分为两个级别， SENTINEL_LEADER 和 SENTINEL_OBSERVER ，前者仅由领头 Sentinel 执行（一个 Sentinel），而后者由监视同一个 master 的所有 Sentinel 执行（多个 Sentinel）。redis（7）
中文资料：/html/3537.html
redis的主从复制在前面的文章已经详细地了解过了，本文主要是针对主从切换的方案来说一下。一种很熟悉的应用场景，加入master的服务器突然间岩机的时候，那么对于整个的系统都是不能写数据（master主要负责写），所以系统就相当于已经瘫痪。如果可以自动地在master发生故障时，能够故障转移（failover）,将其中一个slave推荐成为master。基于redis的官方的sentinel（哨兵）就可以实现这种方案。
sentinel的简介
Redis-sentinel是Redis实例的监控管理、通知和实例失效备援服务，是Redis集群的管理工具。在一般的分布式中心节点数据库中，Redis-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。
sentinel.conf配置：
1：指定监听Master(2个节点)
port 26379
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 900000
#上面配置文件说明如下：
#第一行指定sentinel端口号
#第二行指定sentinel为后台启动
#第三行指定Sentinel去监视一个名为 mymaster 的Master，Master的IP地址为127.0.0.1，端口号为6379，最后的2表示当有2个Sentinel检测到Master异常时才会判定其失效，即只有当2个Sentinel都判定Master失效了才会自动迁移，如果Sentinel的数量不达标，则不会执行自动故障迁移。
#第四行指定Sentinel判定Master断线的时间。（单位为毫秒，判定为主观下线SDOWN）
#第五行指定在执行故障转移时，最多可以有多少个Slave同时对新的Master进行同步。这个数字设置为1，虽然完成故障转移所需的时间会变长，但是可以保证每次只有1个Slave处于不能处理命令请求的状态、
1、分别启动三个redis实例
（1）127.0.0.1 6379 (master)
（2）127.0.0.1 6380（slave）
（3）127.0.0.1 6381 （slave）
每一个实例对应着一个不同的redis.conf文件，master的redis.conf基本不用改。slave主要是修改
&pre name=&code& class=&html&&port 6380
slaveof 127.0.0.1 6379
slaveof 127.0.0.1 6379
每一个slave的实例都配置slaveof。
启动redis,进入到redis的文件夹下面
redis-server redis.conf再打开终端
连接master，端口6379
设置一个键值 name='huangzengbing‘
查看复制信息
可以看到6379是一个master 的角色，其中属于他的slave有两个，分别是
再打开另一个终端，连接6380
获取键名为name的值，之前在master设置的。可以看到在6380的这个slave上已经有了这个值，说明主从复制成功。
在看一下6380的复制信息
可以看到6380是slave的角色，对应的master是在线的
再打开一个终端，连接6381
获取键名为name的值，可以看到存在这个值，说明主从复制成功
在看一下复制信息
角色为slave，对应着master的信息
以上的测试，可以知道master-slave的复制成功。
模拟failover—故障转移
分别启动两个sentinel实例，端口分别对应2,sentinel.conf的配置
port 26379
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 900000例外一个sentinel.conf
port 26380
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 900000
下面启动sentinel，端口26379
注意redis-sentinel这个执行文件是存放在下载的redis的包里的。
启动另一个sentinel，端口26380
下面模拟master出现故障。模拟方案是将master突然关闭掉，在6379的终端上关闭redis实例。
关闭之后，在get name,无法在获取到值。
接着，查看6380的复制信息
可以看到，6380已经成了master的角色，他的slave只有一个6381
在查看6381的复制信息
可以看到6381对应的master是6380，而不是6379（因为它已关闭），说明了什么呢？
再给新的master 6380设置值，看看slave 6381是否同步
在6381上获取键名为address的值
可以看到能够获取到值。说明新建立的主从关系能够实现主从复制。
下面重新启动6379的redis实例
查看复制信息
可以看到，6379已经成为了6380的slave。
获取健名为address的值
6379可以获取到master的设置的值，说明重新启动的slave可以实现复制
再查看一下6379的对应的redis.conf的配置文件
配置文件rewrite（重写）一个新的配置项，标志master是6380
而在查看6380的对应的redis.conf,已经将salveof 127.0.0.1 6379 这一个配置删除，因为它已经成为了新的master了，无需配置slaveof。
模拟测试总结与问题
（1）redis的sentinel提供了一个很好的HA方案，但就目前来说，该方案还没有合并进正式版本中，要在实际生产环境使用的话，可能还需要配合客户端。
（2）客户端如何动态的获取sentinel的信息，如何动态实现主从切换。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：212078次
积分：3198
积分：3198
排名：第11455名
原创：98篇
转载：45篇
评论：39条
(1)(2)(3)(5)(5)(4)(4)(1)(6)(5)(5)(9)(8)(2)(5)(9)(4)(17)(19)(8)(2)(8)(3)(9)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'