孤傲的菜單
- Sentinel模式簡介
- 測試環境介紹
- Sentinel部署環境流程介紹
- 開始部署
-
-
- 對A機器的操作
- 對B機器的操作
-
- 開始測試
-
-
- 完成設想2
- 完成設想3
-
- 使用keepalived完成哨兵模式
- 需要特别注意防火牆在A、B伺服器中的配置
- 更多的指令可參考
Sentinel模式簡介
以下描述來自：https://www.cnblogs.com/xintiao-/p/10414742.html
Redis-Sentinel是redis官方推薦的高可用性解決方案，
當用redis作master-slave的高可用時，如果master本身當機，redis本身或者用戶端都沒有實作主從切換的功能。
而redis-sentinel就是一個獨立運作的程序，用于監控多個master-slave叢集，
自動發現master當機，進行自動切換slave > master。
sentinel主要功能如下：
- 不時的監控redis是否良好運作，如果節點不可達就會對節點進行下線辨別
- 如果被辨別的是主節點，sentinel就會和其他的sentinel節點“協商”，如果其他節點也人為主節點不可達，就會選舉一個sentinel節點來完成自動故障轉義
- 在master-slave進行切換後，master_redis.conf、slave_redis.conf和sentinel.conf的内容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目标會随之調換
測試環境介紹
測試環境為centos7.5
A機器ip：10.0.8.37
B機器ip：10.0.8.243
Redis版本：5.0.3
在這之前，我們分别在A機器和B機器上運作Redis服務，此刻他們均為master節點
Sentinel部署環境流程介紹
文字描述還可以參考：https://www.cnblogs.com/kevingrace/p/9004460.html
開始部署
如果你使用是的redis源代碼安裝形式安裝的Redis，那麼在解壓出來的目錄下，有一個名為sentinel.conf的配置檔案，該檔案就是用來配置sentinel的，拷貝一份，放到~目錄下
前提：無故障時A機器Redis充當master節點，B為slave節點（無論是使用.conf寫slave節點還是使用redis-cli配置均可）
首先做做一下我們的設想
- 設想2：此時A機器上面的Redis挂掉了，那麼B機器此時應當切換為master節點節點
- 設想3：過了一段時間A機器的Redis恢複了，B機器又應該變成slave節點
為了完成上面的設想，先來進行配置，然後再去測試是否成功
對A機器的操作
建立檔案夾redis_data
mkdir /home/zeng/redis_data
修改配置檔案sentinel.conf
daemonize yes
logfile "26379.log"
dir "/home/zeng/redis_data"
sentinel monitor mymaster 10.0.8.37 6379 2
用
redis-sentinel sentinel.conf
啟動A機器上的哨兵
檢視一下目前A機器的redis資訊
redis-cli info replication
可以看到如下
對B機器的操作
建立檔案夾redis_data
mkdir /home/zeng/redis_data
修改配置檔案sentinel.conf
daemonize yes
logfile "26379.log"
dir "/home/zeng/redis_data"
sentinel monitor mymaster 10.0.8.37 6379 2
用
redis-sentinel sentinel.conf
啟動A機器上的哨兵
注意這裡，在A和B機器上，都是同時監聽A機器上的redis是否有響應
redis-cli info replication
檢視一下目前A機器的Redis資訊，再過個幾秒運作，發現B機器的Redis從master自動切換成了slave節點
此時設想1已經成功
開始測試
完成設想2
執行
ps -ef|grep redis-server|grep -v grep|awk '{print $2}'|xargs sudo kill -9
指令，退出redis-server
在B機器上用
redis-cli info replication
檢視一下目前機器的Redis資訊
已經自動切換到了master節點
此時設想2已經成功
完成設想3
此時我們在B機器上設定一個值
在A機器上，重新開機redis
再次檢視A機器上的Redis資訊，發現此時，A是B的slave節點，此時也能取出之前設定的值
是以設想3，需要更改一下：
設想3：過了一段時間A機器的Redis恢複了，~~B機器又應該變成slave節點，~~A機器此時會作為B機器的備用節點存在，這樣才能使用故障時間内所存儲的資料
是以，之前的設想，變成了結論：
- 結論1：無故障時A機器Redis充當master節點，B為slave節點
- 結論2：此時A機器上面的Redis挂掉了，那麼B機器此時應當切換為master節點節點
- 結論3：過了一段時間A機器的Redis恢複了，B機器又應該變成slave節點；隻有此時B機器出故障，A才又會變成master節點
有興趣的朋友可以自己動手驗證以下以上的步驟
使用keepalived完成哨兵模式
keepalived相對于使用Sentinel來說會比較麻煩，監聽的腳本需要自己來寫
具體keepalived來做哨兵的實作可以參考：https://www.cnblogs.com/binchen-china/p/5593451.html
因為連結提供gayhub位址中的腳本源碼已經找不到，是以你隻能按照blog文中的内容來複制粘了
還有其他的keepalived完成哨兵模式有：
使用Python腳本，slave一直ping Redis伺服器，如果發現ping不同master，用指令調用
redis-cli slave none
形式來是目前節點變為master節點；如果恢複過來，用指令調用
redis-cli slave ip 6379
變成slave
需要特别注意防火牆在A、B伺服器中的配置
務必互相打開6379和26379
更多的指令可參考
官網文檔位址：http://redisdoc.com/topic/sentinel.html