使用MongoDB Replica Sets的三種架構)

文章目錄

• 1.在原有的Master/Slave 機制上添加一台arbiter
• 2.一個 Primary用於寫，多個Secondary用於讀和一個Secondary用於備份
• 3.MongoDB經典配置，上層是Auto-Sharding，每個Sharding結點又是一個Replica Sets

原文：http://blog.nosqlfan.com/html/1750.html

MongoDB 的replication機制除了最普通的Master/Slave模式之外，更強大的就是其支援自動容錯移轉的Replica Sets模式了。相對於其問題多多的auto-sharding機制，Replica Sets還是相對比較穩定。

作為MongoDB使用大戶，Foursquare（簡稱4sq） 在MongoDB使用上有相當豐富的經驗，下面是4sq的一篇文章，描述了Replica Sets機制在4sq 中的幾種架構方式。

原文連結：Fun with MongoDB replica sets

1.在原有的Master/Slave 機制上添加一台arbiter

4sq 在早期有一些Master/Slave的MongoDB架構，但這種模式不能實現自動的容錯移轉，需要在發生故障時手動進行切換。在Replica Sets出現後，這種結構被遷移成為三台機器的Replica Sets：一台Primary，一台Secondary，一台Arbiter。

遷移過程：

修改Master和slave的配置，添加如下幾項，並重啟MongoDB。

replSet = auxdb
fastsync = true
rest = true

fastsync 使得重啟動可以使用到原來的資料檔案，重啟會非常快。然後再在Primary上用rs.add 和 rs.addArb 將Secondary和Arbiter添加上。就算完成了。

2.一個 Primary用於寫，多個Secondary用於讀和一個Secondary用於備份

在寫多讀少的應用中，4sq主要使用了Replica Sets來實現讀寫分離。通過在串連時指定slaveOk，將讀操作放到Secondary上，Primary只承擔寫操作。同時指定一台 priority為0，hidden為true的Secondary來進行備份（這樣設定後此機器在讀寫中都不可見，並且不會被選舉為Primary）

3.MongoDB經典配置，上層是Auto-Sharding，每個Sharding結點又是一個Replica Sets

雖然4sq在這上面吃過虧，但很明顯他們已經吸取了教訓並且在更合理更小心的使用Auto-Sharding這一誘人的功能。

備忘：

分區功能效能上損失不小，其他的叢集方式都不能解決擴容的問題。當前還是用戶端均衡好了。