如何配置合适的​Oplog大小?


  • 註冊用戶

    当从节点出现故障后,由于修复的时候耽误了些时间,等到从节点加入奥复制集时,已经超过了Oplog的有效窗口,

    所以想问下Oplog大小应该怎样去预估,如何配置合适的Oplog大小?


  • Lv 1

    第一步:計算你的Oplog Churn

    Oplog churn是單位時間內oplog的增長速度。如果是大部分寫入新資料的場景是可以根據每小時寫入率 x 平均文檔大小計算出來的。對於更新為主的應用,則要通過測試並觀察 db.printReplicationInfo() 輸出的結果來得到。

    舉例來說,下面是一台複製集中的從機的資訊:

    rs0:RECOVERING> db.printReplicationInfo()

    configured oplog size: 36773.8849609375MB

    log length start to end: 7628secs (2.12hrs)

    oplog first event time: Thu Nov 27 2014 09:05:49 GMT+0800 (HKT)

    oplog last event time: Thu Nov 27 2014 11:12:57 GMT+0800 (HKT)

    now: Thu Nov 27 2014 14:54:45 GMT+0800 (HKT)

    這個告訴我們oplog目前配置的是36G,存儲了2.12小時的oplog 記錄。那麼oplog churn在這裡大概就是17G/小時。如果你需要5個小時的Oplog,那麼就需要17×5 = 85G oplog。

    那麼很自然的下一個問題就是如何知道我需要多長時間的Oplog?

    第二步:確定Oplog窗口時間

    首先我們需要知道Oplog的有效視窗時間必須是下述任務所需時間的最大值:

    1) Initial Sync/Resync一個從機所需時間

    想像一下, 如果新加一台從機,它從2014年11月27日9點開始克隆資料庫。複製完成後,再把9點以後複製過程中新進來的操作以oplog方式追加到從庫上從而完成最終同步。如果克隆資料庫需要12個小時,而oplog只能保存5個小時的記錄,那麼在晚上9點從機試圖開始追加oplog的時候發現oplog只有下午4點以後的內容了! 上午9點到下午4點7個小時的操作已經不存在,無法被同步。所以說oplog的視窗時間必須大於initial sync或者resync中複製資料庫的時間。

    克隆資料庫所需時間比較難估計,可以使用一個樣本資料庫進行initial sync或者resync的測試並記錄所需時間,並估算生產資料庫的所需時間。

    2) 恢復一個備份的資料庫到從機上所需時間

    另外一個類似的操作就是有時候你需要從備份恢復資料庫。假設說你的備份策略是6小時一次,並且從備份恢復一個資料庫的時間是2個小時,那麼你的oplog的有效時間必須大於 8小時(6+2)。如果小於8小時的話,你恢復的資料庫就沒法追加所有在這期間在主節點上產生的oplog。 (當然,你的備份還是可以用來做一個整個複製集的恢復,如主節點)

    3) 對從庫進行壓縮或修復所需時間

    有些時候我們會把從庫下線做一些維護操作,如compact或者repair。Oplog的視窗有效時間也必須大於這個compat或repair所需時間。道理類似於上面。

    第三步:計算oplog大小

    有了oplog churn和oplog所需視窗時間,乘一下就可以得到我們希望為oplog設置的大小。如果oplog churn是17G,上述最大值是8個小時,那我們可以選擇10小時(有一點空間),oplog的大小就應該是17×10=170GB。

    注意:修改oplog的時候一定要對所有的複製集成員做同樣地修改。

     


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待