第五一部分 架构篇 第十二章 MongoDB 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的复制集架构：

• 不要在一个Replica Set架构的成员的机器上部署一个Arbiter(仲裁者)服务。
• Arbiter(仲裁者)不存储数据，但是当一个Arbiter（仲裁者）的mongod进程被添加到一个Replica Set架构中，Arbiter(仲裁者)会像其他任何一个mongod进程一样开始启动一个带有满容量的journal的数据文件集合。
• Arbiter允许在一个Replica Set中设置一个投票选举的基数。如下图架构所示：

1.3.2、添加一个Arbiter(仲裁者)

• 创建一个仲裁者的数据目录（如dbpath），mongod实例用这个目录来保存配置数据，该目录不会保存一个来自primary主日志复制的数据集合。如下所示:

mkdir /data/arb

mongod --port 30000 --dbpath /data/arb --replSet rs

rs.addArb("m1.example.net:30000")