redis雜記

Redis repl-disable-tcp-nodelay配置

問題:在slave和master同步後(發送psync/sync),後續的同步是否設置成TCP_NODELAY?
假如設置成yes,則redis會合並小的TCP包從而節省帶寬,但會增加同步延遲(40ms),造成master與slave數據不一致。
假如設置成no,則redis master會立即發送同步數據,沒有延遲。
前者關注性能,後者關注一致性

是否禁止複製tcp鏈接的tcp nodelay參數,可傳遞yes或者no。默認是no,即開啓tcp nodelay。
如果master設置了yes來禁止tcp nodelay設置,在把數據複製給slave的時候,會減少包的數量和更小的網絡帶寬。但是這也可能帶來數據的延遲。默認我們推薦更小的延遲,但是在數據量傳輸很大的場景下,建議選擇yes。

redis執行slaveof命令過程原理(執行步驟)

  1. 從數據庫向主數據庫發送sync命令。
  2. 主數據庫接收sync命令後,執行BGSAVE命令(保存快照),創建一個RDB文件,在創建RDB文件期間執行的命令將保存在緩衝區中。
  3. 當主數據庫執行完BGSAVE時,會向從數據庫發送RDB文件,而從數據庫會接收並載入該文件。
  4. 主數據庫將緩衝區的所有寫命令發給從服務器執行。
  5. 以上處理完之後,之後主數據庫每執行一個寫命令,都會將被執行的寫命令發送給從數據庫。

注意:在Redis2.8之前,主從斷線或則重啓之後再重連接,都需要做一次完整的sync操作(5步驟),即使斷線期間只有幾條的更新操作或則是沒有操作,導致系統資源極度浪費。Redis2.8之後,會用一個psync來替換sync,不會進行完整的sync操作,只需要同步斷線期間的記錄。相關參數:repl-backlog-size、repl-backlog-ttl

repl-diskless-sync-delay

diskless複製的延遲時間,防止設置爲0。一旦複製開始,節點不會再接收新slave的複製請求直到下一個rdb傳輸。所以最好等待一段時間,等更多的slave連上來。
repl-diskless-sync-delay默認爲5

sentinel日誌信息

# Sentinel runid is 07a40fd381d618f0716c20b270d5c1bd47ef8fa3
    +monitor master mymaster 127.0.0.1 10086 quorum 2  #主加入監控
    +slave slave 127.0.0.1:10087 127.0.0.1 10087 @ T1 127.0.0.1 10086 #檢測到一個slave並添加進slave列表
    +slave slave 127.0.0.1:10088 127.0.0.1 10088 @ T1 127.0.0.1 10086 #檢測到一個slave並添加進slave列表
    +sentinel sentinel 127.0.0.1:20087 127.0.0.1 20087 @ T1 127.0.0.1 10086 #增加了一個sentinel
    +sentinel sentinel 127.0.0.1:20088 127.0.0.1 20088 @ T1 127.0.0.1 10086 #增加了一個sentinel
    +reset-master <instance details> -- 當master被重置時.
    +slave <instance details> -- 當檢測到一個slave並添加進slave列表時.
    +failover-state-reconf-slaves <instance details> -- Failover狀態變爲reconf-slaves狀態時
    +failover-detected <instance details> -- 當failover發生時
    +slave-reconf-sent <instance details> -- sentinel發送SLAVEOF命令把它重新配置時
    +slave-reconf-inprog <instance details> -- slave被重新配置爲另外一個master的slave,但數據複製還未發生時。
    +slave-reconf-done <instance details> -- slave被重新配置爲另外一個master的slave並且數據複製已經與master同步時。
    -dup-sentinel <instance details> -- 刪除指定master上的冗餘sentinel時 (當一個sentinel重新啓動時,可能會發生這個事件).
    +sentinel <instance details> -- 當master增加了一個sentinel時。
    +sdown <instance details> -- 進入SDOWN狀態時;
    -sdown <instance details> -- 離開SDOWN狀態時。
    +odown <instance details> -- 進入ODOWN狀態時。
    -odown <instance details> -- 離開ODOWN狀態時。
    +new-epoch <instance details> -- 當前配置版本被更新時。
    +try-failover <instance details> -- 達到failover條件,正等待其他sentinel的選舉。
    +elected-leader <instance details> -- 被選舉爲去執行failover的時候。
    +failover-state-select-slave <instance details> -- 開始要選擇一個slave當選新master時。
    no-good-slave <instance details> -- 沒有合適的slave來擔當新master
    selected-slave <instance details> -- 找到了一個適合的slave來擔當新master
    failover-state-send-slaveof-noone <instance details> -- 當把選擇爲新master的slave的身份進行切換的時候。
    failover-end-for-timeout <instance details> -- failover由於超時而失敗時。
    failover-end <instance details> -- failover成功完成時。
    switch-master <master name> <oldip> <oldport> <newip> <newport> -- 當master的地址發生變化時。通常這是客戶端最感興趣的消息了。
    +tilt -- 進入Tilt模式。
    -tilt -- 退出Tilt模式。

美團在Redis上踩過的一些坑-目錄(本人非美團)
博客地址:http://carlosfu.iteye.com/blog/2254154

發佈了107 篇原創文章 · 獲贊 22 · 訪問量 20萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章