zoukankan      html  css  js  c++  java
  • redis的主从搭建与sentinel高可用服务的搭建

      以下内容是记录在公司的测试服务器上安装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秒。

     

     

  • 相关阅读:
    部署的influxdb没有可以web操作sql的页面
    JUnit5 @TestMethodOrder注释不起作用
    RestAssured 接口测试框架-环境搭建遇到的问题(1)
    PC前端代码 本地启动
    可有可无的“冒烟测试”
    adb devices 找不到连接设备 显示 List of devices attached 解决方法
    【转载】接口测试 rest-assured 使用指南(中文)
    工厂模式
    【腾讯云服务器】基于centos7搭建ftp服务器(vsftpd)
    centos下Django+uwsgi+nginx
  • 原文地址:https://www.cnblogs.com/jiang-jt/p/9449035.html
Copyright © 2011-2022 走看看