redis应用之使用sentinel实现主从复制高可用

一、redis的高可用管理工具sentinel介绍

sentinel是一个管理redis实例的工具，它可以实现对redis的监控、通知、自动故障转移。sentinel不断的检测redis实例是否可以正常工作，通过API向其他程序报告redis的状态，

如果redis master不能工作，则会自动启动故障转移进程，将其中的一个slave提升（通过选举）为master，其他的slave重新设置新的master服务器。而故障的master再次启动后

会被sentinel自动降级为slave服务器加入到集群中。

redis主从的特点：

1、redis使用异步复制，从服务器会以每秒一次的频率向主服务器报告复制流的处理进度

2、一个主服务器可以有多个从服务器，从服务器也可以有自己的从服务器(级联复制)

3、复制功能不会阻塞主服务器，即使一个或多个从服务器正在进行初次同步，主服务器也可以继续处理命令请求

4、复制功能可以用于数据冗余，也可以通过让多个从服务器处理只读命令请求来提升扩展性

5、Redis从节点默认为只读，无须手动配置

redis的主从集群可以实现分担压力的效果，但是无法做到高可用，如果master宕掉，服务就不可用了，所以使用redis的sentinel可以实现HA的功能：

sentinel作用如下：

1、监控：sentinel会不断的检查你的主服务器和从服务器是否运行正常

2、当被监控的某个redis服务器出现问题时，sentinel可以通过API向管理员或者其他应用程序发送通知

3、自动故障转移：当一个主服务器不能正常工作时，sentinel会开始一次自动故障转移操作，他会将其中一个从服务器升级为新的主服务器，并将其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

redis sentinel在监控redis实例时有两种redis宕机状态S_DOWN和O_DOWN：

S_DOWN:当sentinel在指定的超时时间内没有收到一个正确的ping回复值，则认为是S_DOWN

O_DOWN:O_DOWN的条件是有足够多的sentinel认为该redis实例是S_DOWN。

注意：O_DOWN只能是发生在主服务器，sentinel和其他从服务器不会发生O_DOWN

二、开始安装配置主从高可用

1、环境架构：

Centos 6.6 x86_64 redis 3.0.7
master 10.0.18.145 redis port 6379 sentinel port 26379
slave1 10.0.18.146 redis port 6379 sentinel port 26479
slave2 10.0.18.147 redis port 6379 sentinel port 26579
注：redis编译安装配置以及主从配置这里就不在赘述了，请参考之前的redis安装配置日志：
http://linuxg.blog.51cto.com/4410110/1862042

2、在三台redis上配置sentinel

先介绍一下sentinel.conf配置文件中常用的参数，如下：

port 26379        #sentinel的端口
dir /tmp          #工作目录
sentinel monitor mymaster 127.0.0.1 6379 2 
#mymaster是自定义的名称，ip地址是master的ip，6379为master的redis-server端口
#2是quorum，表示sentinel确认一个Master为O_DOWN状态至少需要多少个哨兵同意（此值要小于等于集群中slave的个数）
英文翻译过来是：告诉Sentinel监视这个master，并且只有在至少<quorum> sentinels同意的情况下才考虑它是O_DOWN（客观宕掉）状态。
sentinel down-after-milliseconds mymaster 30000  #mymaster多久不响应认为SDOWN，单位是毫秒
sentinel parallel-syncs mymaster 1               #指定最大同时同步新maser配置的slave数量，官方提示用较低的数字，一般为1
sentinel failover-timeout mymaster 180000        #2次failover切换时间，如果第一次没有failover成功，过多长时间再次failover

sentinel配置文件如下：

18.145上：
#cat /usr/local/redis/conf/sentinel.conf 
port 26379         
sentinel monitor mymaster 10.0.18.145 6379 1
sentinel auth-pass mymaster abcd123    
sentinel down-after-milliseconds mymaster 60000      #1分钟
sentinel failover-timeout mymaster 180000            #3分钟
sentinel parallel-syncs mymaster 1
logfile "/usr/local/redis/log/sentinel_master.log"   #日志位置
注意：18.146和18.147上的sentinel配置和18.145一样，只有端口和log不一样如下：
slave1 18.146
#cat sentinel.conf
port 26479
logfile "/usr/local/redis/log/sentinel_slave1.log" 
slave2 18.147
#cat sentinel.conf
prot 26579
logfile "/usr/local/redis/log/sentinel_slave2.log"

在master和2台slave服务器上启动redis-server和sentinel，确保可以正常启动！

#nohup /usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel.conf &    #我使用此方法
或者nohup /usr/local/redis/bin/redis-server /usr/local/redis/conf/sentinel.conf --sentinel &
查看sentinel进程
#ps aux | grep redis
root     10370  0.1  0.1 137452  2152 ?        Ssl  11:02   0:27 /usr/local/redis/bin/redis-server 10.0.18.145:6379                
root     10474  0.6  0.1 137456  2084 ?        Ssl  15:08   0:00 /usr/local/redis/bin/redis-sentinel *:26379 [sentinel]  
请确保三台redis的redis-server和sentinel进程都可以正常启动！

3、查看sentinel日志

查看master上的sentinel日志：

#tail -f sentinel_master.log
………………
13087:X 14 Oct 15:41:21.313 # Sentinel runid is e8b54004648ea00257cfee7150713e86537e3e69
13087:X 14 Oct 15:41:21.313 # +monitor master mymaster 10.0.18.145 6379 quorum 2
13087:X 14 Oct 15:41:21.314 * +slave slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379
13087:X 14 Oct 15:41:21.317 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
13087:X 14 Oct 15:41:36.241 * +sentinel sentinel 10.0.18.146:26479 10.0.18.146 26479 @ mymaster 10.0.18.145 6379
13087:X 14 Oct 15:41:47.947 * +sentinel sentinel 10.0.18.147:26579 10.0.18.147 26579 @ mymaster 10.0.18.145 6379

查看slave1上的sentinel日志：

#tail -f sentinel_slave1.log
………………
22427:X 14 Oct 15:41:34.145 # Sentinel runid is d0339d3013e855489ff368f6f28a865417ef9818
22427:X 14 Oct 15:41:34.146 # +monitor master mymaster 10.0.18.145 6379 quorum 2
22427:X 14 Oct 15:41:35.147 * +slave slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379
22427:X 14 Oct 15:41:35.158 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
22427:X 14 Oct 15:41:35.574 * +sentinel sentinel 10.0.18.145:26379 10.0.18.145 26379 @ mymaster 10.0.18.145 6379
22427:X 14 Oct 15:41:47.947 * +sentinel sentinel 10.0.18.147:26579 10.0.18.147 26579 @ mymaster 10.0.18.145 6379

查看slave2上的sentinel日志：

#tail -f sentinel_slave2.log
……………
24207:X 14 Oct 15:41:45.920 # Sentinel runid is 4b63b7796970f93d12e41c648f3a2668864ca5db
24207:X 14 Oct 15:41:45.920 # +monitor master mymaster 10.0.18.145 6379 quorum 2
24207:X 14 Oct 15:41:45.922 * +slave slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 15:41:45.925 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 15:41:46.695 * +sentinel sentinel 10.0.18.146:26479 10.0.18.146 26479 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 15:41:47.830 * +sentinel sentinel 10.0.18.145:26379 10.0.18.145 26379 @ mymaster 10.0.18.145 6379

通过以上日志信息可以看出，redis主从复制已经OK，sentinel也已经启动OK！

4、查看主从复制信息和sentinel信息

在master上确认sentinel的信息

#./redis-cli -p 26379   
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=10.0.18.145:6379,slaves=2,sentinels=3
可以看到有2台slave和3台sentinel，状态是ok的
确认master的信息
127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "10.0.18.145"
    5) "port"
    6) "6379"
    7) "runid"
    8) "5673ebe1bfd192d44f5c76df952528a38be28b43"    
    9) "flags"
   10) "master"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "383"
   17) "last-ping-reply"
   18) "383"
   19) "down-after-milliseconds"
   20) "60000"
   21) "info-refresh"
   22) "9715"
   23) "role-reported"
   24) "master"
   25) "role-reported-time"
   26) "1164126"
   27) "config-epoch"
   28) "0"
   29) "num-slaves"
   30) "2"
   31) "num-other-sentinels"
   32) "2"
   33) "quorum"
   34) "2"
   35) "failover-timeout"
   36) "180000"
   37) "parallel-syncs"
   38) "1"
确认slave的信息，如下:
127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "10.0.18.147:6379"
    3) "ip"
    4) "10.0.18.147"
    5) "port"
    6) "6379"
    7) "runid"
    8) "d021efa3c5cb3c6ae695428ad7c6c371bec210dc"  
    9) "flags"
   10) "slave"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "510"
   17) "last-ping-reply"
   18) "510"
   19) "down-after-milliseconds"
   20) "60000"
   21) "info-refresh"
   22) "7173"
   23) "role-reported"
   24) "slave"
   25) "role-reported-time"
   26) "1231725"
   27) "master-link-down-time"
   28) "0"
   29) "master-link-status"
   30) "ok"
   31) "master-host"
   32) "10.0.18.145"
   33) "master-port"
   34) "6379"
   35) "slave-priority"
   36) "100"
   37) "slave-repl-offset"
   38) "244198"
2)  1) "name"
    2) "10.0.18.146:6379"
    3) "ip"
    4) "10.0.18.146"
    5) "port"
    6) "6379"
    7) "runid"
    8) "9608029269c840e8b019bf10ce1b242c56cb231d"  #slave2的唯一标识id
    9) "flags"
   10) "slave"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "503"
   17) "last-ping-reply"
   18) "503"
   19) "down-after-milliseconds"
   20) "60000"
   21) "info-refresh"
   22) "7173"
   23) "role-reported"
   24) "slave"
   25) "role-reported-time"
   26) "1231728"
   27) "master-link-down-time"
   28) "0"
   29) "master-link-status"
   30) "ok"
   31) "master-host"
   32) "10.0.18.145"
   33) "master-port"
   34) "6379"
   35) "slave-priority"
   36) "90"
   37) "slave-repl-offset"
   38) "244198"

5、进行容灾测试：

a、模拟redis的HA集群slave服务器宕机

停掉一台slave，观察集群的状态，这里将slave2的redis-server停掉

首先查看三台sentinel的日志信息，都会刷新一条，如下：

11339:X 13 Oct 10:55:51.391 # +sdown slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379

可以看到18.147down掉了！

到master服务器上查看主从复制信息:

10.0.18.145:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.18.146,port=6379,state=online,offset=172908,lag=0   
master_repl_offset:172908
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:172907
可以看到10.0.18.147已经被master剔除了!

再重新将slave2的redis-server启动起来，继续观察：

三台sentinel的日志信息，如下：

11339:X 13 Oct 10:59:59.040 * +reboot slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
11339:X 13 Oct 10:59:59.097 # -sdown slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
可以看出18.147已经重新启动了！
在master上继续查看复制信息，如下：
10.0.18.145:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.18.146,port=6379,state=online,offset=224670,lag=0
slave1:ip=10.0.18.147,port=6379,state=online,offset=224670,lag=0
master_repl_offset:224944
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:224943
可以看到10.0.18.147已经加入到集群中了

b、模拟redis的HA集群master服务器宕机

说明：停掉master的6379端口，假设master是因为外部问题宕机了（直接kill掉redis-server进程）

观察三台redis的sentinel日志：

#tail -f sentinel_master.log
………………
13087:X 14 Oct 16:13:58.625 # +sdown master mymaster 10.0.18.145 6379 #说明18.145down掉了
13087:X 14 Oct 16:13:58.741 # +new-epoch 1
13087:X 14 Oct 16:13:58.766 # +vote-for-leader 4b63b7796970f93d12e41c648f3a2668864ca5db 1  #投票选举master，可以根据前面sentinel日志知道是18.147
13087:X 14 Oct 16:13:59.713 # +odown master mymaster 10.0.18.145 6379 #quorum 3/2          #投票，有2票确定18.145宕机
13087:X 14 Oct 16:13:59.713 # Next failover delay: I will not start a failover before Fri Oct 14 16:19:59 2016 #第一次failover失败，继续
13087:X 14 Oct 16:13:59.820 # +config-update-from sentinel 10.0.18.147:26579 10.0.18.147 26579 @ mymaster 10.0.18.145 6379 #从18.147同步新配置
13087:X 14 Oct 16:13:59.820 # +switch-master mymaster 10.0.18.145 6379 10.0.18.146 6379   #看来已经选举出了新master为18.146
13087:X 14 Oct 16:13:59.820 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.146 6379  #18.147 重新配置（sentinel修改配置来实现）master指向18.146
13087:X 14 Oct 16:13:59.820 * +slave slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379  #18.145降级为slave，master指向18.146
13087:X 14 Oct 16:14:59.872 # +sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379  #并且检测到18.145这台slave处于down状态
#tail -f sentinel_slave1.log
………………
22427:X 14 Oct 16:13:58.741 # +new-epoch 1
22427:X 14 Oct 16:13:58.767 # +vote-for-leader 4b63b7796970f93d12e41c648f3a2668864ca5db 1 #投票选举master，选18.147
22427:X 14 Oct 16:13:58.768 # +sdown master mymaster 10.0.18.145 6379
22427:X 14 Oct 16:13:58.824 # +odown master mymaster 10.0.18.145 6379 #quorum 3/2
22427:X 14 Oct 16:13:58.824 # Next failover delay: I will not start a failover before Fri Oct 14 16:19:59 2016 #第一次failover失败，继续
22427:X 14 Oct 16:13:59.820 # +config-update-from sentinel 10.0.18.147:26579 10.0.18.147 26579 @ mymaster 10.0.18.145 6379 #从18.147同步新配置
22427:X 14 Oct 16:13:59.820 # +switch-master mymaster 10.0.18.145 6379 10.0.18.146 6379   #看来已经选举出了新master为18.146
22427:X 14 Oct 16:13:59.821 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.146 6379  
22427:X 14 Oct 16:13:59.821 * +slave slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
22427:X 14 Oct 16:14:59.825 # +sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
#tail -f sentinel_slave2.log
………………
24207:X 14 Oct 16:13:58.632 # +sdown master mymaster 10.0.18.145 6379
24207:X 14 Oct 16:13:58.698 # +odown master mymaster 10.0.18.145 6379 #quorum 2/2
24207:X 14 Oct 16:13:58.698 # +new-epoch 1
24207:X 14 Oct 16:13:58.698 # +try-failover master mymaster 10.0.18.145 6379    #尝试failover到18.145，但是18.145redis-server已经down掉
24207:X 14 Oct 16:13:58.701 # +vote-for-leader 4b63b7796970f93d12e41c648f3a2668864ca5db 1 #投票选举master
24207:X 14 Oct 16:13:58.767 # 10.0.18.145:26379 voted for 4b63b7796970f93d12e41c648f3a2668864ca5db 1 #145一票选18.147
24207:X 14 Oct 16:13:58.769 # 10.0.18.146:26479 voted for 4b63b7796970f93d12e41c648f3a2668864ca5db 1 #146一票选18.147
24207:X 14 Oct 16:13:58.867 # +elected-leader master mymaster 10.0.18.145 6379  #又尝试选举18.145
24207:X 14 Oct 16:13:58.868 # +failover-state-select-slave master mymaster 10.0.18.145 6379 #对mymaster进行故障转移
24207:X 14 Oct 16:13:58.920 # +selected-slave slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379  #18.146当选为新的master（因为它的slave_priority比较小）
24207:X 14 Oct 16:13:58.921 * +failover-state-send-slaveof-noone slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379 #Sentinel正在将指定的从服务器(10.146)升级为主服务器，等待升级功能完成。
24207:X 14 Oct 16:13:58.983 * +failover-state-wait-promotion slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379     #等待升级为master
24207:X 14 Oct 16:13:59.750 # +promoted-slave slave 10.0.18.146:6379 10.0.18.146 6379 @ mymaster 10.0.18.145 6379                    #18.146升级为master
24207:X 14 Oct 16:13:59.751 # +failover-state-reconf-slaves master mymaster 10.0.18.145 6379   #当前状态为重新加载18.145配置，将其降级为slave，需要在redis.conf中配置slaveof 
24207:X 14 Oct 16:13:59.819 * +slave-reconf-sent slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 16:14:00.775 * +slave-reconf-inprog slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 16:14:00.775 * +slave-reconf-done slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.145 6379
24207:X 14 Oct 16:14:00.833 # +failover-end master mymaster 10.0.18.145 6379     #故障转移完成
24207:X 14 Oct 16:14:00.833 # +switch-master mymaster 10.0.18.145 6379 10.0.18.146 6379 #master变成了18.146
24207:X 14 Oct 16:14:00.834 * +slave slave 10.0.18.147:6379 10.0.18.147 6379 @ mymaster 10.0.18.146 6379
24207:X 14 Oct 16:14:00.835 * +slave slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
24207:X 14 Oct 16:15:00.845 # +sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379   #而且18.145为slave，并且判断为down状态

到18.146查看主从集群状态信息：

10.0.18.146:6379> auth abcd123
OK
10.0.18.146:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.18.147,port=6379,state=online,offset=1067564,lag=0
master_repl_offset:1067701
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:19126
repl_backlog_histlen:1048576
可以看出此时的18.146已经是master了，并且slave服务器只有18.147！

查看sentinel信息：

#./bin/redis-cli -p 26479
127.0.0.1:26479> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=10.0.18.146:6379,slaves=2,sentinels=3
哨兵master信息：
127.0.0.1:26479> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "10.0.18.146"
    5) "port"
    6) "6379"
    7) "runid"
    8) "9608029269c840e8b019bf10ce1b242c56cb231d"
    9) "flags"
   10) "master"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "399"
   17) "last-ping-reply"
   18) "399"
   19) "down-after-milliseconds"
   20) "60000"
   21) "info-refresh"
   22) "490"
   23) "role-reported"
   24) "master"
   25) "role-reported-time"
   26) "5521890"
   27) "config-epoch"
   28) "1"
   29) "num-slaves"
   30) "2"
   31) "num-other-sentinels"
   32) "2"
   33) "quorum"
   34) "2"
   35) "failover-timeout"
   36) "180000"
   37) "parallel-syncs"
   38) "1"

假如此时10.0.18.145这台服务器的redis-server恢复了，也会被加入slave队列中,如下：

先查看18.145上的sentinel日志
#tail -f sentinel_master.log 
…………
13087:X 14 Oct 17:53:12.701 # -sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
再查看18.146上的sentinel日志
#tail -f sentinel_slave1.log 
…………
22427:X 14 Oct 17:53:12.648 # -sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
22427:X 14 Oct 17:53:22.608 * +convert-to-slave slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379
可以看到18.145的redis-server进程恢复之后，降级为slave，被重新加入到集群中。
再查看18.147上的sentinel日志
#tail -f sentinel_slave2.log 
…………
24207:X 14 Oct 17:53:12.673 # -sdown slave 10.0.18.145:6379 10.0.18.145 6379 @ mymaster 10.0.18.146 6379

6、查看故障转移之后redis和sentinel配置文件的变化

a、首先查看三台redis的redis.conf文件

因为模拟18.145服务器的redis-server宕机而后又重新开启，所以sentinel机制rewrite了redis.conf文件，如下：

# Generated by CONFIG REWRITE
slaveof 10.0.18.146 6379
rewrite机制在18.145的redis.conf末尾添加了如上2行，表示指向18.146这台新的master

查看18.146的redis.conf文件，你会发现原来的参数slaveof 10.0.18.145 6379 已经消失了！

查看18.147的redis.conf文件，如下：

slaveof 10.0.18.146 6379  
由原来的指向10.0.18.145变成了指向新的master10.0.18.146

b、查看三台redis的sentinel.conf文件

10.145上的sentinel.conf文件：
#cat sentinel.conf
port 26379
sentinel monitor mymaster 10.0.18.146 6379 2     #已经由原来的18.145变成了18.146
sentinel down-after-milliseconds mymaster 60000
sentinel auth-pass mymaster abcd123
sentinel config-epoch mymaster 1           
sentinel leader-epoch mymaster 1
logfile "/usr/local/redis/log/sentinel_master.log"
# Generated by CONFIG REWRITE
dir "/usr/local/redis"
sentinel known-slave mymaster 10.0.18.147 6379
sentinel known-slave mymaster 10.0.18.145 6379
sentinel known-sentinel mymaster 10.0.18.147 26579 4b63b7796970f93d12e41c648f3a2668864ca5db   #后边的字符串是sentinel启动时候为每一台redis生成的唯一标识
sentinel known-sentinel mymaster 10.0.18.146 26479 d0339d3013e855489ff368f6f28a865417ef9818
sentinel current-epoch 1
10.146上的sentinel.conf
#cat sentinel.conf
port 26479
sentinel monitor mymaster 10.0.18.146 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel auth-pass mymaster abcd123
sentinel config-epoch mymaster 1
sentinel leader-epoch mymaster 1
logfile "/usr/local/redis/log/sentinel_slave1.log"
# Generated by CONFIG REWRITE
dir "/usr/local/redis/conf"
sentinel known-slave mymaster 10.0.18.147 6379
sentinel known-slave mymaster 10.0.18.145 6379
sentinel known-sentinel mymaster 10.0.18.147 26579 4b63b7796970f93d12e41c648f3a2668864ca5db
sentinel known-sentinel mymaster 10.0.18.145 26379 e8b54004648ea00257cfee7150713e86537e3e69
sentinel current-epoch 1
10.147上的sentinel.conf
#cat sentinel.conf
port 26579
sentinel monitor mymaster 10.0.18.146 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel auth-pass mymaster abcd123
sentinel config-epoch mymaster 1
sentinel leader-epoch mymaster 1
logfile "/usr/local/redis/log/sentinel_slave2.log"
# Generated by CONFIG REWRITE
dir "/usr/local/redis"
sentinel known-slave mymaster 10.0.18.147 6379
sentinel known-slave mymaster 10.0.18.145 6379
sentinel known-sentinel mymaster 10.0.18.146 26479 d0339d3013e855489ff368f6f28a865417ef9818
sentinel known-sentinel mymaster 10.0.18.145 26379 e8b54004648ea00257cfee7150713e86537e3e69
sentinel current-epoch 1

7、sentinel日志中的一些参数说明

+reset-master ：主服务器已被重置。
+slave ：一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
+failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
+slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。
+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 模式。

不足之处，请多多指出！

时间： 2024-10-19 18:17:58

redis应用之使用sentinel实现主从复制高可用的相关文章

读懂Redis并配置主从集群及高可用部署

一.背景运维工作尤其是linux运维,其实最考验你的能力,因为需要学习的东西实在太多, 你既要懂网络:思科华为设备的配置: 要懂性能调优:包括lamp或者lnmp的性能调优,也包括linux操作系统调优: 要懂数据库mysql或者nosql(例如mongodb): 要懂编程语言:Shell是最基本的,还要学习perl,python,甚至ruby和C++等(因为一些软件是这些语言编写的),还得熟练掌握awk,sed,grep以及正则表达式: 要懂一些调试排错的命令工具的使用,比如htop,dst

Redis源码阅读（二）高可用设计——复制

Redis源码阅读(二)高可用设计-复制复制的概念:Redis的复制简单理解就是一个Redis服务器从另一台Redis服务器复制所有的Redis数据库数据,能保持两台Redis服务器的数据库数据一致. 使用场景:复制机制很实用,在客户端并发访问量很大,单台Redis扛不住的情况下,可以部署多台Redis复制相同的数据,共同对外提供服务,提高Redis并发访问处理能力.当然这种通过复制方式部署多台Redis以提高并发处理能力的方式只适用于客户端大部分访问为读数据请求的场景.此外,Redis从2.

redis 之redis-sentinel主从复制高可用

一.redis主从复制背景问题 Redis主从复制可将主节点数据同步给从节点,从节点此时有两个作用: (1)一旦主节点宕机,从节点作为主节点的备份可以随时顶上来. (2)扩展主节点的读能力,分担主节点读压力. 但是问题是: 一旦主节点宕机,从节点上位,那么需要人为修改所有应用方的主节点地址(改为新的master地址),还需要命令所有从节点复制新的主节点那么这个问题,redis-sentinel就可以解决了二. Redis-Sentinel Redis-Sentinel是redis官方推荐的高

浅谈小白如何读懂Redis高速缓存与持久化并存及主从高可用集群

一.简介 Redis是一个基于键值(K-V)的高速缓存软件,和他具有相同功能的软件有memcached,但其支持更为复杂的数据结构,例如:List,set,sorted set,同时redis具有持久性功能.redis究竟是什么?对于不同的应用场合,对redis的理解也不相同,如下有三种不同的理解. ①key value store(键值存储),是一个以键值形式存储的数据库,用来作为唯一的存储系统,同时借助于sentinel实现一定意义上的高可用. ②memory cached(内存缓存),是一

Sentinel 哨兵实现高可用

我们知道redis是有主从复制的,例如下图: 但如果master主进程挂掉之后,没有slave站出来当master,那么整个写redis业务就崩溃了.虽然其他业务可以从从redis上继续读取数据,当主写redis已经崩溃了,势必造成影响.而redis为我们提供了Sentinel来做redis的高可用工具,因此个人觉得实际上redis并不需要像Nginx那样,与keepalived组合成高可用,或者进行集群化操作,用多sentinel与主从即可.当然集群也有着它的好处:构建多节点,节点上的数据都不

redis-sentinel主从复制高可用

一,Redis-Sentinel介绍 Redis-Sentinel是redis官方推荐的高可用性解决方案,当用redis作master-slave的高可用时,如果master本身宕机,redis本身或者客户端都没有实现主从切换的功能. 而redis-sentinel就是一个独立运行的进程,用于监控多个master-slave集群,自动发现master宕机,进行自动切换slave > master. sentinel主要功能如下: 不时的监控redis是否良好运行,如果节点不可达就会对节点进行下线

分布式数据存储 - MySQL主从复制高可用方案

前面几篇文章说道MySQL数据库的高可用方案主从复制.主从复制的延迟产生原因.延迟检测及延迟解决方案(并未从根本上解决),这种主从复制方案保证数据的冗余的同时可以做读写分离来分担系统压力但是并非是高可用方案,因为主从节点中主节点仍然是单点的,一旦主节点宕机会导致应用中写失败.双主复制虽然很好的避免主节点的单点故障,但是未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换.本篇文章就来剖析主从复制的高可用. 一.基础概念介绍 Keep

Centos6.5基于MariaDB10.x 主从复制高可用简单详解

主从复制目的: mysql服务器稳定性提升,避免单台mysql服务器宕机后影响整个业务,当出现宕机问题后,可以立即可使从机提升为新的主服务器.从而实现sql高可用冗余性. 一.演示环境 os:centos6.5 sql:mariadb-10.0.12 iptables off selinux disabled 已装组件: Development tools Server Platform Development 主机master:10.19.90.197 从机slave:10.19.90.111

搭建keepalived+mysql主从复制高可用

准备工作: 完成keepalived的安装完成docker的安装 docker镜像里面自行安装iproute2, vim, iputils-ping(可选)等工具,便于测试 apt-get install iproute2 apt-get install vim apt-get install iputils-ping 主数据库master 1. 使用docker安装mysql mkdir -p ~/compose/mysql-master cd ~/compose/mysql-master