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

redis之哨兵部署运行日志解读的更多相关文章

redis 持久化哨兵主从
Redis搭建步骤环境: 三台机器 centos7 关闭防火墙 selinux Redis版本 3.0.5 依赖环境 yum install gcc-c++ ruby rubygems –y 把版 ...
Redis容灾部署（哨兵Sentinel）
Redis容灾部署(哨兵Sentinel) 哨兵的作用 1. 监控:监控主从是否正常2. 通知:出现问题时,可以通知相关人员3. 故障迁移:自动主从切换4. 统一的配置管理:连接者询问sentinel ...
Redis哨兵部署和配置
目录一.哨兵简介哨兵介绍哨兵原理二.哨兵部署环境介绍哨兵配置三.使用验证一.哨兵简介哨兵介绍 Sentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在 ...
Redis主-从部署实践
0. 前言这篇文章简要介绍Redis的主从部署,实现了一主二从,使用两个哨兵监控,以实现简单的HA,其中从库作为备机. 1. 部署这里有三台服务器,其中239主机上的Redis作为主库,其余两个作 ...
Redis-Sentinel Redis的哨兵模式
Redis-Sentinel Redis的哨兵模式Redis Sentinel 模式简介Redis-Sentinel是官方推荐的高可用解决方案,当redis在做master-slave的高可用方案时, ...
Redis介绍及部署在CentOS7上（一）
0.Redis目录结构 1)Redis介绍及部署在CentOS7上(一) 2)Redis指令与数据结构(二) 3)Redis客户端连接以及持久化数据(三) 4)Redis高可用之主从复制实践(四) 5 ...
Redis Sentinel(哨兵核心机制) 初步深入
##### 1.Redis 的 Sentinel 系统用于管理多个 Redis 服务该系统执行以下三个任务: 1.监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务 ...
5.如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍一下么？redis 的哨兵原理能介绍一下么？
作者:中华石杉面试题如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍一下么?redis 的哨兵原理能介绍一下么? 面试官心理分析其实问这个问题,主要是考考你,redis ...
redis cluster安装部署(测试环境)
redis 应用于web前端,做缓存和数据存取的速度是挺可观的,最近看了一些资料,手痒了,就弄了一个测试环境,两台方案,试用一下. ##Redis 集群部署## 一,方案调研: 参考博客: http: ...

随机推荐

android.content.ActivityNotFoundException: No Activity found to handle Intent { (has extras) }
报错: 初始代码: @OnClick(R.id.include_top_iv_more) public void onViewClicked() { Intent intent_chat_set = ...
ARM伪指令与伪操作
一.伪指令 ARM伪指令有四个,分别是LDR.ADR.ADRL和NOP,下边对其分别介绍. 1.1 LDR LDR 伪指令用于加载 32 位的立即数或一个地址值到指定寄存器 .形式如 LDR{con ...
TCP协议中的三次握手和四次挥手(图解)-转
转自:http://blog.csdn.net/whuslei/article/details/6667471/ 建立TCP需要三次握手才能建立,而断开连接则需要四次握手.整个过程如下图所示: 先来看 ...
极简 Node.js 入门 - 3.2 文件读取
极简 Node.js 入门系列教程:https://www.yuque.com/sunluyong/node 本文更佳阅读体验:https://www.yuque.com/sunluyong/node ...
Ubuntu图形桌面切换到命令行界面
Ubuntu提供两种进入方式,一个是我们平常最熟悉的图形界面形式,还有一种是纯命令行方式. 1.按 Ctrl + Alt + (F1~F6中的任意一个)即可进入纯命令行模式. 进入后,需要输入用户名, ...
JAVA设计模式简介及六种常见设计模式详解
一.什么是设计模式 ...
dcoker 小应用(一)
docker 创建Ubuntu系统 1.创建Dockerfile #ubuntu:14.04 image FROM ubuntu:14.04 MAINTAINER XXX, xxx@xxx.com R ...
微服务项目整合Ocelot+IdentityServer4
项目搭建肯定少不了认证和授权,传统的单体应用基于cookie和session来完成的. 因为http请求是无状态的,每个请求都是完全独立的,服务端无法确认当前请求之前是否登陆过.所以第一次请求(登录) ...
HTML5移动开发之路（1）——jqMobi中Side Menu实现（类似人人网）
记得以前在做Native App的时候类似于人人网侧边滑动的效果非常的热,很多app仿照该效果进行开发,在jqMobi中也有类似的效果被称为Side Menu.下面我们来一步一步实现该效果. 首先新建 ...
muduo源码解析9-timezone类
timezone class timezone:public copyable { }: 作用: 感觉有点看不懂,detail内部实现文件类不明白跟时区有什么关系.timezone类主要是完成各个时区 ...

redis之哨兵部署运行日志解读

redis之哨兵部署运行日志解读的更多相关文章

随机推荐

热门专题