转载自http://www.run-debug.com/?p=674
192.168.110.21 主
192.168.110.31 从
#两台服务器都安装redis
#下载最新稳定版本：http://redis.io/download
wget http://download.redis.io/releases/redis-2.8.19.tar.gz
#安装
tar -zxvf redis-2.8.19.tar.gz
cd redis-2.8.19
more README
make
#安装tclsh8.5
make test
#You need 'tclsh8.5' in order to run the Redis test
ldconfig -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 test
make PREFIX=/usr/local/webserver/redis install
#配置文件和启动脚步
mkdir /usr/local/webserver/redis/etc/
cp redis.conf /usr/local/webserver/redis/etc/redis.conf
cp utils/redis_init_script /etc/init.d/redis
#修改启动脚步：根据实际安装路径修改启动脚步中配置的相关路径
vim /etc/init.d/redis
REDISPORT=6379
EXEC=/usr/local/webserver/redis/bin/redis-server
CLIEXEC=/usr/local/webserver/redis/bin/redis-cli
PIDFILE=/var/run/redis.pid
CONF="/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 start
Starting Redis server...
[root@master redis-2.8.19]# netstat -antpl | grep LIST | grep redis
tcp 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 stop
Stopping ...
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 start
Starting Redis server...
#非持久化配置
[root@master redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli
127.0.0.1:6379> config set requirepass 123456
OK
或
持久化配置：配置文件开启验证配置
requirepass 123456
从库配置文件开启复制，并设置复制密码，设置为只读
slaveof 192.168.110.21 6379
masterauth 123456
slave-read-only
[root@slave redis-2.8.19]# vim /usr/local/webserver/redis/etc/redis.conf
[root@slave redis-2.8.19]# service redis start
Starting 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 6379
192.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 6379
192.168.110.21:6379> set test 123
(error) NOAUTH Authentication required.
认证验证
192.168.110.21:6379> auth 123456
OK
主写数据
192.168.110.21:6379> set test 123
OK
192.168.110.21:6379> quit
登录从，读取数据
[root@slave redis-2.8.19]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379
192.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 26379
sentinel monitor mymaster 192.168.110.21 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.110.31 6379 1
sentinel down-after-milliseconds resque 30000
sentinel failover-timeout resque 180000
sentinel 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 26379
sentinel monitor mymaster 192.168.110.21 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.110.31 6379 1
sentinel down-after-milliseconds resque 30000
sentinel failover-timeout resque 180000
sentinel 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 stop
Stopping ...
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 6379
192.168.110.31:6379> set test 2345
OK
192.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 6379
Could not connect to Redis at 192.168.110.21:6379: Connection refused
not connected> quit
#模拟主redis恢复，开启主redis
连接故障恢复之后的主，发现主没有再变回从（仍然可写）
[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379
192.168.110.31:6379> get test
"2345"
192.168.110.31:6379> set test 23456
OK
192.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 6379
192.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 6379
192.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
# Replication
role:slave
master_host:192.168.110.31
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:85
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
#手动恢复原来主的地位
[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379 SLAVEOF NO ONE
OK
[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.31 -p 6379 SLAVEOF 192.168.110.21 6379
OK
[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379 info
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.110.31,port=6379,state=online,offset=81717,lag=1
master_repl_offset:81717
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:81718
repl_backlog_histlen:0
ps：
sentinel故障切换，从变主原理：sentinel会去掉从库的slaveof语句，是从变新主；原主恢复后，sentinel会在原主配置文件末尾添加slaveof语句，使原主变从。
因此恢复原来主从的地位，最好是先停掉sentinel，然后通过上面的命令切换主从，最后还得改下redis配置文件，修改主从相应slaveof语句。
#测试已经切换过来了
[root@slave ~]# /usr/local/webserver/redis/bin/redis-cli -h 192.168.110.21 -p 6379
192.168.110.21:6379> set hello world
OK
192.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 6379
192.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.htm
http://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 <ip> <port>"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果检测到master处于SDOWN状态的slave个数达到<quorum>,那么此时此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 <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 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
发布与订阅信息
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
以下列出的是客户端可以通过订阅来获得的频道和信息的格式： 第一个英文单词是频道/事件的名字， 其余的是数据的格式。
注意， 当格式中包含 instance details 字样时， 表示频道所返回的信息中包含了以下用于识别目标实例的内容：
<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>
@ 字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。
· +reset-master <instance details>：主服务器已被重置。
· +slave <instance details>：一个新的从服务器已经被 Sentinel 识别并关联。
· +failover-state-reconf-slaves <instance details>：故障转移状态切换到了 reconf-slaves 状态。
· +failover-detected <instance details>：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
· +slave-reconf-sent <instance details>：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。
· +slave-reconf-inprog <instance details>：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
· +slave-reconf-done <instance details>：从服务器已经成功完成对新主服务器的同步。
· -dup-sentinel <instance details>：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
· +sentinel <instance details>：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
· +sdown <instance details>：给定的实例现在处于主观下线状态。
· -sdown <instance details>：给定的实例已经不再处于主观下线状态。
· +odown <instance details>：给定的实例现在处于客观下线状态。
· -odown <instance details>：给定的实例已经不再处于客观下线状态。
· +new-epoch <instance details>：当前的纪元（epoch）已经被更新。
· +try-failover <instance details>：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
· +elected-leader <instance details>：赢得指定纪元的选举，可以进行故障迁移操作了。
· +failover-state-select-slave <instance details>：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
· no-good-slave <instance details>：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
· selected-slave <instance details>：Sentinel 顺利找到适合进行升级的从服务器。
· failover-state-send-slaveof-noone <instance details>：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
· failover-end-for-timeout <instance details>：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
· failover-end <instance details>：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
· +switch-master <master name> <oldip> <oldport> <newip> <newport>：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
· +tilt：进入 tilt 模式。
-tilt：退出 tilt 模式。
