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正好輪訓到了主節點上。