查阅多方资料后,才发现昨天写的配置哨兵模式开启是错的,尴尬。。。
今天重新来配置一下,当然为了避免出现问题,先理清下思路,整理好信息
哨兵模式监控的节点最少三个,昨天监控了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解析之后,发现成功的进行的故障转移,那么这次的哨兵模式配置也是告一段落了
原文地址:https://www.cnblogs.com/huajidafahao/p/11268406.html
时间: 2024-10-11 02:55:06