linux配置系列之redis哨兵配置

很精辟的一段话,"未曾清贫难做人,不经打击永天真；成熟不过是善于隐藏,沧桑不过是无泪有伤。"

redis的主从配置比较容易，主从配置后，主主要进行写的 *** 作,从主要进行读的 *** 作,那么如果主挂了,是不是就没法进行写了？所以redis中可以进行哨兵的配置,具有高可用性，即是在主挂了之后,哨兵检测到后，会在从中进行投票,投票数多的晋升为主。这个配置可折腾我了，按照找的资料进行了哨兵的配置，可是当我把主服务停掉之后，从还在一致尝试连接主

启动哨兵日志

停掉主后从的日志

停掉后哨兵中,日志情况

就是这个问题我一直尝试找到解决办法，看了其中" sentinel-16379.conf"中的配置差不多，跟网上的一样。但是就是不行。

sentinel-16379.conf配置如下

这是我把这个配置文件的注释和空格都去掉后的结果

实际中我修改了如下几个配置

其他的可能都是自动生成的。当然你也可以自己指定日志位置。

auth-pass是因为我的主中做了配置密码了。

官网的配置说明： https://redis.io/topics/sentinel

所以那为什么我的哨兵没有起作用了,最后我找了公司运维一起看,问题的原因就是我的从中的bind的这个属性没有做配置。

加上了这个，all done!!!

如果你直接使用

报错如下

因为bind只配置了10.10.39.105所以连接如下

哨兵启动结果

干掉主进程

哨兵的日志打印状况

从服务器的日志情况：

连接39.105设置数据如下

哨兵监控如下：

测试从是否可以设置数据

在主上设置数据

在从上get数据

三：问题说明

上面也说了，第一次没有成功的原因是因为bind问题

我尝试翻译下如下

redis版本为redis-3.2.12，使用工具将安装包上传到data目录。

在data目录下创建文件夹redis，将redis安装在此目录。

第一步：解压。

第二步：安装，PREFIX=/data/redis用来设置安装目录。

到此，redis已经安装完成，剩下就是配置和启动服务。

进入redis目录， 创建配置文件conf、日志logs、数据库dump、进程号pid四个目录，用来存放对应的文件，这四个目录也可以存放在其他文件夹，只要与配置文件中的配置一致即可，否则在启动服务时会报错。 其中bin目录就是redis安装成功后的一些命令文件。

redis服务配置一主二从，哨兵模式。注意：如果在实际开发中用不到哨兵模式，redis服务配置一主一从即可。

主Redis配置：redis_6379.conf

从Redis配置，redis_6380.conf和redis_6381.conf，与主Redis配置基本上一样，不一样的地方在于 端口、数据库、日志、pid文件名称 ，都以6380或6381为标志， 最重要的地方是建立主从关系和同步验证。

注意： 对只使用redis服务 ，只需要在主Redis里面配置requirepass，在从Redis里面配置masterauth，密码保持一致，密码尽可能复杂，以免被攻击破解。

注意： 对只使用redis服务 ，如果从Redis也有必要加入访问验证，也可以设置requirepass，而且密码可以与主Redis密码不同。

将配置文件放置到/data/redis/conf目录下，然后就可以启动服务了。

启动服务要按照主从顺序依次启动。

查看服务启动情况：

也可以通过查看日志文件来确认服务是否正常启动。

通过客户端登录Redis验证数据同步情况：

主Redis登录验证，设置数据：

从Redis登录，获取数据：从Redis并没有设置密码，所以无需验证就可以 *** 作。

配置哨兵模式：

Redis Sentinel集群通常由3到5个节点组成，如果个别节点挂了，集群还可以正常运作。Sentinel负责监控Redis集群的 健康 情况。

如果主Redis挂掉，Sentinel集群会通过投票选择一个新的主Redis。 当原来的主Redis恢复时，它会被当做新的主Redis的从Redis重新加入Redis集群。

设置连接master和slave的密码，需要注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码必须设置相同。也就是说主Redis和从Redis都必须设置requirepass和masterauth，而且密码必须相同。

sentinel.conf配置信息：

将该配置文件放置到/data/redis/conf目录下，启动sentinel服务：

验证sentinel是否起作用，可以手工shutdown掉主Redis。

这时从Redis想要访问主Redis同步数据就会提示错误信息：

sentinel在监测到主Redis宕机之后，通过选举，将一个从Redis选定为新的主Redis。通过查看sentinel日志可以发现，选定6380为新的主Redis，同时将另外两个Redis作为从Redis。

注意：选定6380为主Redis后，所有的配置文件都会被修改，主要是重新建立主从关系。

6379会新增：slaveof 127.0.0.1 6380

6380会删掉：slaveof 127.0.0.1 6379

6381会修改：slaveof 127.0.0.1 6380

由于6379服务已经关掉，所以虽然sentinel将6379作为6380的从服务，但是没有真正的建立。

重新启动6379服务，这时sentinel会重建建立一次主从关系：

Sentinel（哨兵）进程的作用：

1.监控(Monitoring): sentinel会不断地检查你的Master和Slave是否运作正常

2.提醒(Notification)：当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知

3.自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移 *** 作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断

客观下线 （Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

https://www.cnblogs.com/JJY-/articles/12066861.html

---