MongoDB 复制篇

神甫

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一致