投票成員數 | 大多數 | 容忍失效數 |
---|---|---|
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
通常建議將復制集成員數量設置為奇數,從上表可以看出3個節(jié)點和4個節(jié)點的復制集都只能容忍1個節(jié)點失效,從『服務可用性』的角度看,其效果是一樣的。(但無疑4個節(jié)點能提供更可靠的數據存儲)
特殊的Secondary
正常情況下,復制集的Seconary會參與Primary選舉(自身也可能會被選為Primary),并從Primary同步最新寫入的數據,以保證與Primary存儲相同的數據。
Secondary可以提供讀服務,增加Secondary節(jié)點可以提供復制集的讀服務能力,同時提升復制集的可用性。另外,Mongodb支持對復制集的Secondary節(jié)點進行靈活的配置,以適應多種場景的需求。
Arbiter
Arbiter節(jié)點只參與投票,不能被選為Primary,并且不從Primary同步數據。
比如你部署了一個2個節(jié)點的復制集,1個Primary,1個Secondary,任意節(jié)點宕機,復制集將不能提供服務了(無法選出Primary),這時可以給復制集添加一個Arbiter節(jié)點,即使有節(jié)點宕機,仍能選出Primary。
Arbiter本身不存儲數據,是非常輕量級的服務,當復制集成員為偶數時,最好加入一個Arbiter節(jié)點,以提升復制集可用性。
Priority0
Priority0節(jié)點的選舉優(yōu)先級為0,不會被選舉為Primary
比如你跨機房A、B部署了一個復制集,并且想指定Primary必須在A機房,這時可以將B機房的復制集成員Priority設置為0,這樣Primary就一定會是A機房的成員。(注意:如果這樣部署,最好將『大多數』節(jié)點部署在A機房,否則網絡分區(qū)時可能無法選出Primary)
Vote0
Mongodb 3.0里,復制集成員最多50個,參與Primary選舉投票的成員最多7個,其他成員(Vote0)的vote屬性必須設置為0,即不參與投票。
Hidden
Hidden節(jié)點不能被選為主(Priority為0),并且對Driver不可見。
因Hidden節(jié)點不會接受Driver的請求,可使用Hidden節(jié)點做一些數據備份、離線計算的任務,不會影響復制集的服務。
Delayed
Delayed節(jié)點必須是Hidden節(jié)點,并且其數據落后與Primary一段時間(可配置,比如1個小時)。
因Delayed節(jié)點的數據比Primary落后一段時間,當錯誤或者無效的數據寫入Primary時,可通過Delayed節(jié)點的數據來恢復到之前的時間點。
數據同步
Primary與Secondary之間通過oplog來同步數據,Primary上的寫操作完成后,會向特殊的local.oplog.rs特殊集合寫入一條oplog,Secondary不斷的從Primary取新的oplog并應用。
因oplog的數據會不斷增加,local.oplog.rs被設置成為一個capped集合,當容量達到配置上限時,會將最舊的數據刪除掉。另外考慮到oplog在Secondary上可能重復應用,oplog必須具有冪等性,即重復應用也會得到相同的結果。
如下oplog的格式,包含ts、h、op、ns、o等字段
{ "ts" : Timestamp(1446011584, 2), "h" : NumberLong("1687359108795812092"), "v" : 2, "op" : "i", "ns" : "test.nosql", "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } }
Secondary初次同步數據時,會先進行init sync,從Primary(或其他數據更新的Secondary)同步全量數據,然后不斷通過tailable cursor從Primary的local.oplog.rs集合里查詢最新的oplog并應用到自身。
init sync過程包含如下步驟
T1時間,從Primary同步所有數據庫的數據(local除外),通過listDatabases + listCollections + cloneCollection敏命令組合完成,假設T2時間完成所有操作。
從Primary應用[T1-T2]時間段內的所有oplog,可能部分操作已經包含在步驟1,但由于oplog的冪等性,可重復應用。
根據Primary各集合的index設置,在Secondary上為相應集合創(chuàng)建index。(每個集合_id的index已在步驟1中完成)。
oplog集合的大小應根據DB規(guī)模及應用寫入需求合理配置,配置得太大,會造成存儲空間的浪費;配置得太小,可能造成Secondary的init sync一直無法成功。比如在步驟1里由于DB數據太多、并且oplog配置太小,導致oplog不足以存儲[T1, T2]時間內的所有oplog,這就Secondary無法從Primary上同步完整的數據集。
修改復制集配置
當需要修改復制集時,比如增加成員、刪除成員、或者修改成員配置(如priorty、vote、hidden、delayed等屬性),可通過replSetReconfig命令(rs.reconfig())對復制集進行重新配置。
比如將復制集的第2個成員Priority設置為2,可執(zhí)行如下命令
cfg = rs.conf(); cfg.members[1].priority = 2; rs.reconfig(cfg);
細說Primary選舉
Primary選舉除了在復制集初始化時發(fā)生,還有如下場景
Primary的選舉受節(jié)點間心跳、優(yōu)先級、最新的oplog時間等多種因素影響。
節(jié)點間心跳
復制集成員間默認每2s會發(fā)送一次心跳信息,如果10s未收到某個節(jié)點的心跳,則認為該節(jié)點已宕機;如果宕機的節(jié)點為Primary,Secondary(前提是可被選為Primary)會發(fā)起新的Primary選舉。
節(jié)點優(yōu)先級
Optime
擁有最新optime(最近一條oplog的時間戳)的節(jié)點才能被選為主。
網絡分區(qū)
只有更大多數投票節(jié)點間保持網絡連通,才有機會被選Primary;如果Primary與大多數的節(jié)點斷開連接,Primary會主動降級為Secondary。當發(fā)生網絡分區(qū)時,可能在短時間內出現多個Primary,故Driver在寫入時,最好設置『大多數成功』的策略,這樣即使出現多個Primary,也只有一個Primary能成功寫入大多數。
復制集的讀寫設置
Read Preference
默認情況下,復制集的所有讀請求都發(fā)到Primary,Driver可通過設置Read Preference來將讀請求路由到其他的節(jié)點。
Write Concern
默認情況下,Primary完成寫操作即返回,Driver可通過設置[Write Concern(https://docs.mongodb.org/manual/core/write-concern/)來設置寫成功的規(guī)則。
如下的write concern規(guī)則設置寫必須在大多數節(jié)點上成功,超時時間為5s。
db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: majority, wtimeout: 5000 } } )
上面的設置方式是針對單個請求的,也可以修改副本集默認的write concern,這樣就不用每個請求單獨設置。
cfg = rs.conf() cfg.settings = {} cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 } rs.reconfig(cfg)
異常處理(rollback)
當Primary宕機時,如果有數據未同步到Secondary,當Primary重新加入時,如果新的Primary上已經發(fā)生了寫操作,則舊Primary需要回滾部分操作,以保證數據集與新的Primary一致。
舊Primary將回滾的數據寫到單獨的rollback目錄下,數據庫管理員可根據需要使用mongorestore進行恢復。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。