此篇的前置原理爲,需要能安裝REDIS 服務器,並且配置主從關係, Redis 有兩種高可用, redis cluster 和 redis sentinel , 今天要說的是redis 的 sentinel, redis sentinel 是從redis 2.8開始提供的一個redis 高可用的功能,這裏有幾個問題
有人提出redis 是緩存式的數據庫,爲什麼還要高可用,直接重新啓動,利用本身的日誌進行恢復即可, 實際上這主要與redis所使用的場景有關,例如在架構設計中,redis 屬於與應用關聯性緊密的設計, 這樣的設計讓系統在高併發和高密度的訪問中游刃有餘,並且也是傳統數據庫和應用系統高併發中的一層緩衝,不少系統中設計的redis 是非常重要的,如果redis停止工作,則整體的應用就處於停擺的狀態,所以即使redis 可以快速重啓,讀入相關日誌,恢復到故障前的狀態,但有些應用設計爲低容忍, 則爲了保證業務redis 必然要設計成高可用的狀態.
首先安裝redis 配置好主從, 這裏已兩個節點爲例, redis 1 , redis 2 爲例,
redis 1
bind 0.0.0.0
port 6379
timeout 10
daemonize yes
loglevel notice
logfile "/redis_data/errorlog.log"
save 900 1
save 300 10
save 60 10000
dbfilename "dump.rdb"
dir "/redis_data"
masterauth "password"
replica-priority 100
requirepass "password"
maxmemory xxxxxxxkb
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
redis2
bind 0.0.0.0
port 6379
timeout 10
daemonize yes
loglevel notice
logfile "/redis_data/errorlog.log"
save 900 1
save 300 10
save 60 10000
dbfilename "dump.rdb"
dir "/redis_data"
masterauth "password"
replica-priority 100
requirepass "password"
maxmemory xxxxxxxkb
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
slaveof 192.168.198.100 6379
配置完成這裏就不在贅述,個體安裝redis數據庫的問題了,.
redis sentinel 節點本身安裝靈活,實際上不非要安裝在redis 數據庫本身的節點中,但大部分的習慣還是安裝在和redis的數據庫服務器中, Redis sentinel 本身是一個分佈式架構, 其中包含若干個sentinel節點和 redis 節點, 對於高可用來講, redis 的sentinel 應該至少爲 3 節點, 這也符合大多數原理, 但實際當中部分的redis sentinel 部署是兩個節點. 每個sentinel 節點對數據節點和其他的sentinel 節點進行監控. 當有節點失控後,sentinel會被觸發並和其他的sentinel節點協商來決定,並開始故障轉移,整個過程是完全自動的.
總結 sentinel 節點的功能
1定期監控sentinel節點定期檢測redis 數據節點,以及其他的sentinel節點
2 sentinel會將節點故障轉移的結果通知給應用
3 故障轉移從節點晉升爲主節點的工作也需要sentinel來進行設置.
下面是配置文件
port 26379
sentinel 訪問的端口號
daemonize yes
釋放在後端運行
pidfile "/var/run/redis-sentinel.pid"
logfile "/redis_data/sential.log"
日誌文件存放地
dir "/redis_data"
sentienl 數據目錄
sentinel monitor redis1 192.168.198.100 6379 1
sentinel 監控的主機地址,以及端口號,和幾個sentinel 節點來判斷redis主機失效是否切換.
sentinel down-after-milliseconds redis1 5000
多長時間無法連接到redis primary server 就開始準備切換
sentinel parallel-syncs redis 1
在有多副本的情況下,在主機切換後,有多少副本指向新的主
sentinel auth-pass redis1 1234.com
sentinel 之前進行認證的密碼
requirepass 1234.com
sentinel 和 redis之間訪問的密碼sentinel 有兩種部署方式
1 針對多組redis 來說,部署三個節點的 sentinel 即可, 可以通過三個一組的sentinel 節點來管理 多組 redis 主從複製
2 針對少量的redis 主從複製,將 sentinel 和 redis 部署在同一臺服務器
在已經運行的redis節點,運行sentinel 後, 日誌圖
實際上sentinel 在啓動後,本身的sentinel.conf 就會被改變,以上的信息是在啓動sentinel服務後,由sentinel 添加到 sentinel.conf 的文件中
sentinel 在遷移中的一些過程
下面是sentinel.c 的開頭, 其中傳給sentinel 的參數
其中定義了傳入參數中,如何標記當前節點的信息,傳入的二進制數中,
第一位 機器是否是master
第二位 機器釋放是slave
第三位 機器是否是sentinel
第四位 機器是否是主觀down
第五位 機器釋放是客觀down
第六位 sentinel 確認master down
第七位 failover 正在進行中
第八位 選擇哪個slave爲主
第九位 哪個新master發送slaveof 給其他從
第十位 從同步的進度
第十一位 新主的與從同步
第十二位 master 新主生效
第十三位 SCRIPT KILL already sent on -BUSY
在sentinal 中以後兩個關於redis 服務器的狀態的問題
SDOWN: subjectively down 主觀失效, 既當前的sentinel 對於redis服務器的狀態已經至爲不可用的狀態. 而 ODOWN: objectively down 的意思爲多數(至少不是一個)sentinel 認爲此節點的redis 已經失效.
當sentinel 產生了 objectively down 後就要進行failover的操作了.
那麼SDOWN 的狀態是從哪裏來的, 在REDIS 中主從服務器會建立TCP連接,並週期性的發送ping,默認爲1秒鐘的時間.在 down-after-milliseconds 時間內如果彼此之間有無法響應的情況,則會啓用 sdown, 如果sdown 爲主服務器,此時判斷出主DOWN的sentinel 會開始發送 is-master-down-by-addr 信息,當達到大多數sentinel 都確認後,就會產生ODOWN, 啓動FAILOVER操作
首先sentinel之間是怎麼進行互相溝通的
1 每個sentinel 在配置中都表明首次與REIDS 主進行溝通
2 每個sentinel都會發送自己的 hello 信息, 發送自己的ip 和 port
3 通過redis primary 這個介質, sentinel 之間進行了溝通
4 藉由 redis primary 與 SLAVE 之間的信息溝通,redis primary 也獲得了SLAVE的信息, sentinel 也就通過redis primary 獲得slave的信息,並開始進行溝通.
sentinel初始配置
port 26379
pidfile "/redis_data/sentinel.pid"
dir "/redis_data"
daemonize yes
protected-mode no
logfile "/redis_data/sentinel.log"
sentinel myid 2a9dca6062c5bc4d8811c614970c6aa1d38472b5
sentinel deny-scripts-reconfig yes
sentinel monitor redisMaster 192.168.198.101 6379 2
sentinel down-after-milliseconds redisMaster 1000
sentinel failover-timeout redisMaster 6000
sentinel client-reconfig-script redisMaster /redis_data/vip.sh
requirepass "1234.com"
# Generated by CONFIG REWRITE
maxclients 4064
運行後sentinel 添加的信息
sentinel auth-pass redisMaster 1234.com
sentinel config-epoch redisMaster 7
sentinel leader-epoch redisMaster 7
sentinel known-replica redisMaster 192.168.198.100 6379
sentinel known-replica redisMaster 192.168.198.102 6379
sentinel known-sentinel redisMaster 192.168.198.102 26379 711a3d1d1e216abc13c275de972f15307c4a7c30
sentinel known-sentinel redisMaster 192.168.198.101 26379 f698f72600e34df22b878a57a4583fa98200b1d9
sentinel current-epoch 7
IP 切換的腳本
#!/bin/bash
MASTER_IP=${6}
MY_IP='192.168.198.101' # 每個Server本身的IP
VIP='192.168.198.106' # VIP
NETMASK='24' # Netmask
INTERFACE='ens33' # 接口
if [ ${MASTER_IP} = ${MY_IP} ]; then
sudo /sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}
sudo /sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
exit 0
else
sudo /sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}
exit 0
fi
exit 1
大部分出問題的地方主要在切換的腳本
MASTER_IP=${6}, 下圖是配置文件的具體解釋, 在執行腳本時會傳遞幾個參數
1 master-name
2 role
3 state
4 from-ip
5 from-port
6 to-ip
7 to-port
那這裏就有問題了,在執行reconfig.sh 時是所有的sentinel 都執行嗎?
如果都執行執行幾遍.
實際上這個問題並不一定要去看源代碼,直接在reconfig 腳本中部署打印的語句到日誌中, 類似我們調試某些存儲過程的方式.
最後以我上面的配置, 在除primary節點上 reconfig 腳本執行了三次.
另外如何測試的問題, 當然可以通過命令來關閉REIDS , 但其實也有更好的方式來測試系統是否配置成功可以進行切換,
DEBUG sleep 秒 的方式可以讓主的redis 在你設置的時間無響應而觸發你切換.
