摘要：所有的讀操作都在復(fù)制集的從節(jié)點(diǎn)上執(zhí)行。讀操作會在復(fù)制集中網(wǎng)絡(luò)延時(shí)最小的節(jié)點(diǎn)上進(jìn)行，與節(jié)點(diǎn)類型無關(guān)。根據(jù)上面講的，如果復(fù)制集的讀選項(xiàng)是配置的。為了避免這種情況，提高服務(wù)的可用性，可以在服務(wù)器上部署一個(gè)投票節(jié)點(diǎn)。

1.備份數(shù)據(jù)
通過自帶的 mongo_dump/mongo_restore 工具也可以實(shí)現(xiàn)備份，但是畢竟沒有復(fù)制集的自動(dòng)同步備份方便。

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

3.在某些特定的場景下提高讀性能
默認(rèn)情況下，讀和寫都只能在主節(jié)點(diǎn)上進(jìn)行。
下面是MongoDB的客戶端支持5種復(fù)制集讀選項(xiàng)：

primary：默認(rèn)模式，所有的讀操作都在復(fù)制集的 主節(jié)點(diǎn) 進(jìn)行的。

primaryPreferred：在大多數(shù)情況時(shí)，讀操作在 主節(jié)點(diǎn) 上進(jìn)行，但是如果主節(jié)點(diǎn)不可用了，讀操作就會轉(zhuǎn)移到 從節(jié)點(diǎn) 上執(zhí)行。

secondary：所有的讀操作都在復(fù)制集的 從節(jié)點(diǎn) 上執(zhí)行。

secondaryPreferred：在大多數(shù)情況下，讀操作都是在 從節(jié)點(diǎn) 上進(jìn)行的，但是當(dāng) 從節(jié)點(diǎn) 不可用了，讀操作會轉(zhuǎn)移到 主節(jié)點(diǎn) 上進(jìn)行。

nearest：讀操作會在 復(fù)制集 中網(wǎng)絡(luò)延時(shí)最小的節(jié)點(diǎn)上進(jìn)行，與節(jié)點(diǎn)類型無關(guān)。

來源：http://docs.mongoing.com/manual-zh/core/read-preference.html

不推薦在從節(jié)點(diǎn)上進(jìn)行讀操作，因?yàn)閺墓?jié)點(diǎn)上的數(shù)據(jù)可能不是最新數(shù)據(jù)（主要原因）。
在從節(jié)點(diǎn)上進(jìn)行讀操作的場景很有限，官方手冊中寫明了適用的場景和不推薦從節(jié)點(diǎn)讀操作的多個(gè)原因：http://docs.mongoing.com/manual-zh/core/read-preference.html#use-cases

說說我自己的看法：復(fù)制集并不是為了提高讀性能而存在的，除了個(gè)別場景，不推薦在從節(jié)點(diǎn)上進(jìn)行讀操作。如果想提升讀性能，那么請使用索引和分片。插一句，如果數(shù)據(jù)規(guī)模不大，就沒必要使用分片了。我們線上數(shù)據(jù)庫中單個(gè)集合記錄有將近 2 億條，性能還比較 OK（當(dāng)然，機(jī)器配置也不差，而且上面就只跑了一個(gè) Redis 和一個(gè) MongoDB）。

請看手冊：http://docs.mongoing.com/manual-zh/tutorial/deploy-replica-set.html

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

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

這樣配置后，如果只是其中一臺 MongoDB 服務(wù)掛斷后，剩余的節(jié)點(diǎn)會自動(dòng)選舉出新的主節(jié)點(diǎn)，程序還是可以繼續(xù)正常運(yùn)行。在選舉的過程中，程序還是會拋出異常的，盡管選舉過程很快，但是為了程序的健壯性，必須考慮異常的處理。當(dāng)然，如果選舉不出新的主節(jié)點(diǎn)，那么整個(gè) MongoDB 就不可用了。（根據(jù)上面講的，如果復(fù)制集的讀選項(xiàng)是配置的 primaryPreferred。如果沒有了主節(jié)點(diǎn)，但是從節(jié)點(diǎn)還可用的話，那么讀操作將轉(zhuǎn)移到從節(jié)點(diǎn)上去，這樣整個(gè) MongoDB 復(fù)制集還能提供讀操作服務(wù)）

其實(shí)如果指定了復(fù)制集名 "replicaSet" => "rs0"，那么就算不列出所有節(jié)點(diǎn)地址，僅寫一個(gè)有效節(jié)點(diǎn)地址，mongo 驅(qū)動(dòng)會自動(dòng)獲取到所有有效節(jié)點(diǎn)，$client->getHosts() 方法可以查看所有有效節(jié)點(diǎn)的地址。

但是如果你只寫了一個(gè)節(jié)點(diǎn)地址，剛好是那個(gè)節(jié)點(diǎn)掛掉了，那就連不上了。所有我建議配置完整的節(jié)點(diǎn)地址列表。

開啟復(fù)制集后，會在 local 庫下生成一個(gè)集合叫 oplog.rs，這是一個(gè)有限集合，也就是大小是固定的。每次對數(shù)據(jù)庫的寫操作都會被記錄到這個(gè)集合里面。復(fù)制集中的節(jié)點(diǎn)就是通過讀取其他節(jié)點(diǎn)上面的 oplog 來實(shí)現(xiàn)數(shù)據(jù)同步的。

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

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

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

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

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

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

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

那么，這個(gè)時(shí)候就得重新同步了。恩，回不去的就永遠(yuǎn)回不去了，再找個(gè)新的重新開始吧。(逃

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

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

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

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

journal = false
smallfiles = true
noprealloc = true

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