一、復制

在MongoDB中，創(chuàng)建副本集后就可以使用復制功能了，副本集是一組服務器，其中一個用于處理寫操作的主節(jié)點primary，還有多個用于保存主節(jié)點數(shù)據(jù)副本的從節(jié)點secondary。如果主節(jié)點崩潰了，則從節(jié)點會選取出一個新的主節(jié)點。

如果使用復制功能時有一臺服務器停止運行了，那么仍然可以從副本集中的其它服務器訪問數(shù)據(jù)。如果服務器上的數(shù)據(jù)已損壞或無法訪問，則可以從副本集中的其它成員中創(chuàng)建一個新的數(shù)據(jù)副本。

副本集中的每個成員都必須能夠連接到其它成員，如果收到有關成員無法訪問到其它成員，則可能需要更改網(wǎng)絡配置以允許它們之間的連接。

二、如何進行選舉

當一個從節(jié)點無法與主節(jié)點連通時，它就會聯(lián)系并請求其它的副本集成員將自己選舉為主節(jié)點。

其它成員會做幾項健全性檢查：

1. 它們能否連接到主節(jié)點，而這個主節(jié)點是發(fā)起選舉的節(jié)點無法連接到的？
2. 這個發(fā)起選舉的從節(jié)點是否有最新數(shù)據(jù)？
3. 有沒有其它更高優(yōu)先級的成員可以被選舉為主節(jié)點？

MongoDB在3.2版本中引入了第1版復制協(xié)議。這是一個類PAFT的協(xié)議，并且包含了一些特定于MongoDB的副本集概念，比如仲裁節(jié)點、優(yōu)先級、非選舉成員、寫入關注點等。還提出了很多新概念，比如更短的故障轉移時間，大大減少了檢測主節(jié)點失效的時間，它還通過使用term ID來防止重復投票。

RAFT是一種共識算法，它被分解成了相對獨立的子問題。共識是指多臺服務器或進程在一些值上達成一致的過程。RAFT確保了一致性，使得同一序列的命令產生相同序列的結果，并在所部署的各個成員中達到相同序列的狀態(tài)。

副本集成員相互間每隔兩秒發(fā)送一次心跳。如果某個成員在10秒內沒有反饋心跳，則其它成員會將不良成員標記為無法訪問。選舉算法將盡最大努力嘗試讓具有最高優(yōu)先權的從節(jié)點發(fā)起選舉。成員優(yōu)先權會影響選舉的時機和結果。優(yōu)先級高的從節(jié)點要比優(yōu)先級低的從節(jié)點更快發(fā)起選舉，而且也更有可能成為主節(jié)點。然而，低優(yōu)先級的從節(jié)點也是有可能被短暫的選舉為主節(jié)點的，副本集成員會繼續(xù)發(fā)起選舉直到可用的最高優(yōu)先級成員被選舉為主節(jié)點。被選舉為主節(jié)點的從節(jié)點必須擁有最新的復制數(shù)據(jù)。

三、優(yōu)先級

優(yōu)先級用于表示一個成員稱為主節(jié)點的優(yōu)先程度，取值范圍是0 ~ 100。數(shù)值越大，優(yōu)先級越高。默認為1，如果將priority設置為0，表示此節(jié)點永遠無法成為主節(jié)點，這樣的成員還有一個名字~被動成員。

四、選舉仲裁者

大多數(shù)小型項目，MongoDB只有兩個副本集，為了參與選舉，MongoDB支持一種特殊類型的成員，稱為仲裁者，其唯一作用就是參與仲裁。仲裁者不參與存儲數(shù)據(jù)，也不會為程序提供服務，它只是為了幫助只有兩個副本集的集群選舉主節(jié)點（為了滿足大多數(shù)），需要注意的是，只能有一個仲裁者。

仲裁者的缺點：

假設有一個主節(jié)點，兩個從節(jié)點，一個仲裁者。如果一個從節(jié)點停止運行了，那么就需要一個新的從節(jié)點，并且將主節(jié)點的數(shù)據(jù)復制到新的從節(jié)點，復制數(shù)據(jù)會父服務器造成很大的壓力，降低程序運行速度。所以，盡可能使用奇數(shù)的從節(jié)點，而不是使用仲裁者。

五、同步

MongoDB通過保存操作日志oplog使多臺服務器間保持相同的數(shù)據(jù)，oplog中保存著主節(jié)點執(zhí)行的每一次寫操作。oplog存在于主節(jié)點local數(shù)據(jù)庫中的一個固定集合中，從節(jié)點通過查詢此集合以獲取需要復制的操作。

每個從節(jié)點同樣維護著自己的oplog，用來記錄它從主節(jié)點復制的每個操作。這使得每個成員都可以被用作其他成員的同步源。如果應用某個操作失敗，則從節(jié)點會停止從當前數(shù)據(jù)源復制數(shù)據(jù)。

如果一個從節(jié)點由于某種原因停止工作了，它重新啟動后，會從oplog中的最后一個操作開始同步。由于這些操作是先應用到數(shù)據(jù)上然后再寫入oplog，因此從節(jié)點可能會重復已經應用到數(shù)據(jù)上的操作。MongoDB在設計時考慮了這點，oplog中的操作執(zhí)行一次和多次，效果都是一樣的，oplog中的每個操作都是冪等的。

六、處理過時數(shù)據(jù)

如果某個從節(jié)點的數(shù)據(jù)遠遠落后于同步源當前的操作，那么這個從節(jié)點就是過時的。過時的從節(jié)點無法趕上同步源，如果繼續(xù)同步，從節(jié)點就需要跳過一些操作。此時，需要從其它節(jié)點進行復制，看看其它成員是否有更長的oplog以繼續(xù)同步。如果都沒有，該節(jié)點當前的復制操作將停止，需要進行完全同步或從最近的備份中恢復。

為了避免出現(xiàn)不同步的節(jié)點，讓主節(jié)點擁有比較大的oplog以保存足夠多的操作日志。

七、哈希片鍵

為了盡可能快地加載數(shù)據(jù)，哈希片鍵是最好的選擇。哈希片鍵可以使任何字段隨機分發(fā)。如果打算在大量查詢中使用升序鍵，但又想在寫操作時隨機分發(fā)，哈希片鍵是不錯的選擇，不過需要注意的是，哈希片鍵無法執(zhí)行指定目標的范圍查詢。

創(chuàng)建哈希片鍵：

db.users.createIndex({"name":"hashed"})

有一點需要注意，哈希片鍵的字段，不能是數(shù)組。

Error: hashed indexes do not currently support array values

??????八、多熱點

單獨的mongod服務器在執(zhí)行升序寫操作時效率最高，這與分片相沖突，當寫操作分發(fā)在集群中時分片效率最高。每個分片上都有幾個熱點，便于寫操作在集群中均勻分發(fā)。

可以使用復合片鍵實現(xiàn)均勻分發(fā)，復合片鍵的第一個值可以是一個基數(shù)較小的值，片鍵的第二部分是一個升序值，這意味著在塊的內部，值總是在增加的。

九、分片規(guī)則

1、分片的限制

比如上圖的異常，片鍵不能是數(shù)組，大多數(shù)特殊類型的索引不能用作片鍵。特別是，不能在地理空間索引上進行分片。

2、片鍵的基數(shù)

片鍵與索引類似，在基數(shù)高的字段上進行分片，性能會更好。如果有一個status鍵，只有“正常”、“異常”、“錯誤”幾個值，MongoDB是無法將數(shù)據(jù)拆分成3個以上的塊（因為目前只有三個值），如果想將一個取值較小的鍵作為片鍵，那么可以將其與另一個擁有多值的鍵組成復合片鍵，比如createTime字段。這樣復合片鍵就擁有了較高的基數(shù)。

十、控制數(shù)據(jù)分發(fā)

1、自動分片

MongoDB將集合均勻分發(fā)在集群中的每個分片上，如果存儲的是同構數(shù)據(jù)，那么這種方式非常高效。如果有一個日志集合，價值不是很大，你可能不希望它存儲在性能最好的服務器上，性能最好的服務器一般會存儲重要的實時數(shù)據(jù)，而不允許其它集合使用它。

可以通過sh.addShardToZone("shard0","hign")、sh.addShardToZone("shard1","low")、sh.addShardToZone("shard2","low")實現(xiàn)它。

可以將不同的集合分配給不同的分片，比如，對及其重要的實時集合執(zhí)行：

sh.updateZoneKeyRange("super.important",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey},"high")

這條命令指的是：

對于這個集合super.important，將片鍵從負無窮到正無窮的數(shù)據(jù)保存在標記為“high”的分片上。這不會影響其它集合的均勻分發(fā)。

同樣可以通過low，將不重要的日志集合存放在性能較差的服務器上。

sh.updateZoneKeyRange("super.logs",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey},"low")

此時，日志集合就會均勻的分發(fā)到shard1和shard2上。

同樣，可以通過removeShardFromZone()從區(qū)域中刪除分片。

sh.removeShardFromZone("super.logs",{"<shardKey>":MinKey},...{"<shardKey>":MaxKey})

2、手動分發(fā)

可以通過關閉均衡器 sh.stopBalancer()啟動手動分發(fā)。

如果當前正在進行遷移，則此設置在遷移完成之前不會生效。一旦正在運行的遷移完成，均衡器就會停止移動數(shù)據(jù)。

除非遇到特殊情況，否則，MongoDB應該使用自動分片，而不是手動分片。

到此這篇關于MongoDB高可用與分片的文章就介紹到這了,更多相關MongoDB高可用與分片內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論