### REDIS-SENTINEL ################################################ # master redis-sentinel: image: johnson19900110/redis-sentinel:latest restart: always #如果master未开启数据持久化，此项应该删除 volumes: - ./redis-sentinel/config/sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis # redis sentinel slave 1 redis-sentinel-slave1: image: johnson19900110/redis-sentinel:latest restart: always volumes: - ./redis-sentinel/config/sentinel-slave1.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis-slave1 - redis-sentinel # redis sentinel slave 2 redis-sentinel-slave2: image: johnson19900110/redis-sentinel:latest restart: always volumes: - ./redis-sentinel/config/sentinel-slave2.conf:/usr/local/etc/redis/redis-sentinel.conf networks: - backend depends_on: - redis-slave2 - redis-sentinel-slave1
启动容器
docker-compose up -d redis-sentinel-slave2
执行以上命令后，就启动了三个哨兵模式的容器
这是我们进入容器，查看是否redis-sentinel是否在工作。
我们可看到，已经与master建立连接，通过status=ok可以知道，master正在正常工作，并且有2个从节点和3个哨兵节点。现在你再打开sentinel的配置文件，会发现发生了改变。
conf文件被重写了，并且哨兵模式会自动检测到master的两个slave和另外两个sentinel。
故障演示
1、使master宕机，只需要关闭master的容器即可。
如果此时再去三个哨兵节点里用info sentinel查看信息。
会发现这时候master节点的address信息变了，这就说明哨兵模式起作用了。但他这里还是显示新的master有两个slave。是因为原master节点宕机了，一旦它重启，sentinel就会把它变成新的master节点的slave节点。我们可以去172.18.0.6这个容器中看下。
可以用以上docker命令查看容器的IP地址。进入容器后，还是在redis-cli下用info replication查看信息。
我们可以看到这个slave变成了新的master，另外一个slave也变成了新master节点的slave。如果你查看redis节点的配置文件，会发现也被重写了。 这是我们再重启原master节点试试（注意：当他重启成功后，就变成了slave节点，所以要打开持久化配置）。
当容器重启成功后，我们再去新的master节点中使用info replication查看下。
正如我们所料，它成为了新的master的slave节点。如果你查看原master的配置文件，会发现多了
最后，因为新的master节点是slave节点升级的，所以他的持久化配置还是存在的，如果你想要关掉它，只需要进入redis-cli，然后执行
至此，一次redis的master节点故障转移就演示完成了。这次演示实现了redis的监控和自动故障转移特性。
提醒特性是使用的订阅功能，需要后端代码开发配合的。
发布与订阅信息
![](upload/201811131650118838.gif") left top no-repeat; font-weight: bold;){kind=link}
联系我们
电话咨询
0532-85025005
扫码添加微信
