爲什麼要對開源mongodb數據庫內核作二次開發

  0. 手把手教你作中間件、高性能服務器、分佈式存儲技術交流羣

        手把手教你作中間件、高性能服務器、分佈式存儲等(redis、memcache、nginx、大容量redis pika、rocksdb、mongodb、wiredtiger存儲引擎、高性能代理中間件)，git地址以下:   https://github.com/y123456yz/middleware_development_learning

 

       Mongodb數據庫版本包含企業版本和社區版本，他們的區別是企業版本相比有更多功能，使用企業版本必須購買付費，因此mongodb部分核心功能沒有開源。爲了加強mongodb集羣穩定性，企業須要對開源版本內核進行二次開發，主要包括如下功能模塊的開發(增長如下功能後，會有很好的收益)：

1. mongos和mongod各類操做時延統計。
2. Mongos代理慢日誌記錄。
3. 普通用戶權限細化控制，危險操做過濾。
4. 危險操做日誌審計。
5. 全部增刪改操做sql異步日誌記錄。
6. mongodb增長熱備功能。

1. 各類操做時延統計

    開發背景：mongodb社區版本只有mongod有讀寫時延統計，沒有各類詳細時延統計功能，同時mongos沒有時延統計，例如想看insert、update、delete、find操做的各類詳細時延統計，開源版本沒有該功能。

    解決辦法：給各類增、刪、查、改操做增長詳細的平均時延、最大時延等統計。

    收益：1. 避免扯皮(例如以前線上某個業務線有一次估值，客戶端時延提高了數倍，業務方抖動厲害，可是業務方時延監控包括了調用mongodb的時延及其餘業務邏輯，這時候就區分不出來是mongodb抖動引發仍是其餘業務邏輯抖動引發)。2. 主動發現mongodb抖動問題，沒有該功能前，mongodb抖動徹底只能靠業務方發現，或者經過mongodb慢日誌發現，可是mongodb慢日誌記錄得是100ms以上的操做，不能精確的反映各類時延問題。

 

2. mongos慢日誌記錄

    開發背景: 因爲mongos代理後端能夠由多個sharding分片，例如mongos後端有50個sharding分片，若是我要分析整個mongodb集羣的慢日誌信息，那麼就必現去分析後端50個sharding的慢日誌，因爲慢日誌在每一個sharding的主、從上均可能產生，若是每一個sharding分片是一主兩從架構，那麼久必現分析3*50個mongo數據庫實例。分析過程複雜繁瑣。

    解決辦法: 因爲代理默認部署就3個實例，直接在mongos代理攔截全部流量，記錄下和後端sharding的詳細慢日誌便可。

    收益：簡化了慢日誌收集分析過程，能夠更快速的發現不合理的查詢、寫入等引發的慢日誌。

 

3. 普通用戶權限細化控制、危險操做過濾

      開發背景: mongodb普通用戶權限默認擁有全部操做權限(包括刪庫、刪表、建索引等)，除非在建立帳號的時候經過privileges來指定actions，若是經過privileges來指定actions會很是麻煩，由於mongodb有數百個不一樣actions操做。此外，業務方還得根據本身實際狀況來梳理代碼使用的action操做，若是想增長某種action，還得提各類申請添加，限制了業務方使用靈活性。

       解決辦法: mongodb中增長普通用戶權限控制並對各類危險操做進行過濾，只要是普通用戶訪問mongodb數據庫，就禁止其刪庫、刪表、建庫、建表、建索引等危險操做。

       收益: 經過在mongodb中增長普通用戶權限控制、危險操做過濾，加強了mongodb權限控制及穩定性功能，同時也使得業務方能夠隨意使用各類不一樣的action，使用也更加靈活。

 

4. 危險操做日誌審計

      開發背景: 數據庫管理人員具備數據庫root權限，擁有刪庫、刪表等危險操做權限，若是誤操做，將會帶來巨大損失。若是某個庫被惡意刪除，怎麼肯定是由那個用戶刪除的？經過那臺客戶端登陸的，何時作了該操做？

       解決辦法: 增長危險操做日誌審計功能，記錄這些危險操做的詳細信息，包括用戶、IP地址、key信息等。

       收益: 快速定位是由哪位管理員惡意操做引發。此外，若是是業務方使用了刪庫、刪表的操做，一樣會記錄下整個詳細操做信息。

 

5. 全部增刪改操做sql異步日誌記錄

      開發背景:  場景1. 業務方感受某個數據丟了，懷疑是數據庫丟數據了。可是mongodb管理員以爲mongodb很穩定，不存在丟數據的狀況，管理員以爲是客戶端本身刪除了，到底是業務方本身刪的仍是mongodb丟數據呢？ 場景2. 業務方在某個時間段作了幾個誤操做，誤刪除了一些數據，想找出在這個時間段內誤刪除的具體數據。

       解決辦法: 把全部的增、刪、改操做過程詳細記錄下來。

       收益: 1. 避免扯皮。2.業務方想要的任意時間段的操做數據均可以獲取出來，便於他們進行問題分析排查。

 

6. 給mongodb增長熱備功能

      開發背景: mongodb社區版本沒有熱備功能，若是須要備份數據庫數據，須要對某個Mongod實例下線進行冷備。或者經過mongodump工具進行主從數據備份(該工具就是模擬mongodb的slave先作全量數據同步，而後拉取Oplog進行增量同步)。若是是冷備，須要停機某個副本，等cp拷貝整個mongodb數據完成後，而後在繼續上線，這種備份方式須要下線實例對業務影響比較大。若是是經過mongodump方式模擬slave來拉取數據，在全量數據拉取過程當中，會佔用較大帶寬，業務方時延會有較大抖動。此外，經過mongodump工具拉取數據很是慢，線上拉取400G數據須要10個小時左右，若是須要增長一個slave，經過這種方式徹底不可接受。

    解決辦法: 藉助wiredtiger存儲引擎機制，增長熱備功能。

    收益: 1. 熱備期間對業務影響較小。2. 備份數據時間下降百倍數量級，例如400G數據經過mongodump方式須要10小時，可是經過熱備方式只須要幾分鐘便可。

 

   若是對mongodb數據庫和wiredtiger存儲引擎源碼感興趣，能夠參考以下注釋:

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6.1