MongoDB 第13章 Replica Sets 架构（简介）

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中设置一个投票选举的基数。如下图架构所示：