Redis5.0+哨兵模式+Keepalived实现高可用

Redis主备配置

原理：

从服务器向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存到内存中。

在BGSVAE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成之后，主服务器会将这段时间缓存的写指令再以redis协议的格式发给从服务器。

1.redis安装

$ tar xf redis-5.0.3.tar.gz

$ mv redis-5.0.3 redis

$ yum -y install gcc gcc-c++ jemalloc-devel

$ cd redis

$ make

2.配置主从

$ cp redis.conf redis_7000.conf

$ vim redis_7000.conf

    port 7000

    pidfile /var/run/redis_7000.pid

    logfile /var/log/7000.log

    dir ./7000



    # replicaof <masterip> <masterport>：主服务这句话注释，从服务配置的需要开启。配置主服务的ip的port。



    # 主端的密码

    masterauth

    # 客户端访问密码

    requirepass

3.配置哨兵模式

$ vim sentinel.conf

    daemonize yes

    logfile /var/log/redis-sentinel.log

    # 多少毫秒没有接收到主节点的反馈，认为主节点down

    sentinel down-after-milliseconds mymaster 60000

    # 哨兵监控主节点的IP和端口   1表示至少一个节点认为主节点down了，才开始选举新节点

    sentinel monitor mymaster 127.0.0.1 7000 1

    # failover过期时间

    sentinel failover-timeout mymaster 30000

    # 配置哨兵连接主节点的认证密码。（主节点配置的requirepass）

    sentinel auth-pass mymaster ypmdd21312@#asdhjs@#!

如果Master宕机切换到Slave上，直接向slave写数据，之后将slave的角色切换成Master，原来的master重新加入到主从中，成为slave，对数据不会有影响。

Redis启动的一些警告

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

警告：过量使用内存设置为0！在低内存环境下，后台保存可能失败。

$ vim /etc/sysctl.conf

    vm.overcommit_memory = 1

$ sysctl -p

4.检测

查看master或者slave状态

$ redis-cli -a 密码 （没有密码则忽略-a）

$ INFO REPLICATION

查看哨兵状态

cat /var/log/redis-sentinel.log

keepalived

1.安装keepalived服务

$ yum -y install keepalived

2.配置keepalived

$ vim /etc/keepalived/keepalived.conf

global_defs {

   router_id redis1

}



vrrp_instance VI_1 {

    state BACKUP

    nopreempt

    interface eth0

    virtual_router_id 51

    priority 100

    # 本机ip地址

    unicast_src_ip 10.13.2.230

    # 对端ip地址，必须写成三行的形式

    unicast_peer {

        10.13.14.196

    }

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

        10.13.171.98                #HAVIP

    }

}



virtual_server 10.13.171.98 6379 {

    delay_loop 3

    lb_algo rr

    lb_kind DR

    persistence_timeout 50

    protocol TCP



    real_server 10.13.2.230 6379 {

        weight 1

        TCP_CHECK {

            connect_timeout 3

        }

    }

    real_server 10.13.14.196 6379 {

        weight 1

        TCP_CHECK {

            connect_timeout 3

        }

    }

}

3.启动服务

$ systemctl start keepalived

4.测试

$ ip a

5.配置脚本

$ vim /etc/keepalived/keepalived.conf

···

    vrrp_script check_redis {

        script "/etc/keepalived/check_redis.sh"

        interval 3

    }

···

    vrrp_instance VI_1 {

        track_script {

            check_redis

        }

    }

$ vim /etc/keepalived/check_redis.sh

    #/bin/bash

    port=`ss -antp | grep 7000 | grep LISTEN | wc -l `

    if [ $port -eq 0 ];then

            systemctl stop keepalived

    fi

云上布置Keepalived的问题

# 本机ip地址

unicast_src_ip 10.13.2.230

# 对端ip地址，必须写成三行的形式

unicast_peer {

    10.13.14.196

}

路由交换层禁用了ARP的广播限制，造成keepalived主备无法通z过vrrp协议广播的方式进行通讯，造成了两端都会产生HAVIP。必须配置指定IP的两台服务器间进行通讯。

telnet+端口不成功

ping端口没有问题，但是telnet VIP + 服务端口会偶尔出现问题，telnet VIP +其他端口没有问题。

virtual_server 10.13.171.98 6379 {

    delay_loop 3

    #lb_algo rr

    #lb_kind DR

    persistence_timeout 50

    protocol TCP

因为用不到LVS的调度算法lb_algo和转发方式lb_kind,这两个会影响到telnet VIP+配置的端口。

原因：

因为如果采用了lvs的转发方式的话，以DR模式为例，直接将请求转发给了后端的真实服务器，但是目的ip为vip，后端的服务器上没有vip，所以导致请求无法响应。偶尔可以成功是因为rr正好轮训到了主节点上。

巴特西