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设置其大小。