redis哨兵

1.为什么要用哨兵？

          在主从复制架构中，难免会出现宕机的情况，需要分情况看：

            1.1 从库宕机

                 在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据（版本2.8之后是增量复制）。

            1.2 主库宕机

                  分两步：

                         第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；

                         第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；

             很明显，手动恢复是比较麻烦的，所以这个时候就用到哨兵机制了。

2.什么是哨兵？

           从字面的意思来看，哨兵的作用就是对redis的运行情况的一个监控，它是一个独立的进程。功能有两个：

              2.1 监控主从数据库是否运行正常

              2.2 主数据库故障后，自动的将从数据库转为主数据库

3.环境

        一主多从6379,6380,6381

4.哨兵配置

       先要创建哨兵配置文件

       vim sentinel.conf

      输入内容：

       sentinel monitor redisMaster 127.0.0.16379 1

       参数说明：

            redisMaster：监控主数据的名称，自定义即可，可以使用大小写字母和“.-_”符号

            127.0.0.1：监控的主数据库的IP

            6379：监控的主数据库的端口

            1：最低通过票数

       启动哨兵进程：

       redis-sentinel ./sentinel.conf

                      

           由上图可以看到：

           1、  哨兵已经启动，它有一个自己的runid

           2、  为master数据库添加了一个监控

           3、  发现了2个slave（所以，哨兵无需配置slave，只需要指定master，哨兵会自动发现slave）

5.宕机分类

   5.1从库宕机

    [root@localhost 6380]# redis-server redis.conf 
    [root@localhost 6380]# ps -ef|grep redis
    root      2563     1  0 13:40 ?        00:00:05 redis-server *:6379
    root      2772  2704  0 14:37 pts/0    00:00:11 redis-sentinel *:26379 [sentinel]
    root      2781     1  0 14:38 ?        00:00:02 redis-server *:6381
    root      2847     1  0 15:18 ?        00:00:00 redis-server *:6380
    root      2852  2435  0 15:18 pts/1    00:00:00 grep --color=auto redis

      kill -9 2847 将6380从库强制杀掉，在哨兵的控制台过一会会输出：

        2772:X 09 Nov 15:18:19.010 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379

     说明已经监控到slave宕机了，那么，如果我们将6380端口的redis实例启动后，会自动加入到主从复制吗？

       2772:X 09 Nov 15:23:17.709 * +reboot slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379
       2772:X 09 Nov 15:23:17.798 # -sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379

     可以看出，slave从新加入到了主从复制中。-sdown：说明是恢复服务。

   5.2 主库宕机

2772:X 09 Nov 15:27:31.135 # +sdown master redisMaster 127.0.0.1 6379     master服务已经宕机
2772:X 09 Nov 15:27:31.135 # +odown master redisMaster 127.0.0.1 6379 #quorum 1/1
2772:X 09 Nov 15:27:31.135 # +new-epoch 1
2772:X 09 Nov 15:27:31.135 # +try-failover master redisMaster 127.0.0.1 6379   开始恢复故障
2772:X 09 Nov 15:27:31.136 # +vote-for-leader 3063f4b0bfc7a657383266ffcb0d2fa9f5ab9b84 1 投票选举哨兵leader，现在就一个哨兵所以leader就是自己
2772:X 09 Nov 15:27:31.137 # +elected-leader master redisMaster 127.0.0.1 6379             选中leader
2772:X 09 Nov 15:27:31.137 # +failover-state-select-slave master redisMaster 127.0.0.1 6379     选中其中的一个slave当做master
2772:X 09 Nov 15:27:31.220 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ redisMaster 127.0.0.1 6379    选中6381
2772:X 09 Nov 15:27:31.221 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ redisMaster 127.0.0.1 6379  发送slaveof no one命令
2772:X 09 Nov 15:27:31.276 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ redisMaster 127.0.0.1 6379 等待升级master
2772:X 09 Nov 15:27:32.172 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ redisMaster 127.0.0.1 6379    升级6381为master
2772:X 09 Nov 15:27:32.172 # +failover-state-reconf-slaves master redisMaster 127.0.0.1 6379
2772:X 09 Nov 15:27:32.223 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379
2772:X 09 Nov 15:27:33.219 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379
2772:X 09 Nov 15:27:34.245 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6379
2772:X 09 Nov 15:27:34.346 # +failover-end master redisMaster 127.0.0.1 6379    故障恢复完成
2772:X 09 Nov 15:27:34.346 # +switch-master redisMaster 127.0.0.1 6379 127.0.0.1 6381    主数据库从6379转变为6381
2772:X 09 Nov 15:27:34.346 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redisMaster 127.0.0.1 6381  添加6380为6381的从库
2772:X 09 Nov 15:27:34.346 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redisMaster 127.0.0.1 6381  添加6379为6381的从库

       可以看到6381是主库，它有一个从库6380

[root@localhost 6380]# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=29050,lag=1
master_repl_offset:29050
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:29049
127.0.0.1:6381> 

将6379恢复，接下来，我们恢复6379查看状态：

2772:X 09 Nov 15:37:07.409 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ redisMaster 127.0.0.1 6381  379已经恢复服务
2772:X 09 Nov 15:37:17.373 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redisMaster 127.0.0.1 6381  将6379设置为6381的slave

6.配置多个哨兵

配置如下，但是我没有测试，你们可以测试一下。

vim sentinel.conf

输入内容：

sentinel monitor taotaoMaster 127.0.0.1 6381 2

sentinel monitor taotaoMaster2 127.0.0.16381 1