查阅多方资料后，才发现昨天写的配置哨兵模式开启是错的，尴尬。。。
今天重新来配置一下，当然为了避免出现问题，先理清下思路，整理好信息
哨兵模式监控的节点最少三个，昨天监控了2个是不够的，所以我又再一次的拷贝了一份redis.conf
| 服务器类型 | 是否主服务器 | IP地址 | 端口号 |
| Redis | 是 | 192.168.200.128 | 6379 |
| Redis | 否 | 192.168.200.128 | 6380 |
| Redis | 否 | 192.168.200.128 | 6381 |
| Sentinel | - | 192.168.200.128 | 26379 |
| Sentinel | - | 192.168.200.128 | 26380 |
| Sentinel | - | 192.168.200.128 | 26381 |
上面就是我三个节点以及三个哨兵模式的端口配置了，因为资源有限，就都弄在一个虚拟机上了
废话就不多说，开干了
先配置主服务器，修改redis-6379.conf，加上下面的配置
#设置主服务器的密码
requirepass "123456“
#使外网也能访问主数据库
bind 0.0.0.0
2个从服务器也需要配置一下，修改redis-6380.conf和redis-6381.conf，加上下面的配置
#指定主服务器 slaveof 192.168.200.128 6379 #主服务器密码 masterauth 123456
两个配置好后，我们再来配置哨兵，有3个节点，就需要3个哨兵了
首先设置第一个哨兵，其他的哨兵都是一样的
port 26379 daemonize yes logfile "26379.log" dir "/usr/local/redis/bin" sentinel deny-scripts-reconfig yes sentinel monitor mymaster 192.168.200.128 6379 2 sentinel failover-timeout mymaster 15000 sentinel auth-pass mymaster 123456 bind 192.168.200.128 127.0.0.1 # Generated by CONFIG REWRITE protected-mode no sentinel config-epoch mymaster 0 sentinel leader-epoch mymaster 0 sentinel current-epoch 0
接下来先启动主服务器，后启动从服务器，最后启动三个哨兵即可
我们来测试一下，我们突然停掉主服务器，看看哨兵能不能完成故障转移
#发现master无法连接了 2722:X 29 Jul 2019 19:13:01.161 # +sdown master mymaster 192.168.200.128 6379 #经过投票后，有3个sentinel发现master不能用 2722:X 29 Jul 2019 19:13:01.219 # +odown master mymaster 192.168.200.128 6379 #quorum 3/2 #当前配置版本被更新 2722:X 29 Jul 2019 19:13:01.219 # +new-epoch 1 #达成故障转移条件，等待其他sentinel的选举 2722:X 29 Jul 2019 19:13:01.219 # +try-failover master mymaster 192.168.200.128 6379 #开始投票选举slave服务器 2722:X 29 Jul 2019 19:13:01.221 # +vote-for-leader 0a15116eb684859ad0405cd5878f7a3996d7b9d0 1 2722:X 29 Jul 2019 19:13:01.225 # 108dfb973098e0bafe67f8500d45b742b5c257eb voted for 0a15116eb684859ad0405cd5878f7a3996d7b9d0 1 2722:X 29 Jul 2019 19:13:01.226 # 0decb1582394f4c013012c7df1693138cfd26f20 voted for 0a15116eb684859ad0405cd5878f7a3996d7b9d0 1 2722:X 29 Jul 2019 19:13:01.312 # +elected-leader master mymaster 192.168.200.128 6379 2722:X 29 Jul 2019 19:13:01.313 # +failover-state-select-slave master mymaster 192.168.200.128 6379 #把选举出来的slave进行身份master切换 2722:X 29 Jul 2019 19:13:01.398 # +selected-slave slave 192.168.200.128:6381 192.168.200.128 6381 @ mymaster 192.168.200.128 6379 2722:X 29 Jul 2019 19:13:01.398 * +failover-state-send-slaveof-noone slave 192.168.200.128:6381 192.168.200.128 6381 @ mymaster 192.168.200.128 6379 2722:X 29 Jul 2019 19:13:01.499 * +failover-state-wait-promotion slave 192.168.200.128:6381 192.168.200.128 6381 @ mymaster 192.168.200.128 6379 2722:X 29 Jul 2019 19:13:02.334 # +promoted-slave slave 192.168.200.128:6381 192.168.200.128 6381 @ mymaster 192.168.200.128 6379 #把故障转移failover改变reconf-slaves 2722:X 29 Jul 2019 19:13:02.334 # +failover-state-reconf-slaves master mymaster 192.168.200.128 6379 #sentinel发送slaveof命令把6380端口重新同步6379master 2722:X 29 Jul 2019 19:13:02.434 * +slave-reconf-sent slave 192.168.200.128:6380 192.168.200.128 6380 @ mymaster 192.168.200.128 6379 #离开不可用的master 2722:X 29 Jul 2019 19:13:03.353 # -odown master mymaster 192.168.200.128 6379 #slave被重新配置为另外一个master的slave，但数据还未发生 2722:X 29 Jul 2019 19:13:03.353 * +slave-reconf-inprog slave 192.168.200.128:6380 192.168.200.128 6380 @ mymaster 192.168.200.128 6379 #与master进行数据同步 2722:X 29 Jul 2019 19:13:03.353 * +slave-reconf-done slave 192.168.200.128:6380 192.168.200.128 6380 @ mymaster 192.168.200.128 6379 #故障转移完成 2722:X 29 Jul 2019 19:13:03.423 # +failover-end master mymaster 192.168.200.128 6379 #master地址发生改变 2722:X 29 Jul 2019 19:13:03.423 # +switch-master mymaster 192.168.200.128 6379 192.168.200.128 6381 #检测slave并添加到slave列表 2722:X 29 Jul 2019 19:13:03.423 * +slave slave 192.168.200.128:6380 192.168.200.128 6380 @ mymaster 192.168.200.128 6381 2722:X 29 Jul 2019 19:13:03.423 * +slave slave 192.168.200.128:6379 192.168.200.128 6379 @ mymaster 192.168.200.128 6381
通过上面的log解析之后，发现成功的进行的故障转移，那么这次的哨兵模式配置也是告一段落了