Redis主從復制相關配置和常見問題的解決方法

本篇內容主要講解“Redis主從復制相關配置和常見問題的解決方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis主從復制相關配置和常見問題的解決方法”吧!

1. 主從復制相關配置

主從復制的配置都是在從節點配置，所以以下幾個參數都是在從節點配置

1、slaveof  <master ip> <master port>

slave實例需要配置該項，指向master的ip和port

2、masterauth <master-password>

如果master實例啟用了密碼，則該配置項需要填master的啟動密碼，若master未啟用密碼，該配置需要注釋掉

3、slave-server-stale-data

指定slave與master連接中斷時的動作，默認為yes，表明slave會繼續應答來自client的請求，但這些數據可能已經過期（因為連接中斷導致無法從master同步）。若配置為no，則slave除正常應答info和slaveof命令外，其余來自客戶端請求的命令會均得到“sync with master in prigress”的應答，直到該slave與master的連接重建成功或改slave被提升為master

4、slave-read-only

指定slave是否只讀，默認為yes。若配置為no，這表示slave是可寫的，但是寫的內容在主從同步后會被刪除

5、repl-disable-tcp-nodelay

指向slave同步數據時，是否禁用scoket的NO_DELAY選項，若配置為yes則禁用NO_DELAY,則tcp協議棧會合并小包統一發送，這樣可以減少主從節點間的包數量并節省寬帶，但會增加數據同步到slave的時間。若配置為no，表明啟用NO_DELAY，則tcp協議棧不會延遲小包的發送時機，這樣數據同步的延時會減少，但需要更大的寬帶，通常情況下，應該配置為no以降低同步延時，但在主從節點間網絡負載已經很高的情況下， 可以配置為yes

6、slave-priority

指定slave的優先級，在不只1個salve存在的部署環境下，當master宕機時，redis sentinel會將priority值最小的slave提升為master，需要注意的是，若改配置項為0，則對應的slave永遠不會被redis sentinel自動提升為master

2. 主從復制進階常見問題解決

2.1 讀寫分離

讀流量分攤到從節點，這是個非常好的特性，如果一個業務只需要讀數據，那么我們只需要連接一臺slave從機讀數據

雖然讀寫有優勢，能夠讓讀這部分分配給各個slave從機，如果不夠，直接加slave機器就好了，但是也會出現以下問題

1、復制數據延遲

可能會出現slave延遲當值讀寫不一致等問題，當然你也可以使用監控偏移量offset，如果offset超出范圍就切換到master上，邏輯切換，而具體延遲多少，可以通過info replication的offset指標進行排查

對于無法容忍大量延遲場景，可以編寫外部監控程序（consul）監聽主節點的復制偏移量，當延遲較大時觸發報警或者通知客戶端避免讀取延遲過高的從節點

同時從節點的slave-serve-stale-data參數也與此有關，它控制這種情況下從節點的表現：如果為yes（默認值），則從節點仍能夠響應客戶端的命令；如果為no，則從節點只能響應info、slaveof等少數命令。該參數的設置與應用對數據一致性的要求有關；如果對數據一致性要求很高，則應設置為no。

2、只有n個從節點鏈接的時候才允許寫入

redis2.8以后，可以設置從節點在有N臺從節點鏈接的時候可以寫入請求，然后因為redis使用的是異步復制，所以沒有辦法保證從節點確實收到的給定寫入請求，所以存在一個窗口期的數據丟失的可能性。

下來解釋一下這個特性是如何工作的

從節點每秒鐘都會ping主節點，告知它所有的復制流工作了

主節點會記住每個從節點收到的最新的ping

用戶可以給主節點配置一個在等于從節點的數量的最低值和不超過最高值之間的延遲

如果至少有N個從節點，如果少于延遲M秒，則寫入就將被接受

你可能覺得經最大努力保證數據安全機制，雖然數據一致性無法保證，但是至少只是幾秒的時間窗口內丟失數據，通常情況下范圍數據丟失可比無范圍數據丟失好多了

如果條件不滿足，主節點將會返回一個錯誤，并且寫入請求將不接受

主機配置兩個參數：

最小的從主機連接數量

min-slaves-to-write <number of slaves>

最大的延遲時間

min-slaves-max-lag <number of seconds>

舉個例子，如果我們向主服務器提供以下設置：

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

那么在從服務器的數量少于3個，或者三個從服務器的延遲（lag）值都大于或等于10秒時，主服務器將拒絕執行寫命令

3、如何選擇，要不要讀寫分離

沒有最合適的方案，只有最合適的場景，讀寫分離需要業務可以容忍一定程度的數據不一致，適合讀多寫少的業務場景，讀寫分離，是為了什么，主要是因為要建立一主多從的架構，才能橫向任意擴展slave node去支撐更大的讀吞吐量

2.2從節點故障

對于從節點的故障問題，需要在客戶端維護一個可用從節點可用列表，當從節點故障時，立刻切換到其他從節點或主節點，之后redis Cluster 時候可以解決這個問題

2.2.1配置不一致

主機和從機不同，經常導致主機和從機的配置不一致，并帶來的問題

數據丟失：主機和從機有時候會發生配置不一致的情況，例如maxmemory不一致，如果主機配置maxmemory為8g，從機slave設置為4g，這個時候是可以用的，而且還不會報錯。但是如果要做高可用，讓從節點變成主節點的時候，就會發現數據已經丟失了，而且無法挽回

2.2.2規避全量復制

全量復制指的是當slave從機斷掉并重啟后，runid產生變化而導致需要在master主機里拷貝全部數據。這種拷貝全部數據的過程非常耗資源

全量復制是不可避免的，例如第一次的全量復制是不可避免的，這是我們需要選擇小主節點且maxmemory值不要過大，這樣就比較快。同時選擇在低峰值的時候做全量復制

2.2.3造成全量復制的原因

1、主從節點運行的runid不匹配。主節點如果重啟，runid將會發生變化。如果從節點監控到runid不是同一個，它就會認為你的節點不安全。當發生故障轉移時候，如果主節點發生故障，那么從機就會變成主節點。后邊會說到哨兵和集群

2、復制緩沖區空間不足，比如默認1M，可以部分復制。但如果緩沖區不夠大的話，首先需要網絡中斷，部分復制就無法滿足。其次需要增大復制緩沖區配置（relbacklogsize）對網絡的緩沖增強

2.2.4解決全量復制

在一些場景下，可能希望對主節點進行重啟，例如主節點內存碎片率過高，或者希望調整一些只能在啟動時調整的參數。如果使用普通的手段重啟主節點，會使得runid發生變化，可能導致不必要的全量復制

為了解決這個問題，Redis提供了debug reload的重啟方式：重啟后，主節點的runid和offset都不受影響，避免了全量復制。

例如：當一個主機下面掛了很多個slave從機的時候，主機master掛了，這時master主機重啟后，因為runid發生了變化，所有的slave從機都要做一次全量復制。這將引起單節點和單機器的復制風暴，開銷會非常大。

解決：

可以采用樹狀結構降低多個從節點對主節點的消耗

從節點采用樹狀樹非常有用，網絡開銷交給位于中間層的從節點，而不必消耗頂層的主節點。但是這種樹狀結構也帶來了運維的復雜性，增加了手動和自動處理故障轉移的難度

2.2.5 單機風暴

由于 Redis 的單線程架構，通常單臺機器會部署多個 Redis 實例。當一臺機器（machine）上同時部署多個主節點（master）時，如果每個 master 主機只有一臺 slave 從機，那么當機器宕機以后，會產生大量全量復制。這種情況是非常危險的情況，帶寬馬上會被占用，會導致不可用。

解決：

應該把主節點盡量分散在多臺機器上，避免在單臺機器上部署過多的主節點。

當主節點所在機器故障后提供故障轉移機制，避免機器恢復后進行密集的全量復制

到此，相信大家對“Redis主從復制相關配置和常見問題的解決方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！