63 redis哨兵監控之理論簡介
什么是哨兵
master掛了如何辦?從機原地待命。此時數據只能讀取不能更新。因此需要：
吹哨人巡查監控后臺master主機是否故障,如果故障了根據投票數自動將某一個從庫轉換為新主庫,
哨兵的作用
1、監控redis運行狀態,包括master和slave
2、當master down機,能自動將slave切換成新master
如何使用哨兵
主從監控?監控主從redis庫運行是否正常
????????Sentinel 實時監控 Redis 的主從節點運行狀態，檢測節點是否宕機或失聯。
消息通知?哨兵可以將故障轉移的結果發送給客戶端
????????當發生主從切換后，Sentinel 會將新的主節點信息通知給客戶端或相關服務，確保其連接到正確的主節點。
故障轉移?如果Master異常,則會進行主從切換,將其中一個Slave作為新Master
????????Sentinel 發現主節點（Master）宕機，并經多個 Sentinel 實例協商確認后，會自動將其中一個從節點（Slave）提升為新的主節點，并將其他從節點重新配置為復制新的主節點。
配置中心?客戶端通過連接哨兵來獲得當前Redis服務的主節點地址
????????客戶端可以通過連接 Sentinel 獲取當前可用的主節點地址，而不需要手動修改配置，從而實現動態主節點發現。
64 redis哨兵監控之案例實操1
3個哨兵?自動監控和維護集群,不存放數據,只是吹哨人
1主2從 用于數據讀取和存放
為什么要有 3 個 Sentinel 哨兵？
1.防止一個哨兵掛了，無法實現監控
2.基數好投票
Redis Sentinel 使用一種簡單的共識機制來避免誤判【有時候主機并不是真死了，可能是網絡不好】。哨兵集群通過“投票”來決定主節點是否真的故障。這個過程稱為：
故障主觀判斷（sdown） → 故障客觀判斷（odown）
每個 Sentinel 實例獨立判斷主節點是否故障（sdown）
當大多數 Sentinel 都認為主節點不可用時，才會觸發故障轉移（odown）
Redis 集群中通常部署 3 個 Sentinel（哨兵），是為了實現高可用的主從切換機制。哨兵之間通過投票機制達成共識，判斷主節點是否真的故障，并協調自動故障轉移。3 個是最小可容忍 1 個故障的投票集，是安全性與資源使用的最佳平衡。
由于硬件問題，無法用6臺機子去模擬過程，因此6379：master,6390、6381：slave。同時三個哨兵和6379共用一個主機。
先看看/opt目錄下默認的sentinel.conf文件【哨兵配置文件】的內容
將此sentinel.conf文件拷貝到myredis文件夾下
重點參數項說明
bind：服務監聽地址,用于客戶端連接,默認本機地址
daemonize：是否以后臺daemon方式運行
protected-mode：安全保護模式
port：端口
logfile：日志文件路徑
pidfile：pid文件路徑? ? 用于指定 進程 ID 文件（PID 文件） 的保存路徑。
dir：工作目錄
設置要監控的Master服務器
sentinel monitor <master-name> <ip> <redis-port> <quorum>
| 參數 | 說明 |
|---|---|
<master-name> | 主節點的名稱（邏輯標識，可自定義） |
<ip> | 要監控的主節點的 IP 地址 |
<redis-port> | 主節點的端口 |
<quorum> | 最少有多少個 Sentinel 認為主節點掛了，才會進行故障轉移（投票數量） |
sentinel auth-pass <master-name> <password> 配置主節點認證密碼的重要命令，用于確保 Sentinel 在連接主節點時通過密碼驗證。
| 參數 | 說明 |
|---|---|
<master-name> | 與 sentinel monitor 中配置的主節點名稱保持一致 |
<password> | 主節點 Redis 的訪問密碼（即 requirepass 設置的密碼） |
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster myRedisPassword
這個配置告訴 Sentinel：
“連接并監控名為mymaster的主節點時，需要使用密碼myRedisPassword。”
61 redis哨兵監控之案例實操2?
我們知道,網絡是不可靠的,有時候一個sentinel會因為網絡堵塞而誤以為一個master redis已經死掉了,在sentinel集群環境下需要多個sentinel互相溝通來確認某個master是否真的死了,quorum這個參數是進行客觀下線的一個依據,意思是至少有quorum個sentinel認為這個master有故障,才會對這個master進行下線以及故障轉移。因為有的時候,某個sentinel節點可能因為自身網絡原因,導致無法連接master,而此時master并沒有出現故障,所以,這就需要多個sentinel都一致認為該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>:
- 客戶端重新配置主節點參數腳本
66 redis哨兵監控之案例實操3
如果你使用的是 redis-sentinel 可執行文件（或者你有一個指向 redis-server 的符號鏈接，名為 redis-sentinel），你可以通過以下命令來以 Sentinel 模式運行：
redis-sentinel /path/to/sentinel.conf
否則，你也可以直接使用 redis-server 可執行文件，并通過 Sentinel 模式啟動，如下所示：
redis-server /path/to/sentinel.conf -- sentinel
哨兵默認監聽 TCP 端口 26379，因此要讓哨兵正常工作，你的服務器必須開放 26379 端口，以接收來自其他哨兵實例 IP 地址的連接。否則，哨兵之間將無法通信，也無法就該執行什么操作達成一致，故障轉移也將無法進行。
本案例sentinel文件通用配置
由于機器硬件關系,我們的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
| 配置項 | 含義 |
|---|---|
bind 0.0.0.0 | 監聽所有網卡（對外可訪問） |
daemonize yes | 以守護進程方式運行（后臺運行） |
protected-mode no | 關閉保護模式（確保你已配置防火墻，否則不安全） |
port 26379 | Sentinel 的監聽端口，默認就是這個 |
logfile | 日志文件路徑（建議確保 /myredis 目錄存在） |
pidfile | PID 文件路徑（注意你原來寫的是 redis-sentine126379. pid，有空格和拼寫錯） |
dir | Sentinel 持久化信息的工作目錄 |
sentinel monitor | 配置要監控的主節點（名稱、IP、端口、投票數） |
sentinel auth-pass | Sentinel 連接主節點使用的認證密碼 |
sentinel26380.conf
sentinel26381.conf
請看一眼sentinel26379.conf、sentinel26380.conf、sentinel26381.conf我們自己填寫的內容
master主機配置文件說明
67 redis哨兵監控之案例實操4
哨兵內容部分
啟動3個哨兵，完成監控
redis-sentinel sentinel26379.conf -- sentinel
redis-sentinel sentinel26380.conf -- sentinel
redis-sentinel sentinel26381.conf -- sentinel
啟動3個哨兵后再測試一次主從復制
原有的master掛了
????????兩臺從機數據是否OK???????? ok
????????是否會從剩下的2臺機器上選出新的master ????????是，master變為6381
????????之前down機的master機器重啟回來,誰將會是新老大?會不會雙master沖突?? ? ? ? 重啟回來會變為從機。
69 reids哨兵監控之案例實操6
broken pipe
6379突然斷開后會報兩種錯誤：
6379斷開后，6380先是會報錯，但過一會又能正常使用
這兩種錯誤幾乎是一樣的原因
認識broken pipe
????????pipe是管道的意思,管道里面是數據流,通常是從文件或網絡套接字讀取的數據。當該管道從另一端突然關閉時,會發生數據突然中斷,即是broken.對于socket來說,可能是網絡被拔出或另一端
的進程崩潰
解決問題
????????其實當該異常產生的時候,對于服務端來說,并沒有多少影響。因為可能是某個客戶端突然中止了進程導致了該錯誤
總結 Broken Pipe
????????這個異常是客戶端讀取超時關閉了連接,這時候服務器端再向客戶端已經斷開的連接寫數據時就發生了broken pipe異常!
誰是master
6381被選為新master,上位成功,以前的6379從master降級變成了slave
6380還是slave,只不過換了個新老大6381(6379變6381),6380還是slave
注意！6379后續可能會變成從機,需要設置訪問新主機的密碼,請設置masterauth項訪問密碼為111111,不然后續可能報錯master_link_status:down
對比配置文件
由于主機從機的位置互換，檢查配置文件會發現里面有關主從機配置的參數也會發生改變：
文件的內容,在運行期間會被sentinel動態進行更改
Master-Slave切換后,master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變,即master_redis.conf中會多一行slaveof的配置,sentinel.conf的監控目標會隨之調換
)
