Replica Sets機制在4sq中有哪些架構方式

這篇文章的內容主要圍繞Replica Sets機制在4sq中有哪些架構方式進行講述，文章內容清晰易懂，條理清晰，非常適合新手學習，值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲！

　　MongoDB的replication機制除了最普通的Master/Slave模式之外，更強大的就是其支持自動故障轉移的ReplicaSets模式了。相對于其問題多多的auto-sharding機制，ReplicaSets還是相對比較穩(wěn)定。

　　ReplicaSets機制在4sq中有幾種架構方式

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

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

　　遷移過程：

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

　　replSet=auxdb

　　fastsync=true

　　rest=true

　　fastsync使得重啟動可以使用到原來的數據文件，重啟會非?？臁Ｈ缓笤僭赑rimary上用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這一誘人的功能。

感謝你的閱讀，相信你對“Replica Sets機制在4sq中有哪些架構方式”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關知識點，可以關注億速云網站！小編會繼續(xù)為大家?guī)砀玫奈恼拢?/p>