redis進化四:redis的哨兵程序
主從複製完成後,無法實現主從的替換,需要引入redis的哨兵技術。
redis的哨兵邏輯
單獨啟動哨兵的程序,監聽某一個主從的結構,單獨連線主節點,利用info命令檢視主從狀態
rpc心跳(heartbeat)機制檢測主節點的存活;
哨兵叢集會對當前監聽的主從節構中出現的事故進行過半選舉的投票;
例如主節點的宕機會通過哨兵叢集進行過半選舉,從從節點中選出一個來接替稱為主節點。
哨兵(sentinel)監聽的結構圖
哨兵的安裝與測試
1、修改啟動哨兵的配置檔案
在redis根目錄的一個sentinel.conf(裡面配置了主從關係,主節點資訊)
通過:redis-sentinel sentinel.conf 啟動哨兵(這裡先不啟動)
需要註釋掉bind ,不需要繫結
protected-mode no 取消註釋,配置為no
配置埠(23680,26381)
sentinel monitor mymaster 127.0.0.1 6379 2
修改監聽主從的掛接配置
sentinel monitor:開始監聽主從結構中的主節點;
mymaster:監聽當前主從結構的代號(自定義)
ip:主節點所在的ip(使用對外能往返的主節點ip)
如果哨兵和主從節點在同一個機器,不要使用127.0.0.1,會造成程式碼訪問失效;
port:主節點埠號;
2:主觀下限票數(最少最少啟動的監聽主從結構的哨兵個數)
哨兵叢集某個節點也有宕機可能,一旦宕機會造成叢集投票情況的變化,
為了防止宕機過多最終導致整個哨兵的投票不可信(1個節點的投票不可信)
選舉新主節點失敗時的時間延遲(第二輪選舉和第一輪選舉的時間間隔)
失敗重新選舉
sentinel failover-timeout mymaster 10000(10s)
當前哨兵叢集對某一個事件的選舉如果不成立,將會根據這裡的配置毫秒數進行新的選舉
直到選舉成功為止。
同理配置第二 、第三個哨兵。
2、啟動哨兵程序,開啟監聽主從結構
#redis-sentinel 配置檔名
3、測試
a、kill掉主節點,哨兵能否高可用
6383被選舉為主節點
b、將宕機的主節點重啟
啟動後發現哨兵將重啟的主節點轉化成從節點提供主從服務
c、宕機掉一個哨兵
當兩個哨兵管理主從時,一個宕機,導致另一個的選舉沒有過半無法生效
quorum
最好啟動奇數個哨兵,每次至少有過半的哨兵選舉成功才行
4、重啟哨兵叢集步驟
a、先啟動三個主從節點
b、檢查主從關係
分別登陸3個客戶端,使用info replication檢視主從關係
c、檢視setinel配置檔案
如果和當前重新建立的主從結構一致,直接啟動哨兵
如果埠和和主從不一致,將埠修改後,把最後的配置內容刪除
d、啟動哨兵
redis-sentinel 哨兵配置檔案