是什麼 吹哨人巡查監控後臺master主機是否故障,如果故障了根據投票數自動將某一個從庫轉為新主庫,繼續對外服務 能幹嘛 主從監控:監控主從Redis庫運行是否正常 消息通知:哨兵可以將故障轉移的結果發送給客戶端 故障轉移:如果Master異常,則會進行主從切換,將其中一個Slave作為新Maste ...
吹哨人巡查監控後臺master主機是否故障,如果故障了根據投票數自動將某一個從庫轉為新主庫,繼續對外服務
能幹嘛
-
主從監控:監控主從Redis庫運行是否正常
-
消息通知:哨兵可以將故障轉移的結果發送給客戶端
-
故障轉移:如果Master異常,則會進行主從切換,將其中一個Slave作為新Master
-
配置中心:客戶端通過連接哨兵來獲得當前Redis服務的主節點地址
案例演示
架構
-
3個哨兵:自動監控和維護集群,不存放數據,只是吹哨人
-
1主2從:用於數據讀取和存放
sentinel.conf
重點參數:
-
bind:服務監聽地址,用於客戶端連接,預設本機地址
-
daemonize:是否以後臺daemon方式運行
-
protected-mode:安全保護模式
-
port:埠
-
logfile:日誌文件路徑
-
pidfile:pid文件路徑
-
dir:工作目錄
-
sentinel monitor < master-name > < ip > < redis-port > < quorum >:
-
設置要監控的Master伺服器
-
quorum表示最少有幾個哨兵認可客觀下線,同意故障遷移的法定票數
-
-
sentinel auth-pass < master-name > < password >:Master設置了密碼,連接Master服務的密碼
其它參數:
-
sentinel down-after-milliseconds < master-name > < milliseconds >:指定多少毫秒之後,主節點沒有應答哨兵,此時哨兵主觀上認為主節點下線
-
sentinel parallel-syncs < master-name > < nums >:表示允許並行同步的slave個數,當Master掛了後,哨兵會選出新的Master,此時,剩餘的slave會向新的master發起同步數據
-
sentinel failover-timeout < master-name > < milliseconds >:故障轉移的超時時間,進行故障轉移時,如果超過設置的毫秒,表示故障轉移失敗
-
sentinel notification-script < master-name > < script-path > :配置當某一事件發生時所需要執行的腳本
-
sentinel client-reconfig-script < master-name > < script-path >:客戶端重新配置主節點參數腳本
本次案例配置
由於硬體配置關係,本次3個哨兵都配置進同一臺機器(192.168.111.169)
sentinel26379.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
sentinel26380.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
sentinel26381.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
-
先啟動一主兩從3個Redis實例,測試正常的主從複製
設置好 replicaof < masterip> < masterport>
設置好masterauth項訪問密碼,(6379後續可能會變成從機,故需要設置訪問新主機的密碼)不然後續可能報錯 master_link_status:down
-
再啟動3個哨兵,完成監控
redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel
-
手動關閉6379伺服器,模擬master掛了。
兩台從機數據是否OK?OK!
是否會從剩下的2台機器上選出新的master?會!
之前宕機的master機器重啟回來,誰將是新的老大?會不會雙master衝突?已經被篡位了,回來變小弟!
-
關閉6379後另外兩個伺服器可能會出現以下兩種情況中的一種:
然後過幾秒鐘就會恢復正常,兩台剩餘從機中會選出新的master
by the way
配置文件內容在運行期間會發生改變,被sentinel動態更改了。
Master-Slave切換後,master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變,即master_redis.conf中會多一行slaveof的配置,sentinel.conf的監控目標會隨之調換。
備註
-
哨兵本身不涉及業務,不涉及高併發,壓力不大。
-
生產都是不同機房不同伺服器,很少出現3個哨兵全掛掉的情況。
-
可以同時監控多個master,一行一個。
哨兵的運行流程和選舉原理
當一個主從配置中的master失效之後,sentinel可以選舉出一個新的master用於自動接替原master的工作,主從配置中的其他redis伺服器自動指向新的master同步數據。一般建議sentinel採取奇數台,防止某一臺sentinel無法連接到master導致誤切換。
過程:
-
三個哨兵一主二從,正常運行中。。。。。。
-
SDown主觀下線(Subjectively Down)
SDown(主觀不可用)是單個sentinel自己主觀上檢測到的關於master的狀態,從sentinel的角度來看,如果發送了PING心跳後,在一定時間內沒有收到合法的回覆,就達到了SDown的條件。
sentinel配置文件中的down-after-milliseconds設置了判斷主觀下線的時間長度。
說明:
所謂主觀下線(Subjectively Down, 簡稱 SDOWN)指的是單個Sentinel實例對伺服器做出的下線判斷,即單個sentinel認為某個服務下線(有可能是接收不到訂閱,之間的網路不通等等原因)。主觀下線就是說如果伺服器在[sentinel down-after-milliseconds]給定的毫秒數之內沒有回應PING命令或者返回一個錯誤消息, 那麼這個Sentinel會主觀的(單方面的)認為這個master不可以用了,o(╥﹏╥)o
sentinel down-after-milliseconds < masterName > < timeout >
表示master被當前sentinel實例認定為失效的間隔時間,這個配置其實就是進行主觀下線的一個依據
master在多長時間內一直沒有給Sentine返回有效信息,則認定該master主觀下線。也就是說如果多久沒聯繫上redis-servevr,認為這個redis-server進入到失效(SDOWN)狀態。
-
ODown客觀下線(Objectively Down)
ODOWN需要一定數量的sentinel,多個哨兵達成一致意見才能認為一個master客觀上已經宕掉。
說明:
四個參數含義:
masterName是對某個master+slave組合的一個區分標識(一套sentinel可以監聽多組master+slave這樣的組合)
quorum這個參數是進行客觀下線的一個依據,法定人數/法定票數
意思是至少有quorum個sentinel認為這個master有故障才會對這個master進行下線以及故障轉移。因為有的時候,某個sentinel節點可能因為自身網路原因導致無法連接master,而此時master並沒有出現故障,所以這就需要多個sentinel都一致認為該master有問題,才可以進行下一步操作,這就保證了公平性和高可用。
-
選出領導者哨兵(哨兵中選出兵王)
當主節點被判斷客觀下線後,各個哨兵節點會進行協商,先選舉出一個領導者哨兵節點(兵王)並由該領導者節點,進行failover(故障遷移)。
哨兵領導者(兵王)是如何選出來的?Raft演算法。
監視該主節點的所有哨兵都有可能被選為領導者,選舉使用的演算法是Raft演算法;Raft演算法的基本思路是先到先得:
即在一輪選舉中,哨兵A向B發送成為領導者的申請,如果B沒有同意過其他哨兵,則會同意A成為領導者。
-
由兵王開始推動故障切換流程並選出一個新的master
-
新主登基:某個slave被選中稱為新Master。
規則:剩餘slave節點健康的前提下:
-
redis.conf文件中,優先順序slave-priority或者replica-priority最高的從節點(數字越小優先順序越高)
-
複製偏移位置offset最大的從節點
-
最小的Run ID從節點(字典順序,ASCII碼)
-
-
群臣俯首:一朝天子一朝臣,換個碼頭重新拜
執行slaveof no one命令讓選出來的從節點成為新的主節點,並通過slaveof命令讓其他節點成為其從節點。
sentinel leader會對選舉出的新Master執行slaveof no one操作,將其提升為Master節點。
sentinel leader向其他slave發送命令,讓剩餘的slave成為新的Master節點的slave。
-
舊主拜服:老Master回來也得低頭
將之前已下線的老Master設置為心選出的新Master的從節點,當老Master重新上線後,它會成為新Master的從節點。
sentinel leader會讓原來的Master降級為slave並恢復正常工作。
上述的failover操作均由sentinel自己獨立完成,完全無需人工干預。
-
哨兵使用建議
-
哨兵節點的數量應該為多個,哨兵本身應該集群,保證高可用。
-
哨兵節點的數量應該是奇數
-
各個哨兵節點的配置應一致
-
如果哨兵節點部署在Docker等容器裡面,尤其要註意埠的正確映射
-
哨兵集群+主從複製 並不能保證數據零丟失!承上啟下引出集群!