本文共 18925 字，大约阅读时间需要 63 分钟。
192.168.110.21 主192.168.110.31 从#两台服务器都安装redis#下载最新稳定版本：http://redis.io/downloadwget http://download.redis.io/releases/redis-2.8.19.tar.gz#安装tar -zxvf redis-2.8.19.tar.gzcd redis-2.8.19more READMEmake#安装tclsh8.5make test#You need 'tclsh8.5' in order to run the Redis testldconfig -p |grep tcl#libtcl8.4.so (libc6,x86-64) => /usr/lib64/libtcl8.4.so 【tcl8.5】 wget http://downloads.sourceforge.net/tcl/tcl8.5.12-src.tar.gz tar zxvf tcl8.5.12-src.tar.gz cd tcl8.5.12 cd unix ./configure --prefix=/usr --enable-threads --mandir=/usr/share/man make sed -e "s@^\(TCL_SRC_DIR='\).*@\1/usr/include'@" -e "/TCL_B/s@='\(-L\)\?.*unix@='\1/usr/lib@" -i tclConfig.sh make test make install make install-private-headers ln -v -sf tclsh8.5 /usr/bin/tclsh chmod -v 755 /usr/lib/libtcl8.5.so#继续安装make testmake PREFIX=/usr/local/webserver/redis install#配置文件和启动脚步mkdir /usr/local/webserver/redis/etc/cp redis.conf /usr/local/webserver/redis/etc/redis.confcp utils/redis_init_script /etc/init.d/redis#修改启动脚步：根据实际安装路径修改启动脚步中配置的相关路径vim /etc/init.d/redisREDISPORT=6379EXEC=/usr/local/webserver/redis/bin/redis-serverCLIEXEC=/usr/local/webserver/redis/bin/redis-cliPIDFILE=/var/run/redis.pidCONF="/usr/local/webserver/redis/etc/redis.conf"#修改内核配置vim /etc/sysctl.conf添加vm.overcommit_memory=1刷新配置使之生效sysctl vm.overcommit_memory=1 【该文件指定了内核针对内存分配的策略，其值可以是0、1、2。0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何。2，表示内核允许分配超过所有物理内存和交换空间总和的内存Redis在dump数据的时候，会fork出一个子进程，理论上child进程所占用的内存和parent是一样的，比如parent占用的内存为8G，这个时候也要同样分配8G的内存给child, 如果内存无法负担，往往会造成redis服务器的down机或者IO负载过高，效率下降。所以这里比较优化的内存分配策略应该设置为 1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何）】#创建数据目录和日志目录(后面配置文件要用到)mkdir -p /data1/logs/redis/mkdir -p /data0/redis/var/#修改配置文件（部分配置）vim /usr/local/webserver/redis/etc/redis.conf daemonize yes #pidfile记得和启动脚步对应 pidfile /var/run/redis.pid port 6379 #为了避免service redis stop命令无法正常关闭redis，这里同时绑定127.0.0.1（因为脚步默认是通过127.0.0.1链接redis） #Could not connect to Redis at 127.0.0.1:6379: Connection refused bind 127.0.0.1 192.168.110.21 timeout 300 tcp-keepalive 0 loglevel notice logfile /data1/logs/redis/redis.log dir /data0/redis/var/ maxmemory 2G maxmemory-policy volatile-lru#设置防火墙不允许外部访问（安全问题）iptables -A INPUT -s 192.168.110.0/24 -p tcp -m tcp --dport 6379 -j ACCEPT#启动、关闭redis[root@master redis-2.8.19]# service redis startStarting Redis server...[root@master redis-2.8.19]# netstat -antpl | grep LIST | grep redistcp 0 0 192.168.110.21:6379 0.0.0.0:* LISTEN 6906/redis-server 1 tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 6906/redis-server 1 [root@master redis-2.8.19]# service redis stopStopping ...Redis stopped[root@master redis-2.8.19]# netstat -antpl | grep LIST | grep redis#查看redis信息192.168.110.21:6379> info#配置主从同步主库设置复制账号[root@master redis-2.8.19]# service redis startStarting Redis server...#非持久化配置[root@master redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli 127.0.0.1:6379> config set requirepass 123456OK或持久化配置：配置文件开启验证配置requirepass 123456从库配置文件开启复制，并设置复制密码，设置为只读slaveof 192.168.110.21 6379masterauth 123456slave-read-only[root@slave redis-2.8.19]# vim /usr/local/webserver/redis/etc/redis.conf[root@slave redis-2.8.19]# service redis startStarting Redis server...#错误处理：Unable to AUTH to MASTER: -ERR Client sent AUTH, but no password is set确保主requirepass 123456配置 和 从masterauth 123456配置成对出现#主从测试登录从，因为配置从只读，所以写失败[root@slave redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379192.168.110.31:6379> set test 123(error) READONLY You can't write against a read only slave.192.168.110.31:6379> quit登录主，写数据提示需要认证[root@slave redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379192.168.110.21:6379> set test 123(error) NOAUTH Authentication required.认证验证192.168.110.21:6379> auth 123456OK主写数据192.168.110.21:6379> set test 123OK192.168.110.21:6379> quit登录从，读取数据[root@slave redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379192.168.110.31:6379> set test 123(error) READONLY You can't write against a read only slave.192.168.110.31:6379> get test"123"#sentinel实现故障切换[root@master redis-2.8.19]# cp sentinel.conf /usr/local/webserver/redis/etc/sentinel.conf[root@master redis-2.8.19]# vim /usr/local/webserver/redis/etc/sentinel.conf port 26379sentinel monitor mymaster 192.168.110.21 6379 1sentinel down-after-milliseconds mymaster 30000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.110.31 6379 1sentinel down-after-milliseconds resque 30000sentinel failover-timeout resque 180000sentinel parallel-syncs resque 1[root@master redis-2.8.19]# cp sentinel.conf /usr/local/webserver/redis/etc/sentinel.conf[root@master redis-2.8.19]# vim /usr/local/webserver/redis/etc/sentinel.conf port 26379sentinel monitor mymaster 192.168.110.21 6379 1sentinel down-after-milliseconds mymaster 30000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.110.31 6379 1sentinel down-after-milliseconds resque 30000sentinel failover-timeout resque 180000sentinel parallel-syncs resque 1#启用sentinel主sentinel日志[root@master redis-2.8.19]# /usr/local/webserver/redis/bin/redis-sentinel /usr/local/webserver/redis/etc/sentinel.conf [9377] 14 Dec 16:53:42.578 # Sentinel runid is d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[9377] 14 Dec 16:53:42.578 # +monitor master resque 192.168.110.31 6379 quorum 1[9377] 14 Dec 16:53:42.578 # +monitor master mymaster 192.168.110.21 6379 quorum 1[9377] 14 Dec 16:53:42.579 * +slave slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[9377] 14 Dec 16:54:09.868 * +sentinel sentinel 192.168.110.31:26379 192.168.110.31 26379 @ mymaster 192.168.110.21 6379[9377] 14 Dec 16:54:09.923 * +sentinel sentinel 192.168.110.31:26379 192.168.110.31 26379 @ resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.592 # +sdown master resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.592 # +odown master resque 192.168.110.31 6379 #quorum 1/1[9377] 14 Dec 16:54:12.592 # +new-epoch 1[9377] 14 Dec 16:54:12.592 # +try-failover master resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.593 # +vote-for-leader d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6 1[9377] 14 Dec 16:54:12.595 # 192.168.110.31:26379 voted for d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6 1[9377] 14 Dec 16:54:12.651 # +elected-leader master resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.651 # +failover-state-select-slave master resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.718 # -failover-abort-no-good-slave master resque 192.168.110.31 6379[9377] 14 Dec 16:54:12.784 # Next failover delay: I will not start a failover before Wed Dec 14 17:00:13 2014从sentinel日志[root@slave redis-2.8.19]# /usr/local/webserver/redis/bin/redis-sentinel /usr/local/webserver/redis/etc/sentinel.conf [13754] 14 Dec 16:54:07.781 # Sentinel runid is e013d55cf2e4742f1cc7b27380f9ff8ea5b9485f[13754] 14 Dec 16:54:07.781 # +monitor master resque 192.168.110.31 6379 quorum 1[13754] 14 Dec 16:54:07.781 # +monitor master mymaster 192.168.110.21 6379 quorum 1[13754] 14 Dec 16:54:07.782 * +slave slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:08.974 * +sentinel sentinel 192.168.110.22:26379 192.168.110.22 26379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:09.228 * +sentinel sentinel 192.168.110.22:26379 192.168.110.22 26379 @ resque 192.168.110.31 6379[13754] 14 Dec 16:54:09.229 * -dup-sentinel master mymaster 192.168.110.21 6379 #duplicate of 192.168.110.21:26379 or d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[13754] 14 Dec 16:54:09.229 * +sentinel sentinel 192.168.110.21:26379 192.168.110.21 26379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:11.014 * -dup-sentinel master mymaster 192.168.110.21 6379 #duplicate of 192.168.110.22:26379 or d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[13754] 14 Dec 16:54:11.014 * +sentinel sentinel 192.168.110.22:26379 192.168.110.22 26379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:11.234 * -dup-sentinel master mymaster 192.168.110.21 6379 #duplicate of 192.168.110.21:26379 or d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[13754] 14 Dec 16:54:11.234 * +sentinel sentinel 192.168.110.21:26379 192.168.110.21 26379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:11.865 * -dup-sentinel master mymaster 192.168.110.21 6379 #duplicate of 192.168.110.22:26379 or d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[13754] 14 Dec 16:54:11.865 * +sentinel sentinel 192.168.110.22:26379 192.168.110.22 26379 @ mymaster 192.168.110.21 6379[13754] 14 Dec 16:54:12.574 # +new-epoch 1[13754] 14 Dec 16:54:12.574 # +vote-for-leader d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6 1[13754] 14 Dec 16:54:13.276 * -dup-sentinel master mymaster 192.168.110.21 6379 #duplicate of 192.168.110.21:26379 or d689a57f25afcb0f2e2c74f39e8e6ce5b65ca8a6[13754] 14 Dec 16:54:13.276 * +sentinel sentinel 192.168.110.21:26379 192.168.110.21 26379 @ mymaster 192.168.110.21 6379#模拟主redis故障，关闭主redis[root@master ~]# service redis stopStopping ...Redis stopped主日志：[9377] 14 Dec 17:01:59.992 # +new-epoch 3[9377] 14 Dec 17:01:59.993 # +vote-for-leader 0a4e141303e359663634c004686cab2a7141b828 3[9377] 14 Dec 17:01:59.993 # +sdown master mymaster 192.168.110.21 6379[9377] 14 Dec 17:01:59.993 # +odown master mymaster 192.168.110.21 6379 #quorum 1/1[9377] 14 Dec 17:01:59.993 # Next failover delay: I will not start a failover before Wed Dec 14 17:08:00 2014[9377] 14 Dec 17:02:00.532 # +config-update-from sentinel 192.168.110.31:26379 192.168.110.31 26379 @ mymaster 192.168.110.21 6379[9377] 14 Dec 17:02:00.532 # +switch-master mymaster 192.168.110.21 6379 192.168.110.31 6379[9377] 14 Dec 17:02:00.532 * +slave slave 192.168.110.21:6379 192.168.110.21 6379 @ mymaster 192.168.110.31 6379[9377] 14 Dec 17:02:04.282 # -sdown master resque 192.168.110.31 6379[9377] 14 Dec 17:02:04.282 # -odown master resque 192.168.110.31 6379[9377] 14 Dec 17:03:00.543 # +sdown slave 192.168.110.21:6379 192.168.110.21 6379 @ mymaster 192.168.110.31 6379从日志：[13797] 14 Dec 17:01:59.969 # +sdown master mymaster 192.168.110.21 6379[13797] 14 Dec 17:01:59.969 # +odown master mymaster 192.168.110.21 6379 #quorum 1/1[13797] 14 Dec 17:01:59.969 # +new-epoch 3[13797] 14 Dec 17:01:59.969 # +try-failover master mymaster 192.168.110.21 6379[13797] 14 Dec 17:01:59.971 # +vote-for-leader 0a4e141303e359663634c004686cab2a7141b828 3[13797] 14 Dec 17:01:59.973 # 192.168.110.22:26379 voted for 0a4e141303e359663634c004686cab2a7141b828 3[13797] 14 Dec 17:02:00.054 # +elected-leader master mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.054 # +failover-state-select-slave master mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.121 # +selected-slave slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.121 * +failover-state-send-slaveof-noone slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.211 * +failover-state-wait-promotion slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.440 # +promoted-slave slave 192.168.110.31:6379 192.168.110.31 6379 @ mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.440 # +failover-state-reconf-slaves master mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.510 # +failover-end master mymaster 192.168.110.21 6379[13797] 14 Dec 17:02:00.510 # +switch-master mymaster 192.168.110.21 6379 192.168.110.31 6379[13797] 14 Dec 17:02:00.510 * +slave slave 192.168.110.21:6379 192.168.110.21 6379 @ mymaster 192.168.110.31 6379[13797] 14 Dec 17:02:09.460 # -sdown master resque 192.168.110.31 6379[13797] 14 Dec 17:02:09.460 # -odown master resque 192.168.110.31 6379[13797] 14 Dec 17:03:00.577 # +sdown slave 192.168.110.21:6379 192.168.110.21 6379 @ mymaster 192.168.110.31 6379连接之前的从库，发现从已经变成主了（可以写了）[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379192.168.110.31:6379> set test 2345OK192.168.110.31:6379> get test"2345"192.168.110.31:6379> quit之前主已经连接不上了[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379Could not connect to Redis at 192.168.110.21:6379: Connection refusednot connected> quit#模拟主redis恢复，开启主redis连接故障恢复之后的主，发现主没有再变回从（仍然可写）[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379192.168.110.31:6379> get test"2345"192.168.110.31:6379> set test 23456OK192.168.110.31:6379> get test"23456"192.168.110.31:6379> quit连接故障恢复之后的从，发现从还是没有变回主（仍然只能读不可写）[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379192.168.110.21:6379> get test"23456"192.168.110.21:6379> set test 23456(error) READONLY You can't write against a read only slave.#关闭主从的redis之后，再启动，原来的主仍然没有变成主，看来得手动干预，让原来的主8.21重新回到主的位置啦[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379192.168.110.21:6379> get test"23456"192.168.110.21:6379> set test 123456(error) READONLY You can't write against a read only slave.192.168.110.21:6379> info# Replicationrole:slavemaster_host:192.168.110.31master_port:6379master_link_status:upmaster_last_io_seconds_ago:6master_sync_in_progress:0slave_repl_offset:85slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0#手动恢复原来主的地位[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379 SLAVEOF NO ONEOK[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379 SLAVEOF 192.168.110.21 6379OK[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379 info # Replicationrole:masterconnected_slaves:1slave0:ip=192.168.110.31,port=6379,state=online,offset=81717,lag=1master_repl_offset:81717repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:81718repl_backlog_histlen:0ps：sentinel故障切换，从变主原理：sentinel会去掉从库的slaveof语句，是从变新主；原主恢复后，sentinel会在原主配置文件末尾添加slaveof语句，使原主变从。因此恢复原来主从的地位，最好是先停掉sentinel，然后通过上面的命令切换主从，最后还得改下redis配置文件，修改主从相应slaveof语句。#测试已经切换过来了[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379192.168.110.21:6379> set hello worldOK192.168.110.21:6379> get hello"world"192.168.110.21:6379> quit[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379192.168.110.31:6379> get hello"world"192.168.110.31:6379> set hello world!(error) READONLY You can't write against a read only slave.#不使用sentinel，利用keepalived 和 虚拟ip实现主从切换，客户端配置不需要修改，以及故障恢复后的主从切换http://www.linuxidc.com/Linux/2014-07/104552.htmhttp://www.linuxidc.com/Linux/2014-07/104552p2.htm参考：http://shift-alt-ctrl.iteye.com/blog/1884370#sentinel原理 首先解释2个名词:SDOWN和ODOWN.SDOWN:subjectively down,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.ODOWN:objectively down,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover. SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN". 1) SDOWN与ODOWN转换过程:每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒)在交互中,如果redis-server无法在"down-after-milliseconds"时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.如果2)中SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送"is-master-down-by-addr"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor ",如果检测到master处于SDOWN状态的slave个数达到 ,那么此时此sentinel实例将会认为master处于ODOWN.每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.经过上述过程后,所有的sentinel对master失效达成一致后,开始failover. 2) Sentinel与slaves"自动发现"机制: 在sentinel的配置文件中(local-sentinel.conf),都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送"PING"以及类似于"is-master-down-by-addr"指令集,可用用来检测其他sentinel实例的有效性以及"ODOWN"和"failover"过程中信息的交互. 在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口:参考： http://diannaowa.blog.51cto.com/3219919/1557617关闭master的redis服务测试故障转移,若redis配置了分片功能，则该方式会出现一定的BUG。在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。有两种方式可以和 Sentinel 进行通讯：· 第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。· 另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。Sentinel 命令以下列出的是 Sentinel 接受的命令：· PING：返回 PONG 。· SENTINEL masters：列出所有被监视的主服务器，以及这些主服务器的当前状态。· SENTINEL slaves ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。· SENTINEL get-master-addr-by-name ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。· SENTINEL reset ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。· SENTINEL failover ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。发布与订阅信息客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。以下列出的是客户端可以通过订阅来获得的频道和信息的格式： 第一个英文单词是频道/事件的名字， 其余的是数据的格式。注意， 当格式中包含 instance details 字样时， 表示频道所返回的信息中包含了以下用于识别目标实例的内容： @ @ 字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。· +reset-master ：主服务器已被重置。· +slave ：一个新的从服务器已经被 Sentinel 识别并关联。· +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。· +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。· +slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。· +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。· +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。· -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。· +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。· +sdown ：给定的实例现在处于主观下线状态。· -sdown ：给定的实例已经不再处于主观下线状态。· +odown ：给定的实例现在处于客观下线状态。· -odown ：给定的实例已经不再处于客观下线状态。· +new-epoch ：当前的纪元（epoch）已经被更新。· +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。· +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。· +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。· no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。· selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。· failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。· failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。· failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。· +switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。· +tilt：进入 tilt 模式。 -tilt：退出 tilt 模式。 转载地址：http://www.run-debug.com/?p=674