Redis3.2.x-哨兵模式以及遇到的问题

有了主从复制的实现以后，我们如果想对主从服务器进行监控，那么在Redis2.6以后提供了一个“哨兵”机制，在2.6版本中的哨兵为1.0版本，并不稳定，会出现各种各样的问题。在2.8以后的版本的哨兵功能就稳定起来了。

哨兵的含义就是监控Redis系统的运行状况，其主要功能有两点：

1、监控主数据库和从数据库是否正常运行

2、主数据库出现故障后，可以自动将从数据库转换为主数据库，实现自动切换

 

一般实现哨兵模式可以有以下两种方式：

1、假如11是主服务器，12和13是从服务器，然后14是专门启动哨兵模式监控主服务器是否宕机的。但是这样有一个问题就是，14这台机子专门只启动哨兵服务，那么是想当的浪费资源的。

2、11还是主服务器，12和13是从服务器，但是12或者13或者两台都再启动哨兵服务，这样子就不浪费资源了。

 

下面我就用第二种方式了。我有三台机子，IP分别为192.168.123.11和192.168.123.12和192.168.123.13，我将分别叫他们11、12、13，其中11是主服务器，12和13都是从服务器，现在我将在12机子弄个哨兵。当然了，12和13一起弄哨兵也是完全没问题的。

 

第一步：到redis的安装路径，然后将sentinel.conf文件拷贝到/usr/local/redis/etc下

cp sentinel.conf /usr/local/redis/etc/

 

第二步：修改启动哨兵服务的配置文件sentiel.conf

①vim sentiel.conf

     将dir改为 /usr/local/redis/etc/ --就像redis.conf文件一样，我们统一放到这个文件下

②增加一行 sentinel monitor mymaster 192.168.123.11 6379 1

      上面红色字体分别是名称（随意）、主服务器IP、主服务器端口、投票选举次数

③sentinel down-after-milliseconds mymaster 5000

    mymaster和上面的名称对应上，默认是1s检测一次，现在是配置超时5000毫秒（5秒）

④sentinel parallel-syncs mymaster 2 #主服务器有两台从服务器

 

第三步：我们来进行测试

①先是启动主从服务

启动完主从服务，可以再主服务器看主从信息

info replication

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.123.12,port=6379,state=online,offset=71,lag=1
slave1:ip=192.168.123.13,port=6379,state=online,offset=71,lag=0
master_repl_offset:71
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:70

②启动哨兵服务

/usr/local/redis/bin/redis-server /usr/local/redis/etc/sentinel.conf --sentinel &

但是一直停在这里，我们可以ctrl+c，但是其实服务是没有停止的

但是我们看到上面的信息明显是有+sdown的，两台从服务器并没有成功弄上去。我们通过下面命令看一下哨兵信息

/usr/local/redis/bin/redis-cli -h 192.168.123.12 -p 26379 info Sentinel

出现错误了，大概意思是redis是在保护模式下运行的，现在连接不了。

幸好下面也给出了解决的方法，幸好英文过了四级。。。。

第一个是直接通过命令将安全模式关掉

config set protected-mode no

第二个应该是在redis.conf配置文件将安全模式设置为no

protected-mode no

第三个是，如果你的redis服务只是拿来测试，可以在启动的时候带上下面参数

--protected-mode no

第四个是，设置一个绑定address或者加上一个认证密码。但是要注意，如果加上认证密码，sentinel.conf里面也记得配置上。

 

那么我们都去主从服务器的redis.conf文件去添加上protected-mode=no

vim /usr/local/redis/etc/redis.conf

下面再重启redis服务和sentinel服务

可见，还是不行。。。。这时候我在想，是不是像上篇文章一样，连接出错是因为bind的问题呢？

我们再去尝试一下，将从服务器的bind都改为0.0.0.0

再次启动哨兵：

也没说从服务器down，看看信息吧：

 

还是说保护模式。但是我确定我全部都设置好了，不管那么多，我们先测试一下在13机子能不能连接到12机子的客户端

/usr/local/redis/bin/redis-cli -h 192.168.123.12 -p 6379

这个是可以的。那么我知道了，到现在为止，其实主从服务器都是protected-mode no，哨兵配置文件的sentinel.conf没有将protected-mode改为no

下面直接进行测试了：

那我们先不这样子查看哨兵信息，我们直接进行测试，将11的机子shutdown掉。

/usr/local/redis/bin/redis-cli shutdown

发现，哨兵有消息出来了！！！

可以看到，确实在超时时间后，12机子成功成为了主服务器，而13和11也变为12的从服务器了。

我们各自在12和13的机子查看主从信息：

果然没毛病啊老铁，哈哈

最后测试一下重新启动11的机子，看是不是将是12的从服务器

启动后，哨兵又来信息了，就是说11成为12的从服务器嘛：

下面11机子的主从信息，没问题。

我们最后调皮一下，将12的机子shutdown掉，看会不会继续选举出主服务器（验证哨兵是真的没问题的）。

完全没问题。！

 

好了，我们最后还原到11是主服务器，12和13是从服务器，然后将sentinel.conf的protected-mode也改为no，再启动看看。

开始到里面看，原来默认就是no的，那么我们加个bind 0.0.0.0吧。

恩，没问题了。。

最后总结一下：

如果redis主服务器绑定了127.0.0.1，那么跨服务器IP的访问就会失败，从服务器用IP和端口访问主的时候，主服务器发现本机6379端口绑在了127.0.0.1上，也就是只能本机才能访问，外部请求会被过滤，这是linux的网络安全策略管理的。如果bind的IP地址是192.168.123.11，那么本机通过localhost和127.0.0.1、或者直接输入命令redis-cli登录本机redis也就会失败了。只能加上本机ip才能访问到。 
所以，在研发、测试环境可以考虑bind 0.0.0.0，线上生产环境建议绑定IP地址。

还有的就是protected-mode，这是3.2版本之后新加入的特性，我们都设置为no，不然处于保护模式是不支持跨服务器连接的，只能本地连接。但是如果真的在线上生产环境的话，不建议修改protexted-mode为no，可以在redis.conf加上密码。