- 頻繁的全量複製（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 = rep1 master_repl_offset = repl-offset
通過info命令可以查看該信息
作用：本機保存上次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
repl-timeout
該參數定義了超時時間的閾值（默認60秒），超過該值，釋放slave
- 頻繁的網絡中斷（2）
問題現象：
slave與master連接斷開
問題原因：
master發送ping指令頻度較低
Master設定超時時間較短
Ping指令在網絡中存在丟包
解決方案：提高ping指令發送的頻度
超時時間repl-time的時間至少是ping指令頻度的5到10倍，否則slave很容易判定超時
- 數據不一致
問題現象：多個slave獲取相同數據不同步
問題原因：網絡信息不同步，數據發送有延遲
解決方案：優化主從間的網絡環境，通常設置在同一個機房部署，如使用阿里雲等雲服務器時要注意此現象
監控主從節點延遲（通過offset）判斷，如果slave延遲過大，暫時屏蔽程序對該slave的數據訪問
slave-serve-stale-data yes|no
開啓後僅響應info、slaveof等少數命令（慎用，除非對數據一致性要求很高）