GaussDB(for Mongo)只讀副本的設計與實現

相關資訊：6月30日，華為openGauss正式開源，開放openGauss數據庫源代碼，并成立openGauss開源社區。

GaussDB(for Mongo)是華為云自主研發兼容MongoDB4.0接口的文檔數據庫。其領先的副本集計算存儲架構，對于傳統MongoDB社區版有如下優勢：

l??秒級添加Secondary節點(相比社區版Mongo小時級添加Secondary節點)

l??基于WAL復制, Secondary節點無寫IO,從根本上解決社區版Secondary節點Oplog脫節問題

l??Primary/Secondary無任何IO交互,Secondary節點個數理論無上限, 支持百萬OPS的讀事務能力

l??LSMTree Compaction 計算/IO卸載到Compaction統一調度池,集中管理,不浪費用戶讀寫IO

GaussDB(for Mongo)?架構介紹

GaussDB(for Mongo) 是兼容mongodb4.0接口的計算存儲分離架構的高性能數據庫。通過底層存儲來保證多副本的數據的安全可靠，上層計算節點可以做到無狀態的運行。

GaussDB(for Mongo) 有以下幾個優點：

1.秒級的節點擴容能力

GaussDB(for Mongo) 具有秒級的節點擴容能力。在業務流量突發的時候，可以迅速采取擴容措施，應對業務高峰。傳統的 mongodb 因為采用的是 計算節點讀取本地數據的方式， 擴容節點后，新加節點還需要等待節點同步完主節點數據才可以對外提供服務。如果數據量很大， 新增節點的數據同步會花費很多時間，在這段時間內，新增節點非但不能提供服務，反而因為需要從集群同步數據的緣故，進一步加重了數據庫的負載。

2.?從根源上杜絕了社區版MongoDB數據被Rollback的問題

社區版mongodb副本集基于Raft協議，當Primary宕機后，Secondary節點選舉成新的Primary，老Primary有數據回滾的風險，而GaussDB(for Mongo)基于共享存儲則不存在這種問題。

3.?計算節點寫壓力卸載

傳統的數據庫通過只讀副本可以做到業務數據的讀寫分離。基于共享存儲的GaussDB(for Mongo) 不僅僅能做到業務數據的讀寫分離，還能分離主節點的LSMTree Compaction壓力。 將主節點的后臺Compaction壓力托管給Compaction Service微服務，從而節約主節點的IO與CPU資源，提升主節點的寫吞吐量，為客戶業務提供更好的數據抗壓能力。這個特性稱為 'Compaction Offload'(Compaction卸載)。

4.?主從復制占用的資源少

傳統的數據庫使用 MongoDB層面的Oplog進行數據同步，所有主節點上的寫IO在從節點必須被鏡像式的回放一遍。GaussDB(for Mongo) 在數據同步技術上，充分利用了共享存儲的優勢， 僅需要主備之間同步存儲池數據文件的元數據變更信息，以及讀取變更數據的Write Ahead Log到內存的操作。避免了Secondary節點數據的Double甚至Triple Write，為用戶的業務讓出更多的CPU和IO資源。

GaussDB(for Mongo)?只讀節點設計

只讀節點功能設計

l??傳統社區版MongoDB副本集基于Oplog做數據復制，只讀節點需要鏡像主節點的所有寫IO操作。GaussDB(for Mongo) 的只讀節點和主節點共享同一份底層數據庫文件(LSMTree的SST文件)，只讀節點并不自己生成SST文件。

l??隨著業務數據的寫入，Compaction的不斷執行，LSMTree的當前版本(包含哪些SST文件)不斷更新，LSMTree的元數據更新(增刪SST文件的記錄)被同步到只讀節點執行。

l??RocksDB中，數據的變更被持久化到WAL里，元數據的變更(增刪文件的操作, 叫做VersionEdit)被持久化到Mainifest里。RocksDB的數據和元數據是分開的，WAL流和VersionEdit流是并行的，沒有嚴格的先后順序。為了保證只讀節點和主節點完全一致的事件回放順序，WAL和VersionEdit流必須要合并成一個流，在雙流合并后，通過LSN就可以為每個事件(WAL的寫操作/VersionEdit)定序。

l??基于WAL+VersionEdit復制，而不基于Oplog復制

l??共享文件(sst/wal)的生命周期管理由主節點負責

sst文件和wal的文件的生命周期由主節點負責。RocksDB中，SST文件通過層級的引用計數來維持不被刪除。如下圖，RocksDB的每個游標會維持SuperVersion，如下圖中的S0，S1，S2。每個SuperVersion會引用一個Version，一個Version代表LSMTree在不斷變形(通過增刪SST文件變形)的過程中，某個時間點的形狀，最新的Version就代表LSMTree當前的形狀。

l??在GaussDB(for Mongo)中，主節點會記錄所有只讀節點在使用的Version，并為這些Version增加引用計數從而維持SST文件的生命周期。

對于WAL，主節點會記錄所有只讀節點中最老的LSN(oldestLsn)，最老的LSN來自于復制最慢的只讀節點。并刪除比oldestLsn還舊的WAL文件。

l??元數據變更通知

無論是oldestLsn還是只讀節點的當前在用的活躍的Version，都需要及時推進，這些元數據的變更是通過主從節點的定期心跳上報到主節點上的。主節點利用心跳數據對垃圾版本與WAL做清理。

如下圖所示，在經歷一次心跳后，主節點發現Secondary0的Version0和Secondary1的Version0不再使用。刪除這兩個Version后，SST0的引用計數為0，表示SST0可以被刪除。OldestLsn也從100推進到了250，可以清理掉250之前的WAL。

l??只讀節點的Memtable的釋放

主節點的Memtable不會實時Flush為SST文件。如果只讀節點不處理主節點的Memtable的話，只讀節點的數據就不是實時的，且存在數據一致性問題。只讀節點通過回放WAL到內存的Memtable中，來覆蓋SST文件與主節點的Memtable的Gap。

上文介紹了只讀節點是不往共享存儲寫入數據的， 所以只讀節點上的 Memtable 最后的結局一定是被丟棄掉。但什么時候丟棄這個 Memtable 就是一個問題。過早的丟棄，會造成SST文件與Memtable之間的數據不連續，存在Gap，過晚的丟棄會造成內存的浪費。只有當只讀節點識別到SST的數據已經完全能夠Cover某個Memtable時，這個Memtable才可以被丟棄。

GaussDB(for Mongo)的只讀節點在每次應用VersionEdit后，檢查所有SST中的最大的LSN與Memtable的最小的LSN的關系，來決定是否要丟棄某個Memtable。

l??內存元數據的反向更新

傳統的復制，數據流從Oplog來，走一遍完整的數據庫Server層CRUD接口，再落到引擎層。這種邏輯和主節點上業務的寫入邏輯是一致的，因此Server層的一些內存元數據結構，在這個過程中就自然而然的得到更新了。但是當采用基于WAL的復制后，整個WritePath并不經過只讀節點的Server層。因此Server層的內存元數據更新，就是一個很大的挑戰。在這里，只讀節點對每一條WAL做分析，如果WAL的內容會影響Mongo內存元數據，就會reload對應的元數據模塊。

GaussDB(for Mongo)?實現

考慮到只讀節點和主節點，以及 GaussDB(for Mongo)的軟件分層， 我們將只讀副本方案的實現，分為四個部分， 如下圖所示:

三大流程如圖所示：

l??開始復制

l??持續復制

l??心跳處理

總結

GaussDB(for Mongo) 只讀節點功能，實現了一份數據多計算節點共用的功能。極大的提升了存儲的利用效率，提高了計算節點的讀取數據能力。為了讓副本節點具有持續的讀擴展能力，整個只讀方案采用元數據的同步模式，在不降低主節點負載的情況下，極大的提升了整個系統的讀數據的處理能力。為3節點，5節點，乃至于15節點以上的副本集的工作提供了可能。

GaussDB(for Mongo) 只讀節點功能，極大的提升了計算節點的彈性能力， 秒級擴縮容的能力在應對負載高峰和降低數據庫成本方面效果顯著。真正的做到了按需使用，彈性擴容的核心能力。也為客戶業務面對熱點爆發流量數據提供了更加高效安全的保證。

【優惠福利】華為云GaussDB重磅發布，新品嘗鮮低至6折，旗艦產品低至￥8.3/小時，戳它體驗>>

數據庫 云數據庫 GaussDB(for Mongo)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。