文章目錄

• • • • • 一、 主從數據一致性
        • • 1. 主多從少
          • 2. 主少從多
          • 3. 知識點補充
        • 二、 數據延遲
        • • 2.1. 數據延遲因素
          • 2.2. 解決方案
        • 三、 臟數據
        • • 3.1. 臟數據產生的場景
          • 3.2. 解決方案
        • 四、 數據安全性
        • • 4.1. 場景
          • 4.2. 解決方案
        • 五、 規避全量復制
        • • 5.1. 低峰時段
          • 5.2. 主節點變更
          • 5.3. 增大復制緩沖區
        • 六、 規避復制風暴
        • • 5.1. 單主節點
          • 5.2. 單機多主

一、 主從數據一致性

1. 主多從少

主從網絡延遲時，主多從少情況下，進行部分重同步。
場景簡述：主多從少就是在網絡延遲的情況下，從服務器尚未把主服務器的數據全部復制過來。
解決方案：
第一種：這時，我們可以等延遲結束之后，讓從服務器進行部分重同步，就是我們說增量復制。
第二種：如果比較著急，向讓他立刻執行重同步，需要任務干預。在從節點輸入

psync 主節點master的run_id 追加需要復制的起始偏移量offset

就可以實現部分重同步
第三種：人為斷開讓從節點和主節點重新建立連接，也會觸發部分重同步。

2. 主少從多

主少從多情況下，進行全量復制。
場景簡述(主少從多)：這種情況是從服務器開啟了寫的操作導致的，也就是我們的從服務器是讀寫模式，當從從服務器寫入，就會導致主從不一致。
解決方案:
把從服務器數據清空，讓從服務器和主服務器重新建立連接，進行去哪量數據復制即可。

3. 知識點補充

在redis2.8版本之前，如果從節點和主節點斷開重新連接，從節點就會全量復制，這無疑是一個降低性能的問題。
為了解決這個問題，redis在2.8版本之后，添加了一個特性；我們主從斷開重連的時候，可以進行一個邏輯判斷處理，來判斷從節點進行全量復制還是增量復制？
其實就是我們的主服務器在內存中為每一個從服務器都維護了一個同步日志和同步標識，這三個同步日志就是backlog ，這個同步標識就是offset，每個從服務器在跟主服務器進行同步的時候，會攜帶同步標識和上次同步的位置，這樣就會判斷出這個復制，要做全量復制還是增量復制。

二、 數據延遲

2.1. 數據延遲因素

數據延遲，根據那些配置或者屬性決定的。在info replication返回的信息中有一個偏移量，其實，就是根據這個偏移量來決定當前數據的一個健康狀態，數據是否有延遲，我們的主節點在寫入命令的時候，比如：我寫入3000字節的一個偏移量，此時，我們的從節點只復制了1000，他們的差值比較大的時候，就說明數據延遲就很高了。

2.2. 解決方案

1.編寫外部程序監聽主從節點的復制偏移量，延遲較大時發出報警或者通知客戶端，切換到主節點或者其他節點。
2設置從節點slave-serve-stale-data為no 除INFO SLAVEOF命令之外的任何請求都會返回一個錯誤“SYNC with master in progress”

三、 臟數據

3.1. 臟數據產生的場景

• 惰性：現在有一個key已經過期了，現在沒有人活著客戶端訪問，就不會刪除這個過期的key；在訪問的時候在判斷這個key是否過期，過期了就會刪除，導致一個過期的key如果不被訪問就會永遠存在內存中。

• 定時：解決惰性缺點，內部有一個定時任務，隔一段時間就會判斷一批key是否過期，過期了就刪除掉。

• 主動刪除：當前數據存儲超過了redia的存儲上限，然后，觸發主動刪除，正是因為rerdis刪除機智的原因導致有臟數據的產生。
  從節點可寫導致的，從節點一般都是只讀模式，如果你開啟了讀寫模式，這個數據從從節點誤寫入，可能導致產生臟數據。

3.2. 解決方案

• 忽略：比如：12306查詢票，雙11查詢庫存，當你去查詢這些信息的時候，我并沒有去做一個寫操作，這樣業務場景允許你出現一定的的錯誤，有一定的容錯。我么可以選擇忽略。
• 強制讀主：當我們買一張車票，下單呢？秒殺搶購這個商品，這個時候數據一定要是準確的，我們可以采用強制讀主的方式，從節點間接變為了備份服務器(某個業務)
• 從節點只讀：規避從節點寫入臟數據
  目前redis6.x之后，讀取數據之前檢查鍵過期時間來決定是否返回數據

四、 數據安全性

4.1. 場景

關閉主節點持久化會提升性能，同時會帶來復制的安全性問題。

4.2. 解決方案

主節點不自動重啟，不是用shell腳本手段監控主節點自動觸發重啟

五、 規避全量復制

5.1. 低峰時段

第一次全量復制解決方案：低峰時段掛載slave節點，比如：晚上12點

5.2. 主節點變更

選舉slave為主節點

待補充

5.3. 增大復制緩沖區

六、 規避復制風暴

5.1. 單主節點

單主節點復制風暴：主節點重啟，從節點全量復制
解決方案：
選舉slave為主節點、樹狀復制結構

5.2. 單機多主

單機多主復制風暴：一臺機器，多個主節點(樹狀復制架構)
解決方案：把主節點分散在多臺機器上

總結

以上是生活随笔為你收集整理的（进阶篇）Redis6.2.0 集群 主从复制_故障解决_03的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。