前言

最近一些變動，有一個老項目交由我們組負(fù)責(zé)維護(hù)，碰到這樣的事情我的內(nèi)心是崩潰的，但還得強(qiáng)顏歡笑，拍著胸脯說沒問題。更悲哀的是，該項目中還使用了mongo，還是自己搭建的，沒有交由DBA統(tǒng)一管理，無奈，只能趕鴨子上架，自己學(xué)習(xí)mongo了。

為什么使用集群架構(gòu)？

主從：故障轉(zhuǎn)移:無法實現(xiàn),如果主機(jī)宕機(jī)，需要關(guān)閉slave并且按照master模式啟動。無法解決單點故障 無法autofailover 不可以自動主從的切換

為了解決主從的問題，MongoDB3.0之后出現(xiàn)副本集，副本集解決了故障轉(zhuǎn)移的問題，但是一個副本集中的數(shù)據(jù)是相同的，無法做到海量數(shù)據(jù)的存儲。所以就需要一個架構(gòu)去解決這個問題。也就是分片式集群。

一個健壯的簡單的MongoDB集群的搭建需要十個服務(wù)進(jìn)程（分開搭建需要十臺服務(wù)器），這里在一臺虛擬機(jī)上進(jìn)行搭建。

關(guān)于MongoDB

mongodb的集群搭建方式主要有三種，主從模式，Replica set模式，sharding模式, 三種模式各有優(yōu)劣，適用于不同的場合，屬Replica set應(yīng)用最為廣泛，主從模式現(xiàn)在用的較少，sharding模式最為完備，但配置維護(hù)較為復(fù)雜。

而目前接手過來的項目所用的就是Replica set,所以也就主要了解了這個模式。官網(wǎng)介紹可以點擊這里

其中Replica Set模式中三類角色有必要知道下：

主節(jié)點[Primary]

接收所有的寫請求，然后把修改同步到所有Secondary。一個Replica Set只能有一個Primary節(jié)點，當(dāng)Primary掛掉后，其他Secondary或者Arbiter節(jié)點會重新選舉出來一個主節(jié)點。默認(rèn)讀請求也是發(fā)到Primary節(jié)點處理的，需要轉(zhuǎn)發(fā)到Secondary需要客戶端修改一下連接配置。

副本節(jié)點[Secondary]

與主節(jié)點保持同樣的數(shù)據(jù)集。當(dāng)主節(jié)點掛掉的時候，參與選主。

仲裁者[Arbiter]

不保有數(shù)據(jù)，不參與選主，只進(jìn)行選主投票。使用Arbiter可以減輕數(shù)據(jù)存儲的硬件需求，Arbiter跑起來幾乎沒什么大的硬件資源需求，但重要的一點是，在生產(chǎn)環(huán)境下它和其他數(shù)據(jù)節(jié)點不要部署在同一臺機(jī)器上。

注意，一個自動failover的Replica Set節(jié)點數(shù)必須為奇數(shù)，目的是選主投票的時候要有一個大多數(shù)才能進(jìn)行選主決策。

搭建集群

了解了基本概念之后，就開始嘗試搭建集群，為了更好的理解，特意找了三臺測試機(jī)進(jìn)行部署。

前期準(zhǔn)備

首先準(zhǔn)備三臺測試機(jī)：

 10.100.1.101 主節(jié)點(master)
 10.100.1.102 備節(jié)點(slave)
 10.100.1.103 仲裁點(arbiter)

然后就是mongo的安裝包(由于線上用的是3.4.2的版本，所以保持統(tǒng)一)

curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.4.2.tgz