mongoDB研究笔记：复制集数据同步机制

qns_fengyusong

　　http://www.iyunv.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设置其大小。