Mongodb副本集

原创 2013年12月03日 21:09:49

Mongodb副本集

一、简介:

简单来说,副本集(Replica Set)就是有自动故障恢复功能的主从集群。主从集群和副本集最为明显的区别是副本集没有固定的“主节点”:整个集群会选举出一个“主节点”,当其不能工作时则变更到其他节点。然而,二者看上去非常相似:副本集总会有一个活跃节点(primary)和一个或多个备份节点(secondary)。

副本集最美妙的地方就是所有东西都是自动化的。首先他为你做了很多管理工作,自动提升备份节点为活跃节点,其次,对开发者而言也非常易用:仅需要为副本集指定一下服务器,驱动程序就会自动找到服务器,在当前活跃节点死机时自动处理故障恢复这类事情。

当活跃节点挂了,备份节点自动成为活跃节点。

当活跃节点又恢复了,由于已经有活跃节点了,自动变为备份节点。

二、副本集中的节点

1. Standard: 常规节点,存储了完整数据副本,参与投票,可能成为活跃节点,优先权非0.

2. Passive: 存储了完整数据副本,参与投票,不能成为活跃节点。优先权为0.

3. Arbiter:仲裁者,只参与投票,不接受复制的数据,也不能成为活跃节点。

如果活跃节点坏了,其他节点会选出一个新的活跃节点来。选举过程可以由任何非活跃节点发起。新的活跃节点由副本集中的大多数选举产生。仲裁节点也会参与投票,避免出现僵局。新的活跃节点将是优先级最高的节点,优先级相同则数据较新的获胜。

活跃节点使用心跳来跟踪集群中有多少节点对其可见。如果不够半数,活跃节点会自动降级为备份节点。这样就能防止活跃节点一直不放权。

不论活跃节点何时变化,新活跃节点的数据就被假定为系统的最新数据。其他节点的操作会回滚,即便之前的活跃节点恢复了工作。

选举:

在以下几种情景发生的时候,副本集通过选举来决定副本集中的primary节点:

·        当第一次初始化一个副本集的时候;

·        primary几点steps down的时候,出现这种情况可能是因为执行了replSetStepDown命令,或者是集群中出现了更适合当primary的节点,比如当primary节点和集群中其他大部分节点无法通信的时候,当primarysteps down的时候,它会关闭所有客户端的连接。

·        当集群中一个secondary节点无法和primary节点建立连接的时候也会导致一次election发生。

·        一次failover

·        执行rs.conf()命令。

在一次选举中包括hidden节点、仲裁者甚至正处于recovering状态的节点都具有投票权。默认配置中所有参与选举的节点具有相等的权利,当然在一些特定情况下,应明确的指定某些secondary会优先成为primary,比如一个远在千里之外异地机房的节点就不应该成为primary节点,选举的权重通过设置priority来调节,默认该值都是1,在前面简单副本集的搭建中已经介绍过了如何修改该值。

集群中任何一个节点都可以否决选举,即使它是non-voting member

·        如果发起选举的节点不具有选举权(priority0的成员);

·        发起选举的节点数据落后太多;

·        发起选举的节点的priority值比集群中其他某一个节点的小;

·        如果当前的primary节点比发起选举的节点拥有更新或同等新的数据(也就optime值相等或更大)。

·        当前的primary节点会否决,如果它拥有比发起选举的节点更新或相同新的数据。

首先获取最多选票的成员(实际上要超过半数)才会成为primary节点,这也说明了为什么当有两个节点的集群中primary节点宕机后,剩下的只能成为secondary,当primary宕掉,此时副本集只剩下一个secondary,它只有1,不超过总节点数的半数,它不会选举自己为primary

读扩展:

 

 

ReadReferences:

应用程序驱动通过read reference来设定如何对副本集进行读取操作,默认的,客户端驱动所有的读操作都是直接访问primary节点的,从而保证了数据的严格一致性。


但有时为了缓解主节点的压力,我们可能需要直接从secondary节点读取,只需要保证最终一致性就可以了。


MongoDB 2.0之后支持五种的readpreference模式:

 

primary:默认,只从主节点上进行读取操作;

primaryPreferred:在绝大部分的情形都是从主节点上读取数据的,只有当主节点不可用的时候,比如在进行failover10秒或更长的时间内会从secondary节点读取数据。

警告2.2版本之前的MongoDBReadPreference支持的还不完全,如果客户端驱动采用primaryPreferred实际上读取操作都会被路由到secondary节点。

secondary:只从secondary节点上进行读取操作,存在的问题是secondary节点的数据会比primary节点数据

secondaryPreferred:优先从secondary节点进行读取操作;

nearest:既有可能从primary,也有可能从secondary节点读取,这个决策是通过一个叫memberselection过程处理的。

 

MongoDB允许在不同的粒度上指定这些模式:连接、数据库、集合甚至单次的操作。不同语言的驱动基本都支持这些粒度。

同步

从节点第一次启动时,会对主节点数据进行完整的同步.从节点复制主节点上的每个文档,很耗资源.同步完成后,

从节点开始查询主节点的oplog并执行这些操作,以保证数据是最新的.

如果从节点的操作和主节点的相差很远,从节点就跟不上同步了.跟不上同步的从节点无法一直追赶主节点.因为

主节点oplog的所有操作太新了.从节点发生了宕机或着疲于应付读取时会出现这个情况,也会在执行完完整同步以后

反生类似的事,因为只要同步的时间太长,同步完成时,oplog可能已经操作了很多.

从节点跟不上同步时,复制就会停下来,从节点需要重新做完整的同步.可以用{"resync":1}命令手动执行从新同步,

也可以在启动从节点时使用--autoresync选项让其自动重新同步,重新同步的代价很高,应尽量避免,方法是配置

足够大的oplog,配置足够大的oplog能存放相当长的时间操作记录.大的oplog会占用更多的磁盘空间,则需要权衡一下.

默认的oplog大小是剩余磁盘空间的5%.

 

三、实例

准备:

两台服务器:

192.168.229.80:80服务器作为节点1,目录如下

/export/servers/dbs/node1/


192.168.192.75:75服务器作为节点2,目录如下


启动node1节点:80:

-bash-3.2# ./bin/mongod --dbpath ./data/node1 --logpath ./data/node1/node1.log --port 10001 --replSet test/192.168.192.75:10002

启动node2节点:75:

[root@localhost mongodb-linux-x86_64-2.0.4]# ./bin/mongod --dbpath ./data/node2/ --port 10002 --replSet test/

 

通过192.168.192.68链接到一台服务器:

./bin/mongo 192.168.229.80:10001/admin                                                                                                                            

初始化副本集:

 db.runCommand({

 "replSetInitiate":{

  "_id":"test",

  "members":[

   {

     "_id":1,

     "host":"192.168.229.80:10001"                                                                                                                                            ,

      "priority":3

   },

   {

     "_id":2,

     "host":"192.168.192.75:10002",

     "priority":2

   }

    ]

 }

});

 

结果如图:提示ok:1即成功,间有几次报错是磁盘满了,清除后ok

 

查看副本集状态:


查看是否为主节点:看到ismaster:true

 

切换到75上查看:ismaster:false

 

往主库插入数据:


去从库查看:


发现查不到数据,这是正常的,因为SECONDARY是不允许读写的,在写多读少的应用中,使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作。

对于replica set 中的secondary 节点默认是不可读的,分别从从库和主库设置setSlaveOk即可。

参考:

http://www.cnblogs.com/refactor/archive/2012/08/13/2600140.html

mongodb副本集删除方法

mongodb副本集删除方法 起因:由于要搭建一个mongodb的测试环境,所以从原来的一台服务器上克隆了一个过来,上面有三个mongodb实例,组成了一个副本集。 副本集的设置也一起copy过来了,...
  • huwei2003
  • huwei2003
  • 2015年09月14日 16:42
  • 6793

MongoDB:副本集的配置

MongoDB学习记录(一):副本集的配置使用副本集的原因 数据安全性 数据的高可用性(读写分离) 灾备恢复 维护方便 。。。 mongodb的副本集优势与mysql的副本集相比,mongodb副本集...
  • u011041412
  • u011041412
  • 2017年08月11日 15:05
  • 399

MongoDB架构篇-Replica Set 副本集-增加删除节点等

MongoDB架构篇 ReplicaSets复制(副本集)增加删除节点:    --命令解释 mongod--replSet rs1(小组) --keyFile=e:/key1(密钥) --port ...
  • dingsai88
  • dingsai88
  • 2015年01月30日 11:02
  • 3575

MongoDB副本集(一)

副本集是一组服务器,其中有一个主服务器(primary),用于处理客户端请求;还有多个备份服务器(secondary),用于保存主服务器的数据副本。如果主服务器崩溃了,备份服务器会自动将其中一个成员升...
  • u014785687
  • u014785687
  • 2017年01月07日 09:54
  • 1011

Mongodb副本集

Mongodb副本集 一、简介: 简单来说,副本集(Replica Set)就是有自动故障恢复功能的主从集群。主从集群和副本集最为明显的区别是副本集没有固定的“主节点”:整个集群会选举出一个“主节点”...
  • ctf_htj
  • ctf_htj
  • 2013年12月03日 21:09
  • 725

mongodb复制-副本集

复制简介        配置一个单节点的mongo服务器适用与学习和测试环境,在线上真正的生产环境中我们需要使用复制将数据副本保存在多台服务器上,一台或者多台服务器挂掉之后可以顺利得通过选举算法选举出...
  • JThink_
  • JThink_
  • 2016年01月14日 11:25
  • 563

mongodb replset副本集部署 优先级设置priority

设置mongodb的副本集方式部署优先级问题
  • luoni186
  • luoni186
  • 2017年08月18日 14:14
  • 145

MongoDB 副本集+分片 架构部署

Replica Set + Sharding  配置部署准备工作架构设计 需要三台机器(racdb,host8,host9):数据节点,sharding2片每个sharding为Replic Set方...
  • lichangzai
  • lichangzai
  • 2016年03月18日 23:52
  • 6301

MongoDB 副本集及其工作原理

一、工作原理 1.   MongoDB 2.6版本开始推荐使用副本集,对主从复制已经不再推荐. 2.   副本集至少需要3个, 可以3个全部做副本集, 也可以让其中一个做仲裁. 3.   副本集中只有...
  • m582445672
  • m582445672
  • 2015年11月24日 09:23
  • 2211

一边搭建一边理解MongoDB副本集(分布于两个或多个数据中心的副本集)

一边搭建一边理解MongoDB副本集(分布于两个或多个数据中心的副本集)作者:链上研发-175405 时间:2017-01-21概览尽管副本集提供了对于单节点故障的基础保护,那些位于同一个数据中心...
  • fang_sh_lianjia
  • fang_sh_lianjia
  • 2017年01月21日 16:50
  • 570
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Mongodb副本集
举报原因:
原因补充:

(最多只允许输入30个字)