no-image

關於 MongoDB 複製集的幾個問題

                                    

為什麼要使用複製集

1.備份資料
通過自帶的 mongo_dump/mongo_restore 工具也可以實現備份,但是畢竟沒有複製集的自動同步備份方便。

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

3.在某些特定的場景下提高讀效能
預設情況下,讀和寫都只能在主節點上進行。
下面是MongoDB的客戶端支援5種複製集讀選項:

primary:預設模式,所有的讀操作都在複製集的 主節點 進行的。

primaryPreferred:在大多數情況時,讀操作在 主節點 上進行,但是如果主節點不可用了,讀操作就會轉移到 從節點 上執行。

secondary:所有的讀操作都在複製集的 從節點 上執行。

secondaryPreferred:在大多數情況下,讀操作都是在 從節點 上進行的,但是當 從節點 不可用了,讀操作會轉移到 主節點 上進行。

nearest:讀操作會在 複製集 中網路延時最小的節點上進行,與節點型別無關。

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

不推薦在從節點上進行讀操作,因為從節點上的資料可能不是最新資料(主要原因)。
在從節點上進行讀操作的場景很有限,官方手冊中寫明瞭適用的場景和不推薦從節點讀操作的多個原因:http://docs.mongoing.com/manual-zh/core/read-preference.html#use-cases

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

如何部署複製集

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

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

以 PHP 的 mongo 驅動為例。

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

這樣配置後,如果只是其中一臺 MongoDB 服務結束通話後,剩餘的節點會自動選舉出新的主節點,程式還是可以繼續正常執行。在選舉的過程中,程式還是會丟擲異常的,儘管選舉過程很快,但是為了程式的健壯性,必須考慮異常的處理。當然,如果選舉不出新的主節點,那麼整個 MongoDB 就不可用了。(根據上面講的,如果複製集的讀選項是配置的 primaryPreferred

主從複製

master-slave 複製架構已經不推薦使用了,建議使用 replica sets 複製集架構。
參見:http://docs.mongoing.com/manual-zh/core/master-slave.html

關聯文章