Redis双机热备方案(3)

(1).在keepalived.conf配置文件中，将keepalived双机 都设置成BACKUP.同时在218上设置了nopreempt，即恢复时不抢占。而规划中是将218作为master。所以在启动过程中要遵循以下顺序：先启动218上的keepalived，等待数据同步完成后，再启动219上的keepalived.

(2).在keepalived的巡检脚本Redis_check.sh中加入了状态切换的监控脚本。在master.sh中设置了当keepalived切换成master，会先将redis切换成slave进行同步数据，再切换回master。所以在启动keepalived之前，要保证Master和Slave上redis的数据是一致的，这样先启动redis的master那台的keepalived，虽然redis master会连接到redis slave同步数据，但是两边数据在刚开始的时候是一致的，并不会产生什么问题。

(3).在实际生产环境中需要修改防火墙策略，开放相应的端口。在此直接先将防火墙关闭:service iptables stop。

以下为各种测试场景和输出结果：

-----------------------------------------初始环境--------------------------------------------------

设定一下初始环境：

----启动218和219的redis: /usr/local/redis/redis-start.sh

----启动218的keepalived: service keepalived start;先不启动219的keepalived.

在218上执行tail –f /usr/local/keepalived/logs/keepalived.log，可看到keepavlived切换成master state(配置文件中是设置state:backup),且绑定了VIP。

查看218Master:redis的日志，可以看到redis切换的过程如下：

----启动219Slave的keepalived，并查看redis的日志，可以看到redis的状态变成了slave：

-----------------------------------------初始环境--------------------------------------------------

-----------------------------------------设计思路3-------------------------------------------------

----模拟设计思路3，将218Master的redis进程kill掉:

此时218的keepalived会被停止，如下图：

219的keepalived会正确切换成State:Master,VIP完成漂移，如下图：

218的redis监控日志如下，

219的redis监控日志如下，显示了219已切换成master，保证了业务（当然此处218在内存中未写入文件的数据会丢失）：

----模拟218从故障中恢复：

因为在发现故障时，会将218上的keepalived关闭，因此恢复时，需要先启动218的redis，然后再启动218的keepalived：

查看218的keepalived日志，218的keepalived直接进入state:backup,不会造成业务的来回切换：

查看218的redis日志，218的redis启动后，会切换成已存在redis服务器的备机。

综上所示，设计思路3测试成功。

-----------------------------------------设计思路3-------------------------------------------------

-----------------------------------------设计思路2-------------------------------------------------

----先设置成初始环境，再模拟设计思路2，将218的keepalived进程kill掉（service keepalived stop）:

查看218的redis监控日志：

查看219的keepalivd日志，说明keepalived正常切换了：

查看219的redis监控日志，可以看到redis完成了主从切换：

----模拟218从keepalived故障中恢复（只需要先kill所有keepalived进程后正常启动），执行service keepalived start:

查看219的keepalived的日志，可以看到keepalived的state为backup，不会造成VIP的漂移：

查看218的redis监控日志，可

查看218的redis运行日志，可以看到redis恢复为slave身份，不会造成业务切换：

综上所示，设计思路2测试成功。

-----------------------------------------设计思路2-------------------------------------------------

设计思路4即为初始环境，设计思路1的情况为设计思路2和3的综合情况，无需测试了。

以上即为Redis双机热备方案。