以下内容是记录在公司的测试服务器上安装redis 3.0.7并搭建主从和配置了sentinel服务的过程,验证了一遍当redis主实例宕机后是否会发生主库自动转移,并探究了在故障转移过程中redis实例和sentinel的配置文件的相关参数变化,体会sentinel监控主从、保证主库高可用的基本过程。
主从搭建
在测试服务器P2P-test1(10.19.62.2)上已安装好redis-3.0.7,安装目录为/home/wwwad/software/redis-3.0.7/,test1服务器上只配置了一个redis实例,相关基本配置信息如下:
端口号为6999(没有采用redis默认的6379端口号);
datadir为"/data/redis/6999/";
安装目录为"/data/redis/6999/bin/";
配置文件为"/etc/redis/6999.conf";
日志文件为"/etc/redis/6999/redis_6999.log"
在测试服务器test_3(10.19.110.150)上也安装了redis-3.0.7,安装目录为/home/wwwad/redis-3.0.7/目录,test_3服务器上只配置了一个redis实例,相关基本配置信息如下:
端口号为6999(没有采用redis默认的6379端口号);
datadir为"/data/redis/6999/";
安装目录为"/data/redis/6999/bin/";
配置文件为"/etc/redis/6999.conf";
日志文件为"/etc/redis/6999/redis_6999.log"
开始搭建主从
我们让10.19.62.2:6999成为主库,10.19.110.150:6999成为从库。搭建主从很简单,最简单地就是进入test_3的redis上,执行"slaveof 10.19.62.2 6999"即建立了主从,如图:
执行info replication命令可以看到role为slave,表示本实例为从库。同样地,可以到10.19.62.2上执行相应的命令查看一下:
这种通过命令行搭建起来的主从架构是不稳定的。当主从断开或者主从重启后它们的复制关系就不存在了,无法保证持久复制,所以需要在配置文件里通过参数永久设置主从复制。方式是在从库的配置文件里添加下面参数:
slaveof 10.19.62.2 6999 #复制参数,指定主库的IP和端口号
slave-read-only yes #设置从库为只读
masterauth redis123 #如果主库设置了requirepass,那么从库连上主库需要有主库的密码才行,如果不设置改参数,那么主从关系可能可以建立,但是主库有数据更新时从库上不会重现(可以试一下)
添加后重启从库,进入从库后执行info replication命令,可以发现此时复制关系仍然存在,这是因为配置文件中的参数作用。如图所示:
搭建sentinel服务
sentinel中文即哨兵的意思,也就是一个“监视器”。它是通过给定的配置文件来发现主服务器,再通过向主服务器发送info信息来发现该主服务器的从服务器。Sentinel实际上就是一个运行在 Sentienl 模式下的 Redis 服务器。
·我们先在从服务器上搭建一个sentinel实例,来测试一下效果。首先建立sentinel实例目录:
[wwwad@test_3 sentinel]$ sudo mkdir /data/redis/sentinel/
·将sentinel的配置文件拷贝到/etc/redis/下
[wwwad@test_3 redis-3.0.7]$ cp sentinel.conf /etc/redis/sentinel_16999.conf
·配置一下下面的关键性的参数,其余的参数默认值即可:
port 16999
#指定sentinel的端口号为16999(默认为26379,这里不采用默认的)
dir "/data/redis/sentinel"
#指定sentinel的安装目录
logfile "/data/redis/sentinel/sentinel_16999.log"
#指定sentinel的日志文件存放位置
daemonize yes
#指定是否用守护线程的方式启动sentinel。yes代表启用守护线程,这时sentinel会在后台运行,不占用前端界面;no表不启用守护线程,这时会占用前端界面
sentinel monitor mymaster 10.19.62.2 6999 1
#告诉sentinel主库的位置在10.19.62.2:6999,并将该主库命名为mymaster,1表示在sentinel集群中,有多少个sentinel认为master不可用了,才能真正认定master不可用。
sentinel auth-pass mymaster redis123
#主库设置requirepass,这里需要指定主库的密码
·启动sentinel
通过命令redis-sentinel并指定配置文件的方式启动sentinel:
[wwwad@test_3 redis-3.0.7]$ sudo redis-sentinel /etc/redis/sentinel_16999.conf
启动后,查看一下sentinel日志的输出信息,如上图中的倒数第二行表示sentinel找到了主库并加入了监控,倒数第一行表示找到slave并加入到slave列表。这时查看sentinel的配置文件,会发现多了这样的一行:
sentinel known-slave mymaster 10.19.110.150 6999
这表示sentinel将从库信息写到配置文件里保存了。
如果日志的输出信息中没有上面的倒数第一行的信息,表示sentinel没有找到主库所对应的从库,sentinel的启动是不成功的,当主库宕机后sentinel无法实现故障转移。这时候需要进行排错,首先看日志文件的输出信息,然后可能的原因如下:
redis-sentinel命令用得对不对;
sentinel的配置文件配置是否正确;
主从库的配置文件以及主从关系是否真正建立。
测试redis的主从故障转移
1、kill掉10.19.62.2:6999主库后的情形
在主库上kill掉主库进程,如图:
在从库上查看从库的状态:
查看sentinel的故障转移过程的输出信息,如下:
13747:X 01 Aug 18:05:07.173 # +sdown master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.173 # +odown master mymaster 10.19.62.2 6999 #quorum 1/1
13747:X 01 Aug 18:05:07.173 # +new-epoch 25
13747:X 01 Aug 18:05:07.173 # +try-failover master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.174 # +vote-for-leader aefc57c5a4d0a78bb985d6ab4252a9dfdcd5b099 25
13747:X 01 Aug 18:05:07.174 # +elected-leader master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.174 # +failover-state-select-slave master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.251 # +selected-slave slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.251 * +failover-state-send-slaveof-noone slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:07.322 * +failover-state-wait-promotion slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:08.214 # +promoted-slave slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:08.214 # +failover-state-reconf-slaves master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:08.284 # +failover-end master mymaster 10.19.62.2 6999
13747:X 01 Aug 18:05:08.284 # +switch-master mymaster 10.19.62.2 6999 10.19.110.150 6999
13747:X 01 Aug 18:05:08.284 * +slave slave 10.19.62.2:6999 10.19.62.2 6999 @ mymaster 10.19.110.150 6999
13747:X 01 Aug 18:05:23.343 # +sdown slave 10.19.62.2:6999 10.19.62.2 6999 @ mymaster 10.19.110.150 6999
在这个转移过程中,10.19.110.150:6999的配置文件和sentinel配置文件都有参数改变:10.19.110.150:6999配置文件的slaveof参数被删除;sentinel配置文件sentinel monitor参数指向了新的主库:sentinel monitor mymaster 10.19.110.150 6999 1;sentinel known-slave参数指向了刚才宕掉的10.19.62.2:6999库:sentinel known-slave mymaster 10.19.62.2 6999
2、重新启动10.19.62.2:6999实例后的情形
重新启动10.19.62.2:6999,重启后进入数据库中查看复制状态,如图:
这里10.19.62.2:6999启动后即成为10.19.110.150:6999的从库,要知道在启动10.19.62.2:6999时,其配置文件中是没有slaveof参数,但是这里还是建立复制关系。这是因为在之前的故障转移时,sentinel把10.19.62.2:6999作为10.19.110.150:6999的slave存到了配置文件中,如下图:
sentinel通过这条配置信息为二者建立了主从关系。再查看10.19.62.2:6999实例的配置文件,会发现多了"slaveof 10.19.110.150 6999"信息,如图:
这时新的主从关系确立了:10.19.62.2:6999变成了从,10.19.110.150:6999变成了主。下面再模拟主库宕机,看sentinel还能不能再切过来。
3、kill掉10.19.110.150:6999后的情形
查看10.19.110.150:6999实例的进程id后并杀死,这时在10.19.62.2:6999上查看复制状态,可以看出和预想的一样,10.19.62.2:6999成为了主库。
这时再查看下10.19.62.2:6999的配置文件信息,看看还有没有"slaveof 10.19.110.150 6999"信息,如下图:
很明显,10.19.62.2:6999配置文件中的这条参数配置已被删除。另外再查看sentinel的配置文件,相应地主从库配置也改变了:
同样地,当启动10.19.110.150:6999实例后,将自动与10.19.62.2:6999建立主从关系,并且10.19.110.150:6999的配置文件里添加了slaveof参数:
4、测试sentinel的sentinel notification-script和sentinel client-reconfig-script参数
网上有文章说notification-script参数指定的脚本不会执行,而client-reconfig-script参数指定的脚本会执行,下面来验证一下。
测试client-reconfig-script参数:
先编辑一个简单的脚本,脚本位于/var/redis/目录下,并赋予脚本可执行权限:chmod 755 /var/redis/reconfig.sh,脚本内容如下:
在sentinel的配置文件中添加如下一行参数:
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
重新启动sentinel:
[wwwad@test_3 sentinel]$ redis-cli -p 16999 shutdown
[wwwad@test_3 sentinel]$ sudo redis-sentinel /etc/redis/sentinel_16999.conf
此时在/home/wwwad/目录下是没有test_1文件的:
现在kill掉redis主库,这时会进行主库切换,sentinel根据配置文件里的client-reconfig-script参数也会去执行reconfig.sh脚本,是否执行过该脚本可以看/home/wwwad/下有没有test_1文件:
可以看出,该参数指定脚本是会执行的。
测试sentinel notification-script参数:
在sentinel配置文件里注释掉sentinel client-reconfig-script参数,添加sentinel notification-script参数:
再重启sentinel,并将/home/wwwad/目录下的test_1文件删除:
此时再模拟一次主库故障,即kill掉主库,过一会在/home/wwwad目录下发现test_1文件同样被创建:
可以看出sentinel notification-script参数指定的脚本同样会执行。所以这两个参数基本上都是有效的。
上面的搭建中,只在10.19.110.150服务器上搭建了一个sentinel,但是一个sentinel容易出现单点问题,所以我们需要配置sentinel集群,在10.19.62.2和10.19.110.150两台服务器上各搭建两个sentinel实例,即redis架构由上图向下图转换:
先创建sentinel的dir目录,然后将redis安装目录下的sentinel.conf文件复制到/etc/redis/目录下:
[wwwad@P2P-test1 redis]$ sudo mkdir sentinel_15999
[wwwad@P2P-test1 redis-3.0.7]$ cp sentinel.conf /etc/redis/sentinel_15999.conf
修改下sentinel的配置文件,进行如下的基本配置:
port 15999
dir "/data/redis/sentinel_15999"
logfile "/data/redis/sentinel_15999/sentinel_1599.log"
daemonize yes
sentinel monitor mymaster 10.19.62.2 6999 3
sentinel down-after-milliseconds mymaster 15000
sentinel auth-pass mymaster redis123
sentinel config-epoch mymaster 38
sentinel leader-epoch mymaster 0
sentinel current-epoch 38
然后开始启动各个sentinel实例,启动后再看各个sentinel的配置文件,会增加如下几行配置信息(以10.19.62.2:15999为例):
上图表示每个sentinel实例都识别到了10.19.110.150:6999从实例以及另外三个sentinel实例的信息,此时构成了sentinel实例集群。
此时redis主从、sentinel监控集群都部署完毕,再模拟故障转移场景。
sentinel集群下的主库故障转移
在主库10.19.62.2:6999上kill掉主库实例并同时记录kill掉的时间:
查看10.19.62.2:16999 sentinel的日志文件,如下:
15168:X 03 Aug 11:42:42.164 # +sdown master mymaster 10.19.62.2 6999
#主观检测到主库不可用
15168:X 03 Aug 11:42:42.222 # +odown master mymaster 10.19.62.2 6999 #quorum 4/3
#投票完成,客观认为主库是不可用的
#这里quorum 4/3感觉有些问题,四个sentinel都将quorum配置为3,但是这里居然是4/3,应该是3/3才合理,但是故障转移过程也实现了。。。。
15168:X 03 Aug 11:42:42.222 # +new-epoch 43
15168:X 03 Aug 11:42:42.222 # +try-failover master mymaster 10.19.62.2 6999
#开始准备转移主库
15168:X 03 Aug 11:42:42.224 # +vote-for-leader 9d853e5036cf96fbfea10c1a717296ee353f0de3 43
15168:X 03 Aug 11:42:42.226 # 10.19.62.2:15999 voted for 9d853e5036cf96fbfea10c1a717296ee353f0de3 43
15168:X 03 Aug 11:42:42.236 # 10.19.110.150:15999 voted for 9d853e5036cf96fbfea10c1a717296ee353f0de3 43
15168:X 03 Aug 11:42:42.236 # 10.19.110.150:16999 voted for 9d853e5036cf96fbfea10c1a717296ee353f0de3 43
#以上都是在选举sentinel leader
15168:X 03 Aug 11:42:42.300 # +elected-leader master mymaster 10.19.62.2 6999
15168:X 03 Aug 11:42:42.300 # +failover-state-select-slave master mymaster 10.19.62.2 6999
#准备选择一个slave来充当新主
15168:X 03 Aug 11:42:42.377 # +selected-slave slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
#选择10.19.110.150:6999为新主
15168:X 03 Aug 11:42:42.377 * +failover-state-send-slaveof-noone slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
#改变10.19.110.150:6999的身份,即去除掉其配置文件里slaveof参数
15168:X 03 Aug 11:42:42.439 * +failover-state-wait-promotion slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
15168:X 03 Aug 11:42:43.287 # +promoted-slave slave 10.19.110.150:6999 10.19.110.150 6999 @ mymaster 10.19.62.2 6999
#提升10.19.110.150:6999为主库
15168:X 03 Aug 11:42:43.287 # +failover-state-reconf-slaves master mymaster 10.19.62.2 6999
15168:X 03 Aug 11:42:43.368 # +failover-end master mymaster 10.19.62.2 6999
#表示故障转移成功
15168:X 03 Aug 11:42:43.369 # +switch-master mymaster 10.19.62.2 6999 10.19.110.150 6999
#master的地址发生变化
15168:X 03 Aug 11:42:43.369 * +slave slave 10.19.62.2:6999 10.19.62.2 6999 @ mymaster 10.19.110.150 6999
15168:X 03 Aug 11:42:58.420 # +sdown slave 10.19.62.2:6999 10.19.62.2 6999 @ mymaster 10.19.110.150 6999
#以上是添加其他slave到新主下,但10.19.62.2:6999处于不可用状态
查看日志,发现sentinel是在11:42:42秒开始进行故障转移,到11:42:58秒结束,而故障是发生在11:42:27秒。