搭建Redis哨兵集群(实例):

搭建哨兵模式的前提是要首先搭建Redis主从复制:

Redis主从复制原理:

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

 

全量复制: 而在slave服务在接受到数据库文件数据后,将其存盘并加载到内存中.

增量复制: 在第一进行全量复制的基础在次进行同步的时候,就只会同步增量的地方,而且对于从机是没有修改数据的权限,从机主要用于读数据,而主机时用于修改数据.

构建主从架构:

准备三台服务器:

主机服务器:192.168.181.5

从机服务器: 192.168.181.4; 从机服务器: 192.168.181.6

首先是对三台主机安装相同版本的Redis服务.

1. 配置主机服务器:

修改redis的配置文件,redis.conf .将bind 127.0.0.1这行进行注释,或指定ip地址.如果指定了ip,则就是仅这台主机能连接上,而注释了则是全网段链接.

2/开启守护进程: daemonize yes

3/修改如图模块配置: Protected-mode 是为了禁止公网访问redis cache，加强redis安全的。关闭掉,则是全网段都可以访问到.

 

4/设置访问密码:

 

5/配置从服务器: 前面的操作与主服务器配置基本相同.

6/配置所属主服务器ip和端口

 

这里配置所属主服务器的密码,.然后进行测试:

主机上添加数据:

 

 

从机上查看数据:

 

注意;从机只能用来读取数据,不能写数据,使用set命令.会报错.

至此主从复制配置完成,

哨兵模式

主从切换的技术方法是: 当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用,,哨兵模式: 就是为了解决这个问题而产生的.

定义:

哨兵(Sentinle)是用于监控redis集群中的Master状态的工具,是Redis的高可用性解决方案,

sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有slave；当某个master服务下线时，自动将该master下的slave升级为master服务替代已下线的master服务继续处理请求。

sentinel可以让Redis实现主从复制,当一个集群中的master失效后,sentinel可以选举出一个新的master用于自动接替master的工作,集群中的其他Redis服务器自动指向新的master同步数据,.一般建议采取基数太,防止某一台sentinel无法连接到master导致误切换

 

哨兵模式搭建:

 上面的主从复制的基础上,继续进行实验:

主机服务器:192.168.181.5

从机服务器: 192.168.181.4; 从机服务器: 192.168.181.6

1. 首先修改三个节点上哨兵配置文件: sentinel.conf (因为三个主机上给文件的配置内容相同,所以,可以使用scp命令,将文件远程拷贝过去.),
2. 文件需要修改的内容如下图: (这里的ip地址就是你的主机地址,)

 

scp命令实例:

 

1. 在主机上开启redis服务,使用./src/redis-server redis.conf:注意启动顺序,先启动主机的redis,然后启动从机的.
2. 然后在主机上启动哨兵服务,使用命令: ./src/redis-server sentinel.conf --sentinel
3. 可能会出现如下警告:
4. 提示socket连接数设置的太低了， echo 1024 > /proc/sys/net/core/somaxconn
5. 需要修改后重启服务就不会有警告提示 然后重新启动成功页面如下:

 

然后依次启动从机服务.

这里可能会出现,哨兵启动后,就无响应的状况.,需要特别注意:

原因是没有设置节点认证的密码，也就是我的redis设置了节点通信的密码，那么在哨兵里面也是需要配置的。

 

这里的密码是上面主从复制时,给主机设置的密码.要把密码添加进入后,从机才能正常链接主机.修改配置文件后,需要重启整个服务.

在主机页面下可以看到,slave的两个节点已经加入去了:

 

重新打开一个新的主机终端窗口:进入Redis客户端: 使用如下图的命令,可以查看当前的主机信息

 

也可以在从机上输入相同的命令.查看当前的状态.至此安装搭建完成,后面进行测试:

测试:

第一次测试:模拟主机宕机故障,进行测试:

 

然后可以从机上看到生成的日志文件; (因为是前端启动,日志会直接在窗口中)

从下图中可以看出,之前主机宕机后,通过哨兵的选举,产生了新的主机192.168.181.6(该图示在192.168.181.4下显示的)

 

此时:查看192.168.181.6中的信息,发信身份已经转为了主机,同时他们的sentinel.conf配置文件中的主机配置ip也会自动编程当前主机的ip地址.

 

第二次测试:

 将刚才模式宕机的主机重新恢复上线,会发现此时另一个从机和当前主机的,日志文件会有新的输出.

 

同时可以看到:新加入从机的sentinel.conf文件发生了变化.:

 

.至此: Redis哨兵模式,配置搭建测试成功.

Sentinel模式下的几个事件：

·       +reset-master ：主服务器已被重置。

·       +slave ：一个新的从服务器已经被 Sentinel 识别并关联。

·       +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。

·       +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。

·       +slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，

为实例设置新的主服务器。

·       +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。

·       +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。

·       -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel

实例重启的时候，就会出现这种情况。

·       +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。

·       +sdown ：给定的实例现在处于主观下线状态。

·       -sdown ：给定的实例已经不再处于主观下线状态。

·       +odown ：给定的实例现在处于客观下线状态。

·       -odown ：给定的实例已经不再处于客观下线状态。

·       +new-epoch ：当前的纪元（epoch）已经被更新。

·       +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中

（waiting to be elected by the majority）。

·       +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。

·       +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主

服务器的从服务器。

·       no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。

·       selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。

·       failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。

·       failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。

·       failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。

·       +switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。

·       +tilt ：进入 tilt 模式。

·       -tilt ：退出 tilt 模式。