副本集的概念
副本集是一組伺服器,其中有一個是主伺服器(primary),用於處理客戶端請求;還有多個備份伺服器(secondary),用於儲存主伺服器的資料副本。如果主伺服器崩潰了,備份伺服器會自動將其中一個成員升級為新的主伺服器。
副本集特徵:
· N 個節點的叢集
· 任何節點可作為主節點
· 所有寫入操作都在主節點上
· 自動故障轉移
· 自動恢復
副本集還有以下幾個需要注意的地方:
1. 最小構成是:primary,secondary,arbiter,一般部署是:primary,2 secondary。
2. 成員數應該為奇數,如果為偶數的情況下新增arbiter,arbiter不儲存資料,只投票。
3. 最大50 members,但是隻能有 7 voting members,其他是non-voting members。
1、資料同步
Mongo的複製功能是通過oplog實現的,oplog包含了主節點的每一次寫操作,是主節點的local資料庫中的一個固定集合,備份節點通過查詢這個集合就可以知道需要進行復制的操作。每個備份節點有自己的oplog,這樣每個成員就可以當作同步源提供給其他成員使用。備份節點從當前同步源中獲取需要執行的操作,然後在自己的資料集上執行這些操作,最後將這些操作寫入自己的oplog。
如果備份節點掛了,當它重啟後,會自動從oplog中最後一個操作開始同步,由於複製操作的過程是先複製資料再寫入oplog,所以備份節點有可能在已經同步過的資料上再次執行復制操作。Mongo是這麼處理的:將oplog中的同一操作執行多次與只執行一次的效果是一樣。
由於oplog大小是固定的,通常它的使用空間的增長速度與系統處理寫請求的速率近乎相同。但是有些例外情況:如果單次處理能夠影響到多個文件,那麼每個受影響的文件都會對應oplog的一條日誌。比如執行db.coll.remove()刪除了1000000個文件,那麼oplog中就會有1000000條操作日誌,這樣oplog很快就會被填滿。
2、仲裁節點
仲裁者唯一的作用就是選舉,不儲存資料,也不會為客戶端提供服務,它只是為了滿足“大部分”的要求
新增仲裁者的兩種方式
>rs.addArb(“server-5:27017”)
>rs.add({“_id”:4,”host”:” server-5:27017”,”arbiterOnly”:true})
仲裁的缺點
比如有三個成員的副本集,其中一個是仲裁節點。當一個資料節點掛了,那麼另一個資料節點成為主節點,為了保證資料安全,就需要新增一個新的備份節點,但由於仲裁節點無資料,那麼新節點的資料傳輸只能靠當前的主節點完成。那麼它不僅要處理應用程式請求,還要資料複製到備份節點,會造成伺服器壓力巨大
所以儘量配置成奇數個資料成員,而不使用仲裁者
3、優先順序
優先順序表示一個成員渴望成為主節點的程度,取值範圍0-100,預設1,0代表永遠不能成為主節點(passive member)
優先順序別高的會優先選舉為主節點(只要他能得到大部分的支援,並且資料是最新的)
4、心跳
每個成員每隔兩秒都會向其他成員傳送一個心跳請求,用於檢查每個成員的狀態,知道自己是否符合大多數的條件。
5、回滾
如果主節點執行了一次寫請求後掛了,但是備份節點還沒來得及複製這次操作,那麼新選舉出來的主節點就會漏掉這次寫操作。這時就會執行回滾過程。
6、記憶體管理mmap
MongoDB應該分配的記憶體大小最好滿足記憶體大小>索引+熱資料+連線佔用記憶體,通過db.stats()命令可檢視到當前資料庫的索引大小情況
db.stats()
下面是公司的MongoDB儲存了14億資料,佔1.4T儲存空間
shard1:SECONDARY> db.stats() { "db" : "database", // 當前使用的資料庫 "collections" : 662, // 多少張表 "objects" : 1405948982, // 所有表的多少條資料 -- 14.05億 "avgObjSize" : 1134.649427176014, // 平均每條資料大小 "dataSize" : 1595259207065, // 總資料大小 -- 1.485TB "storageSize" : 768647647232, // 所有資料佔磁碟的大小 -- 715.85G "numExtents" : 0, "indexes" : 1098, // 索引數量 "indexSize" : 173431967744, // 索引大小 -- 160G "ok" : 1 }