頻繁的全量複製(1)
伴隨著系統的執行,master的資料量會越來越大,一旦master重啟,runid將發生變化,會導致全部slave的全量複製操作
內部最佳化調整方案:
- master內部建立master_replid變數,使用runid相同的策略生產,長度41位,併傳送給所有slave
- 在master關閉時執行命令shutdown save,驚喜RDB持久化,將runid與offset儲存到RDB檔案中
- repl-id repl-offset
- 透過redis-check-rdb命令可以檢視該資訊
- master重啟後載入RDB檔案,恢復資料
重啟後,將RDB檔案中儲存的repl-id與repl-offset載入到記憶體中- master_repl_id = repl master_repl_offset = repl-offset
透過info命令可以檢視該資訊
- master_repl_id = repl master_repl_offset = repl-offset
作用:本機儲存上次runid,重啟後恢復該值,使所有slave認為還是之前的master
頻繁的全量複製(2)
- 問題現象
- 網路環境不佳,出現網路中斷,slave不提供服務
- 問題原因
- 複製緩衝區過小,斷網後slave的offset越界,觸發全量複製
- 最終結果
- slave反覆進行全量複製
- 解決方案
- 修改複製緩衝區大小
repl-backlog-size
- 修改複製緩衝區大小
- 建議設定如下:
- 測算從master到slave的重連平均時長second
- 獲取master平均每秒產生寫命令資料總量write_size_per_second
- 最優複製緩衝區空間 = 2 * second * write_size_per_second
頻繁的網路中斷(1)
- 問題現象
- master的CPU佔用過高或slave頻率斷開連線
- 問題原因
- slave每1秒傳送REPLCONF ACK命令到master
- 當slave接到了慢查詢時(keys *,hgetall等),會大量佔用CPU效能
- master每1秒呼叫複製定時函式replicationCron(),比對slave發現長時間沒有進行響應
- 最終結果
- master各種資源(輸出緩衝區、寬頻、連線等)被嚴重佔用
- 解決方案
- 透過設定合理的超時時間,確認是否釋放slave
該引數定義了超時時間的值(預設60秒),超過該值,釋放slaverepl-timeout
- 透過設定合理的超時時間,確認是否釋放slave
頻繁的網路中斷(2)
- 問題現象
- slave與master連線斷開
- 問題原因
- master傳送ping指令頻度較低
- master設定超時時間較短
- ping指令在網路中存在丟包
- 解決方案
- 提高ping指令傳送的頻度
超時時間repl-time的時間至少是ping指令頻度的5到10倍,否則slave很容易判定超時repl-ping-slave-period
- 提高ping指令傳送的頻度
資料不一致
- 問題現象
- 多個slave獲取相同資料不同步
- 問題原因
- 網路資訊不同步,資料傳送有延遲
- 解決方案
- 最佳化主從間的網路環境,通常放置在同一個機房部署,如使用阿里雲等雲伺服器時要注意此現象
- 監控主從節點延遲(透過offset)判斷,如果slave延遲過大,暫時遮蔽程式對該slave的資料訪問
開啟後僅響應info、slaveof等少數命令(慎用,除非對資料一致性要求很高)slave-serve-stale-data yes|no
本作品採用《CC 協議》,轉載必須註明作者和本文連結