# ? ? ? ? ? ? ? ? ? ? ? ? ? ?

MongoDB教學(xué)介紹為什麼要使用複製集

推薦（免費)：MongoDB教學(xué)

為什麼要使用複製集

1.備份資料
透過自帶的mongo_dump/mongo_restore 工具也可以實現(xiàn)備份，但畢竟沒有複製集的自動同步備份方便。

2.故障自動轉(zhuǎn)移
部署了複製集，當主節(jié)點掛了後，叢集會自動投票再從節(jié)點中選出一個新的主節(jié)點，繼續(xù)提供服務(wù)。而且這一切都是自動完成的，對維運人員和開發(fā)人員是透明的。當然，發(fā)生故障了還是得人工及時處理，不要過度依賴複製集，萬一都掛了，那就連喘息的時間都沒有了。

3.在某些特定的場景下提高讀取效能
預(yù)設(shè)情況下，讀取和寫入都只能在主節(jié)點上進行。
下面是MongoDB的客戶端支援5種複製集讀選項：

• primary：預(yù)設(shè)模式，所有的讀取操作都在複製集的 主節(jié)點 進行的。
• primaryPreferred：在大多數(shù)情況時，讀取操作在 主節(jié)點 上進行，但是如果主節(jié)點不可用了，讀取操作就會轉(zhuǎn)移到 從節(jié)點 上執(zhí)行。
• secondary：所有的讀取操作都在複製集的 從節(jié)點 上執(zhí)行。
• secondaryPreferred：在大多數(shù)情況下，讀取操作都是在 從節(jié)點 上進行的，但是當 從節(jié)點 不可用了，讀取操作會轉(zhuǎn)移到 主節(jié)點 上進行。
• nearest：讀取操作會在 複製集 中網(wǎng)路延時最小的節(jié)點上進行，與節(jié)點類型無關(guān)。

來源：http://docs.mongoing.com/manual-zh/core/re...

不建議在從節(jié)點上進行讀取操作，因為從節(jié)點上的資料可能不是最新資料（主要原因）。
在從節(jié)點上進行讀取操作的場景很有限，官方手冊中寫明了適用的場景和不推薦從節(jié)點讀取操作的多個原因：http://docs.mongoing.com/manual-zh/ core/re...

說說我自己的看法：複製集並不是為了提高讀取效能而存在的，除了個別場景，不建議在從節(jié)點上進行讀取操作。如果想提升讀取效能，那麼請使用索引和分片。插一句，如果資料規(guī)模不大，就沒必要使用分片了。我們線上資料庫中單一集合記錄有將近 2 億條，效能還比較 OK（當然，機器配置也不差，而且上面就只跑了一個 Redis 和一個 MongoDB）。

如何部署複製集

##請看手冊：http://docs.mongoing.com/manual-zh/tutoria...

如何在程式中使用MongoDB 複製集故障自動轉(zhuǎn)移的特性

以PHP 的mongo 驅(qū)動為例。

$client?=?new?MongoClient('mongodb://192.168.1.2:27018,192.168.1.3:27019,192.168.1.4:27020',?array('replicaSet'?=>?'rs0'));

這樣設(shè)定後，如果只是其中一臺 MongoDB 服務(wù)掛接後，剩餘的節(jié)點會自動選出新的主節(jié)點，程式還是可以繼續(xù)正常運作。在選舉的過程中，程序還是會拋出異常的，儘管選舉過程很快，但是為了程序的健壯性，必須考慮異常的處理。當然，如果選舉不出新的主節(jié)點，那麼整個 MongoDB 就不可用了。 （根據(jù)上面講的，如果複製集的讀取選項是配置的

primaryPreferred。如果沒有了主節(jié)點，但是從節(jié)點還可用的話，那麼讀取操作將轉(zhuǎn)移到從節(jié)點上去，這樣整個MongoDB 複製集還能提供讀取操作服務(wù)）

其實如果指定了複製集名

'replicaSet' => 'rs0'，那麼就算不列出所有節(jié)點位址，只寫一個有效節(jié)點位址，mongo 驅(qū)動程式會自動取得到所有有效節(jié)點，$client->getHosts() 方法可以查看所有有效節(jié)點的位址。

但是如果你只寫了一個節(jié)點位址，剛好是那個節(jié)點掛掉了，那就連不上了。

所有我建議配置完整的節(jié)點位址清單。

同步的原理是什麼

開啟複製集後，會在

local 函式庫下產(chǎn)生一個集合叫oplog.rs，這是一個有限集合，也就是大小是固定的。每次資料庫的寫入操作都會被記錄到這個集合裡面。複製集中的節(jié)點就是透過讀取其他節(jié)點上面的 oplog 來實現(xiàn)資料同步的。

舉個例子：
用客戶端向主節(jié)點添加了 100 條記錄，那么 oplog 中也會有這 100 條的 insert 記錄。從節(jié)點通過獲取主節(jié)點的 oplog，也執(zhí)行這 100 條 oplog 記錄。這樣，從節(jié)點也就復(fù)制了主節(jié)點的數(shù)據(jù)，實現(xiàn)了同步。

需要說明的是：并不是從節(jié)點只能獲取主節(jié)點的 oplog。

為了提高復(fù)制的效率，復(fù)制集中所有節(jié)點之間會互相進行心跳檢測（通過ping）。每個節(jié)點都可以從任何其他節(jié)點上獲取oplog。

還有，用一條語句批量刪除 50 條記錄，并不是在 oplog 中只記錄一條數(shù)據(jù)，而是記錄 50 條單條刪除的記錄。

oplog中的每一條操作，無論是執(zhí)行一次還是多次執(zhí)行，對數(shù)據(jù)集的影響結(jié)果是一樣的，i.e 每條oplog中的操作都是冪等的。

什么情況下需要重新同步

在上一個問題中得知：oplog 大小是固定的，而且 oplog 里面的記錄數(shù)不一定和節(jié)點中的數(shù)據(jù)量成正比。那么，新記錄肯定會將前面的老記錄給覆蓋。

如果，有天一個從節(jié)點掛了，其他節(jié)點還在正常運行，繼續(xù)有寫操作，oplog 繼續(xù)增長。而這個掛掉的節(jié)點一直不能從其他節(jié)點那里同步最新的 oplog 記錄，當其他節(jié)點的 oplog 已經(jīng)發(fā)生的覆蓋。即使這個從節(jié)點后來恢復(fù)了正常，也不會和其他節(jié)點保持數(shù)據(jù)一致了。因為，覆蓋的就永遠回不來了。

那么，這個時候就得重新同步了。恩，回不去的就永遠回不去了，再找個新的重新開始吧。(逃

如何重新同步

參見：復(fù)制集成員的重新同步

什么時候應(yīng)該使用投票節(jié)點

當復(fù)制集中有偶數(shù)個節(jié)點時，應(yīng)該再加一個投票節(jié)點，用于打破投票僵局。

比如：我線上共有3臺服務(wù)器，其中1臺是作為 Web 服務(wù)器；其余2臺作為 DB 服務(wù)器，各部署了1個MongoDB節(jié)點，構(gòu)成了2個節(jié)點的復(fù)制集。這個時候，我并沒有多余的機器了。在這個情況下，如果任意一臺 DB 服務(wù)器上的 MongoDB 掛了，那么另外一臺的 MongoDB 必然變?yōu)?SECONDARY 節(jié)點，那么就意味著 MongoDB 是不可用的了。為了避免這種情況，提高服務(wù)的可用性，可以在 Web 服務(wù)器上部署一個投票節(jié)點。投票節(jié)點并不存儲數(shù)據(jù)，因此不能升職為 PRIMARY 節(jié)點，它對于硬件資源要求很低，并不會對 Web 服務(wù)器上的其他程序產(chǎn)生太大影響。這種情況下，如果任意一臺 DB 服務(wù)器掛了，另外一臺服務(wù)器上的 MongoDB 將成為 PRIMARY 節(jié)點，此時 MongoDB 還是依舊對外提供服務(wù)的。乘此時機，趕緊排查出故障的那臺服務(wù)器的原因，盡快恢復(fù)服務(wù)。

為了讓投票節(jié)點可以占用更少的資源，可以在配置文件中添加以下幾個配置項：

journal?=?false
smallfiles?=?true
noprealloc?=?true

主從復(fù)制

master-slave 復(fù)制架構(gòu)已經(jīng)不推薦使用了，建議使用 replica sets 復(fù)制集架構(gòu)。
參見：http://docs.mongoing.com/manual-zh/core/ma...

以上是講講關(guān)於 MongoDB 複製集的幾個問題的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！