您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
mongoDB 复制篇
 
   次浏览      
 2018-3-20 
 
编辑推荐:
本文来自于编程人生,主要是在进行节点选举之后的新旧Primary节点的数据不同步。

复制集简介

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型安居

1.复制集被reconfig

2.Secondary节点检测到Primary宕机时,会触发新Primary的选举

3.当有Primary节点主动stepDown(主动降级为Secondary)时,也会触发新的Primary选举

Priamry的选举受到多个因素的影响 例如 点间心跳 优先级 最新的oplog时间的其他的因素

节点间心跳

复制集成员间默认每2s会发送一次心跳信息,如果10s未收到某个节点的心跳,则认为该节点已宕机;如果宕机的节点为PriAlt text

mary,Secondary(前提是可被选为Primary)会发起新的Primary选举。

节点优先级

1.每个节点都倾向于投票给优先级最高的节点

2.优先级为0的节点不会主动发起Primary选举 也就是Priority0节点

3.当Primary发现有优先级更高Secondary,并且该Secondary的数据落后在10s内,则Primary会主动降级,让优先级更高的Secondary有成为Primary的机会。

Optime

拥有最新optime(最近一条oplog的时间戳)的节点才能被选为主。

网络分区

只有更大多数投票节点间保持网络连通,才有机会被选Primary;

复制集的读写设置

Read Preference

默认情况下,复制集的所有读请求都发到Primary.

1.Driver (客户端)可通过设置Read Preference来将读请求路由到其他的节点。

2.primary: 默认规则,所有读请求发到Primary

3.primaryPreferred: Primary优先,如果Primary不可达,请求Secondary

4.secondary: 所有的读请求都发到secondary

5.secondaryPreferred:Secondary优先,当所有Secondary不可达时,请求Primary

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

 

   
次浏览       
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训