使用keepalived实现redis的故障切换

线上的redis环境一直是单点，确实挺危险的。刚开始想用redis的Sentinel来做，可看了半天发现这东西也不靠谱，还挺麻烦的样子，只能暂时抛弃，换成自己熟悉的keepalived来做。 有了方案后剩下的就是查询相关资料了，google了一堆的资料，发现大家的做法普遍是

线上的redis环境一直是单点，确实挺危险的。刚开始想用redis的Sentinel来做，可看了半天发现这东西也不靠谱，还挺麻烦的样子，只能暂时抛弃，换成自己熟悉的keepalived来做。

有了方案后剩下的就是查询相关资料了，google了一堆的资料，发现大家的做法普遍是：

<code>场景：CentOS A —>Keepaliv<b>本文来源gao@!dai!ma.com搞$$代^@码5网@</b>ed Master && Redis Master     CentOS B—>Keepalived Backup && Redis Backup1.正常情况CentOS A 提供服务， CentOS B 备份2.如果CentOS A 挂了，CentOS B 升级为Master;     CentOS A 恢复正常后，CentOS A 抢占为 Master，CentOS B 降级为 Slave.3.如果CentOS A 挂，重复上述过程；如果 CentOS B 挂，请自行修复CentOS B.  可以看到上述步骤2中，一个是当CentOS A 挂了再起来后再次抢占为Master，会照成业务的再次切换,影响线上业务的稳定性；另一个就是可以看到网上大家的做法一般是当CentOS A恢复抢占为Master后，为了保持Redis 主从数据的一致性，会让CentOS A 的 Redis 变成从先跟 CentOS B的Redis 同步数据，同步了一个固定时间后，然后把CentOS A的Redis 变为主，同样CentOS B的Redis 也是先sleep了某一个固定时间等待CentOS A 同步完成后，再变为从，其他状态变化参考这个过程，不多讲。看完后，我深深的震撼了，我靠，这些哥们确信自己真的能精确的控制这些过程吗？脚本中sleep的时间真的可以定下来吗？最简单的Redis 主从复制，主挂了，立即切换到从，都不能保证数据完整（主的数据还没来得及进行持久化，保存到硬盘），加了个keepalived就行了吗？</code>

我的观点是搞运维的要尽量把架构搞的简单点，不要给自己挖坑，过于复杂的架构不仅难维护，而且容易出问题,出了问题还要背黑锅。所以简单的梳理了下我的需求和我想要得到的效果:

<code>场景：        CentOS A —>Keepalived Master && Redis Master        CentOS B—>Keepalived Backup && Redis Backup1.正常情况CentOS A 提供服务，CentOS B  备份2.如果CentOS A 挂了，CentOS B 升级为Master;  CentOS A 恢复正常后， 不抢占，变为slave.3.如果CentOS B挂了，CentOS A 再升级为主</code>

大家知道keepalived会有四种状态的变化，每种状态变化时，都可以调用一个脚本,如下:

<code>当进入Master状态时会呼叫notify_master当进入Backup状态时会呼叫notify_backup当发现异常情况时进入Fault状态呼叫notify_fault当Keepalived程序终止时则呼叫notify_stop    进入Master和Backup这两种状态很容易理解了，就是分别变为主和从；进入Fault这个稍微要注意下，这个是什么意思呢，简单的说就是keepalived发现自己有问题了，既然有问题那他就不可能再去参与Master竞选了，你得修好他才行，进入这种状态一般是keepalived自身出问题了，或者keepalived检测的网卡出问题不通了，再或者就是我们自己写的检测业务的脚本返回错误；进入Stop 这个就容易理解了，执行/etc/init.d/keepalived stop 就会进入这个状态。    我想要的是上诉步骤2中，当CentOS A 挂了后（Keepalived检测的网卡出问题或者Redis挂了），CentOS A 上的Keepalived也立即stop了，这样一个是流程清晰，另一个是可以避免“脑裂”情况的发生，当然了事后要手动把CentOS A 上的Redis 和 Keepalived 起来；同理上诉步骤3中CentOS B挂了后，也是立即停止Keepalived进程，事后手动启动CentOS B的Redis 和 Keepalived。</code>

喜欢 (0)赏

[搞代码]

分享 (0)