前言

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

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

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

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

一個(gè)健壯的簡單的MongoDB集群的搭建需要十個(gè)服務(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ù)雜。

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

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

主節(jié)點(diǎn)[Primary]

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

副本節(jié)點(diǎn)[Secondary]

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

仲裁者[Arbiter]

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

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

搭建集群

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

前期準(zhǔn)備

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

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

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

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