Redis叢集之主從複製,讀寫分離(下)(六)
上一次呢我們講到了redis的叢集,還有redis的主從複製,讀寫分離的一些配置,那麼接下來就接著上次還未完結的內容
上一次呢講的是在正常的情況下redis服務在各個主機上的執行情況,那麼接下來就是要介紹不正常的情況了。
假如說我們的redis的主庫掛了或者是執行redis服務的伺服器掛了,那麼其餘的redis從庫是否會趁機上位還是忠於職守在slave的角色?那麼接下來就為大家揭曉
首先啟動redis服務,包括主庫與從庫
各個伺服器上的redis服務均啟動正常,那麼接下來就是模擬redis主庫宕機了
shutdown表示關閉redis服務
exit表示退出redis連線
那麼接下來就是檢視各個redis從庫的角色以及連線狀態了
我們可以看到,在從庫中還是可以拿到資料的,說明redis主庫掛了並不會影響redis從庫的執行。但是看到master_line_status為down的時候,就知道這個時候的主庫是掛了的,因為一開始的狀態是up
那麼如果redis主庫的服務有重新啟動了呢?redis從庫會不會再次連線上主庫?
首先啟動redis主庫,然後寫入資料,這個時候發現從庫的master_line_status的連線狀態都是up了,並且可以取到在redis主庫中寫入的資料
那麼這樣子是不是很不好啊,假如是電商網站,然後突然間redis主庫掛了,那麼這個時候就只有redis從庫服務在運行了。但是redis從庫是隻讀的是不是就無法寫入資料了,那麼客戶就無法下訂單了。那麼有沒有什麼方法,就是在redis主服務掛了之後我再從redis從庫服務中挑選出一個比較優秀的來接替主庫的位置
方案一:使用命令的方式
那麼接下來呢我們就學習一個新的命令
slaveof no one
可以看到,命令執行之後,就立刻趁機上位了,那麼另外一臺從庫是不是也要換一個新的老大啊
但是這個時候原來的redis主庫有殺回來了呢?這個時候是不是另外兩個就是有兩個redis主庫的服務了,但是原來的從庫並不會回到這個主庫上去,而是後面那兩臺自立規則。那麼這個時候是不是很不好啊,我們想要的是隻有一個redis主庫服務,那麼有沒有什麼解決方法呢?
那麼接下來就是終極的解決方案
方案二:哨兵模式
哨兵模式是反客為主的自動版,能夠jiankong 後臺主機是否故障,如果故障了根據投票數自動將從庫轉換為主庫
首先恢復原來的一主N從的環境
接下來就是配置了
在redis安裝目錄下新建sentinel.conf檔案,名字絕不能錯
編輯sentinel.conf檔案, sentinel monitor 被監控資料庫名字(自己起名字) 127.0.0.1 6379 1【上面最後一個數字1,表示主機掛掉後salve投票看讓誰接替成為主機,得票數多少後成為主機】
接下來就是啟動哨兵進行監控了,命令
redis-sentinel sentinel.conf
那麼這個時候就是哨兵開始監控了
首先模擬主庫宕機,關閉主庫,並且觀察哨兵輸出的日誌並且兩個從庫角色的變化
(這裡需要等待片刻才可看到結果)大家可以看到,埠號為6381的redis從庫立馬變成了主庫,而且埠號為6380的redis從庫就跟著埠號為6381混了。
那麼問題來了,如果原來的老大回來了呢,6381會不會讓位呢?
(這裡也許等待片刻)那麼結果是原來的redis服務就變成從庫了,連線著現在的埠號為6381的主庫了。
哨兵模式的缺點:由於所有的寫操作都是先在Master上操作,然後同步更新到Slave上,所以從Master同步到Slave機器有一定的延遲,當系統很繁忙的時候,延遲問題會更加嚴重,Slave機器數量的增加也會使這個問題更加嚴重。
OK,到這裡就是我們redis主從複製,讀寫分離的全部介紹了
如果大家覺得有哪些地方看不懂或者我的描述有問題的話請留言提醒我,謝謝