前文我們了解了redis的常用數據類型相關命令的使用和說明，回顧請參考http://www.dbjr.com.cn/article/120364.htm 今天我們來聊一下redis的高可用組件sentinel；首先來回顧下redis的主從同步，主從同步最主要的作用是讓master的數據在其他服務器上實時存在副本，起到了備份的效果；對于redis的讀寫來說，主從架構能夠讓讀的請求分散到多個從服務器上，從而降低了單臺redis讀請求的io壓力，同時也提高了redis讀請求的并發(fā)能力；通常為了數據的一致性，從服務器一旦成為某一臺redis的slave，那么從服務器上之前有的數據會被清空，然后把master發(fā)送過來的數據應用到內存，從而實現和master數據一致；除此之外slave通常會是只讀屬性，也就說slave端只能執(zhí)行讀操作，寫操作會被拒絕，所以寫請求始終是由master來完成；

那么問題來了，對于這種主從復制架構的環(huán)境中，如果master宕機了，master宕機意味著整個系統(tǒng)將不能夠寫數據到redis,很顯然這種情況我們應該及時解決；怎么解決呢？有沒有這樣的一組件幫我們對master做實時的監(jiān)控，一旦發(fā)現master宕機就提升一個slave當選新的master，如果原master還有其他slave，將其他slave都從屬于新的master；除此之外它還應該讓系統(tǒng)在發(fā)生切換master時觸發(fā)報警通知，讓管理員盡快把壞掉的master修復上線；對，sentinel就有我們上述的這些功能，它能夠監(jiān)控主從同步集群中的master節(jié)點，在master發(fā)生宕機后能夠自動故障轉移，將提升一臺slave作為新的master，然后通知管理員；

　　Sentinel是一個分布式系統(tǒng)，我們可以在一個架構中運行多個sentinel，這些sentinel進程使用流言協(xié)議（gossipprotocols）來接收關于 Master是否下線的信息，并使用投票協(xié)議(Agreement Protocols)來決定是否執(zhí)行自動故障遷移,以及選擇哪個 Slave 作為新的 Master。每個sentinel進程會向其他sentinel進程、master、slave定時發(fā)送消息，以確保對方是否”活”著，如果發(fā)現對方在指定配置時間(可配置的)內未得到回應，則暫時認為對方已掉線，也就是所謂的”主觀認為宕機” ，英文名稱：Subjective Down，簡稱 SDOWN。有主觀宕機，肯定就有客觀宕機。

當多個sentinel進程中多數的sentinel進程在對 Master 做出 SDOWN 的判斷，并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下線判斷，這種方式就是“客觀宕機”，英文名稱是：Objectively Down， 簡稱 ODOWN。通過一定的 vote 算法，從剩下的 slave 從服務器節(jié)點中，選一臺提升為 Master 服務器節(jié)點，然后自動修改相關配置，并開啟故障轉移（failover）。

　　配置使用sentinel

　　環(huán)境說明

　　架構圖

　　提示：從上面的架構圖可以知道，首先我們必須要有一個主從架構的集群，然后在部署sentinel 來對主從同步集群做監(jiān)控；

　　redis主從復制集群搭建

　　1、在192.168.0.41/42/43上安裝redis，可以使用yum安裝，也可以使用編譯安裝，redis安裝請參考http://www.dbjr.com.cn/article/79096.htm

　　2、配置192.168.0.41/42/43上的redis監(jiān)聽在非本機127.0.0.1上并配置42/43上的redis從屬于192.168.0.41

　　master

　　slave01

　　slave02

　　提示：redis支持在線修改配置，保存配置到配置文件；SLAVEOF 指令用于指定redismaster的ip地址和端口，表示把該redis配置成對應master的slave角色；CONFIG REWRITE是把我們的配置保存到配置文件；

　　在master上查看是否有兩個從節(jié)點連接到master

　　驗證：在master上寫數據，看看是否能夠及時同步到兩個slave上？

　　提示：可以看到在主庫上寫數據，從庫上能夠及時的同步主庫上的數據；到此redis的主從集群就搭建完畢了；

　　配置sentinel，讓其監(jiān)控master

　　提示：三個sentinel的配置都是一樣的，這里需要明確指定監(jiān)控主從同步集群的master的ip地址和端口，以及有效法定票數，有效法定票數指的是至少有多少個sentinel主觀認為master down了，然后才觸發(fā)選舉新master操作；通常在這種流言協(xié)議中，一般都是大于集群半數，如果是3臺sentinel，至少要2臺主觀認為master宕機，才開始觸發(fā)選舉新master；如果是5臺，那至少要3臺；如果master配置的有認證密碼，我們還需要在sentinel中指定認證密碼；

　　sentinel配置文件說明

　　bind：該指令和redis配置文件中的bind是同樣的用法，用于指定sentinel的監(jiān)聽地址；默認不指定，監(jiān)聽本機所有可用地址；

　　protected-mode：指定是否開啟保護模式；

　　port：用于指定sentinel的監(jiān)聽端口；默認是26379

　　daemonize：用于指定sentinel是否運行為守護進程，yes表示運行為后臺守護進程；no表示不運行為守護進程，直接在前臺運行；

　　pidfile：指定pid文件路徑；

　　logfile：指定日志文件路徑；

　　dir：指定sentinel的工作路徑；

　　sentinel monitor <master-name> <ip> <redis-port> <quorum>：用于指定監(jiān)控master節(jié)點的ip地址和端口以及有效法定票數；其中<master-name>是給監(jiān)控的master一個名稱，可以隨便寫，起標識的作用；<quorum>表示sentinel集群的quorum機制，即至少有quorum個sentinel節(jié)點同時判定主節(jié)點故障時，才認為其真的故障；

　　sentinel auth-pass <master-name> <password>：指定master認證密碼；通常都需要設置密碼，并且master的密碼和slave的密碼應該是一樣；

　　sentinel down-after-milliseconds <master-name> <milliseconds>：配置監(jiān)控到指定的集群的主節(jié)點異常狀態(tài)持續(xù)多久方才將標記為“故障”；

　　sentinel parallel-syncs <master-name> <numslaves>：指在failover過程中，能夠被sentinel并行配置的從節(jié)點的數量；

　　sentinel failover-timeout <master-name> <milliseconds>：sentinel必須在此指定的時長內完成故障轉移操作，否則，將視為故障轉移操作失?。?/p>

　　sentinel notification-script <master-name> <script-path>：通知腳本，此腳本被自動傳遞多個參數；

　　了解了sentinel的配置文件，接下我們把3臺sentinel都啟動起來

　　master

　　slave01

　　slave02

　　提示：從上面的信息可以看到3個sentinel都監(jiān)控master的ip地址和端口，其實他們3個的配置文件都是一樣的；

　　查看sentinel日志

　　提示：從上面的日志信息可以了解到sentinel監(jiān)控的master是192.168.0.41：6379；并且有兩個slave分別是192.168.0.42：6379和192.168.0.43：6379；

　　查看sentinel狀態(tài)

　　提示：它提示我們開啟了保護模式；

　　關閉保護模式

　　重啟sentinel，再次查看sentinel狀態(tài)

[root@master ~]# systemctl restart redis-sentinel.service
[root@master ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port 
LISTEN 0 511 *:26379 *:* 
LISTEN 0 511 *:6379 *:* 
LISTEN 0 128 *:22 *:* 
LISTEN 0 100 127.0.0.1:25 *:* 
LISTEN 0 511 :::26379 :::* 
LISTEN 0 128 :::22 :::* 
LISTEN 0 100 ::1:25 :::* 
[root@master ~]# redis-cli -h 192.168.0.41 -p 26379 
192.168.0.41:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3
192.168.0.41:26379> info clients
# Clients
connected_clients:3
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
192.168.0.41:26379> CLIENT LIST
id=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publish
id=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
192.168.0.41:26379>

　　提示：從上面的狀態(tài)信息可以看到當前sentinel監(jiān)控的master是出于正常ok狀態(tài)，有兩個slave和3個sentinel；對于192.168.0.41：26379目前有3個客戶端連接，二個是sentinel，一個本機；到此3臺sentinel搭建啟動完成；

　　驗證：把master宕機，看看sentinel是否將在兩個從節(jié)點選舉一個為新master？是否將另外一個slave重新指向新master？

　　在slave01上查看主從同步信息

　　提示：第一次查看只是告訴我們master宕機了，第二次查看就告訴我們當前節(jié)點為master，并且擁有一個slave節(jié)點，這說明已經完成了故障轉移，slave01已經被提升為新的master了；

　　在192.168.0.43上查看主從信息，看看是否指向新的master？

　　提示：在slave02上看主從同步信息，可以看到slave02已經從屬新master了；

　　查看故障轉移時 sentinel日志

　　提示：從上面的日志信息可以了解到，在從sdown到odown后，就會觸發(fā)vote算法開始選舉leader；然后將原master降級為slave，然后將選舉出來的leader原salve屬性去除（slaveof no one）;然后提升新master，然后將剩下的slave重新配置新master為主；最后是切換master，開始新的監(jiān)控；

　　查看故障 轉移后的 redis 配置文件

　　提示：故障轉移后 redis.conf 中的 slaveof 行的 master IP 會被修改，sentinel.conf 中的 sentinel monitor IP 會被修改。同時在sentinel配置文件的末尾還會有添加known-slave和known-sentinel等信息；

　　修復舊master 讓其重新上線

　　提示：把原master啟動后，它自動就成為了新主的slave；這主要是因為sentinel在故障轉移時把其配置文件中的slaveof 修改成新的master地址了；

　　在新master上查看主從同步信息

　　提示：在沒有恢復原master時，在新master上查看主從同步信息，只能看到一個salve，啟動原master后，在看就有兩個slave是在線；

總結

到此這篇關于Redis服務之高可用組件sentinel的文章就介紹到這了,更多相關Redis服務之高可用組件sentinel內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論