Redis主從複制的問題

Redis

主從複制 可将 主節點 資料同步給 從節點，從節點此時有兩個作用：

1. 一旦 主節點當機，從節點 作為 主節點 的 備份 可以随時頂上來。
2. 擴充 主節點 的 讀能力，分擔主節點讀壓力。

主從複制 同時存在以下幾個問題：

1. 一旦 主節點當機，從節點 晉升成 主節點，同時需要修改 應用方 的 主節點位址，還需要指令所有 從節點去 複制 新的主節點，整個過程需要 人工幹預。
2. 主節點 的 寫能力 受到 單機的限制。
3. 主節點 的 存儲能力 受到 單機的限制。
4. 原生複制 的弊端在早期的版本中也會比較突出，比如：

   Redis

   複制中斷 後，從節點 會發起

   psync

   。此時如果 同步不成功，則會進行 全量同步，主庫 執行 全量備份 的同時，可能會造成毫秒或秒級的 卡頓。

Redis 的 哨兵（Sentinel）深入探究

Redis Sentinel的架構

Redis的哨兵機制就是解決我們以上主從複制存在缺陷（選舉問題），保證我們的Redis高可用，實作自動化故障發現與故障轉移。

該系統執行以下三個任務：

“

監控：哨兵會不斷檢查你的主伺服器和從伺服器是否運作正常。

提醒：當被監控的某個Redis伺服器出現問題時，哨兵可以通過API給程式員發送通知

自動故障轉移：主伺服器當機，哨兵會開始一次自動故障轉移操作，更新一個從伺服器為主伺服器，并讓其他從伺服器改為複制新的主伺服器.

配置 Sentinel

Redis 源碼中包含了一個名為 sentinel.conf 的檔案， 這個檔案是一個帶有詳細注釋的 Sentinel 配置檔案示例。

運作一個 Sentinel 所需的最少配置如下所示：

1）sentinel monitor mymaster 192.168.10.202 6379 2

Sentine監聽的maste位址，第一個參數是給master起的名字，第二個參數為master IP，第三個為master端口，第四個為當該master挂了的時候，若想将該master判為失效，
在Sentine叢集中必須至少2個Sentine同意才行，隻要該數量不達标，則就不會發生故障遷移。
-----------------------------------------------------------------------------------------------      

2）sentinel down-after-milliseconds mymaster 30000

表示master被目前sentinel執行個體認定為失效的間隔時間，在這段時間内一直沒有給Sentine傳回有效資訊，則認定該master主觀下線。
隻有在足夠數量的 Sentinel 都将一個伺服器标記為主觀下線之後， 伺服器才會被标記為客觀下線，``将伺服器标記為客觀下線所需的 Sentinel 數量由對主伺服器的配置決定。
-----------------------------------------------------------------------------------------------      

3）sentinel parallel-syncs mymaster 2

當在執行故障轉移時，設定幾個slave同時進行切換master，該值越大，則可能就有越多的slave在切換master時不可用，可以将該值設定為1，即一個一個來，這樣在某個
slave進行切換master同步資料時，其餘的slave還能正常工作，以此保證每次隻有一個從伺服器處于不能處理指令請求的狀态。
-----------------------------------------------------------------------------------------------      

4）sentinel can-failover mymaster ``yes

在sentinel檢測到O_DOWN後，是否對這台redis啟動failover機制
-----------------------------------------------------------------------------------------------      

5）sentinel auth-pass mymaster 20180408

設定sentinel連接配接的master和slave的密碼，這個需要和redis.conf檔案中設定的密碼一樣
-----------------------------------------------------------------------------------------------      

6）sentinel failover-timeout mymaster 180000

failover過期時間，當failover開始後，在此時間内仍然沒有觸發任何failover操作，目前sentinel将會認為此次failoer失敗。 
執行故障遷移逾時時間，即在指定時間内沒有大多數的sentinel 回報master下線，該故障遷移計劃則失效
-----------------------------------------------------------------------------------------------      

7）sentinel config-epoch mymaster 0

選項指定了在執行故障轉移時， 最多可以有多少個從伺服器同時對新的主伺服器進行同步。這個數字越小， 完成故障轉移所需的時間就越長。
-----------------------------------------------------------------------------------------------      

8）sentinel notification-script mymaster ``/var/redis/notify``.sh

當failover時，可以指定一個``"通知"``腳本用來告知目前叢集的情況。
腳本被允許執行的最大時間為60秒，如果逾時，腳本将會被終止(KILL)
-----------------------------------------------------------------------------------------------      

9）sentinel leader-epoch mymaster 0

同時一時間最多0個slave可同時更新配置,建議數字不要太大,以免影響正常對外提供服務。      

主觀下線和客觀下線

• 主觀下線：指的是單個 Sentinel 執行個體對伺服器做出的下線判斷。
• 客觀下線：指的是多個 Sentinel 執行個體在對同一個伺服器做出 SDOWN主觀下線 判斷。

Redis Sentinel的工作原理

1.每個 Sentinel 以每秒一次的頻率向它所知的主伺服器、從伺服器以及其他 Sentinel 執行個體發送一個 PING 指令。

2.如果一個執行個體距離最後一次有效回複 PING 指令的時間超過指定的值， 那麼這個執行個體會被 Sentinel 标記為主觀下線。

3.正在監視這個主伺服器的所有 Sentinel 要以每秒一次的頻率确認主伺服器的确進入了主觀下線狀态。

4.有足夠數量的 Sentinel 在指定的時間範圍内同意這一判斷， 那麼這個主伺服器被标記為客觀下線。

5.每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主伺服器和從伺服器發送 INFO 指令。當一個主伺服器被 Sentinel 标記為客觀下線時， Sentinel 向下線主伺服器的所有從伺服器發送 INFO 指令的頻率會從 10 秒一次改為每秒一次。

6.Sentinel

和其他

Sentinel

協商 主節點 的狀态，如果 主節點 處于

SDOWN

狀态，則投票自動選出新的 主節點。将剩餘的 從節點 指向 新的主節點 進行 資料複制。

7.當沒有足夠數量的

Sentinel

同意 主伺服器 下線時， 主伺服器 的 客觀下線狀态 就會被移除。當 主伺服器 重新向

Sentinel

的

PING

指令傳回 有效回複 時，主伺服器 的 主觀下線狀态 就會被移除。

自動發現 Sentinel 和從伺服器

一個 Sentinel 可以與其他多個 Sentinel 進行連接配接， 各個 Sentinel 之間可以互相檢查對方的可用性， 并進行資訊交換。

你無須為運作的每個 Sentinel 分别設定其他 Sentinel 的位址， 因為 Sentinel 可以通過釋出與訂閱功能來自動發現正在監視相同主伺服器的其他 Sentinel。

• 每個 Sentinel 會以每兩秒一次的頻率， 通過釋出與訂閱功能， 向被它監視的所有主伺服器和從伺服器的頻道發送一條資訊， 資訊中包含了 Sentinel 的 IP 位址、端口号和運作 ID （runid）。
• 每個 Sentinel 都訂閱了被它監視的所有主伺服器和從伺服器的頻道， 查找之前未出現過的 sentinel 。當一個 Sentinel 發現一個新的 Sentinel 時， 它會将新的 Sentinel 添加到一個清單中。
• Sentinel 發送的資訊中還包括完整的主伺服器目前配置。如果一個 Sentinel 包含的主伺服器配置比另一個 Sentinel 發送的配置要舊， 那麼這個 Sentinel 會立即更新到新配置上。
• 在将一個新 Sentinel 添加到監視主伺服器的清單上面之前， Sentinel 會先檢查清單中是否已經包含了和要添加的 Sentinel 擁有相同運作 ID 或者相同位址（包括 IP 位址和端口号）的 Sentinel ， 如果是的話， Sentinel 會先移除清單中已有的那些擁有相同運作 ID 或者相同位址的 Sentinel ， 然後再添加新 Sentinel

故障轉移

一次故障轉移操作由以下步驟組成：

• 發現主伺服器已經進入客觀下線狀态。
• 對我們的目前紀元進行自增， 并嘗試在這個紀元中當選。
• 如果當選失敗， 那麼在設定的故障遷移逾時時間的兩倍之後， 重新嘗試當選。如果當選成功， 那麼執行以下步驟。
• 選出一個從伺服器，并将它更新為主伺服器。
• 向被選中的從伺服器發送

  SLAVEOF NO ONE

  指令，讓它轉變為主伺服器。
• 通過釋出與訂閱功能， 将更新後的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進行更新。
• 向已下線主伺服器的從伺服器發送 SLAVEOF 指令， 讓它們去複制新的主伺服器。
• 當所有從伺服器都已經開始複制新的主伺服器時， 領頭 Sentinel 終止這次故障遷移操作。

參考：

https://redis.io/ https://www.cnblogs.com/bingshu/p/9776610.html