隨著MongoDB開源社區的不斷髮展，MongoDB通過發布新版本為您提供更多優勢特性，例如更快的效能、更好的安全性、更多的功能等。同時，MongoDB開源社區也陸續停止對低版本MongoDB的支援和維護，若您持續使用低版本MongoDB將會面臨諸多挑戰，甚至會引發一定的安全性、穩定性風險。
根據MongoDB官方的Lifecycle Schedules，MongoDB 4.4版本已於2024年2月正式EOL，ApsaraDB for MongoDB團隊建議您升級至更新的版本（包括5.0、6.0、7.0、8.0），便於擷取更好的服務。
舊版本存在的風險和隱患
以下風險和隱患是ApsaraDB for MongoDB團隊根據長期的雲資料庫營運經驗整理得出。
分區執行個體的孤立文檔導致進行執行個體間資料移轉時校正不一致
受影響的版本及架構：4.2及以下版本的分區叢集執行個體。
簡要描述：在分區叢集執行個體中，若未及時清理孤立文檔，可能會導致在遷移資料時出現資料不一致的問題。
推薦版本：4.4及以上版本。
推薦理由：
當一個Chunk成功遷移到新的分區後，源分區中的該Chunk會延期刪除。孤立文檔通常是因為遷移過程中斷而產生的。孤立文檔並不會影響mongos節點上的正常業務請求，因為請求會經過設定管理員（ConfigServer）的路由資料檢查。
從4.4版本開始，MongoDB實現了能夠自恢複的Chunk遷移和孤立文檔清理。就算節點出現異常，MongoDB也會自動回復之前中斷的遷移過程。您不再需要主動執行
cleanupOrphaned命令來清理孤立文檔。您依然可以執行該命令來確認後台線程是否已經成功完成了相關庫表內孤立文檔的刪除。更多資訊，請參見cleanupOrphaned。
compact阻塞業務讀寫
受影響的版本及架構：4.2及以下版本執行個體。
簡要描述：需要回收磁碟片段的情境下，低版本執行個體執行compact命令會阻塞業務讀寫，而且compact操作不能被中斷，只能重啟，影響業務。
推薦版本：4.4及以上版本。
推薦理由：
從4.4版本開始，最佳化了compact的加鎖行為，不再會阻塞業務正常的讀寫（CURD）操作，只會阻塞一些DDL操作（例如
createIndex、dropIndex等）。業務側不再需要等到維護視窗期再來執行compact命令。更多資訊，請參見回收磁碟片段以提升磁碟利用率、compact Blocking。
說明如需回收磁碟片段，建議您使用ApsaraDB for MongoDB的空間分析功能回收磁碟片段。
compact導致節點進入RECOVERING異常狀態
受影響的版本及架構：4.2及以下版本執行個體（小版本低於4.2.18版本）。
簡要描述：需要回收磁碟片段的情境下，低版本執行個體執行compact命令會導致節點臨時進入RECOVERING狀態，如果期間過長，該節點會被ApsaraDB for MongoDB側執行個體探活組件認定為節點不健康從而觸發相應的重搭操作。
推薦版本：4.4及以上版本。
推薦理由：
從4.2.18版本開始，在mongod節點上執行compact命令將不再導致節點進入異常的RECOVERING狀態，從而避免了節點不可用和上述非預期的重搭任務流問題。
更多資訊，請參見回收磁碟片段以提升磁碟利用率、compact RECOVERING。
說明如需回收磁碟片段，建議您使用ApsaraDB for MongoDB的空間分析功能回收磁碟片段。
hidden節點物理備份帶來的空間膨脹問題
受影響的版本及架構：4.2及以下版本的本地碟版執行個體。
簡要描述：受限於物理備份的機制，備份上傳期間磁碟檔案大小依然在增長，長期積累會導致hidden節點磁碟空間膨脹。當發生節點故障或切換節點時，可能會觸發磁碟使用率的誤警示。
推薦版本：5.0及以上版本的雲端硬碟版執行個體。
推薦理由：
雲端硬碟版架構執行個體的全量備份是基於物理備份結合雲端硬碟快照的方式。從原理上縮短了需要在WiredTiger引擎側維持備份檢查點（Backup checkpoint）的時間，有效解決了hidden節點因備份而導致空間膨脹的問題。
此外，雲端硬碟版的快照備份以及基於快照備份的恢複具備更好的效能。當複本集執行個體的資料規模達到2 TB以上時，本地碟版執行個體的物理備份耗時久、失敗率高、期間無法執行其他營運操作等問題也能得到解決。
分區執行個體重建同名庫表時遇到殘留路由資料的問題
受影響的版本及架構：4.4及以下版本的分區叢集執行個體。
簡要描述：分區叢集執行個體上執行
dropDatabase命令後又重建同名庫表時，由於ConfigServer節點上路由資料有殘留，導致執行個體無法完整正常讀寫操作。推薦版本：5.0及以上版本。
推薦理由：
從5.0版本開始，MongoDB最佳化了
dropDatabase命令對於路由資料的處理，不再會導致路由資料的殘留。在4.2及以下版本中，不僅需要使用者側重複執行dropDatabase命令，還需要額外在所有mongos上通過flushRouterConfig命令重新整理路由資訊，否則就會有殘留資料導致問題。更多資訊，請參見dropDatabase、flushRouterConfig。
預設writeConcern為{w:1}導致主從同步異常
受影響的版本及架構：5.0以下版本執行個體。
簡要描述：如果業務寫入太快，可能會導致從節點落後太多而進入RECOVERING的異常狀態，降低執行個體可用性；也可能導致從節點落後太多而讀不到預期的資料，使得部分讀寫分離的業務受損。而且這種狀態下的增量備份也會受影響，導致無法按時間點恢複。
推薦版本：5.0及以上版本。
推薦理由：
從5.0版本開始，MongoDB將預設的writeConcern從原本的
{w:1}調整為了{w:"majority"}，即寫入的資料需要被複本集內大部分節點確認後才返回成功，犧牲了少量效能換取更好的資料可靠性。解決了因為從節點落後太多而主節點被flowControl影響導致業務查詢響應慢或者主節點異常進入ROLLBACK狀態引起資料丟失的問題。對於寫入效能要求比較高的情境，您依然可以將writeConcern設定為
{w:1}。更多資訊，請參見Default Write Concern、setDefaultRWConcern。
Balancer均衡速度慢，橫向擴縮容效能差，業務高峰期無法橫向擴充
受影響的版本及架構：5.0以下版本執行個體。
簡要描述：Balancer遷移速度無法提升，導致需要橫向擴充的情境無法快速均衡資料，熱點無法快速緩解，影響業務。
推薦版本：5.0及以上版本。
推薦理由：
從5.0版本開始，MongoDB新增了
chunkMigrationConcurrency和balancerMigrationsThrottlingMs兩個可調整參數，用於調整Balancer的遷移並發度和效能。更多資訊，請參見chunkMigrationConcurrency、balancerMigrationsThrottlingMs。
說明如果您的資料庫執行個體已經是5.0版本卻不支援這兩個參數，您可以升級資料庫小版本解決該問題。
分區執行個體資料不均衡而導致的負載不均
受影響的版本及架構：5.0及以下版本執行個體（小版本低於6.0.3版本）。
簡要描述：Balancer按照分區間的Chunks數量來判斷是否均衡，在存在Jumbo Chunk、Empty Chunks、熱點資料的情況下會導致分區間的資料分布不均以及相應的負載不均問題。
推薦版本：6.0及以上版本。
推薦理由：
從6.0.3版本開始，Balancer會根據分區間資料量的差異均衡資料，而不是根據分區間Chunks數量的差異來均衡資料。從而有效解決了之前版本因為Jumbo Chunk、Empty Chunk等原因而導致資料、負載不均勻的問題。
更多資訊，請參見MongoDB 6.0.3版本Balancer改動。
其他核心缺陷相關
版本 | 核心缺陷 | 風險層級 | 補充說明 |
MongoDB 3.4 | 中 | 【觸發條件】：執行個體開啟了讀寫分離。 【現象】：Secondary回放oplog時加全域鎖導致業務讀從節點時的慢請求。 | |
MongoDB 4.0 | 低 | 【觸發條件】：Server側的串連數突增。 【現象】：可能會遇到Sessions不足而觸發斷言，導致mongod節點異常，觸發切換。 | |
MongoDB 3.6 ~ 4.2 | 低 | 【觸發條件】：偶發。 【現象】：用戶端收到類似 | |
MongoDB <= 4.2 | 低 | 【觸發條件】：偶發， 【現象】：會導致mongos異常宕機，重啟後自愈 | |
MongoDB 4.0 ~ 4.2 | 低 | 【觸發條件】：偶發。 【現象】：服務端無法正確區分事務和retryable wirtes而導致請求失敗報錯。 | |
MongoDB 4.0 ~ 4.4 | 高 | 【觸發條件】：長事務操作。 【現象】：wt cache eviction無法正常完成，dirty迅速上漲到>20%。處理逾時事務清理的線程可能會卡住而導致請求延時大幅增加，業務受損。 | |
MongoDB 3.6 ~ 4.4 | 高 | 【觸發條件】：CS節點90天未發生切換。 【現象】：CS上HMAC生產簽名密鑰的缺陷，導致mongos異常宕機無法自愈。 | |
MongoDB 4.0 ~ 4.4 | 中 | 【觸發條件】：偶發。 【現象】：opContext觸發斷言錯誤，導致mongod異常，觸發切換。 | |
MongoDB < 4.4 | 高 | 【觸發條件】：Secondary後台建立索引過程中，oplog中又有DDL操作。 【現象】：DDL操作被阻塞，從節點無法提供服務。 | |
MongoDB < 4.4 | 中 | 【觸發條件】：節點重啟或初始化同步。 【現象】：節點recovery流程中WT引擎裡對於history store的時序判斷問題，會觸發WT斷言錯誤，mongod異常宕機。 | |
MongoDB 4.2 ~ 4.4 | 高 | 【觸發條件】：執行個體開啟了讀寫分離，從節點高負載。 【現象】：pthread互斥鎖的爭用導致從節點的read tickets耗盡，業務查詢受損。 | |
MongoDB 4.2 ~ 4.4 | 中 | 【觸發條件】：業務側頻繁listCollections。 【現象】：遇到底層CollectionCatalog互斥鎖的問題，嚴重影響執行個體效能，業務受損。 | |
MongoDB <= 6.0 | 高 | 【觸發條件】：小規格執行個體，建索引過程中出現過OOM。 【現象】：mongod反覆重啟無法自愈。複本集內2個節點均進入此狀態時，整個複本集不可用。 | |
MongoDB <= 6.0 | 低 | 【觸發條件】：建立TTL索引或調整到期時間後導致有大量到期文檔。 【現象】：後台TTL線程會卡住無法自愈，導致TTL功能失效。 |
新版本的新特性及最佳化
版本 | 新特性/最佳化 | 補充說明 |
MongoDB 5.0 | 時序集合 | 從5.0版本開始，MongoDB可以更好地處理時序資料，適配車連網、物聯網等廣泛情境。 |
查詢長時間運行快照 | 從5.0版本開始，MongoDB提供了讀取歷史快照的能力。 | |
版本化API | 從5.0版本開始，MongoDB正式提供了版本化API的能力，通過將應用程式生命週期和資料庫生命週期解耦，提供了完備的相容性保證。使用者無需擔心升級資料庫版本而帶來的相容性風險了。 | |
MongoDB 6.0 | changeStream若干最佳化 | 從6.0版本開始，ChangeStream包含了諸多最佳化：
|
join查詢最佳化 | 從6.0版本開始，MongoDB分區執行個體也開始支援 | |
分區執行個體支援自動整理分區集合的磁碟片段空間 | 從6.0版本開始，MongoDB分區執行個體支援通過 | |
時序集合若干最佳化 | 從6.0開始，時序集合包含了諸多最佳化：
| |
compact效能大幅提升 | ApsaraDB for MongoDB在6.0版本的基礎上，在WT引擎層對compact命令進行了全方位最佳化，大幅提升了compact的效能，同時也降低了compact執行期間受eviction壓力而失敗的機率。 | |
MongoDB 7.0 | 分區鍵分析 | 從7.0版本開始，支援基於採樣查詢（Sampled queries）的結果來分析集合的分區鍵是否合理，可以協助您更好地設計Schema以及分區鍵、更合理使用分區架構。 |
可查詢加密 （Queryable Encryption） | 從7.0版本開始，可查詢加密使得敏感性資料在其整個生命週期中（傳輸中、靜止中、使用中、日誌中和備份中）都是加密的，並且只在用戶端解密。提供了更強大且全面的資料安全保障，有效避免被“拖庫”的資料泄露風險。 | |
中繼資料一致性檢查 | 從7.0版本開始，在資料庫維護期或者異常（OOM或故障切換等）結束後能夠主動發現潛在的中繼資料/索引不一致風險。 | |
ChangeStream支援超大變更事件 | 從7.0版本開始，新增了 | |
wt引擎動態限流 | 從7.0版本開始，MongoDB會自動動態調整WT儲存引擎的事務並發度（之前預設是128）來實現限流的效果。緩解了之前版本中資料庫異常後因請求堆積而導致雪崩的問題 | |
MongoDB 8.0 | 升級版TCMalloc | 從8.0版本開始，MongoDB開始使用升級版的TCMalloc：
|
複製效能最佳化 |
| |
reshard效能最佳化 | 從8.0版本開始，MongoDB改進最佳化了 |