Mongodb集羣部署

數據副本

MongoDB中的一組副本是一羣mongod進程，這些進程維護一樣的數據集。副本集提供了冗餘和高可用性，是生產環境部署的基礎。

數據冗餘和可用性

經過在不一樣的服務器上存儲相同的數據，副本機制保證了必定程度的容錯，即在一個數據庫掛掉後，數據服務仍然可用。

在某些狀況下，副本能夠提高數據的讀性能，由於用戶能夠從不一樣的數據庫讀取數據。在不一樣的數據中心維護數據的拷貝，可以提升分佈式應用程序的可用性。也能夠維護額外的副本用於其餘的目的，好比災難恢復，告警或者是備份。

Mongo中的副本

一個Mongo副本集包括幾個數據軸承節點和一個可選的仲裁者。在這些節點中，有且只有一個主節點，其餘的節點都被認爲是輔助節點。

主節點接收全部的寫操做。一套副本中，只有主節點可以確認{ w: "majority"}；雖然在一些狀況下，另外的mongod進程會在短期內認爲本身是主節點。主節點將全部數據的變更記錄在日誌中，好比oplog

.

從節點複製主節點的oplog，而後根據日誌重放數據集的變更，經過這樣的方式達到和主節點的數據一致。若是主節點掛掉，一個合格的從節點將發起一次選舉將本身選舉爲新的主節點。

能夠在副本集中添加一個額外的mongod實例做爲仲裁者。仲裁者不維護數據集，它的主要功能是維護節點間的心跳和響應其餘副本集成員的請求。由於仲裁者不維護數據，所以和一個完整節點相比，佔用的資源會更少。若是副本集中節點數量是偶數，添加一個仲裁者能夠在主節點的選舉中添加多數選票的能力。

仲裁者的角色不會變，主節點有可能會降級成從節點，從節點也可能升級爲主節點。

異步複製

從節點異步從主節點應用操做。在從主節點同步數據後，即便有部分節點掛掉，副本集依然能夠保持工做。

自動故障轉移

當一個主節點和副本集中的其餘節點有超過10秒中的鏈接斷開時，一個合格的從節點將發起選舉，將本身提高爲主節點。第一個發起選舉而且獲得副本集中大多數選票的節點會成爲主節點。

故障轉移過程一般在一分鐘內完成。副本集中的其餘節點可能須要10到30秒來讓確認主節點不可訪問。在確認後將發起選舉。選舉的過程可能須要10到30秒。

讀操做

默認狀況下，用戶會從主節點中讀取數據，不過用戶也能夠經過設置發送讀請求到從節點。異步制意味着從節點中的數據可能和主節點並不一致。

數據分片

數據分片是將數據分散存儲在多個機器上。MongoDB使用分片技術來支持部署很是大的數據集，並提升系統的吞吐量。

單服務器會面臨大量數據和高吞吐量的應用程序的挑戰。好比，高頻率的查詢會耗盡服務器的CPU資源；大於系統內存的工做數據集會對磁盤的I/O形成很大壓力。

有兩種方式來應對系統數據的增加：垂直擴展和水平擴展。

垂直擴展包括增長單個服務器的能力，好比使用更強的CPU，添加更多內存，或者增長存儲空間。現有技術的侷限可能讓單臺機器沒法應對某個給定的工做負載。另外，雲服務商可以提供的硬件配置也有必定的上限。所以在實踐中，垂直擴展可以應對的負載有上限。

水平擴展包括數據集的劃分，和多臺服務器分攤負載，水平擴展能夠經過添加新的機器來提高處理能力。雖然單機的能力可能不是很強，可是每臺機器都負責處理總體負載的一個子集，所以有能力提供比高速大容量服務器更高的效率。水平擴展提高系統的處理能力只須要添加新的服務器，這比提高高端服務器性能所需的成本要低。缺點是增長了基礎設施部署和維護的複雜度。

MongoDB經過分片技術支持系統的水平擴展。

分片集羣

MongoDB的分片集羣中有如下組件：

• shard：每一個shard都包含數據分片的一個子集。每一個shard均可以部署爲一個副本集
• mongos：mongos做爲查詢路由，提供客戶端應用程序和分片集羣之間的接口
• config servers：config servers存儲集羣中的元數據和配置數據。在Mongo3.4中，config server必須被部署爲副本集。

下圖展現了各個組件之間的交互。

Shard Keys

MongoDB使用shard key對collection的數據分片。shard key由一個不可變的字段或目標collection中每一個文檔都存在的字段組成。

須要在對collection分片的時候選擇shard key。shard key以後不能更改。一個分片的collection只能有一個shard key。

要對一個非空collection分片，collection必須有一個由shard key開始的索引。對於空的collection，若是沒有一個合適索引，MongoDB會建立索引。

shard key的選擇會影響集羣的性能，效率和可擴展性。shard key可能會成爲集羣的瓶頸，即便集羣中的機器性能都很高。

chunks

MongoDB將數據分片到chunk中。依據選擇的shard key，每一個chunk大小都有下限和上限。

在集羣中，MongoDB使用分片集羣均衡器遷移各個chunk。均衡器試圖實如今集羣中chunk的均衡。

分片的優勢

讀/寫

MongoDB在分片集羣中，將讀和寫的負載分配到各個節點中，容許每一個shard處理集羣操做的一個子集。能夠經過添加更多的shard橫向擴展這種讀寫能力。

對於包括shard key的查詢，mongos能夠將查詢定位到特定的shard。

存儲性能

分片技術將數據分配到集羣中的節點上，每一個shard包含總數據集合的一個子集。隨着數據集的增加，添加shard可以增長集羣的存儲容量。

高可用

即便在部分shard不可用的狀況下，集羣依然能夠繼續執行部分讀／寫操做。在掛掉的shard不可用期間，可用的shard的讀寫不受影響。

在生產環境中，shard應該部署爲副本集，以提供數據冗餘和可用性。

分片注意事項

在集羣上實施分片須要仔細地規劃，執行和維護。

仔細選擇shard key，對於確保集羣的性能和效率是必要的。在分片後不能改變shard key，也不能撤銷分片。

分片有必定的操做要求和限制。

若是查詢不包括shard key，mongos會廣播操做，在集羣中的shard中執行查詢。這樣的查詢可能有較長耗時。

分片和非分片collection

一個數據庫可能同時有分片的collection和非分片的collection。分片的collection是分區的，分佈在集羣的不一樣shard中。非分片的collection存儲在主shard中。每一個數據庫都有本身的主shard。

分片集羣的鏈接

必須鏈接到mongos路由，來與分片集羣中的collection交互。這種交互包括分片collection和非分片collection。客戶端不容許直接鏈接到單獨的shard來進行讀寫操做。

分片策略

MongoDB支持兩種分片策略。

哈希分片

哈希分片是對shard key的值進行哈希運算後進行分片。每一個chunk基於哈希後的值進行分配。

一個範圍內的shard key可能很接近，可是hash後的結果極可能不在同一個chunk中。基於哈希的數據分佈會造成更加均衡的數據分佈，特別是在shard key單調變化的狀況下。

可是，哈希分佈意味着對範圍查詢不太可能定位到單個shard，這會致使廣播操做。

範圍分片

範圍分片是將數據基於shard key的值進行切分。每一個chunk基於shard key的值進行分配。

shard key某個範圍內的值更可能分配在相同的chunk中，mongos會將請求導向只含有請求數據的shard中。

範圍分片的效率取決於shard key。欠考慮的shard key會致使數據的分佈不均，這會減小數據分片的優點或者致使性能瓶頸。

分片集羣的區域

在分片集羣中，能夠基於shard key建立數據區域。能夠把集羣中的多個shard在同個區域中關聯起來。一個shard能夠和任意數量的非衝突區域關聯起來。在平衡的集羣中，MongoDB會將區域中的chunk遷移到區域裏關聯的shard中。

每一個區域包括一個或多個範圍的shard key。每一個區域的覆蓋範圍老是包容它的下邊界和排它的上界。