mongo的复制集

一 MongoDB 复制集简介 MongoDB的复制机制主要分为两种： Master-Slave (主从复制） 这个已经不建议使用 Replica Set (复制集） MongoDB在1.6版本中开发的新功能，官方推荐使用

MongoDB复制集比之前的Master-Slave架构功能强大，支持在多个机器中通过异步复制的方式来实现 数据库的数据冗余，大大降级了单点故障的风险，并且可以实现故障的自动切换。默认情况下，多台机器同一时间只能由一台用于读写操作，从而提供了数据的强一致性，各个DB之间数据完全一致。 MongoDB复制集成员是由一组mongod进程实例组成，其实 Replica Set的结构类似于一个集群，完全可以把它当作一个集群，因为它确实与集群实现的作用是一样的：如果其中一个节点出现故障，其他节点马上就会将业务接管过来而无须停机操作。
二 Replica Set 成员介绍
MongoDB复制集的成员包括：主节点、从节点和仲裁节点三大类，下面一一做详细介绍。

1.主节点(Primary) 主节点负责所有写请求,主节点是复制集里唯一一个可以接受写操作请求的，主节点会将其所有的写操作记录到oplog日志上，从节点就可以复制oplog日志，将这些操作应用到自己的节点上。 默认的情况下，客户端会将其所有读请求发给主节点，但是也可以通过配置让从节点具有读取数据能力。 一个复制集最多只能有一个主节点，当其不可用（或者是资格不够的时候）的时候，通过选举算法从从节点中选择一个来作为新的主节点。 2.从节点(Secondaries)
从节点通过复制主节点数据(通过读取操作日志文件)l来保持数据的一致性。 另外，通过一些配置（比如说不让其拥有投票权、将其优先级设置为零）从节点还可以使其拥有某些特殊的作用。主要有以下的几种常见当配置： 2.1.优先级设置为0(Priority 0)：将一个从节点的优先级设置为零，失去了被选举权，该节点就不可以成为主节点了。
注意： a.Priority0节点虽然没有被选举权，但是拥有选举权，在选举中可以投票，另外它也会保持一份主节点的数据，可以接受读操作。 b.Priority0节点在进行多数据中心部署的时候是十分有用的，可以将主从节点放到主数据中心，priority0放到另外一个，这样可以增加数据当安全性。
c.此外，Priority0可以作为一个替补成员，当复制集中有成员不可用的时候，可以很快的顶替上 ， 也可以把硬件比较差的机器设置为Priority0。
2.2.Hidden成员：Hidden成员对客户端来说是不可见的，因此不对外提供读请求，该类从节点只是拥有一份备份数据。
注意：a.Hidden成员同样也会保持主节点的一份数据，但是它对客户端来说是不见的，db.isMaster() 不会显示Hideen成员 。Hidden成员也是一个Priority0成员，只拥有投票权。 b.Hidden成员与其他从节点的链路是单向通信的，其他节点不能发送请求给Hidden成员，因为Hidden对于其他节点来说也是不可见的，这样的话Hidden成员的网络通讯压力就比较小，我们可以使用它来做报告或者备份。如果要做备份的话，我们应该确保Hidden节点和主节点之间网络带宽，尽可能减小复制滞后的时间，尽量保持两者间数据高度的一致性。 2.3 历史快照延迟(Delayed)成员:该类从节点不会与主节点数据保持时间上的一致，它保存了现在之前的数据，相当有一个历史快照。
a.延迟成员反映了主节点一个更早的状态，比如说我们设置一个延迟一个小时的Delayed成员，当前是9:52，那么一个Delayed成员只记录了8:52之前的数据。由于Delayed成员记录数据的滞后性，当我们进行 系统升级过程中或者一些操作导致错误的话，那么可以利用Delayed成员记录的数据来进行操作回滚。 b.Delayed成员既是Priority0也是hidden.它同样也拥有投票权利。 c.Delayed成员以“滞后”的方式来从主节点操作日志同步数据，所以当我们设置Delayed成员的滞后时间的时候不能太大，因为操作日志是会更新的（是一个Capped Collection），如果设置延迟时间太长的话，操作日志记录的很早的操作可能 就会被更新掉，但是又不能设置的太小，如果太小的话就失去了Delayed成员存在当意义（应该大于系统维护或者升级的窗口时间）。
在下面的5个成员复制集例子中，一个主节点和4个从节点都存有一份数据，其中一个成员被设置为延迟3600秒（一个小时），注意到一个Delayed成员也是一个Priority0和Hidden成员。
我们可以像下面这样设置一个Delayed成员：
｛ "_id" : <null> , "host" : <hostname:port> , "priority" : 0, "slaveDelay" : <seconds> , "hidden" : true }

注意：1.每一个从节点都拥有一份主节点的数据拷贝，它们通过主节点（或者是从节点，只要是该从节点操作日志比自己的操作日志记录的操作新的话）操作日志记录的信息，异步的完成写操作。 3.仲裁节点（ arbiter） 仲裁者可以成为复制集的成员，它不会存储数据，它的主要作用是用来投票的。例如当复制集有偶数个成员时，可以添加一个仲裁者。 注意：只有当复制集中可以投票的节点数目为偶数的时候我们可以添加一个仲裁者。例如下图所示，一个复制集原来有四个成员，这个时候我们可以添加一个仲裁者，仲裁者不存储数据。


注意：一个复制集最多只能有12个成员，每次同时只能有7个成员可以投票，这样的限制是为了减少投票话费的时间，提高故障切换的效率。


三 总结
复制集的使用对于用户来说是透明的。客户端也可以通过配置“读引用”从 从节点获取数据，但是此时获取的数据可能不是最新的，因为可能主节点的操作数据还未同步到从节点上，这种现象叫“最终一致性”，即如果允许从节点读取数据的话，MongoDB不能保证数据的“强一致性”。