溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章的內容主要圍繞Replica Sets機制在4sq中有哪些架構方式進行講述，文章內容清晰易懂，條理清晰，非常適合新手學習，值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲！
MongoDB的replication機制除了最普通的Master/Slave模式之外，更強大的就是其支持自動故障轉移的ReplicaSets模式了。相對于其問題多多的auto-sharding機制，ReplicaSets還是相對比較穩定。
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這一誘人的功能。
感謝你的閱讀，相信你對“Replica Sets機制在4sq中有哪些架構方式”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關知識點，可以關注億速云網站！小編會繼續為大家帶來更好的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
