前言
在平时的学习开发中，我们一般都是在单点模式下进行的，也就是使用单台服务器，一个mongod服务器进程。对于单点模式，首先部署起来很方便，只需要几个简单的参数或者使用默认配置就能将实例启动，其次单点模式很节省资源。但是在生成环境中，如果服务器崩溃或者不可访问怎么办？数据库至少有一段时间不可用。如果硬盘损坏或将满，可能需要将数据转移到另一个机器上。在最坏的情况下，硬盘或网络出现问题可能会导致数据损坏或者数据不可访问。这是就可以使用MongoDB的复制功能，即使一台或多台服务器出错，也可以保证应用程序正常运行和数据安全。
复制集介绍
MongoDB复制集是从传统主从结构（Master/Slave）演变而来，是由一组拥有相同数据集的mongod实例所组成的集群。
读写分离的主从结构：
读写分离的基本原理就是让主数据库处理事务性增、改、删（写）操作，而从数据库处理查询（读）操作。数据库复制被用来把事务性操作导致的变更同步到其他从数据库。以SQL为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新到读库。写库就一个，读库可以有多个，采用日志同步的方式实现主库和多个读库的数据同步。
一个复制集包含多个数据节点和一个选举节点。数据节点中仅有一个为主节点（Primary），其它的为从节点（Secondary）。对于主节点，所有的请求都是在它上面完成的，从节点接收主节点传来的操作并以此来保证与主节点上的数据完全一致。需注意只有主节点能接收写操作，从节点是绝对无法写入的。不同于MySQL设置read only的从节点若有super权限同样可进行写操作。不难看出，复制集是通过复制而实现数据的冗余而提高数据的可靠性。
replica-set-read-write-operations-primary
从上图可以看出，所有的读写请求都是由客户端应用程序通过驱动来指向MongoDB数据库，写请求都是指向当前数据库的主节点，写请求执行完毕后，会记录在主节点的
oplog中（记录写操作而不记录读操作），从节点通过主节点的oplog来进行复制操作。在默认情况下，读请求也是指向主节点的。因为MongoDB复制集是异步复制形式，会由于磁盘的刷盘效率和网络的原因导致从节点的数据相对于主节点有一点延迟，驱动在没有配置的情况下会指向主库，也就是当前最新的数据。当然如果对数据的时效性要求不高时可以配置读操作指向某一个从节点，实现读写分离。
复制集特点
- MongoDB复制集的主是唯一的，但不是固定的。
当前主节点出现故障时，比如网络不通等等，集群会自动容灾，通过选举在从节点中选出一个合适的充当主节点。我们可以通过配置从节点优先级来决定哪个从节点尽可能地成为主节点。 - MongoDB有一个大多数原则。
当主节点出故障时，是否能选举出新的主节点，并不是由复制集中投票节点存在与否来决定的，而是由当前复制集成员存活数量来决定的。当存活节点小于等于二分之一时，将全部降为从节点，只可读不可写。 - 从库无法写入，这点在前面已经介绍。
-
传统主从结构仅剩的一丝尊严
在某些情况下，可能由于硬盘空间的限制，从节点并不想完全复制主节点中的数据，只想给特定的数据库做冗余。这时就可以用主从结构，在搭建从节点时在配置文件中指定only选项，并把要复制的数据库的库名作为参数放在后面。但是only并不能应用于复制集中，想象一下，如果当前主节点A拥有三个库1、2、3，从节点只复制其中的一个库1。当主节点A挂了，则选举出新的主节点B。当A恢复正常重新投入使用，它要从新的主节点B中复制数据时，发现B中没有2、3库，那么这时复制就会出错，这就是复制集不支持复制指定库的原因。 -
限制
在3.0.0版本中，复制集最多拥有50个节点（之前的版本仅支持12个）且参与选举的数据节点只能有7个，超过该限制就需要使用主从结构。
