1、Replication简介
MongoDB Replication即是在多个服务器中同步复制数据，数据复制的目的为提供冗余和提高数据的可用性，数据复制的操作即在不同的数据库服务器上保存多份复制的数据集，以此来避免单机故障进而丢失数据，复制机制也允许你恢复硬件故障和服务中断，进而起到数据的容灾和备份作用。
在MongoDB中，一个复制集就是一组mongod实例，一个mongod实例作为primary也就是所谓的master服务，接收所有的写操作，其他的mongod实例作为secondaries也就是所谓的slave服务，它们的业务来自于primary，以便于得到和primary相同的数据集。
1.1、Primary（master）
primary服务接收来自客户端的所有些操作，一个复制集架构中仅仅只能有一个primary服务，因为仅仅只允许一个复制集的成员接收写操作，复制集架构提供严格规定所有的读必须来自primary，MongoDB通过oplog日志来支持数据的变更。
以下是基于primary的复制集基础架构图：
1.2、secondaries（slave）
secondaries服务复制primary的主日志(oplog)来对它们的数据集进行操作，Secondaries数据集反映的是primary数据集，如果primary服务不可达，Replica Set架构会自动选择一个Secondaries来作为Primary，默认情况下，客户端从Primary进行读操作，然而客户端可以直接发送读操作给一个Secondaries服务来获取数据。客户端从Secondaries服务读取的数据不一定反映的是Primary的数据。
以下是基于Secondaries的复制集架构：
1.3、Arbiter(仲裁者)
基于上述的两种架构，你可以可以在其中添加一个额外的mongod实例作为replica set架构的仲裁者(arbiter),arbiter不会持有一个数据集，arbiter仅仅在当primary不可达时，要选择一个Secondary来作为primary的选举中投票使用，如果你的replica set架构有很多的成员，添加一个arbiter在primary的初级选举中会获得更多的票数，Arbiter不需要专门的硬件来支持。
以下是添加Arbiter的Replica Set架构：
注意：一个arbiter将永远都是一个arbiter，也就是说在一个Replica Set架构中一个仲裁者将永远是一个仲裁者，一个Primary可以变成一个Secondary，一个Secondary在重新的选举中也可以成为一个Primary。但是仲裁者在架构中不管发生都不能变化。
1.3.1、Replica Set Arbiter(复制集仲裁者)
在前面我们已经讲到了一个Arbiter（仲裁者）不会持有数据集的备份，也不能成为一个Primary服务来接收客户端的写操作，Replica Set也许在选择Primary有Arbiter(仲裁者)来增加选票，Aribter（仲裁者）允许复制集有不均匀的成员数量，它却没有像成员复制数据的开销。
注意：不要在和Primary服务以及Secondary服务成员同一台主机上运行一个Arbiter（仲裁者），仅仅添加一个Arbiter（仲裁者）作为一个Replica Set的固定成员，如果你添加一个Arbiter（仲裁者）作为一个Replica Set的临时成员，这个Replica Set也许在选举中造成投票不公平。
那么怎么在一个Replica Set架构中添加一个Arbiter（仲裁者）呢？
Arbiters（仲裁者）是一个mongod实例，作为Replica Set架构的一部分，但是它不会持有数据集，Arbiter（仲裁者）参与Primary的选举，以便打破选举中的绑架关系，如果一个Replica Set有均匀的成员，添加一个Arbiter（仲裁者）需要有一些极少的必备条件，它不需要硬件的支持，你可以在一个应用服务或者监控主机上部署一个Arbiter(仲裁者)服务。
注意事项：
- 不要在一个Replica Set架构的成员的机器上部署一个Arbiter(仲裁者)服务。
- Arbiter(仲裁者)不存储数据，但是当一个Arbiter（仲裁者）的mongod进程被添加到一个Replica Set架构中，Arbiter(仲裁者)会像其他任何一个mongod进程一样开始启动一个带有满容量的journal的数据文件集合。
- Arbiter允许在一个Replica Set中设置一个投票选举的基数。如下图架构所示：
1.3.2、添加一个Arbiter(仲裁者)
- 创建一个仲裁者的数据目录（如dbpath），mongod实例用这个目录来保存配置数据，该目录不会保存一个来自primary主日志复制的数据集合。如下所示:
- 开启一个Arbiter服务，需要指定数据目录和Replica Set名称，如下所示：
mongod --port 30000 --dbpath /data/arb --replSet rs
- 使用rs.addArb()方法将Arbiter服务添加到一个Replica Set，同时连接到Primary服务。
rs.addArb("m1.example.net:30000")
此时便在m1.example.net主机上运行了一个端口在30000的Arbiter(仲裁者)服务。
1.3.3、(Security)安全
Authentication(认证)
当Arbiter运行在一个需要认证的Replica Set的架构中时，Arbiter(仲裁者)交换凭据对该组成员进行身份验证，通过mongodb的加密认证进程，MongoDB认证交换加密的安全证书，此时Arbiter(仲裁者)服务需要一个key文件去验证Replica Set架构。
Communication(沟通)
在一个部署有Arbiter(仲裁者)的Replica Set架构中，仅仅只有Arbiter和其他成员的沟通，如选举投票、心跳、和配置数据的这些数据中不进行加密。
注意：当然如果你的MongoDB使用SSL部署，MongoDB将加密Replica Set架构中所有成员的沟通，关于SSL的MongoDB中应用在后面的章节会依依列出。
-------------------------------------------------------------MongoDB系列博文更新--------------------------------------------------------------------------------------------
