1)Redis介紹及部署在CentOS7上(一)html
2)Redis指令與數據結構(二)mysql
3)Redis客戶端鏈接以及持久化數據(三)redis
4)Redis高可用之主從複製實踐(四)sql
5)Redis高可用之哨兵模式Sentinel配置與啓動(五)服務器
6)Redis高可用之集羣配置(六)微信
上一篇咱們已經介紹了Redis的主從複製,傳送門:《Redis高可用之主從複製實踐(四)》,想必你們對redis已經有一個概念了,那麼問題來了,若是redis主從複製的master服務器掛掉了,那麼總體redis就崩潰了,由於master沒法進行寫數據,致使slave中沒法更新數據。網絡
那麼爲了解決這個問題咱們就須要有一種方案讓redis宕機後能夠自動進行故障轉移,還好redis給咱們提供一種高可用解決方案 Redis-Sentinel。Redis-sentinel自己也是一個獨立運行的進程,它能監控多個master-slave集羣,發現master宕機後能進行自動切換。Sentinel能夠監視任意多個主服務器數據結構
以及主服務器屬下的從服務器,並在被監視的主服務器下線時,自動執行故障轉移操做。架構
既然有這麼好的解決方案,那麼咱們就來看看如何在咱們的服務器上進行配置asp.net
一、環境配置
第一:準備3臺服務器,此處個人sentinel就直接放在原先的服務器上
主機說明 | 主機IP | 端口 | sentinel端口 |
master | 192.168.250.132
|
7000 |
26379 |
slave | 192.168.250.133 | 7001 | 26380 |
slave | 192.168.250.134 |
7002
|
26381 |
此處要說明一個問題,我這邊的sentinel採用的是集羣部署的方式,而不是單點,想必你們也知道單點會存在不少的問題,好比:
1):當sentinel進程宕掉後(sentinel自己也有單點問題,single-point-of-failure)整個集羣系統將沒法按照預期的方式運行;
2):若是隻有一個sentinel進程,若是這個進程運行出錯,或者是網絡堵塞,那麼將沒法實現redis集羣的主備切換(單點問題)。
若是有多個sentinel,redis的客戶端能夠隨意地鏈接任意一個sentinel來得到關於redis集羣中的信息;即便有一些sentinel進程宕掉了,依然能夠進行redis集羣的主備切換;
二、建立sentinel配置文件
進入 132 服務器的redis文件夾下,咱們建立一個文件名爲 sentinel-26379.conf 配置文件,文件內容以下:
port 26379 daemonize yes logfile "26379.log" dir "./" sentinel monitor mymaster 192.168.250.132 7000 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 15000 sentinel auth-pass mymaster 123 bind 192.168.250.132 127.0.0.1
那麼133與134服務器下的redis文件夾中咱們也建立相同的sentinel 配置文件,但主要修改一下端口26380/26381以及bin綁定的數據。
看到這裏你們由於會對上面的配置有些疑惑,那我分別介紹一下參數的含義:
像 port、daemonize、logfile、dir、bind 這些我就不介紹了,以前也介紹過了,這邊重點介紹一下sentinel的配置
sentinel monitor <master-name> <ip> <redis-port> <quorum> 告訴sentinel去監聽地址爲ip:port的一個master,這裏的master-name能夠自定義,quorum是一個數字,指明當有多少個sentinel認爲一個master失效時,master纔算真正失效 sentinel auth-pass <master-name> <password> 設置鏈接master和slave時的密碼,注意的是sentinel不能分別爲master和slave設置不一樣的密碼,所以master和slave的密碼應該設置相同。 sentinel down-after-milliseconds <master-name> <milliseconds> 這個配置項指定了須要多少失效時間,一個master纔會被這個sentinel主觀地認爲是不可用的。 單位是毫秒,默認爲30秒 sentinel parallel-syncs <master-name> <numslaves> 這個配置項指定了在發生failover主備切換時最多能夠有多少個slave同時對新的master進行 同步,這個數字越小,完成failover所需的時間就越長,可是若是這個數字越大,就意味着越 多的slave由於replication而不可用。能夠經過將這個值設爲 1 來保證每次只有一個slave 處於不能處理命令請求的狀態。 sentinel failover-timeout <master-name> <milliseconds> failover-timeout 能夠用在如下這些方面: 1. 同一個sentinel對同一個master兩次failover之間的間隔時間。 2. 當一個slave從一個錯誤的master那裏同步數據開始計算時間。直到slave被糾正爲向正確的master那裏同步數據時。 3.當想要取消一個正在進行的failover所須要的時間。 4.當進行failover時,配置全部slaves指向新的master所需的最大時間。不過,即便過了這個超時,slaves依然會被正確配置爲指向master,可是就不按parallel-syncs所配置的規則來了。
配圖以下:
這樣子你們也能明白,那麼接下來咱們就要開始啓動咱們的sentinel啦,固然前提你們要先把redis主從複製開啓。
sentinel 運行命令以下:
./src/redis-sentinel sentinel-26379.conf ./src/redis-sentinel sentinel-26380.conf ./src/redis-sentinel sentinel-26381.conf
運行完後咱們再來看看sentinel-263779.conf的配置,發現配置文件被重寫了,從內容能夠看出有哪些slave和sentinel
內容已經配置完畢,如今咱們進行一下故障轉移吧,
三、故障轉移
咱們關閉master主節點,固然我演示的項目中master服務器是134,由於我以前有測試過,所以你們在操做的時候能夠按照本身機器上的爲主。
第一步:咱們關閉134的redis,等待一會,咱們再查看一下sentinel的日誌。咱們經過日誌來分析一下自動故障轉移的流程
=======================134master發現不能用
40325:X 09 Jan 2019 16:46:09.920 # +sdown master mymaster 192.168.250.134 7002
=======================投票後有兩個sentinel發現master不能用
40325:X 09 Jan 2019 16:46:10.005 # +odown master mymaster 192.168.250.134 7002 #quorum 2/2
=======================當前配置版本被更新
40325:X 09 Jan 2019 16:46:10.005 # +new-epoch 2
=======================達到故障轉移failover條件,正等待其餘sentinel的選舉
40325:X 09 Jan 2019 16:46:10.005 # +try-failover master mymaster 192.168.250.134 7002
=======================進行投票選舉slave服務器
40325:X 09 Jan 2019 16:46:10.006 # +vote-for-leader 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.007 # f53245a5100693311aeaf090b903de8587b3743a voted for 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.008 # c8e067032a78eafcdca9636cb4d9777b492daea6 voted for 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.077 # +elected-leader master mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.077 # +failover-state-select-slave master mymaster 192.168.250.134 7002
=======================選擇一個slave當選新的master
40325:X 09 Jan 2019 16:46:10.178 # +selected-slave slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
=======================把選舉出來的slave進行身份master切換
40325:X 09 Jan 2019 16:46:10.178 * +failover-state-send-slaveof-noone slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.241 * +failover-state-wait-promotion slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.393 # +promoted-slave slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
=======================把故障轉移failover改變reconf-slaves
40325:X 09 Jan 2019 16:46:10.393 # +failover-state-reconf-slaves master mymaster 192.168.250.134 7002
=======================sentinel發送slaveof命令把133從新同步132master
40325:X 09 Jan 2019 16:46:10.448 * +slave-reconf-sent slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002
=======================重寫rewrite master地址到sentinel配置文件中
40325:X 09 Jan 2019 16:46:10.738 * +sentinel-address-switch master mymaster 192.168.250.134 7002 ip 192.168.250.132 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea6 40325:X 09 Jan 2019 16:46:10.907 * +sentinel-address-switch master mymaster 192.168.250.134 7002 ip 192.168.250.138 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea6
=======================離開不可用的master 40325:X 09 Jan 2019 16:46:11.135 # -odown master mymaster 192.168.250.134 7002
=======================slave被從新配置爲另一個master的slave,但數據還未發生
40325:X 09 Jan 2019 16:46:11.407 * +slave-reconf-inprog slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002
=======================與master進行數據同步
40325:X 09 Jan 2019 16:46:11.407 * +slave-reconf-done slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002
=======================故障轉移完成
40325:X 09 Jan 2019 16:46:11.508 # +failover-end master mymaster 192.168.250.134 7002
=======================master地址發生改變
40325:X 09 Jan 2019 16:46:11.508 # +switch-master mymaster 192.168.250.134 7002 192.168.250.132 7000
=======================檢測slave並添加到slave列表
40325:X 09 Jan 2019 16:46:11.508 * +slave slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.132 7000
40325:X 09 Jan 2019 16:46:11.508 * +slave slave 192.168.250.134:7002 192.168.250.134 7002 @ mymaster 192.168.250.132 7000
40325:X 09 Jan 2019 16:46:12.475 * +sentinel-address-switch master mymaster 192.168.250.132 7000 ip 192.168.250.132 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea
自此故障轉移完成,咱們查看一下132,如今132已經變成master了,而且 133和134變爲了slave。
咱們再來對比一下 sentinel-26379.conf的配置文件數據,發現已經修改了。自此failover完成。
redis的高可用已經講解了兩大部分了,剩餘的集羣部署將是咱們的最後的步驟,也是關鍵的。下一篇將會開啓集羣的配置。
若是上述有問題,歡迎你們指教。
參考文章:
《Redis及其Sentinel配置項詳細說明》:https://blog.csdn.net/a1282379904/article/details/52335051
《Redis 複製、Sentinel的搭建和原理說明》:https://www.cnblogs.com/zhoujinyi/p/5570024.html
《Redis Sentinel高可用架構》:https://www.cnblogs.com/gomysql/p/5040847.html
asp.net core 交流羣:787464275 歡迎加羣交流
若是您認爲這篇文章還不錯或者有所收穫,您能夠點擊右下角的【推薦】按鈕精神支持,由於這種支持是我繼續寫做,分享的最大動力!
微信公衆號:歡迎關注 QQ技術交流羣: 歡迎加羣