redis之哨兵部署運行日志解讀

轉載自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 模式。