MongoDB 3.4 功能改進一覽

mongodb 3.4裡，分片叢集的所有元件，config server、mongod、mongos 都能互相感覺整個分片叢集的存在，了解整個分片叢集的配置資訊，這樣能避免分片叢集的誤配置，比如在現在的版本，有可能會将一個 shard 錯誤的加到多個 sharded cluster 了。這個特性引入了如下限制

分片叢集裡 mongod 啟動時，必須顯式配置 sharding.clusterrole 為 shardsrv

3.4版本的 mongos 不能連接配接低版本的 mongod

mongodb 3.2及以前版本裡，分片叢集的負載均衡由 mongos 負責，多個 mongos 會搶一個分布式鎖，搶鎖成功的 mongos 會對執行負載均衡任務，在 shard 間遷移 chunk；在3.4版本裡，負載均衡将由 config server 的 primary 節點負責，預計會在負載均衡并發度及效率上會有大的提升。

mongodb 3.2版本引入了複制集模式的 config server（csrs 模式），在此之前，config server 由多個鏡像的單節點組成（sccc模式），3.4版本裡，mongodb 将不再支援 sccc模式的 config server。

使用wiredtiger 引擎時，movechunk 的secondarythrottle選項預設設定為 false，即不用等待遷移的資料複制到secondary節點

支援并行的 chunk 遷移，對于包含 n 個 shard 的 sharding 叢集，mongodb 最多可以同時跑 n/2 個遷移任務。

配置複制集時，增加 writeconcernmajorityjournaldefault 選項，預設為 true，即當指定 writeconcern 為 majority 時，資料寫到大多數節點并且 journal 成功刷盤後，才向用戶端确認成功；如果為 false，資料寫到大多數節點的記憶體，就向用戶端确認。

配置複制集時，增加 catchuptimeoutmillis 選項，預設為2s，來指定新選舉出來的 primary 從其它擁有更新資料的節點追資料的時間，增加該時間能最大限度的減少需要 rollback 的資料，但可能增加整個 failover 的時間，該選項隻能在 protocolversion 為1時使用。

"linearizable" read concern 級别保證，一定能讀到 writeconcern 為 majority，并且确認時間在讀請求開始之前的資料，該級别僅在查詢結果隻有單個文檔的情況下有效。

在拷貝資料的時候，同時建立所有的索引（以前版本隻有_id索引是在同步資料時建立的）

拷貝資料的階段，secondary 不斷拉取新的 oplog，確定 secondary 的 local 資料庫有足夠的空間來存儲這些臨時資料。

跟 double 類型不同，decimal 資料存儲的是實際的資料，無精度問題，以9.99為例，decimal numberdecimal("9.99") 的值就是9.99； 而 double 類型的9.99則是一個大概值 9.9900000000000002131628....

mongodb 在3.4版本增加了大量的 aggregation 操作符，功能更加強大了，舉幾個例子

create、createindexes、find、aggregate 等涉及字元串操作的指令都支援 collation。

mongodb 3.4 引入 mongoreplay 工具，可用于監控并記錄 mongod 上執行的指令并 replay 到另一個 mongod 執行個體上，該工具可用于代替 mongosniff。

支援 systemd

降低預設的 wiredtiger cache 配置

<a href="https://docs.mongodb.com/master/release-notes/3.4-upgrade-standalone/">單節點更新到 3.4</a>

<a href="https://docs.mongodb.com/master/release-notes/3.4-upgrade-replica-set/">複制集更新到 3.4</a>

<a href="https://docs.mongodb.com/master/release-notes/3.4-upgrade-sharded-cluster/">分片叢集更新到 3.4</a>