Sentinel模式

Sentinel模式介紹

主從模式的弊端就是不具備高可用性，當master掛掉以後，Redis將不能再對外提供寫入操作，因此sentinel應運而生。

sentinel中文含義為哨兵，顧名思義，它的作用就是監控redis叢集的執行狀況

功能

1.監控（Monitoring）：
Sentinel會'不斷地檢查'你的主伺服器和從伺服器是否運作正常。(每秒一次ping)

2.提醒（Notification）：
當被監控的某個Redis伺服器出現問題時，Sentinel可以'通過API'向管理員或者其他應用程式傳送'通知'。

3.自動故障遷移（Automatic failover）：
#sentinel發現主伺服器是根據配置檔案發現的
一次故障轉移操作由以下步驟組成：
1.發現主伺服器已經進入'客觀下線狀態'。
2.基於Raft leader election協議，進行'投票選舉'
3.如果當選失敗，那麼在設定的故障遷移超時時間的兩倍之後，'重新嘗試當選'。如果當選成功，那麼執行以下步驟。
	1）選出一個從伺服器，並將它升級為主伺服器。(#多種選擇方法)
	2）向被選中的從伺服器傳送 'SLAVEOF NO ONE '命令，讓它轉變為主伺服器。
	3）通過'釋出與訂閱功能'，將更新後的配置傳播給所有其他Sentinel，其他Sentinel對它們自己的配置進行更新。
	4）向已下線主伺服器的從伺服器傳送'SLAVEOF命令'，讓它們去複製新的主伺服器。
	5）當所有從伺服器都已經開始複製新的主伺服器時
	6）叢集也會向客戶端'返回新主伺服器的地址'，使得叢集可以使用新主伺服器代替失效伺服器。
	
#sentinel選擇主庫的規則
1.在失效主伺服器屬下的從伺服器當中，那些被標記為主觀下線、已斷線、或者最後一次回覆PING命令的時間大於五秒鐘的從伺服器都會被淘汰。
2.在失效主伺服器屬下的從伺服器當中，那些與失效主伺服器連線斷開的時長超過down-after選項指定的時長十倍的從伺服器都會被淘汰。
3.在經歷了以上兩輪淘汰之後剩下來的從伺服器中，我們選出'複製偏移量'（資料量）（replication offset）最大的那個從伺服器作為新的主伺服器；如果複製偏移量不可用，或者從伺服器的複製偏移量相同，那麼帶有'最小執行ID'的那個從伺服器成為新的主伺服器。（#或最大優先順序）

#簡單來說，我們可以將Sentinel配置看作是一個帶有版本號的狀態。一個狀態會以最後寫入者勝出（last-write-wins）的方式（也即是，最新的配置總是勝出）傳播至所有其他Sentinel。
#sentinel僅僅解決了叢集的單點問題
 

特點

* sentinel模式是建立在'主從模式的基礎上'，如果只有一個Redis節點，sentinel就沒有任何意義
* 當master掛了以後，sentinel會在slave中選擇一個做為master，並'修改它們的配置檔案'，其他slave的配置檔案也會被修改，比如'slaveof屬性'會指向新的master
* 當master重新啟動後，它將不再是master而是'做為slave'接收新的master的同步資料(#以從庫身份加入)
* sentinel因為也是一個程序有掛掉的可能，所以sentinel也會啟動多個形成一個'sentinel叢集'
* 多sentinel配置的時候，'sentinel之間'也會自動監控
* 當主從模式配置'密碼'時，sentinel也會同步將配置資訊修改到配置檔案中，不需要擔心
* 一個sentinel或sentinel叢集可以管理'多個主從Redis'，多個sentinel也可以監控'同一個redis'
* sentinel最好不要和Redis部署在同一臺機器，不然Redis的伺服器掛了以後，sentinel也掛了

#sentinel的作用，必須在redis主從已經做好的前提下
 

工作機制

* 每個sentinel以'每10秒鐘一次'的頻率向它所知的master，slave以及其他sentinel例項傳送一個 PING 命令 
* 如果一個例項距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個例項會被這個sentinel'標記為主觀下線'。 
* 如果一個master被標記為主觀下線，則正在監視這個master的'所有sentinel'要以每秒一次的頻率確認master的確進入了主觀下線狀態
* 當有足夠數量的sentinel（大於等於配置檔案指定的值）在指定的時間範圍內確認master的確進入了主觀下線狀態， 則'master會被標記為客觀下線 '

* 在一般情況下， 每個sentinel會以每' 10 秒一次'的頻率向它已知的所有master，slave傳送 INFO 命令 
* 當master被sentinel標記為客觀下線時，sentinel向下線的master的所有slave傳送 INFO 命令的頻率會從 10 秒一次改為' 1 秒一次 '
* 若沒有'足夠數量'的sentinel同意master已經下線，master的客觀下線狀態就會被移除；
  若master重新向sentinel的 PING 命令返回'有效回覆'，master的主觀下線狀態就會被移除
  
 當使用sentinel模式的時候，客戶端就不要'直接連線'Redis，'而是連線'sentinel的ip和port，由sentinel來提供具體的可提供服務的Redis實現，這樣當master節點掛掉以後，sentinel就會感知並將新的master節點提供給使用者。 
 
Redis的Sentinel中關於'下線'（down）有兩個不同的概念：
	1）主觀下線（Subjectively Down， 簡稱 SDOWN）指的是'單個 Sentinel' 例項對伺服器做出的下線判斷。
	2）客觀下線（Objectively Down，簡稱 ODOWN）指的是'多個Sentinel例項'在對同一個伺服器做出SDOWN判斷，並且通過SENTINEL' is-master-down-by-addr'命令互相交流之後，得出的伺服器下線判斷。（一個 Sentinel可以通過向另一個Sentinel傳送SENTINEL is-master-down-by-addr命令來詢問對方是否認為給定的伺服器已下線。）
	
#sentinel通過ping命令判斷是否存活，通過訂閱傳送訊息，
#通過訂閱相同的slave，sentinel之間可以交流投票數
#leader sentinel終止故障轉移
 

Sentinel模式搭建

0.檢查主從狀態，根據主從狀態編輯配置檔案

1.安裝或選擇一臺Redis用來配置sentinel例項
2.編輯sentinel配置檔案(#編輯的時候註釋要去掉)
mkdir /service/redis/26379/
[root@db02 ~]# vim /service/redis/26379/sentinel.conf
#sentinel的埠
port 26379
daemonize yes
pidfile /service/redis/26379/sentinel.pid
logfile /service/redis/26379/sentinel.log
dir /service/redis/26379
bind 172.16.1.52 127.0.0.1
#主庫的ip 埠和sentinel的半數以上
sentinel monitor mymaster 172.16.1.52 6379 1
#主庫的密碼
sentinel auth-pass mymaster 123
#sentinel的ping的返回時間x,超過該時間則認為該例項下線
sentinel down-after-milliseconds mymaster 5000
#sentinel ping該下線主庫的從庫，從xx秒內返回pong的這些從庫中選一個主庫
sentinel failover-timeout mymaster 180000
#同時同步主庫的從庫的數量
sentinel parallel-syncs mymaster 1

3.啟動sentinel
[root@db02 ~]# redis-sentinel /service/redis/26379/sentinel.conf
4.關閉主庫Redis
[root@db02 ~]# redis-cli -a 123 -p 6302 shutdown
5.登入從庫，檢視主庫是誰
[root@db03 ~]# redis-cli -a 123 -p 6303
127.0.0.1:6303> info replication
6.修復壞掉的主庫，啟動
[root@db02 ~]# redis-server /service/redis/6302/redis.conf
7.登入該例項，檢視主從
[root@db02 ~]# redis-cli -a 123 -p 6302
127.0.0.1:6302> info replication

#6379 1
埠後面的這個數值取決於sentinel的數量，與投票有關（半數以上）
#主庫根據slave序號優先選擇誰為主庫
slave0:ip=172.16.1.53,port=6303,state=online,offset=23539,lag=1
slave1:ip=172.16.1.52,port=6302,state=online,offset=23539,lag=0

#根據偏移量和優先順序判斷誰為主庫
127.0.0.1:6302> info replication
slave_repl_offset:41850 （偏移量=資料量）
slave_priority:100 （優先順序越高，下次主庫就是誰）

sentinel日誌

[root@db02 ~]# tailf /service/redis/26379/sentinel.log

129161:X 06 Aug 13:45:55.330 # +monitor master mymaster 172.16.1.52 6379 quorum 1
129161:X 06 Aug 13:46:00.368 # +sdown master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.368 # +odown master mymaster 172.16.1.52 6379 #quorum 1/1
129161:X 06 Aug 13:46:00.368 # +new-epoch 3
129161:X 06 Aug 13:46:00.368 # +try-failover master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.369 # +vote-for-leader fda1d8e2784d51f26e24ae1d42a4a66c7eda0ece 3
129161:X 06 Aug 13:46:00.369 # +elected-leader master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.369 # +failover-state-select-slave master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.424 # -failover-abort-no-good-slave master mymaster 172.16.1.52 6379
129161:X 06 Aug 13:46:00.525 # Next failover delay: I will not start a failover before Thu Aug  6 13:52:00 2020

·       +reset-master ：主伺服器已被重置。
·       +slave ：一個新的從伺服器已經被 Sentinel 識別並關聯。
·       +failover-state-reconf-slaves ：故障轉移狀態切換到了 reconf-slaves 狀態。
·       +failover-detected ：另一個 Sentinel 開始了一次故障轉移操作，或者一個從伺服器轉換成了主伺服器。
·       +slave-reconf-sent ：領頭（leader）的 Sentinel 向例項傳送了 [SLAVEOF](/commands/slaveof.html) 命令，為例項設定新的主伺服器。
·       +slave-reconf-inprog ：例項正在將自己設定為指定主伺服器的從伺服器，但相應的同步過程仍未完成。
·       +slave-reconf-done ：從伺服器已經成功完成對新主伺服器的同步。
·       -dup-sentinel ：對給定主伺服器進行監視的一個或多個 Sentinel 已經因為重複出現而被移除 —— 當 Sentinel 例項重啟的時候，就會出現這種情況。
·       +sentinel ：一個監視給定主伺服器的新 Sentinel 已經被識別並新增。
·       +sdown ：給定的例項現在處於主觀下線狀態。
·       -sdown ：給定的例項已經不再處於主觀下線狀態。
·       +odown ：給定的例項現在處於客觀下線狀態。
·       -odown ：給定的例項已經不再處於客觀下線狀態。
·       +new-epoch ：當前的紀元（epoch）已經被更新。
·       +try-failover ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by the majority）。
·       +elected-leader ：贏得指定紀元的選舉，可以進行故障遷移操作了。
·       +failover-state-select-slave ：故障轉移操作現在處於 select-slave 狀態 —— Sentinel 正在尋找可以升級為主伺服器的從伺服器。
·       no-good-slave ：Sentinel 操作未能找到適合進行升級的從伺服器。Sentinel 會在一段時間之後再次嘗試尋找合適的從伺服器來進行升級，又或者直接放棄執行故障轉移操作。
·       selected-slave ：Sentinel 順利找到適合進行升級的從伺服器。
·       failover-state-send-slaveof-noone ：Sentinel 正在將指定的從伺服器升級為主伺服器，等待升級功能完成。
·       failover-end-for-timeout ：故障轉移因為超時而中止，不過最終所有從伺服器都會開始複製新的主伺服器（slaves will eventually be configured to replicate with the new master anyway）。
·       failover-end ：故障轉移操作順利完成。所有從伺服器都開始複製新的主伺服器了。
·       +switch-master ：配置變更，主伺服器的 IP 和地址已經改變。 這是絕大多數外部使用者都關心的資訊。
·       +tilt ：進入 tilt 模式。
·       -tilt ：退出 tilt 模式。

sentinel管理命令（不常用）

#連線sentinel管理埠
[root@db01 ~]# redis-cli -a 123 -p 26379

#檢測狀態，返回PONG(說明sentinel監控下，主庫狀態正常)
127.0.0.1:26379> ping
PONG
#列出所有被監視的主伺服器
127.0.0.1:26380> SENTINEL masters
#列出所有被監視的從伺服器
127.0.0.1:26380> SENTINEL slaves mymaster
#返回給定名字的主伺服器的IP地址和埠號
127.0.0.1:26380> SENTINEL get-master-addr-by-name mymaster
1) "172.16.1.51"
2) "6379
#重置所有名字和給定模式
127.0.0.1:26380> SENTINEL reset mymaster

#當主伺服器失效時，在不詢問其他Sentinel意見的情況下，強制開始一次自動故障遷移。
127.0.0.1:26380> SENTINEL failover mymaster

設定權重，指定主庫的優先順序

#檢視db02的權重
172.16.1.52:6379> CONFIG GET slave-priority
1) "slave-priority"
2) "100"

#修改db02的權重值為0
172.16.1.52:6379> CONFIG set slave-priority 0
OK

172.16.1.52:6379> CONFIG GET slave-priority
1) "slave-priority"
2) "0"

#權重值越低越不會優先切換為主庫

#強制開始一次自動故障遷移
127.0.0.1:26380> SENTINEL failover mymaster

#再次檢視，主庫為db03
172.16.1.53:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.16.1.52,port=6379,state=online,offset=71377,lag=0
slave1:ip=172.16.1.51,port=6379,state=online,offset=71377,lag=0
master_repl_offset:71514
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:70496
repl_backlog_histlen:1019