MongoDB 副本集運維策略

  • 2020 年 1 月 19 日
  • 筆記

前文傳送門

  1. 解鎖MongoDB replica set核心姿勢
  2. MongoDB副本集自動故障轉移全流程原理

「副本集不僅能幫助數據庫從節點故障/網絡分區中快速恢復，而且使您能夠執行運維任務而不會影響高可用性。

本文聊一聊 MongoDB 副本集運維窗口期的操作策略，最大程度地減少主節點不可用的時間。

P1 滾動維護/升級

MongoDB 副本集的維護/升級通常以滾動方式執行，依次在輔助節點上執行維護，而最後執行主節點維護。

  1. 在輔助節點上停止MongoDB服務，執行運維操作
  2. 在服務器上啟動MongoDB服務
  3. 等待節點的MongoDB同步到最新的Oplog（追趕）
  4. 在副本集中的其他輔助節點上重複上述操作

假定一個副本集包含mon01（主節點），mon02（輔助）mon03（輔助），滾動運維通常需要：

  1. 先後在輔助節點mon03、mon02上進行維護
  2. 將主節點mon01降級（stepDown），等待選舉新主節點，比如說mon02
  3. 在以前的主節點mon01上執行維護

如果主服務器意外終止/大多數輔助節點覺得與主節點失聯，則輔助節點會在丟失心跳10秒鐘後要求進行選舉。

P2 快速選舉

主節點降級，觸發快速選舉

退出（stepDown）主節點可加快故障轉移過程，建議使用stepDown命令退出主節點以強制觸發選舉，而不是關閉（shutDownServer）主數據庫 (輔助節點需花時間識別主節點失聯)

減少electionTimeoutMillis閾值

輔助節點認定主節點失聯的默認閾值是10s， 在滾動維護期間我們可人為縮短這個閾值，加快選舉。但是運維完畢，請恢復這個默認設置。

rs.isMaster().me  // mon02:27000  // rs0:PRIMARY>  // on the new primary  var conf = rs.conf()  conf.settings.electionTimeoutMillis=10000  /*  rs.reconfig(conf)  {    "ok": 1,    "operationTime": Timestamp(1529034252, 1),    "$clusterTime": {      "clusterTime": Timestamp(1529034252, 1),      "signature": {        "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="),        "keyId": NumberLong(0)      }    }  }  */

「10s的閾值是合適的，我們要確保集群能夠忽略和忍耐網絡抖動或網絡延遲， 減少不必要的重選。

P3  優選新主節點

一般情況下，會根據如下因素選擇 主節點

  • 低複製滯後
  • 低網絡延遲

若想指定某輔助節點mon02為下一個主節點，在其他輔助節點上運行rs.freeze（60）凍結它們成為主節點的資格；當你stepDown主節點mon01時，輔助節點mon02是唯一可以選擇的主節點，這將加快選舉速度。

或 您可以通過給予副本集成員比其他成員更高的member [n] .priority值來使其成為主節點。

cfg = rs.conf()  cfg.members[0].priority = 0.5  cfg.members[1].priority = 0.5  cfg.members[2].priority = 1

參考的運維命令：

rs.conf() 返回包含當前副本集配置的文檔  rs.sttaus() 返回副本集某成員視角收到的副本集狀態  rs.stepDown(stepDownSecs, secondaryCatchUpPeriodSecs) 指示主節點退化為輔助節點，之後合格的輔助節點會發起選舉；另外並不是立即退化，等待指定時間確保有一個節點與主節點保持最新同步。  rs.freeze(seconds)  在一定時間內凍結節點成為主節點的資格  rs.reconfig(configuration, force) 重新配置現有副本集，覆蓋現有副本集配置(需要連到主節點執行）

VirMach 便宜 VPS

QNews

QNews