redis部署及其高可用方案：主从+sentinel，安装步骤

最新推荐文章于 2024-08-14 18:56:15 发布

seapeak007

最新推荐文章于 2024-08-14 18:56:15 发布

阅读量1.5k

点赞数

分类专栏： redis

redis 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

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 模式。

转载地址：http://www.run-debug.com/?p=674