1. 复制集(Replica sets)模式时，其会使用下面的local数据库
local.system.replset 用于复制集配置对象存储 (通过shell下的rs.conf()或直接查询)
local.oplog.rs 一个capped collection集合.可在命令行下使用--oplogSize 选项设置该集合大小尺寸.
local.replset.minvalid 通常在复制集内使用，用于跟踪同步状态(sync status)
2. 主从复制模式(Master/Slave)
* Master
o local.oplog.$main 存储"oplog"信息
o local.slaves 存储在master结点上相应slave结点的同步情况（比如syncTo时间戳等）
* Slave
o local.sources 从结点所要链接的master结点信息（可通过--source配置参数指定）
* Other
o local.me 未知待查:)
o local.pair.* (replica pairs选项，目前已不推荐使用)
3. 还有oplog的数据结构（存储在local.oplog.$main）
{ ts : ..., op: ..., ns: ..., o: ... o2: ... }
上面就是一条oplog信息，复制机制就是通过这些信息来进行节点间的数据同步并维护数据一致性的，其中：
ts：8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。
这个值很重要，在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primary。
op：1字节的操作类型，例如i表示insert，d表示delete。
ns：操作所在的namespace。
o：操作所对应的document,即当前操作的内容（比如更新操作时要更新的的字段和值）
o2: 在执行更新操作时的where条件，仅限于update时才有该属性
其中op，可以是如下几种情形之一：
"i"： insert
"u"： update
"d"： delete
"c"： db cmd
"db"：声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')
"n": no op,即空操作，其会定期执行以确保时效性
- ts: the time this operation occurred.
- h: a unique ID for this operation. Each operation will have a different value in this field.
- op: the write operation that should be applied to the slave. n indicates a no-op, this is just an informational message.
- ns: the database and collection affected by this operation. Since this is a no-op, this field is left blank.
- o: the actual document representing the op. Since this is a no-op, this field is pretty useless.
- for the update, there are two o fields (o and o2). o2 give the update criteria and o gives the modifications (equivalent to update()‘s second argument).
4. 同步系统设计
mongoDB oplog的说明:
如果需要及时获取mongoDB的增量信息，就可以应用oplog了！
常用的场景模式：索引更新，主动更新缓存等。
通常一个服务监控oplog，将“增量信息”经过一定的处理后塞到ActiveMQ中，相关的应用程序再从ActiveMQ中获取消息进行消费。
注意点：
1）如果当前服务断掉了，要有个断点机制，下次可以接着来。这个主要是对ts字段进行控制。
因此需要实时记录读到了什么位置。
2）如果应用端是异构的，采用一种跨语言的协议，例如json。
3）消息中间件（ActiveMQ）起到解耦、缓冲的作用。