首页 > 代码库 > 第五部分 架构篇 第十二章 MongoDB Replica Sets 架构（简介）

第五部分 架构篇 第十二章 MongoDB Replica Sets 架构（简介）

2024-11-03 18:42:39   204人阅读

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主日志复制的数据集合。如下所示:

mkdir /data/arb

  • 开启一个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系列博文更新--------------------------------------------------------------------------------------------

第一部分 基础篇 第一章 走进MongoDB

第一部分 基础篇 第二章 安装MongoDB

第一部分 基础篇 第三章 MongoDB体系结构

第一部分 基础篇 第四章 MongoDB快速入门

第一部分 基础篇 第四章 MongoDB查询

第二部分 应用篇 第五章 MongoDB高级查询

第二部分 应用篇 第六章 MongoDB GridFS

第二部分 应用篇 第七章 MongoDB MapReduce

第三部分 管理篇 第八章 MongoDB服务管理

第三部分 管理篇 第九章 MongoDB shell之系统命令、用户命令

第三部分 管理篇 第九章 MongoDB shell之eval、进程

第四部分 性能篇 第十章 MongoDB 索引

第四部分 性能篇 第十一章 MongoDB 性能监控

第五部分 架构篇 第十二章 MongoDB Replica Sets 架构（简介）


联系
我们