MongoDB的replication機制除了最普通的Master/Slave模式之外，更強大的就是其支持自動故障轉移的ReplicaSets模式了。相對於其問題多多的auto-sharding機制，ReplicaSets還是相對比較穩定。下面學步園小編來講解下ReplicaSets機制在4sq中有幾種架構方式?
ReplicaSets機制在4sq中有幾種架構方式
1.在原有的Master/Slave機制上添加一台arbiter
4sq在早期有一些Master/Slave的MongoDB架構，但這種模式不能實現自動的故障轉移，需要在發生故障時手動進行切換。在ReplicaSets出現後，這種結構被遷移成為三台機器的ReplicaSets：一台Primary，一台Secondary，一台Arbiter。
遷移過程：
修改Master和slave的配置，添加如下幾項，並重啟MongoDB。
replSet=auxdb
fastsync=true
rest=true
fastsync使得重啟動可以使用到原來的數據文件，重啟會非常快。然後再在Primary上用rs.add和rs.addArb將Secondary和Arbiter添加上。就算完成了。
ReplicaSets機制在4sq中有幾種架構方式
2.一個Primary用於寫，多個Secondary用於讀和一個Secondary用於備份
在寫多讀少的應用中，4sq主要使用了ReplicaSets來實現讀寫分離。通過在連接時指定slaveOk，將讀操作放到Secondary上，Primary只承擔寫操作。同時指定一台priority為0，hidden為true的Secondary來進行備份(這樣設置後此機器在讀寫中都不可見，並且不會被選舉為Primary)
3.MongoDB經典配置，上層是Auto-Sharding，每個Sharding結點又是一個ReplicaSets
雖然4sq在這上面吃過虧，但很明顯他們已經吸取了教訓並且在更合理更小心的使用Auto-Sharding這一誘人的功能。
以上就是關於「ReplicaSets機制在4sq中有幾種架構方式」的內容，希望對大家有用。更多資訊請關注學步園。學步園，您學習IT技術的優質平台!