MongoDB高可用分為哪些方式

這篇文章主要介紹“MongoDB高可用分為哪些方式”，在日常操作中，相信很多人在MongoDB高可用分為哪些方式問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MongoDB高可用分為哪些方式”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1 ： MongDB的架構設計之中，MongoDB支持多個機器之間通過異步復制達到故障轉移和實現冗余，多臺的機器之中只有一臺是用于寫操作，正是由于這個原因，在MongoDB之中只有一臺充當了Primary角色的機器能把讀操作分發給Slave。

MongoDB 高可用可以分為兩種的方式：

1：master——Slave 主從復制，目前已經不怎么實用了

2：Replica Sets復制集

        MongoDB 在1.6版之后加入了新的一個功能點叫做復制及：replica Set，增加了故障的自動切換和自動修復成員節點。各個DB之間的數據完全一致。大大降低了維護成功，

如圖：

                數學上來將，就是一個同構型的集合：也就是一個集群。MongoDB的Relica Set架構是通過一個日志來存儲寫操作的。這個操作就叫做”oplog“，oplog.rs 是一個固定長度的CappedCollection。這個Collection的位置存在于“Local數據庫之中”，用于記錄Replica Set操作的日志，它在默認的情況之下，對于64位的MongoDB，opLog是比較大的。可以達到5%的磁盤空間，oplog的大小是可以通過Mongod的參數 ”—oplogSize“來改變。

              除了固定的復制集意外，還保持了較好的伸縮性，一旦需求得不到滿足，那么就需要添加新的機器。那么句需要增加一些節點將壓力平均分配一下。

        增加節點的方式，一般可以通過oplog直接進行增加節點，操作簡單并且無需人工干預，可是oplog是

capped collection，采用的循環方式進行日志處理，所以采用的是oplog的方式來添加，可能會有不一致的問題。

因為日志中間存儲的信息由可能已經刷新過了。不過沒關系。通常而言，你可以通過數據庫的快照 --fastsync和oplog結合的

方式來增加節點。這種方式的操作流程是，先取某一個復制集成員的物理文件來作為一個初始化的數據，然后剩余的部分用

oplog的方式去添加。

而 Sharding，這是一種將海量的數據水平擴展的數據庫集群系統，數據庫分表存儲在 sharding的各個節點之上。MongoDB的數據分塊成為chunk，每一個Chunk都是Collection中一段連續的數據記錄，通常的最大的尺寸是200MB。超出那么就會生成一個最新的數據塊。這個和Hbase Region的分裂是一樣的。

整個分拆的過程大致如下：

對于MongoDB

首先在CL： Client 這一層面來說，底層是否需要分片？是否需要這樣的一個復制集對與使用者來說完全不必要知道。Mongos： 好比就是一個大管家，要怎么去分拆Collections？，你Client完全不必要知道，只需要你告訴我一個東西：分區的Key是什么？在很多的組件之中，包括在hadoop，Storm，等個各種數據庫之中都會有這樣的一個 Partition Key的概念。對應于我們的網絡之上就會充當了這樣一個路由的功能。并且將自己所把控的一些集群的信息存放在Config服務器之中。

在其他的數據庫中間也就是如此，對于Hbase。依然需要對于表再進行分拆。對應于Hbase之中的Region。和MongoDB的分片其實用一個比較常用的英文名字就叫做 Segment。

如果你對于Hbase之流不夠了解沒關系。你只是需要知道，Region是表分裂的一個片段，region按大小分割的，每個表一開始就只是一個Region，Region隨著數據的寫入會不斷的擴大，以至于達到了設計閾值以后，Region就開始分裂了，由1分二。當table中的行越來越多的時候，Region的數量就越來越多。

HRegion是Hbase之中分布式存儲和負載的最小的單位，在這里給出一個比照的圖：如下：

而在kafka之中之中的Replication，其實更加相當于Hadoop體系之中的 【副本機制】，和分片所需要解決的矛盾不同。

    簡單的額來說，分布式系統有自己獨特的屬性與性質，對于其存存儲體系有著固定的訴求。

到此，關于“MongoDB高可用分為哪些方式”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！