mongoDB 復制篇
復制集簡介
Mongodb復制集由一組Mongod實例（進程）組成，包含一個Primary節點和多個Secondary節點，Mongodb Driver（客戶端）的所有數據都寫入Primary，Secondary從Primary同步寫入的數據，以保持復制集內所有成員存儲相同的數據集。
官方文檔上的復制集
Primary選舉
復制集在初始化之后要進行Priamry選舉，在獲得大多數的成員投票之后的節點會成為Priamry節點，其余的成為Secondary節點
初始化復制集
config = {
_id : "my_replica_set",
members : [
{_id : 0, host : "rs1.example.net:27017"},
{_id : 1, host : "rs2.example.net:27017"},
{_id : 2, host : "rs3.example.net:27017"},
]
}
rs.initiate(config)
大多數的定義為N/2 + 1 N為復制集數量。當復制集的存活的數量不足大多數時，整個復制集無法選出Priamry ，復制集只提供讀服務。
特殊的Secondary
Priamry的作用是將自己的數據同步給其他的Secondary。並保持最新的數據
下面是一些特殊的Secondary的節點的介紹，這些幾點的主要作用是在Priamry節點主動或被動退出時，選舉出新的Priamry節點
Arbiter
Arbiter節點只參與投票，不能被選為Primary，並且不從Primary同步數據。
Arbiter本身不存儲數據，是非常輕量級的服務
Arbiter本身不存儲數據，是非常輕量級的服務
Priority0節點的選舉優先級為0，不會被選舉為Primary
Vote0
Mongodb 3.0里，復制集成員最多50個，參與Primary選舉投票的成員最多7個，其他成員（Vote0）的vote屬性必須設置為0，即不參與投票。
Hidden
Hidden節點不能被選為主（Priority為0），並且對Driver不可見。
Delayed
Delayed節點必須是Hidden節點，並且其數據落后與Primary一段時間（可配置，比如1個小時）。
主要作用是Delayed的節點數據比Priamry的數據落后，這樣當Priamry的數據出現錯誤的時候，可以通過Delayed節點的數據進行恢復
###數據的同步 **同步的原理** **Primary**與**Secondary**之間通過**oplog**來同步數據，**Primary**上的寫操作完成后，會向特殊的***local.oplog.rs***特殊集合寫入一條**oplog**，**Secondary**不斷的從**Primary**取新的**oplog**並應用。 當然oplog的數據也不是一直在增加，當容量達到上限時，會將最舊的數據刪除。 **oplog**的格式
{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}
- ts： 操作時間，當前timestamp + 計數器，計數器每秒都被重置
- h：操作的全局唯一標識
- v：oplog版本信息
- op：操作類型
- 1 i：插入操作
- 2 u：更新操作
- 3 d：刪除操作
- 4 c：執行命令（如createDatabase，dropDatabase）
- 5 n：空操作，特殊用途
- ns：操作針對的集合
- o：操作內容，如果是更新操作
- o2：操作查詢條件，僅update操作包含該字段
###修改復制集配置 當需要修改復制集時，比如增加成員、刪除成員、或者修改成員配置（如**priorty**、**vote**、**hidden**、**delayed**等屬性），可通過**replSetReconfig**命令（**rs.reconfig()**）對復制集進行重新配置。 例如下面的例子
cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);
這個例子的作用是將復制集的第二個成員的Priamry設置為2
###Primary選舉的選舉細節 下面的幾種情況會引復制集的U型安居 - 復制集被reconfig - Secondary節點檢測到Primary宕機時，會觸發新Primary的選舉 - 當有Primary節點主動stepDown（主動降級為Secondary）時，也會觸發新的Primary選舉 **Priamry**的選舉受到多個因素的影響 例如 **點間心跳** **優先級** **最新的oplog時間**的其他的因素
節點間心跳
復制集成員間默認每2s會發送一次心跳信息，如果10s未收到某個節點的心跳，則認為該節點已宕機；如果宕機的節點為Pri
mary，Secondary（前提是可被選為Primary）會發起新的Primary選舉。
節點優先級
- 每個節點都傾向於投票給優先級最高的節點
- 優先級為0的節點不會主動發起Primary選舉 也就是Priority0節點
- 當Primary發現有優先級更高Secondary，並且該Secondary的數據落后在10s內，則Primary會主動降級，讓優先級更高的Secondary有成為Primary的機會。
Optime
擁有最新optime（最近一條oplog的時間戳）的節點才能被選為主。
網絡分區
只有更大多數投票節點間保持網絡連通，才有機會被選Primary；
復制集的讀寫設置
Read Preference
默認情況下，復制集的所有讀請求都發到Primary.
Driver (客戶端)可通過設置Read Preference來將讀請求路由到其他的節點。
- primary： 默認規則，所有讀請求發到Primary
- primaryPreferred： Primary優先，如果Primary不可達，請求Secondary
- secondary： 所有的讀請求都發到secondary
- secondaryPreferred：Secondary優先，當所有Secondary不可達時，請求Primary
- nearest：讀請求發送到最近的可達節點上（通過ping探測得出最近的節點）
Write Concern
默認情況下，Primary完成寫操作即返回，但是Driver可通過設置Write Concern來設置寫成功的規則
例如
db.products.insert(
{ item: "envelopes", qty : 100, type: "Clasp" },
{ writeConcern: { w: majority, wtimeout: 5000 } }
)
write concern規則設置寫必須在大多數節點上成功，超時時間為5s。
上面的設置方式是針對單個請求的，也可以修改副本集默認的write concern，這樣就不用每個請求單獨設置
cfg = rs.conf()
cfg.settings = {}
cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
rs.reconfig(cfg)
異常處理（rollback）
這里的異常處理主要是在進行節點選舉之后的新舊Primary節點的數據不同步。要講舊的Priamry的進行回滾部分，以保證數據集與新的Priamry一致