阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

Redis+Keepalived高可用方案详细分析

450次阅读
没有评论

共计 13275 个字符,预计需要花费 34 分钟才能阅读完成。

上一篇简单的了解了一下 Redis 官方自带的 HA 方案 sentinel(见 http://www.linuxidc.com/Linux/2014-02/96079.htm),试用发现还是不错的,但是由于还没有合并进稳定分支中,所以在生产环境也不敢使用,还有一个就是需求还暂时不能完全满足,所以就尝试一下 redis+keepalived 方案,毕竟 keepalived 现在还是很稳定的,而且资料也充足。

实验环境

Ubuntu 12.04  10.20.112.26 默认的 master

10.20.112.27 默认的 slave

VIP          10.20.112.29

redis-server 2.6.16

keepalived 默认只能做到对网络故障和 keepalived 本身的监控,即当出现网络故障或者 keepalived 本身出现问题时,进行切换。但我们更关注的是机器上运行的业务,如果业务出问题了 VIP 没有变化,整体来说还是失败的。这时候就需要根据业务进程的运行状态决定是否需要进行主备切换。还好 keepalived 提供了这样一个自定义脚本监控功能,不过该参数设置在官方默认的文档中并没有出现。

其实文档中有两个我们常用的参数都没有提到:

1 vrrp_script && track_script

vrrp_script 代码块是用来定义监控脚本,脚本执行时间间隔以及脚本的执行结果导致优先级变更幅度的。

vrrp_script chk_redis {
    script “/etc/keepalived/scripts/redis_check.sh”  #指定执行脚本的路径
    interval 1                                      #指定脚本的执行时间间隔
    weight 10                                        #脚本结果导致的优先级变更:10 表示优先级 +10;-10 则表示优先级 -10
}

定义好 vrrp_script 代码块之后,就可以在 instance 中使用了

track_script {
    chk_redis
}

注意:VRRP 脚本 (vrrp_script) 和 VRRP 实例 (vrrp_instance) 属于同一个级别

2 notify_stop

keepalived 停止运行前运行 notify_stop 指定的脚本。

配合官方文档提到的以下三个参数一起使用,功能更强大:

notify_master  keepalived 切换到 master 时执行的脚本 

      notify_backup  keepalived 切换到 backup 时执行的脚本 

      notify_fault  keepalived 出现故障时执行的脚本

3 还有个问题需要注意

当 master down 了,backup 接管了,master 再次起来,不能再成为 master。否则 master 恢复了再接管的话,会造成业务来回切换,这时候就需要 nopreempt 参数了。

nopreempt:设置不抢占,这里只能设置在 state 为 backup 的节点上,而且这个节点的优先级必须别另外的高。

先来看看方案的整体思路:

通过 keepalived 的自定义脚本功能监控本机的 redis 服务状态,当监控脚本检测到 redis 服务出现异常时,则改变本机 keepalived 的优先级,同时这会导致 master/backup 角色的变化,而 keepalived 在角色变化时也会触发一些机制执行相关脚本,这就为我们改变 redis 的 master/slave 状态提供了机会,这样做的目的是为了是 redis 的 master/slave 直接的数据保持一致。

在 keepalived+redis 的使用过程中有四种情况:

1 一种是 keepalived 挂了,同时 redis 也挂了,这样的话直接 VIP 飘走之后,是不需要进行 redis 数据同步的,因为 redis 挂了,你也无法去 master 上同步,不过会损失已经写在 master 上却还没同步到 slave 上面的这部分数据。

2 另一种是 keepalived 挂了,redis 没挂,这时候 VIP 飘走后,redis 的 master/slave 还是老的对应关系,如果不变化的话会把数据写入 redis slave 中,从而不会同步到 master 上去,这就要借助监控脚本反转 redis 的 master/slave 关系。这时候就要预留一点时间进行数据同步,然后反转 master/slave。

3 还有一种是 keepalived 没挂,redis 挂了,这时候根据监控脚本会检测到 redis 挂了,并且降低 keepalived master 的优先级,同样会导致 VIP 飘走,情况和第二种一样,也是需要进行数据同步,然后反转当前 redis 的 master/slave 关系的。

4 随后一种是 keepalived 没挂,redis 也没挂,大吉大利啊,什么都不用操作。

本文的实验环境四种情况都适合,第一种是不需要同步数据的,脚本会默认去同步数据,但是其实是不会成功的。脚本主要是用来处理第二和第三种情况的。

Redis 的详细介绍:请点这里
Redis 的下载地址:请点这里

推荐阅读:

Redis 集群明细文档 http://www.linuxidc.com/Linux/2013-09/90118.htm

Ubuntu 12.10 下安装 Redis(图文详解)+ Jedis 连接 Redis http://www.linuxidc.com/Linux/2013-06/85816.htm

Redis 系列 - 安装部署维护篇 http://www.linuxidc.com/Linux/2012-12/75627.htm

CentOS 6.3 安装 Redis http://www.linuxidc.com/Linux/2012-12/75314.htm

Redis 配置文件 redis.conf 详解 http://www.linuxidc.com/Linux/2013-11/92524.htm

配置 10.20.112.26

1 安装 keepalived

apt-get install keepalived
2 安装 Redis
    redis 是采用源码编译安装的,Ubuntu12.04 默认自带版本没有这么高,安装过程参照以前文档。

3 配置 keepalived

global_defs {

    lvs_id LVS_redis 

vrrp_script chk_redis {

        script “/etc/keepalived/scripts/redis_check.sh”

        weight -20

        interval 2                                     

 

vrrp_instance VI_1 {

        state backup                             

        interface eth0                           

        virtual_router_id 51

        nopreempt 

        priority 200     

        advert_int 5                     

        track_script {

            chk_redis                     

        } 

        virtual_ipaddress {

            10.20.112.29                       

        } 

        notify_master /etc/keepalived/scripts/redis_master.sh 

        notify_backup /etc/keepalived/scripts/redis_backup.sh 

        notify_fault  /etc/keepalived/scripts/redis_fault.sh 

        notify_stop  /etc/keepalived/scripts/redis_stop.sh 

}

4 配置 redis,/etc/redis/redis.com 

    最简单的配置就是把默认配置文件中的 bind 127.0.0.1 修改为 0.0.0.0 即可。

5 建立 redis 状态切换脚本

    在 /etc/keepalived 目录下建立 log 和 scripts 目录。

    在 script 下有五个脚本,一个是检测 redis 状态的 redis_check.sh 脚本,其余四个是 keepalived 状态变化时执行的脚本。keepalived 有 master/backup/stop/fault 四种状态,因为我们主要是关注系统上的业务,所以在在 keepalived 进入 fault/stop 状态后,也认为是进入了 backup 状态,需要对 redis 的 master/slave 关系进行反转,否则即使 VIP 漂移过去,但是 redis 的主从关系还没有改变,会导致数据不一致,所以最终四个脚本只有两种内容。

  5.1 redis 服务状态检测脚本 redis_check.sh(27 上面内容和它一样)

#!/bin/bash 

###/etc/keepalived/scripts/redis_check.sh 

ALIVE=`/usr/bin/redis-cli PING` 

if [“$ALIVE” == “PONG”]; then 

  echo $ALIVE 

  exit 0

else

  echo $ALIVE 

  exit 1

fi

5.2 keepalived 进入 master 状态时的检测脚本 redis_master.sh

w sourceprint?01 #!/bin/bash 

###/etc/keepalived/scripts/redis_master.sh 

REDISCLI=”redis-cli”

LOGFILE=”/etc/keepalived/log/redis-state.log”

pid=$$ 

 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver]” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] Run ‘SLAVEOF 10.20.112.27 6379′” >> $LOGFILE 

$REDISCLI SLAVEOF 10.20.112.27 6379 >> $LOGFILE  2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] wait 10 sec for data sync from old master” >> $LOGFILE 

sleep 10 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] data rsync from old mater ok…” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] Run slaveof no one,close master/slave” >> $LOGFILE 

$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] wait other slave connect….” >> $LOGFILE

    5.3 keepalived 进入 backup/stop/fault 时的检测脚本,由于内容都一致,所以只写出 redis_backup.sh

#!/bin/bash 

###/etc/keepalived/scripts/redis_backup.sh 

REDISCLI=”redis-cli”

LOGFILE=”/etc/keepalived/log/redis-state.log”

pid=$$ 

 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master]” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] Being slave state…” >> $LOGFILE 2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] wait 10 sec for data sync from old master” >> $LOGFILE 

sleep 10

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] data rsync from old mater ok…” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] Run ‘SLAVEOF 10.20.112.27 6379′” >> $LOGFILE 

$REDISCLI SLAVEOF 10.20.112.27 6379 >> $LOGFILE  2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] slave connect to 10.20.112.27 ok…” >> $LOGFILE

配置 10.20.112.27

1 安装 keepalived

2 安装 redis

3 配置 redis,/etc/redis/redis.com

    前面三步骤均一样

4 配置 keepalived

 

global_defs {

    lvs_id LVS_redis 

 

vrrp_script chk_redis {

        script “/etc/keepalived/scripts/redis_check.sh”   

        weight  -20 

        interval 2                                       

vrrp_instance VI_1 {

        state backup                                 

        interface eth0                               

        virtual_router_id 51 

        priority 190   

        advert_int  5                           

        track_script {

            chk_redis                   

        } 

        virtual_ipaddress {

            10.20.112.29                   

        } 

        notify_master /etc/keepalived/scripts/redis_master.sh 

        notify_backup /etc/keepalived/scripts/redis_backup.sh 

        notify_fault  /etc/keepalived/scripts/redis_fault.sh 

        notify_stop  /etc/keepalived/scripts/redis_stop.sh 

}

5 建立 redis 状态切换脚本

    在 /etc/keepalived 目录下建立 log 和 scripts 目录

    5.1 redis 服务状态检测脚本 redis_check.sh(26 上面内容和它一样)

    5.2 keepalived 进入 master 状态时的检测脚本 redis_master.sh

#!/bin/bash 

###/etc/keepalived/scripts/redis_master.sh 

REDISCLI=”/usr/bin/redis-cli”

LOGFILE=”/etc/keepalived/log/redis-state.log”

pid=$$ 

 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[backup]” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[backup] Run ‘SLAVEOF 10.20.112.26 6379′” >> $LOGFILE 

$REDISCLI SLAVEOF 10.20.112.26 6379 >> $LOGFILE  2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[backup] wait 10 sec for data sync from old master” >> $LOGFILE 

sleep 10

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] data rsync from old mater ok…” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] Run slaveof no one,close master/slave” >> $LOGFILE 

$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] wait other slave connect….” >> $LOGFILE

    5.3 keepalived 进入 backup/stop/fault 时的检测脚本,由于内容都一致,所以只写出 redis_backup.sh

#!/bin/bash 

###/etc/keepalived/scripts/redis_backup.sh 

REDISCLI=”/usr/bin/redis-cli”

LOGFILE=”/etc/keepalived/log/redis-state.log”

pid=$$ 

 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] Being slave state…” >> $LOGFILE 2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] wait 15 sec for data sync from old master” >> $LOGFILE 

sleep 15 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[master] data rsync from old mater ok…” >> $LOGFILE 

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] Run ‘SLAVEOF 10.20.112.26 6379′” >> $LOGFILE 

$REDISCLI SLAVEOF 10.20.112.26 6379 >> $LOGFILE  2>&1

echo “`date +’%Y-%m-%d:%H:%M:%S’`|$pid|state:[slaver] slave connect to 10.20.112.26 ok…” >> $LOGFILE

上一篇简单的了解了一下 Redis 官方自带的 HA 方案 sentinel(见 http://www.linuxidc.com/Linux/2014-02/96079.htm),试用发现还是不错的,但是由于还没有合并进稳定分支中,所以在生产环境也不敢使用,还有一个就是需求还暂时不能完全满足,所以就尝试一下 redis+keepalived 方案,毕竟 keepalived 现在还是很稳定的,而且资料也充足。

实验环境

Ubuntu 12.04  10.20.112.26 默认的 master

10.20.112.27 默认的 slave

VIP          10.20.112.29

redis-server 2.6.16

keepalived 默认只能做到对网络故障和 keepalived 本身的监控,即当出现网络故障或者 keepalived 本身出现问题时,进行切换。但我们更关注的是机器上运行的业务,如果业务出问题了 VIP 没有变化,整体来说还是失败的。这时候就需要根据业务进程的运行状态决定是否需要进行主备切换。还好 keepalived 提供了这样一个自定义脚本监控功能,不过该参数设置在官方默认的文档中并没有出现。

其实文档中有两个我们常用的参数都没有提到:

1 vrrp_script && track_script

vrrp_script 代码块是用来定义监控脚本,脚本执行时间间隔以及脚本的执行结果导致优先级变更幅度的。

vrrp_script chk_redis {
    script “/etc/keepalived/scripts/redis_check.sh”  #指定执行脚本的路径
    interval 1                                      #指定脚本的执行时间间隔
    weight 10                                        #脚本结果导致的优先级变更:10 表示优先级 +10;-10 则表示优先级 -10
}

定义好 vrrp_script 代码块之后,就可以在 instance 中使用了

track_script {
    chk_redis
}

注意:VRRP 脚本 (vrrp_script) 和 VRRP 实例 (vrrp_instance) 属于同一个级别

2 notify_stop

keepalived 停止运行前运行 notify_stop 指定的脚本。

配合官方文档提到的以下三个参数一起使用,功能更强大:

notify_master  keepalived 切换到 master 时执行的脚本 

      notify_backup  keepalived 切换到 backup 时执行的脚本 

      notify_fault  keepalived 出现故障时执行的脚本

3 还有个问题需要注意

当 master down 了,backup 接管了,master 再次起来,不能再成为 master。否则 master 恢复了再接管的话,会造成业务来回切换,这时候就需要 nopreempt 参数了。

nopreempt:设置不抢占,这里只能设置在 state 为 backup 的节点上,而且这个节点的优先级必须别另外的高。

先来看看方案的整体思路:

通过 keepalived 的自定义脚本功能监控本机的 redis 服务状态,当监控脚本检测到 redis 服务出现异常时,则改变本机 keepalived 的优先级,同时这会导致 master/backup 角色的变化,而 keepalived 在角色变化时也会触发一些机制执行相关脚本,这就为我们改变 redis 的 master/slave 状态提供了机会,这样做的目的是为了是 redis 的 master/slave 直接的数据保持一致。

在 keepalived+redis 的使用过程中有四种情况:

1 一种是 keepalived 挂了,同时 redis 也挂了,这样的话直接 VIP 飘走之后,是不需要进行 redis 数据同步的,因为 redis 挂了,你也无法去 master 上同步,不过会损失已经写在 master 上却还没同步到 slave 上面的这部分数据。

2 另一种是 keepalived 挂了,redis 没挂,这时候 VIP 飘走后,redis 的 master/slave 还是老的对应关系,如果不变化的话会把数据写入 redis slave 中,从而不会同步到 master 上去,这就要借助监控脚本反转 redis 的 master/slave 关系。这时候就要预留一点时间进行数据同步,然后反转 master/slave。

3 还有一种是 keepalived 没挂,redis 挂了,这时候根据监控脚本会检测到 redis 挂了,并且降低 keepalived master 的优先级,同样会导致 VIP 飘走,情况和第二种一样,也是需要进行数据同步,然后反转当前 redis 的 master/slave 关系的。

4 随后一种是 keepalived 没挂,redis 也没挂,大吉大利啊,什么都不用操作。

本文的实验环境四种情况都适合,第一种是不需要同步数据的,脚本会默认去同步数据,但是其实是不会成功的。脚本主要是用来处理第二和第三种情况的。

Redis 的详细介绍:请点这里
Redis 的下载地址:请点这里

推荐阅读:

Redis 集群明细文档 http://www.linuxidc.com/Linux/2013-09/90118.htm

Ubuntu 12.10 下安装 Redis(图文详解)+ Jedis 连接 Redis http://www.linuxidc.com/Linux/2013-06/85816.htm

Redis 系列 - 安装部署维护篇 http://www.linuxidc.com/Linux/2012-12/75627.htm

CentOS 6.3 安装 Redis http://www.linuxidc.com/Linux/2012-12/75314.htm

Redis 配置文件 redis.conf 详解 http://www.linuxidc.com/Linux/2013-11/92524.htm

下面开始试验

既然我们设置了 nopreempt,那么在启动 keepalived 的时候就有启动的顺序问题了,我们把 Redis 的 master 和 keepalived 的 master(虽然配置文件中都是 backup,但是我们是想让 26 这台做 master 的 ) 默认设置在同一台机器上,由于在 keepalived 的 master 上面设置了 nopreempt 参数,所以在启动 keepalived 服务的时候,一定要先启动 redis master 的那台,因为在设置了 nopreempt 了,keepalived 在启动后都是先进入 backup 状态,而脚本又设置了进入 backup 状态后,会连接新的对方进行数据同步,所以, 在启动 keepalived 之前还有一个条件就是 redis 的 master 和 slave 中的数据必须一致。这样先启动 redis 的 master 那台的 keepalived,虽然 redis master 会连接到 redis slave 同步数据,但是两边数据在刚开始的时候是一致的,并不会产生什么问题。

1 先启动 26 和 27 上的 redis 服务,配置 27 从 26 上面同步数据,同步完毕后,取消 27 的同步机制。

这个就是在 27 的 redis 上面执行 slaveof 10.20.112.26 6379,等待数据同步完毕后再执行 slaveos on one,让 26 和 27 的 redis 都保持 master 状态

2 接着启动 26 的 keepalived,不要启动 27 的 keepalived,在 26 和 27 上面各开启三个终端,观察自定义日志和系统日志状态

26 的 syslog

Redis+Keepalived 高可用方案详细分析

红框 19 秒 keepalived 启动后,由于设置了不抢占,且起始状态都是 backup,所以启动后 keepalived 先进入 backup 状态,进入 bankup 状态后,成功的执行了 redis_backup.sh 脚本

绿框 34 秒的时候,keepalived 开始向 master 状态转变,注意:这个时间很重要,为什么是 34 秒呢?默认是 3 秒后就开始向 master 状态转变,由于我们设置了 advert_int 5,默认检测三次,所以 15 秒之后才向 master 转变,为什么设置间隔这么长时间呢?是为了让 redis_backup.sh 脚本有充足的时间执行完毕。39 秒的时候成功的转变为 master 状态,这时候会执行 redis_master.sh 脚本。

26 的redis-state.log

Redis+Keepalived 高可用方案详细分析

过程解释:

红框 确实如系统日志表现的那样,19 秒的时候先进入 backup 状态,执行 redis_backup.sh 脚本。redis_backup 是 keepalived 进入到 backup 状态时执行的脚本。进入到 banckup 状态,说明自身以前是 master 状态或者无状态,这时候会等待两秒种,让之前的 slave 把数据同步完,2 秒钟在数据大的时候有些短,其实是可以设置的,只要小于 3 倍的 advert_int 时间就行,因为 3 倍的时间之后会转为 master 状态的。2 秒钟之后我们的redis 连接到 27 上面(27 这时候充当 master),开始进行正常的 master/slave 机制同步数据,也就是红框中 21 秒的时候。到此为止,redis_backup.sh 执行完毕。

绿框 由于设置了不抢占,所以过了 3 倍的 advert_int 时间之后,开始向 master 状态转变,这个转变过程需要的时间是不固定的,在上面的日志中需要 5 秒,正式的成为 master 状态,这时候会执行 redis_master.sh 脚本,脚本指定需要到 27 的 redis 上同步数据(27 在红框中的时候是充当 master 的),你可以看到已经有连接了,那是因为在红框中已经连接过一次了,我设置的是同步 10 秒钟之后断开和 27 的连接,可以看到 49 秒的时候执行了 slaveof no one 命令,断开了和 27 的连接,把 26 自身的 redis 提升为 master,这时候数据也是最新的了。

3 待 26 的各项进程都 ok 后,我们开始启动 27 上面的 keepalived 服务

27 的 syslog

Redis+Keepalived 高可用方案详细分析

红框 40 秒的时候启动 27 的 keepalived,由于默认都是 backup,所以直接进入 backup 状态,由于 27 的优先级比 26 低,所以 27 并不会过度到 master 状态,这时候 26 是 master 状态了。在 backup 状态执行了 redis_backup.sh 脚本。

27 的redis-state.log

Redis+Keepalived 高可用方案详细分析

红框 在进入 backup 状态后,默认之前是 master 状态或者无状态,所以等待 15 秒,让 26 把数据同步完(26 这时候充当 backup),在 15 秒之后,开始向 backup 转变,开始执行 slaveof 10.20.112.26 6379,作为 26 的 slave。

 

下面要模拟故障 3:

1 kill 掉 26 的 redis 进程,保持 keepalived 进程。(模拟 3)

26 的 syslog

Redis+Keepalived 高可用方案详细分析

红框 可以看到检测脚本 chk_redis 发现 redis 已经宕掉,降低了 26 的 keepalived 的优先级,导致 26 进入 backup 状态,开始执行 redis_backup.sh 监控脚本

26 的redis-state.log

Redis+Keepalived 高可用方案详细分析

红框 由于 redis 我是 kill 掉的,所以必然不能进行数据同步了,不过这并不影响使用。

27 的 syslog

Redis+Keepalived 高可用方案详细分析

绿框 可以看到 27 转变到 master 状态,并且执行了 redis_master.sh 脚本

27 的redis-state.log

Redis+Keepalived 高可用方案详细分析

绿框 由于 26 的 redis 是 kill 掉的,所以��使 27 转变到 master 状态也不能去 26 同步数据,当然 27 也等不到 26 连接上来,不过并不影响我们使用。

下面要模拟故障 2:

2 kill 掉 26 的 keepalived 进程,保持 redis 进程。(模拟 2)

26 的 syslog

Redis+Keepalived 高可用方案详细分析

红框 是 keepslived 的启动过程,在模拟 3 中已经详细分析过

绿框 是 kill 掉 keepalived 进程后的日志。

26 的redis-state.log

Redis+Keepalived 高可用方案详细分析

红框 是 keepalived 启动过程中执行的监控脚本日志,前面模拟 3 中已经详细分析过

绿框 是 keepalived 进程 kill 掉之后,执行的监控脚本日志,在等待 27 同步完数据后,作为 27 的 slave 连接上去。

26 的 redis info

Redis+Keepalived 高可用方案详细分析

可以看到 master/slave 的转变过程

27 的 syslog

Redis+Keepalived 高可用方案详细分析

红框 是 keepalived 作为 backup 的启动过程,在模拟 3 中已经分析过。

绿框 是 kill 掉 26 的 keepalived 进程后,27 转变为 master 时的日志,执行了 redis_master.sh 脚本。

27 的redis-state.log

Redis+Keepalived 高可用方案详细分析

红框 是 keepalived 启动时执行的监控脚本日志,由于开始是 backup 的,所以没有过多的状态切换过程。

绿框 是 26 的 keepalived 进程被 kill 掉之后,27 转变为 master 时执行的脚本日志,由于 keepalived 挂了,但是 26 的 redis 进程还在,所以先和 26 进行数据同步,完成之后再把自己提升为 redis master。

27 的 redis info

Redis+Keepalived 高可用方案详细分析

可以看到 redis 的 master/slave 变化过程

 

以上就是我所能想到的 keepalived+redis HA 方案中需要注意的地方。

Keepalived 的详细介绍:请点这里
Keepalived 的下载地址:请点这里

推荐阅读:

CentOS 6.3 下 Haproxy+Keepalived+Apache 配置笔记 http://www.linuxidc.com/Linux/2013-06/85598.htm

Haproxy + KeepAlived 实现 WEB 群集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm

Keepalived+Haproxy 配置高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm

Haproxy+Keepalived 构建高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-20发表,共计13275字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中

星哥玩云

星哥玩云
星哥玩云
分享互联网知识
用户数
4
文章数
19351
评论数
4
阅读量
7982142
文章搜索
热门文章
星哥带你玩飞牛NAS-6:抖音视频同步工具,视频下载自动下载保存

星哥带你玩飞牛NAS-6:抖音视频同步工具,视频下载自动下载保存

星哥带你玩飞牛 NAS-6:抖音视频同步工具,视频下载自动下载保存 前言 各位玩 NAS 的朋友好,我是星哥!...
星哥带你玩飞牛NAS-3:安装飞牛NAS后的很有必要的操作

星哥带你玩飞牛NAS-3:安装飞牛NAS后的很有必要的操作

星哥带你玩飞牛 NAS-3:安装飞牛 NAS 后的很有必要的操作 前言 如果你已经有了飞牛 NAS 系统,之前...
我把用了20年的360安全卫士卸载了

我把用了20年的360安全卫士卸载了

我把用了 20 年的 360 安全卫士卸载了 是的,正如标题你看到的。 原因 偷摸安装自家的软件 莫名其妙安装...
再见zabbix!轻量级自建服务器监控神器在Linux 的完整部署指南

再见zabbix!轻量级自建服务器监控神器在Linux 的完整部署指南

再见 zabbix!轻量级自建服务器监控神器在 Linux 的完整部署指南 在日常运维中,服务器监控是绕不开的...
飞牛NAS中安装Navidrome音乐文件中文标签乱码问题解决、安装FntermX终端

飞牛NAS中安装Navidrome音乐文件中文标签乱码问题解决、安装FntermX终端

飞牛 NAS 中安装 Navidrome 音乐文件中文标签乱码问题解决、安装 FntermX 终端 问题背景 ...
阿里云CDN
阿里云CDN-提高用户访问的响应速度和成功率
随机文章
星哥带你玩飞牛NAS-1:安装飞牛NAS

星哥带你玩飞牛NAS-1:安装飞牛NAS

星哥带你玩飞牛 NAS-1:安装飞牛 NAS 前言 在家庭和小型工作室场景中,NAS(Network Atta...
星哥带你玩飞牛NAS硬件03:五盘位+N5105+双网口的成品NAS值得入手吗

星哥带你玩飞牛NAS硬件03:五盘位+N5105+双网口的成品NAS值得入手吗

星哥带你玩飞牛 NAS 硬件 03:五盘位 +N5105+ 双网口的成品 NAS 值得入手吗 前言 大家好,我...
支付宝、淘宝、闲鱼又双叕崩了,Cloudflare也瘫了连监控都挂,根因藏在哪?

支付宝、淘宝、闲鱼又双叕崩了,Cloudflare也瘫了连监控都挂,根因藏在哪?

支付宝、淘宝、闲鱼又双叕崩了,Cloudflare 也瘫了连监控都挂,根因藏在哪? 最近两天的互联网堪称“故障...
300元就能买到的”小钢炮”?惠普7L四盘位小主机解析

300元就能买到的”小钢炮”?惠普7L四盘位小主机解析

  300 元就能买到的 ” 小钢炮 ”?惠普 7L 四盘位小主机解析 最近...
我用AI做了一个1978年至2019年中国大陆企业注册的查询网站

我用AI做了一个1978年至2019年中国大陆企业注册的查询网站

我用 AI 做了一个 1978 年至 2019 年中国大陆企业注册的查询网站 最近星哥在 GitHub 上偶然...

免费图片视频管理工具让灵感库告别混乱

一言一句话
-「
手气不错
告别Notion焦虑!这款全平台开源加密笔记神器,让你的隐私真正“上锁”

告别Notion焦虑!这款全平台开源加密笔记神器,让你的隐私真正“上锁”

  告别 Notion 焦虑!这款全平台开源加密笔记神器,让你的隐私真正“上锁” 引言 在数字笔记工...
星哥带你玩飞牛NAS-14:解锁公网自由!Lucky功能工具安装使用保姆级教程

星哥带你玩飞牛NAS-14:解锁公网自由!Lucky功能工具安装使用保姆级教程

星哥带你玩飞牛 NAS-14:解锁公网自由!Lucky 功能工具安装使用保姆级教程 作为 NAS 玩家,咱们最...
星哥带你玩飞牛NAS-16:飞牛云NAS换桌面,fndesk图标管理神器上线!

星哥带你玩飞牛NAS-16:飞牛云NAS换桌面,fndesk图标管理神器上线!

  星哥带你玩飞牛 NAS-16:飞牛云 NAS 换桌面,fndesk 图标管理神器上线! 引言 哈...
星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛 NAS 硬件 02:某鱼 6 张左右就可拿下 5 盘位的飞牛圣体 NAS 前言 大家好,我是星...
零成本上线!用 Hugging Face免费服务器+Docker 快速部署HertzBeat 监控平台

零成本上线!用 Hugging Face免费服务器+Docker 快速部署HertzBeat 监控平台

零成本上线!用 Hugging Face 免费服务器 +Docker 快速部署 HertzBeat 监控平台 ...