未加星标

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

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

一、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

架构说明:

a、如果主节点修复后再上线,就会变成从节点。

b、客户端程序连接时,应该连接sentinel节点

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同意才能判断一个服务器失效,一个Sentinel都需要获得系统中多数(majority)Sentinel的支持,才能发起一次自动故障迁移, 并预留一个给定的配置纪元(configuration Epoch,一个配置纪元就是一个新主服务器配置的版本号)。换句话说,在只有少数(minority)Sentinel 进程正常运作的情况下, Sentinel 是不能执行自动故障迁移的!

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进程都可以正常启动!

注:Sentinel通过监听Master,知道了Master的存在,那么Sentinel可以读取Master关于Slave的信息,然后交由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" #master的唯一标识id 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" #slave1的唯一标识id 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 模式。

注:在http://linuxg.blog.51cto.com/4410110/1862042这篇博客中我是从redis源码中复制的redis.conf文件而不是手动创建的,是因为我配置sentinel高可用(暨redis应用之使用sentinel实现主从复制高可用)的过程中遇到一个坑,使用手动自创建的redis.conf,当停掉master的redis-server进程的时候,sentinel无法通过选举实现failover,日志中一直是failover 超时,百思不得其解,也在google寻找解决方案无果,后来改为复制源码中的redis.conf,然后failover就OK了!

8、Sentinel的客户端

如果要做到应用程序(客户端)对Redis的failover透明Transparent),客户端需要监控sentinel的频道信息,并自动连接新的主节点。官方提供了一个专门的topic来讲解这个问题: Guidelines for Redis clients with support for Redis Sentinel 而一些常用的开发语言也已经有了整合sentinel的redis driver,如下:

Node.JS redis-sentinel-client Transparent Redis Sentinel client

python redis 2.10.3

Java Jedis

以Python为例,首先安装redis-py

#pip install redis

一个简单的测试代码如下,首先获得一个Sentinel对象,然后

#vim sentinel.py from redis.sentinel import Sentinel sentinel = Sentinel([('localhost', 26379)], socket_timeout=0.1) master = sentinel.master_for('myredis', socket_timeout=0.1) master.set('foo', 'bar') slave = sentinel.slave_for('myredis', socket_timeout=0.1) slave.get('foo')

执行后成功得到bar这个值

python sentinel.py bar

上面的master和slave都是标准的建立好连接的StrictRedis实例,slave则是sentinel查询到的第一个可用的slave。如果正在连接的master不可用时,客户端会先抛出redis.exceptions.ConnectionError异常(此时还没开始failover),然后抛出redis.sentinel.MasterNotFoundError异常(failover进行中),在sentinel正常failover之后,实例正常。所以要开发一个sentinel的高可用客户端,可以参考上面那篇官方的指导。

参考链接:

http://debugo.com/redis-sentinel/

http://www.fblinux.com/?p=157

不足之处,请多多指出!

本文数据库(综合)相关术语:系统安全软件

分页:12
转载请注明
本文标题:redis应用之使用sentinel实现主从复制高可用
本站链接:http://www.codesec.net/view/485576.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(36)