mongoDB研究笔记:复制集数据同步机制 – 郭远威

   http://www.cnblogs.com/guoyuanwei/p/3279572.html  概述了复制集,整体上对复制集有了个概念,但是复制集最重要的功能之一数据同步是如何实现的?带着这个问题,下面展开分析。

先利用mongo客户端登录到复制集的primary节点上。

>mongo –port 40000

查看实例上所有数据库

rs0:PRIMARY> show dbs

local   0.09375GB

可以看到只有一个local数据库,因为此时还没有在复制集上创建任何其它数据库,local数据库为复制集所有成员节点上默认创建的一个数据库。在primary节点上查看local数据上的集合:

rs0:PRIMARY> show collections

oplog.rs

slaves

startup_log

system.indexes

system.replset

如果是在secondary节点则local数据库上的集合与上面有点不同,secondary节点上没有slaves集合,因为这个集合保存的是需要从primary节点同步数据的secondary节点;secondary节点上会有一个me集合,保存了实例本身所在的服务器名称;secondary节点上还有一个minvalid集合,用于保存对数据库的最新操作的时间截。其它集合primary节点和secondary节点都有,其中startup_log集合表示的是mongod实例每一次的启动信息;system.indexes集合保存的是当前数据库(local)上的所有索引信息;system.replset集合保存的是复制集的成员配置信息,复制集上的命令rs.conf()实际上是从这个集合取的数据返回的。最后要介绍的集合是oplog.rs,这个可是重中之中。

mongoDB就是通过oplog.rs来实现复制集间数据同步的,为了分析数据的变化,先在复制集上的primary节点上创建一个数据库students,然后插入一条记录。

rs0:PRIMARY> use students

switched to db students

rs0:PRIMARY> db.scores.insert({“stuid”:1,”subject”:”math”,”score”:99});

接着查看一下primary节点上oplog.rs集合的内容:

rs0:PRIMARY> use local

switched to db local

rs0:PRIMARY> db.oplog.rs.find();

返回记录中会多出一条下面这样的记录(里面还有几条记录是复制集初始化时创建的):

{ “ts” : { “t” : 1376838296, “i” : 1 }, “h” : NumberLong(“6357586994520331181”),

 “v” : 2, “op” : “i”, “ns” : “students.scores”, “o” : { “_id” : ObjectId(“5210e2

98d7b419b44afa58cc”), “stuid” : 1, “subject” : “math”, “score” : 99 } }

里面有几个重要字段,其中”ts”表示是这条记录的时间截,”t”是秒数,”i”每秒操作的次数;字段”op”表示的是操作码,值为”i”表示的是insert操作;”ns”表示插入操作发生的命名空间,这里值为: “students.scores”,由数据库和集合名构成;”o”表示的是此插入操作包含的文档对象;

当primary节点完成插入操作后,secondary节点为了保证数据的同步也会完成一些动作:

所有secondary节点检查自己的local数据上oplog.rs集合,找出最近的一条记录的时间截;接着它会查询primary节点上的oplog.rs集合,找出所有大于此时间截的记录;最后它将这些找到的记录插入到自己的oplog.rs集合中并执行这些记录所代表的操作;通过这三步策略,就能保证secondary节点上的数据与primary节点上的数据同步了。

查看一下secondary节点上的数据,证明上面的分析是正确的。

rs0:SECONDARY> show dbs

local   0.09375GB

students        0.0625GB

  在secondary节点上新插入了一个数据库students。但是有一点要注意:现在还不能在secondary节点上直接查询students集合上的内容,默认情况下mongoDB的所有读写操作都是在primary节点上完成的,后面也会介绍通过设置从secondary节点上来读,这将引入一个新的主题,后面再分析。

关于oplog.rs集合还有一个很重要的方面,那就是它的大小是固定的,mongoDB这样设置也是有道理的,假如大小没限制,那么随着时间的推移,在数据库上的操作会逐渐累积,oplog.rs集合中保存的记录也会逐渐增多,这样会消耗大量的存储空间,同时对于某个时间点以前的操作记录,早已同步到secondary节点上,也没有必要一直保存这些记录,因此mongoDB将oplog.rs集合设置成一个capped类型的集合,实际上就是一个循环使用的缓冲区。

固定大小的oplog.rs会带来新的问题,考虑下面这种场景:假如一个secondary节点因为宕机,长时间不能恢复,而此时大量的写操作发生在primary节点上,当secondary节点恢复时,利用自己oplog.rs集合上最新的时间截去查找primary节点上的oplog.rs集合,会出现找不到任何记录。因为长时间不在线,primary节点上的oplog.rs集合中的记录早已全部刷新了一遍,这样就不得不手动重新同步数据了。因此oplog.rs的大小是很重要,在32位的系统上默认大小是50MB,在64位的机器上默认是5%的空闲磁盘空间大小,也可以在mongod启动命令中通过项—oplogSize设置其大小。

本文链接:http://www.cnblogs.com/guoyuanwei/p/3293668.html,转载请注明。



You must enable javascript to see captcha here!

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress

无觅相关文章插件,快速提升流量