MongoDB writeConcern原理解析

MongoDB支持客戶端靈活配置寫入策略(writeConcern),以滿足不同場景的需求。

db.collection.insert({x: 1}, {writeConcern: {w: 1}})

writeConcern選項

MongoDB支持的WriteConncern選項如下

  1. w: 數據寫入到number個節點才向用客戶端確認
    • {w: 0} 對客戶端的寫入不需要發送任何確認,適用于性能要求高,但不關注正確性的場景
    • {w: 1} 默認的writeConcern,數據寫入到Primary就向客戶端發送確認
    • {w: “majority”} 數據寫入到副本集大多數成員后向客戶端發送確認,適用于對數據安全性要求比較高的場景,該選項會降低寫入性能
  2. j: 寫入操作的journal持久化后才向客戶端確認
    • 默認為”{j: false},如果要求Primary寫入持久化了才向客戶端確認,則指定該選項為true
  3. wtimeout: 寫入超時時間,僅w的值大于1時有效。
    • 當指定{w: }時,數據需要成功寫入number個節點才算成功,如果寫入過程中有節點故障,可能導致這個條件一直不能滿足,從而一直不能向客戶端發送確認結果,針對這種情況,客戶端可設置wtimeout選項來指定超時時間,當寫入過程持續超過該時間仍未結束,則認為寫入失敗。

{w: “majority”}解析

{w: 1}、{j: true}等writeConcern選項很好理解,Primary等待條件滿足發送確認;但{w: “majority”}則相對復雜些,需要確認數據成功寫入到大多數節點才算成功,而MongoDB的復制是通過Secondary不斷拉取oplog并重放來實現的,并不是Primary主動將寫入同步給Secondary,那么Primary是如何確認數據已成功寫入到大多數節點的?

http://77g6ez.com1.z0.glb.clouddn.com/majority.png

  1. Client向Primary發起請求,指定writeConcern為{w: “majority”},Primary收到請求,本地寫入并記錄寫請求到oplog,然后等待大多數節點都同步了這條/批oplog(Secondary應用完oplog會向主報告最新進度)。
  2. Secondary拉取到Primary上新寫入的oplog,本地重放并記錄oplog。為了讓Secondary能在第一時間內拉取到主上的oplog,find命令支持一個awaitData的選項,當find沒有任何符合條件的文檔時,并不立即返回,而是等待最多maxTimeMS(默認為2s)時間看是否有新的符合條件的數據,如果有就返回;所以當新寫入oplog時,備立馬能獲取到新的oplog。
  3. Secondary上有單獨的線程,當oplog的最新時間戳發生更新時,就會向Primary發送replSetUpdatePosition命令更新自己的oplog時間戳。
  4. 當Primary發現有足夠多的節點oplog時間戳已經滿足條件了,向客戶端發送確認。

參考資料

作者簡介

張友東,阿里巴巴技術專家,主要關注分布式存儲、Nosql數據庫等技術領域,先后參與TFS(淘寶分布式文件系統)Redis云數據庫等項目,目前主要從事MongoDB云數據庫的研發工作,致力于讓開發者用上最好的MongoDB云服務。

MongoDB writeConcern原理解析》有11個想法

  1. Pingback: 2019
  2. Pingback: cleantalkorg2.ru
  3. Pingback: #macron #Lassalle
  4. Pingback: a2019-2020
  5. Pingback: facebook
  6. Pingback: facebook1
  7. Pingback: javsearch.mobi

發表評論