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的監控目標會隨之調換