mongoDB replSet（复制集群）
MongoDB支持多个机器中通过异步复制达到故障转移和实现冗余。多机器中同一时刻只有一台是用于写操作。正式由于这个情况，为mongoDB提供了数据一致性的保障。担当primary角色的机器能把读操作分发给slave。
部署Replica Sets
当读的压力越来越大时，可能会考虑添加slave节点机，分摊读压力。通常我们有两种方式添加节点。
一）通过oplog添加节点
oplog是主从操作日志。mongoDB的 Replice Set架构是通过一个日志来存储写操作，就是oplog。oplog.rs是一个固定长度的capped collection，他存储在local数据库中，用于记录Replice Set 操作日志（写）。
我们可以通过db.oplog.rs.find()查看其具体操作内容，或者使用printReplicationInfo()查看oplog元数据信息，printSlaveReplicationInfo查看slave的同步状态。
使用这种方式添加节点就好比通过oplog模拟了Primary的“整个”操作过程，（是整个完整的么？）以完成内容复制。
问题：
由于oplog是一个固定长度的capped collection，那么他并非完整的记录了primary的所有操作，因为日志中存储的信息有可能已经刷新过了。那么这个时候我们就要利用第二种方式了。
二）--fastsync和oplog配合使用
我们会想，直接将primary（或者当前集群中的某一slave）的数据文件复制出来，然后新节点直接指定到该数据文件目录（--dbpath），然后将复制到添加到集群（rs.add）过程中primary的操作通过oplog日志追加不就好了么？
实际上，这就是方式二的做法。
1）获取一个复制集成员的物理文件来初始化数据
scp -r /data/r /data/newSlave
特别注意，由于复制时被复制的物理文件尚未“离线”（r文件夹中持有mongoDB的锁），这个锁也会被复制到newSlave中，引起数据同步失败！
2）启用新节点
3）在primary中添加节点（rs.add）
----------------------------------------------------
Capped Collection
capped collection 是性能出色的有着固定大小的集合，以LRU（least recently used）规则和插入顺序进行age-out处理，自动维护集合中对象的插入顺序，在创建时要预先指定大小。如果空间用完，新添加的对象将会取代集合中最旧的对象。
