MongoDB中怎么實現集群

本篇文章給大家分享的是有關MongoDB中怎么實現集群，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

基本概念

文檔（document）：文檔是MongoDB的核心概念，是數據的基本單元，類似于關系數據庫中的行。在MongoDB中，文檔表示為鍵值對的一個有序集。文檔一般使用如下的樣式來標記：

{"title":"hello!"} {"title":"hello!","recommend":5} {"title":"hello!","recommend":5,"author":{"firstname":"paul","lastname":"frank"}}

從上面的例子可以看到，文檔的值有不同的數據類型，甚至可以是一個完整的內嵌文檔（***一個示例的author就是一個文檔）

集合（collection）：集合是一組文檔的集合，相當于關系型數據庫中的數據表，MongoDB數據庫不是關系型數據庫，沒有模式的概念。同一集合中的文檔可以有不同的形式。比如：

{"name":"jack","age":19}  {"name":"wangjun","age":22,"sex":"1"}

可以存在同一個集合當中。

數據庫（database）：多個文檔構成集合，多個集合組成數據庫。一個MongoDB實例可以承載多個數據庫，每個數據庫可以擁有0到多個集合。

MongoDB 的主要目標是在鍵值對存儲方式（提供了高性能和高度伸縮性）以及傳統的 RDBMS（關系性數據庫）系統，集兩者的優勢于一身。MongoDB適用于以下場景：

• 網站數據：Mongo 非常適合實時的插入，更新與查詢，并具備網站實時數據存儲所需的復制及高度伸縮性。

• 緩存：由于性能很高，Mongo 也適合作為信息基礎設施的緩存層。在系統重啟之后，由 Mongo 搭建的持久化緩存可以避免下層的數據源過載。 

• 大尺寸、低價值的數據：使用傳統的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。

• 高伸縮性的場景：Mongo非常適合由數十或數百臺服務器組成的數據庫

• 用于對象及JSON數據的存儲：Mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。

當然 MongoDB 也有不適合的場景：

• 高度事務性的系統：例如銀行或會計系統。傳統的關系型數據庫目前還是更適用于需要大量事務的應用程序。

• 傳統的商業智能應用：針對特定問題的 BI 數據庫能夠提供高度優化的查詢方式。對于此類應用，數據倉庫可能時更適合的選擇（如Hadoop套件中的Hive）。

• 需要SQL的問題。  

集群攻略

MongoDB在商用環境中，為了高可用性，通常都是以集群形式使用的，MongoDB的集群環境搭建非常簡單，下面就作一個介紹。

主從模式

我們在使用MySQL數據庫時廣泛采用的模式，采用雙機備份后主節點掛掉了后從節點可以接替主機繼續服務。所以這種模式比單節點的要可靠得多。

下面看一下怎么一步步搭建MongoDB的主從復制節點：

1. 準備兩臺機器 10.43.159.56 和 10.43.159.58。 10.43.159.56當作主節點， 10.43.159.58作為從節點。

2. 分別下載MongoDB安裝程序包。在10.43.159.56上建立文件夾/data/MongoDBtest/master，10.43.159.58建立文件夾/data/MongoDBtest/slave。

3. 在10.43.159.56啟動MongoDB主節點程序。注意后面的這個 “ –master ”參數，標示主節點：

mongod –dbpath /data/MongoDBtest/master–master

輸出日志如下，成功：

[initandlisten] MongoDB starting :pid=18285 port=27017 dbpath=/data/MongoDBtest/master master=1

4. 在10.43.159.58啟動MongoDB從節點程序。關鍵配置：指定主節點ip地址和端口 –source 10.43.159.56:27017 和標示從節點 –slave參數：

mongod –dbpath /data/MongoDBtest/slave–slave –source 10.43.159.56:27017

輸出日志如下，成功：

[initandlisten] MongoDB starting : pid=17888port=27017 dbpath=/data/MongoDBtest/slave slave=1

日志顯示從節點從主節點同步復制數據 ：

[replslave] repl: from host: 10.43.159.56:27017

這樣，主從結構的MongoDB集群就搭建好了，是不是很簡單？

下面我們來看看這個集群能做什么？先登錄到從節點shell上，執行插入數據：

mongo 127.0.0.1:27017    > db.testdb.insert({"test3":"testval3"});    not master

可以看到 MongoDB的從節點是只能讀，不能執行寫操作的。

那么如果主服務器掛掉，從服務器可以接替工作嗎？

可以試一下，強制關掉主節點上的MongoDB進程，登錄在從節點上，再次執行插入數據：

> db.testdb.insert({"test3":"testval3"});    not master

看來從節點并沒有自動接替主節點的工作，那就只有人工處理了，停止從節點，再以master的方式啟動從節點，由于從節點上數據跟主節點一樣，此時從節點是可以替代主節點工作的，這屬于人工切換。

此外，我們可以搭建多個從節點，實現數據庫的讀寫分離，比如主節點負責寫，多個從節點負責讀，對于移動APP，絕大部分操作都是讀操作，可以實現負荷分擔。

那么，搭建了這套主從結構的集群是不是就能應付商用環境呢？我們發現還是有幾個問題亟待解決的：

• 主節點掛了能否自動切換連接？目前需要手工切換。

• 主節點的寫壓力過大如何解決？

• 從節點每個上面的數據都是對數據庫全量拷貝，從節點壓力會不會過大？

• 就算對從節點路由實施路由訪問策略能否做到自動擴展？

解決這幾個問題就要靠下面介紹的副本集模式了。

副本模式

MongoDB官方已經不建議使用主從模式了，替代方案是采用副本集的模式，那什么是副本集呢？簡單地說，副本集就是有自動故障恢復功能的主從集群，或者說主從模式其實就是一個單副本的應用，沒有很好的擴展性和容錯性。而副本集具有多個副本保證了容錯性，就算一個副本掛掉了還有很多副本存在，更棒的是副本集很多地方都是自動化的，它為你做了很多管理工作。聰明的讀者已經發現，主從模式的***個問題手工切換已經得到解決了，難怪MongoDB官方強烈推薦使用這種模式。我們來看看MongoDB副本集的架構圖：

由圖可以看到客戶端連接到整個副本集，不關心具體哪一臺機器是否掛掉。主服務器負責整個副本集的讀寫，副本集定期同步數據備份，一旦主節點掛掉，副本節點就會選舉一個新的主服務器，這一切對于應用服務器不需要關心。我們看一下主服務器掛掉后的架構：

副本集中的副本節點通過心跳機制檢測到主節點掛掉后，就會在集群內發起主節點的選舉機制，自動選舉一位新的主服務器。So Cool！讓我們趕緊來部署一下！

官方推薦的副本集機器數量為至少3個（官方說副本集數量***是奇數），那我們也按照這個數量配置測試。

1. 準備三臺機器 10.43.159.56、 10.43.159.58、10.43.159.60。10.43.159.56當作副本集主節點，10.43.159.58、10.43.159.60作為副本集副本節點。

2. 分別在每臺機器上建立MongoDB副本集測試文件夾

3. 下載安裝MongoDB的安裝程序包

4. 分別在每臺機器上啟動MongoDB

給你的副本集取個名字吧，比如這里叫test：

/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongod  --dbpath /data/MongoDBtest/replset/data   --replSet test

從日志可以看出副本集還沒有初始化。

5. 初始化副本集

在三臺機器上任意一臺機器登陸MongoDB：

/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongo

使用admin數據庫：

use admin

定義副本集配置變量，這里的 _id:”test” 和上面命令參數“ –replSet test” 要保持一致：

config = { _id:"test", members:[  ... {_id:0,host:" 10.43.159.56:27017"},  ... {_id:1,host:" 10.43.159.58:27017"},  ... {_id:2,host:" 10.43.159.60:27017"}]  ... }

初始化副本集配置：

rs.initiate(config);

輸出成功：

{        "info" : "Config now saved locally.  Should come online in about a minute.",        "ok" : 1    }

查看日志，副本集啟動成功后，56為主節點PRIMARY，58、60為副本節點SECONDARY，注意這里是三個節點共同選舉出的主節點，有一定隨機性。

查看集群節點的狀態：

rs.status();

整個副本集已經搭建成功了。是不是超級簡單？

副本集模式的MongoDB不僅搭建簡單，而且功能強大。現在回頭看看這種模式能否解決我們前面遺留的問題：主節點掛了能否自動切換連接？

先測試副本集數據復制功能是否正常

首先在主節點56上插入數據，然后再副本節點上查看數據，發現日志報錯：

error: { "$err" : "not master and slaveOk=false", "code" : 13435 } at src/mongo/shell/query.js:128

這是因為默認只從主節點讀寫數據，副本不允許讀，只要設置副本可以讀即可。在副本節點上執行：rs.slaveOk()，然后查詢數據，發現主節點的數據已經同步過來了。

再測試下副本集的故障轉移功能

先停掉主節點56上的進程，可以看到58和60節點上的日志顯示的就是投票過程。再執行rs.status()可以看到集群狀態更新了，56為不可達，58成為主節點，60還是副本。再啟動56節點，發現還是58為主節點，56變為副本節點。這樣就解決了***個故障自動轉移的問題。

那么，對于主節點讀寫壓力過大，如何解決呢？常見的解決方案是讀寫分離，MongoDB副本集的讀寫分離如何做呢？

看圖說話：

對于移動APP的場景，通常寫操作遠沒有讀操作多，所以一臺主節點負責寫，兩臺副本節點負責讀。從哪個節點讀，完全可以由客戶端選擇，數據讀取參數一共有五類（Primary、PrimaryPreferred、Secondary、SecondaryPreferred、Nearest）：

• Primary：默認參數，只從主節點上進行讀取操作； 

• PrimaryPreferred：大部分從主節點上讀取數據，只有主節點不可用時從Secondary節點讀取數據。 

• Secondary：只從Secondary節點上進行讀取操作，存在的問題是Secondary節點的數據會比Primary節點數據“舊”。 

• SecondaryPreferred：優先從Secondary節點進行讀取操作，Secondary節點不可用時從主節點讀取數據； 

• Nearest：不管是主節點、Secondary節點，從網絡延遲***的節點上讀取數據。

典型的副本集組網中，除了有副本節點，還有其他角色，比如仲裁節點，如下圖：

其中的仲裁節點不存儲數據，只是負責故障轉移的群體投票，這樣就少了數據復制的壓力。此外還有Secondary-Only、Hidden、Delayed、Non-Voting等角色。

Secondary-Only：不能成為Primary節點，只能作為Secondary副本節點，防止一些性能不高的節點成為主節點。

Hidden：這類節點是不能夠被客戶端制定IP引用，也不能被設置為主節點，但是可以投票，一般用于備份數據。

Delayed：可以指定一個時間延遲從Primary節點同步數據。主要用于備份數據，如果實時同步，誤刪除數據馬上同步到從節點，恢復又恢復不了。

Non-Voting：沒有選舉權的Secondary節點，純粹的備份數據節點。

以上就是MongoDB中怎么實現集群，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。