常见问题：复制和副本集

• MongoDB支持哪种复制？ • 复制是否可以通过Internet和WAN连接进行？ • MongoDB可以通过“noisy”连接进行复制吗？ • 如果复制已经提供数据冗余，为什么还要使用journaling(预写日志,WAL)功能？ • 仲裁节点与副本集的其他节点交换了哪些信息？ • 副本集成员使用了不同大小的磁盘空间是否正常？ • 我可以重命名副本集吗？

本文档回答了有关MongoDB中复制的常见问题。另请参阅手册中的“ 复制”部分，其中提供了复制的概述，包括有关以下内容的详细信息：

• 副本集成员 • 副本集部署体系结构 • 副本集选举

MongoDB支持哪种复制？

MongoDB支持副本集，最多可包含50个节点。

MongoDB 4.0 移除了不再推荐使用的master-slave复制架构的支持。

复制是否可以通过Internet和WAN连接进行？

是。

例如，在东海岸数据中心可以部署一个primary和一个secondary，以及在西海岸数据中心部署一个作为灾难恢复的secondary成员。

也可以看看 部署异地冗余的副本集

MongoDB可以通过“noisy”连接进行复制吗？

是的，但连接失败和非常明显的延迟情况下不行。

副本集的成员将尝试重新连接到该组的其他成员以应对网络波动。这不需要管理员干预。但是，如果副本集中节点之间的网络连接非常慢，则节点成员可能无法跟上复制。

也可以看看 副本集选举

如果复制已经提供数据冗余，为什么还要使用journaling（预写日志,WAL）功能？

journaling功能有助于加快崩溃恢复速度。在journaling技术存在之前，崩溃的恢复通常需要修复数据库 或数据完全重新同步。两者都很慢，并且第一个是不可靠的。

journaling功能对于防止电源故障特别有用，尤其是当您的副本集部署在单个数据中心或电源电路中时。

当副本集与journaling功能一起运行时，您可以安全地重新启动 mongod实例而无需其他人工干预。

注意

journaling需要一些资源开销用于写入操作。但是，日记对读取性能没有影响。

在MongoDB v2.0及更高版本的所有64位版本上journaling功能是默认启用的。

仲裁节点与副本集的其余节点交换了哪些信息？

仲裁节点（Arbiters）永远不会复制集合的数据内容，但会与副本集的其余节点交换如下信息：

• 用于与副本集认证仲裁节点的凭据。这些交换数据是加密的。 • 副本集配置数据和投票数据。此信息未加密。仅加密凭证信息。

如果您的MongoDB使用TLS / SSL部署，则仲裁节点与副本集的其他成员之间的所有通信都是安全的。

有关详细信息，请参阅配置mongod和mongos  TLS / SSL的文档。与所有MongoDB组件一样，应该在安全网络上运行仲裁节点。

参见 副本集的仲裁成员节点概述 。

副本集成员使用了不同大小的磁盘空间是否正常？

是正常的。

因素包括：不同的oplog大小，不同程度的存储碎片，以及MongoDB的数据文件预分配都可能导致节点之间存储利用率的变化。添加成员的时间不同，则存储使用差异最为明显（译者注：可以理解为先后添加，因此上述存储碎片程度等差异就会比较明显，从而导致影响磁盘占用不同）。

我可以重命名副本集吗？

不可以。

您可以使用“ 从MongoDB备份还原副本集”教程中所述的备份和还原过程 来创建具有所需名称的新副本集。可能需要停机时间以确保原始副本集和新副本集之间的奇偶校验。

译者

钟秋

BBD技术经理，资深架构师，MongoDB中文社区联席主席

有丰富项目中应用MongoDB经验，熟悉MongoDB相互模式设计及性能优化，熟悉大数据相关技术和互联网及大数据应用架构设计