Redis主從切換

  • 2019 年 10 月 8 日
  • 筆記

Redis主從複製實際上就是將主Redis節點的數據,複製到其他從Redis節點去進行存儲,當主節點因為出現異常宕機後,如何將從節點切換成主節點繼續提供服務呢?Redis主從切換主要分為以下兩種方式:手動切換以及哨兵模式。今天我們一起來看看Redis在出現故障是如何進行主從切換繼續提供服務的。

題外話

首先開始講主從切換前,先補充昨天遺漏的一個知識點:我們啟動主節點和啟動不同的從節點啟動間隔時間不能太短,因為主節點需要將數據同步到不同的從節點會耗費大量資源。

主從手動切換

當主節點出現宕機時,這時候最簡單的方式可以使用主從手動切換的方式,手動的將一台從節點切換成主節點,所以我們需要人工干預手動設置,最關鍵在手動切換的過程中會造成Redis服務不可用。所以說主從手動切換的方案不是一個合適的主從切換方案,但是我們也來看下主從手動切換是如何實現的。

當主節點出現宕機,這時候我們需要手動將從節點設置成主節點。命令:

redis-cli -h <從節點ip> -p <從節點埠號> slaveof no one

通過上面命令,可以將該從節點臨時設置為主節點。當Redis重啟時,主從切換設置將會失效。然後按照上一篇主從複製的配置將其他從節點的主配置改成現在的主節點。當原來的主節點從宕機中進行恢復,則將臨時主節點的數據進行保存,將AOF文件與RDB文件拷貝替換原主節點下的AOF文件與RDB文件。然後重啟原主節點Redis服務以及臨時主節點Redis服務,恢復原先的主從關係。但是畢竟主從手動切換方案是存在問題的不是很適用,所以一般主從切換會採用哨兵模式。

哨兵模式

在Redis中,哨兵是一個獨立的進程獨立運行。由一個或多個Sentinel實例組成,可以監視多個主節點以及主節點下的從節點。當監視的主節點因為故障宕機,Sentinel實例可以自動的將主節點下的其中一個從節點升級為新的主節點,由這個新的主節點繼續處理寫請求。實際上可以把哨兵理解為一個運行在特殊模式下的Redis伺服器,在哨兵伺服器初始化完成後,哨兵伺服器會保存所有的哨兵功能有關的狀態記錄。哨兵實際上一共有三個任務:監控(Monitoring)、提醒(Notification)、自動故障遷移(Automatic failover)。

  • 監控:Sentinel實例會不斷檢測主從節點是否正常運行。
  • 提醒:當某個節點出現異常宕機時,Sentinel實例會向管理員或者其他應用發送提醒。
  • 自動故障遷移:當主節點宕機時,Sentinel實例會將該主節點下的其中一個從節點升級為新的主節點,並且原先其他從節點重新發起socket請求成為新的主節點的從節點。
  • 配置中心:向客戶端返回新主節點的地址,就可以正常上使用新的主節點來處理請求了。

通過上面的簡單介紹,其實可以發現哨兵模式實際上就可以將主從手動切換給變成自動切換,哨兵會定時通過發送命令,讓監視的主從節點返回運行狀態,當哨兵監視到主節點宕機,則會自動選擇該主節點下的一個從節點,切換成新的主節點。然後通知其他從節點修改成新的主節點的從節點,這樣就可以成功進行主從切換開始處理新請求。但是如果我們只使用一個哨兵,也就是只開啟一個Sentinel實例進行監視,容易出現問題,一般情況下會開啟多個Sentinel實例進行監控,一般情況下至少需要3個Sentinel實例。

節點的兩種宕機狀態

哨兵檢測到主節點宕機一般有兩種狀態:sdown(主觀宕機)和odown(客觀宕機)。如果只有一個哨兵認為這個主節點宕機了,則成為主觀宕機。如果達到一定數量的節點認為該主節點宕機,則成為客觀宕機。

哨兵如何判斷主觀宕機與客觀宕機

當某一個哨兵ping該主節點,在超過了is-master-down-after-milliseconds配置的超時毫秒數沒有資訊返回,則該哨兵認為這個主節點宕機,這個時候成為主觀宕機,也就是sdown。當這個哨兵在指定時間內收到了指定數量的哨兵同樣認為該主節點宕機,則這個時候就是客觀宕機,也就是odown。當一定時間內沒有足夠數量的哨兵認同主節點宕機,則主節點的客觀宕機狀態將會移除。當認為主觀宕機的哨兵再次ping並得到有效回復時,則主節點的主觀宕機也會被移除。

為什麼至少需要3個Sentinel實例?

剛才說過了,當指定時間內指定哨兵數量都認為主節點宕機則稱為客觀宕機。那指定數量是多少呢?這個指定數量實際上等於哨兵數量 / 2 + 1.也就是說如果哨兵數量等於2,出現一個哨兵宕機的情況,在需要主從切換的時候因為無法達到認為主節點宕機的哨兵數量為2,所以在主節點出現宕機時無法進行主從切換。所以說部署哨兵至少需要3個Sentinel實例來保證健壯性。

哨兵模式引發數據丟失問題

哨兵模式 + Redis主從複製這種部署結構,無法保證數據不會出現丟失。哨兵模式下數據丟失主要有兩種情況:

  • 因為主從複製是非同步操作,可能主從複製還沒成功,主節點宕機了。這時候還沒成功複製的數據就會丟失了。
  • 如果主節點無法與其他從節點連接,但是實際上還在運行。這時候哨兵會將一個從節點切換成新的主節點,但是在這個過程中實際上主節點還在運行,所以繼續向這個主節點寫入的數據會被丟失。

解決數據丟失方案

使用命令:

min-slaves-to-write 1  min-slaves-max-lag 10

使用這組命令可以設置至少有一個從節點數據複製延遲不能超過10S,也就是說如果一個直接點下所有從節點數據複製延遲都超過10S,則停止主節點繼續接收處理新的請求。這樣可以保證數據丟失最多只會丟失10S內的數據。

歡迎關注公眾號:程式猿周先森。

Tags: