来扫视 的架构 知晓 7 MongoDB 复制和分片 MongoDB

MongoDB 经过建设在几个外围架构基础之上的开发者数据平台，使您能够满足现代运行程序的需求。它让您能够以最佳形式启动翻新，构建事务性、操作性和剖析性运行程序。本章将特意强调两个关键元素：复制和分片，来扫视 MongoDB 的架构。

复制是 MongoDB 散布式架构中的关键组成局部，确保数据的可访问性和对缺点的韧性。它使您能够将相反的数据集散布在不同的数据库主机上，防止单个主机的缺点。

此外，您还将了解到分片，这是一种将数据散布在多台机器上的水平裁减战略。随着运行程序的遍及和它们发生的数据量参与，跨机器裁减变得至关关键，以确保足够的读写吞吐量。

人们经常将复制与分片混杂。虽然两者都是数据库治理中经常使用的系统集，但它们服务于不同的目的，并因不同的要素而经常使用。复制是一个数据被复制并存储在多个位置以确保冗余和牢靠性的环节，在数据包全和可访问性中表演着至关关键的角色。

另一方面，分片触及将较大的数据库划分为更小、更易于治理的局部，称为分片。每个分片在独自的数据库主机实例上存储数据集的一局部。但是，须要留意的是，每个分片还必定成功复制以保养数据的完整性和可用性。

联合分片和复制的目的是确保数据的耐久性和高可用性。当分片的主机实例失败，且该分片上只要单个数据正本时，或许会造成数据无法用，直到主机复原或改换为止。经过在每个分片内驳回复制，分片集群可以坚持数据可用性，并防止主机缺点惹起的任何终止。这种方法使分片集群能够在不停机的状况下启动滚动更新，准许颠簸且不连续的系统保养。

接上去的几节将深化讨论复制和分片及其各自的组件。

复制 在 MongoDB 中，正本集是指保养相反数据集的一组 mongod 进程。它们提供冗余和高可用性，是一切消费实施的基础。经过在多个数据库主机上领有多个数据正本，复制确保了必定水平的容错才干，包全免受单个数据库主机缺点的影响。

图 2.1：一个正本集

主节点处置一切写操作，并将一切数据集更改记载在其操作日志（oplog）中。MongoDB 正本集只能有一个主节点。

辅佐节点复制主节点的 oplog，并在自己的数据集上成功操作，确保它们镜像主节点的数据集。假设主节点变得无法访问，一个合格的辅佐节点将启动选举成为新的主节点。

经过在多个主机上存储数据，复制提高了系统的牢靠性。此外，支持滚动更新准许您在不终止的状况下更新单个主机的软件或配件，确保数据库的继续可用性。复制清楚提高了读取密集型运行程序的性能，将读取负载散布在多个主机上，以确保极速的数据检索。

正本集选举MongoDB 经常使用建设在 Raft 共识算法之上的协定来协调正本集选举，确保散布式系统的数据分歧性。该协定包括正本集用于选用哪个成员将承当主角色的投票机制。

可以启动选举的几个事情包括：

您的运行程序的衔接处置逻辑应该设计得能够思考智能缺点转移和随后的选举。MongoDB 驱动程序有才干识别主节点的失落，并智能重试特定的读取或写入操作，为选举提供了额外的内置韧性层。

当主正本变得无法用时，辅佐正本会为新的主节点投票。具备最近写入时期戳的正本更有或许赢得选举。这种战略最小化了先前的主节点从新参与集时的回滚时机。选举后，节点进入解冻期，在这时期它们不能启动另一次性选举。这是为了防止延续、极速的选举，这或许会破坏系统的稳固性。目前，MongoDB 正本集仅支持称为协定版本 1（pv1）的协定。

图 2.2：选举新的主节点

正本集在选举成功完结之前无法口头写操作。但是，假设它们被性能为针对辅佐节点，正本集依然可以处置读取操作。

在反常状况下，自动正本集性能设置下，集群选举新主节点所需的平均时期不应超越 12 秒。这个继续时期包括发表主节点无法访问所需的时期，以及启动和成功选举所需的时期。可以经过更改设置来调整这个时期框架。选举超时性能选项settings.electionTimeoutMillis 可以调整这个时期。

成员优先级 ：一旦建设了稳固的主节点，选举算法准许最高优先级的辅佐节点启动选举。成员优先级影响选举的机遇和结果，优先级更高的辅佐节点或许会更早地启动选举并获胜。但是，虽然有优先级更高的成员可用，优先级较低的成员或许会持久地担任主节点。选举环节继续启动，直到最高优先级的成员成为主节点。优先级值为 0 的成员不能成为主节点，也不寻求选举。

由于正本集最多可以容纳 50 名成员，其中只要 7 名是投票成员，包括非投票成员可以使集超越 7 名的限度。非投票成员的特色是领有零票，必定具备优先级为 0。

正本集 oplog ：oplog 是一个共同的固定汇合，它保养了一个延续的日志，记载了一切扭转 MongoDB 数据库中数据的操作。它可以裁减超越其设置的大小限度，以防止删除大少数提交点。

MongoD 中的写操作在主节点上口头，随后记载在主节点的 oplog 中。辅佐成员异步复制并运行这些操作。正本集的一切成员都持有 oplog 的正本，位于 local.oplog.rs 汇合中，使它们能够跟上数据库的形态。

为了支持复制，正本集的一切成员都相互替换心跳（ping）。任何辅佐成员都可以从任何其余成员导入 oplog 条目。oplog 中的每个操作都是幂等的，这象征着无论对目的数据集运行一次性还是屡次，oplog 操作都会发生相反的结果。

oplog 窗口 ：Oplog 条目带有时期戳。oplog 窗口指的是 oplog 中最近和最早时期戳之间的时时期隔。假设辅佐节点与主节点失去衔接，只要在从新建设衔接的时期在 oplog 窗口的继续时期内，它才干经常使用复制从新同步。MongoDB 准许定义保管 oplog 条目的最小继续时期（以小时为单位），以及特定大小。系统仅在以下条件下才会摈弃 oplog 条目：

正本集部署架构 ：消费系统的规范部署触及一个三成员的正本集。这些集提供了冗余和对缺点的韧性。虽然倡导防止不用要的复杂性，但架构最终应由运行程序的需求指点。通常，应遵照以下规定：

正本集仲裁者 ：在您领有一个主节点和一个辅佐节点，但估算限度阻止您参与另一个辅佐节点的状况下，您可以将仲裁者归入您的正本集。仲裁者介入主节点选举，但它不持有数据集的正本，也无法成为主节点。仲裁者在选举中携带一票。自动状况下，其优先级设置为0。

暗藏的正本集成员 ：暗藏成员造成副 本集的一个关键局部；但是，它们不能担任主节点角色，并且在客户端运行程序中无法见。虽然无法见，暗藏成员依然能够介入并投票选举。暗藏节点可以作为公用正本集成员，用于口头备份操作或运转某些报告查问。要设置一个暗藏节点并防止成员被优化为主节点，您可以将其优先级设置为0，并将暗藏参数性能为true，如下例所示：

cfg = rs.conf()cfg.members[n].hidden = truecfg.members[n].priority = 0rs.reconfig(cfg)

提前的正本集成员提前成员也是暗藏成员，它们以故意的提前从源oplog复制和运行操作，代表集群的先前形态。例如，假设时期是08:01，并且一个成员的提前设置为一小时，那么提前成员上的最新操作不会晚于07:01：

cfg = rs.conf()cfg.members[n].hidden = truecfg.members[n].priority = 0cfg.members[0].secondaryDelaySecs = 3600rs.reconfig(cfg)

提前成员充任继续的备份或数据集的实时历史记载，为防止人为失误提供安保网。例如，它们可以促成从失败的运行程序更新和操作员失误中复原，如异常删除数据库和汇合。

写入关注写入关注确定MongoDB在正本集上确认写入操作的形式。它提供了一种机制，以确保在确认写入操作之前，数据被写入指定数量的节点。

写入关注的组成局部以下字段可以蕴含

{ w: <value>, j: <boolean>, wtimeout: <number> }

从MongoDB 4.4开局，正本集和分片集群都有才干建设全局自动写入关注。任何未定义特定写入关注的操作都将智能驳回此全局自动写入关注的设置。经常使用治理命令setDefaultRWConcern来建设全局自动性能，用于读取或写入关注：

db.adminCommand({setDefaultRWConcern : 1,defaultReadConcern: { <read concern> },defaultWriteConcern: { <write concern> },writeConcern: { <write concern> },comment: <any>})

从MongoDB 5.0起，自动写入关注设置为 { w: "majority" }。但是，当部署包括仲裁者时，有例外：

写入关注的关键性写入关注的选用可以影响数据的性能和耐久性：

读取偏好在MongoDB中，读取偏好确定MongoDB客户端如何将读取操作路由到正本集的成员。自动状况下，MongoDB将一切读取操作定向到主成员。但是，经过调整读取偏好，可以将读取负载散布到辅佐成员，提高系统的全体性能和可用性。

读取偏好的组成局部MongoDB支持五种读

除了读取偏好形式，您还可以指定以下选项：

读取偏好的关键性读取偏好的选用可以影响数据的性能和可用性：

读取关注读取关注选择了从正本集和分片集群中读取的数据的分歧性和隔离属性。经过调整读取关注，可以控制读取操作中数据的可见性，从而确保所需的分歧性和隔离级别。

读取关注的组成局部MongoDB 支持以下读取关注级别：

读取关注的关键性读取关注的选用可以影响数据的分歧性和隔离性：

复制方法MongoDB Shell (mongosh) 提供了一系列 shell 辅佐方法，旨在促成与正本集的交互。它们是治理复制 MongoDB 部署的关键工具。让咱们审核一些治理 MongoDB 复制所需的关键方法：

无关复制方法的具体列表，请访问以下资源：复制方法

除了上述复制方法，您还可以经常使用复制命令启动特定操作。例如，replSetResizeOplog 扭转正本集中变量 oplog 的大小。该命令接受以下字段：

db.adminCommand({replSetResizeOplog: <int>,size: <double>,minRetentionHours: <double>})

要了解更多关于复制命令的消息，请访问以下资源：复制命令

分片MongoDB 经过火片支持水平裁减。分片触及将数据散布在泛滥进程中，并在治理和组织大规模数据中施展关键作用。这种方法将较大的数据库划分为更小、更易治理的组件，称为分片。每个分片存储在独自的数据库主机实例上，这扩散了负载并提供了有效的数据治理方法。此外，该技术准许创立散布式数据库以支持天文散布的运行程序，成功强迫数据在特定区域内寓居的战略。

为什么须要分片？思考一个数据极速裁减且数据库凑近其最大容量的场景。这种状况或许会出现许多应战。通常，最紧迫的疑问是性能好转。随着数据库的增长，查问和检索数据所需的时期或许会清楚参与。这种减速对用户体验发生负面影响，使运行程序看起来缓慢或无照应。

另一个潜在阻碍是存储限度。大少数 系统都有一个它们可以有效治理的数据量下限。假设您的数据增长超越了系统的存储才干，它或许造成系统缺点。在治理系统增长方面，有两种关键战略——垂直裁减和水平裁减：

分片集群的关键元素MongoDB 分片集群由

图 2.3 展现了分片集群内组件的交互。

图 2.3：一个分片集群

在 MongoDB 中，数据分片出当初汇合级别，这象征着汇合的数据散布在集群内的多个分片中。须要留意的是，分片集群中的每个数据库都有自己的主分片，担任存储该数据库内一切未分片的汇合。值得一提的是，分片集群中的主分片概念与正本集中的主节点不同；它们服务于不同的目的，彼此之间没无关联。

创立新数据库时，由 mongos 进程选用主分片。它选用集群中数据量起码的分片。listDatabases 命令前往的 totalSize 字段被用作选用规范的一个要素。

经常使用 movePrimary 命令可以在初次调配后移动主分片。movePrimary 命令最后扭转集群元数据中的主分片，而后迁徙一切未分片的汇合到指定的分片。

微分片在某些状况下，MongoDB 提供了一种更先进的分片性能，称为微分片。与传统的将每个分片调配给公用机器的方法不同，微分片准许经过在单个主机上共置多个分片来成功更细粒度的控制和资源优化。

微分片可以是一 种有效的战略，特意是当处置每个分片的较小数据大小时。经过在单个主机上兼并多个分片，可以最大化资源应用率，从而提高配件效率。

图 2.4：微分片性能

留意：这种方法须要细心的资源治理，以防止同一主机上运转的不同MongoDB进程之间出现抵触。每个MongoDB进程都须要调配足够的资源以有效运转。在实施微分片战略时，正确性能每个MongoDB进程的缓存大小至关关键。可以经过设置storage.wiredTiger.engineConfig.cacheSizeGB来调整MongoDB中WiredTiger存储引擎的缓存大小。这个缓存应该足够大，以容纳每个MongoDB进程的上班集。假设缓存缺乏必要的空间来加载更少数据，WiredTiger将从缓存中移除页面以腾出空间。

自动状况下，storage.wiredTiger.engineConfig.cacheSizeGB 性能为总RAM的50%，少于1GB。但是，当在同一台机器上运转多个MongoDB进程时，您应该调整此设置，以确保一切MongoDB进程的总内存经常使用量不超越可用RAM。

例如，假设您在一台领有16GB RAM的机器上运转两个MongoDB进程，您可以为每个进程将storage.wiredTiger.engineConfig.cacheSizeGB设置为25%（或4GB），而不是自动的50%。这可以防止MongoDB进程群体消耗超越总可用RAM的内存，为操作系统和其余运行程序留出足够的内存。

分片的长处：分片提供了几个好处，例

数据散布： 在分片的MongoDB集群中，正确的数据散布关于平衡上班负载、提高性能和增强可裁减性至关关键，它可以防止瓶颈并确保资源的有效应用。

分片键： MongoDB在汇合级别口头分片，准许您选用要分片的汇合。选用分片键关于分片集群至关关键，由于不当的选用或许造成数据散布不均、分片之间负载调配不平衡和查问性能降低。这些疑问或许会使某些分片过载，而其余分片则未充沛应用，降低系统效率。在极其状况下，一个被称为热分片的单个分片或许会成为瓶颈，重大影响集群性能。因此，选用正确的分片键关于分片环境中的最优性能至关关键。

经过经常使用由一个或多个文档字段组成的分片键，MongoDB将汇合的文档散布在各个分片上。数据经过合成分片键值的范畴被划分为不堆叠的块。目的是在集群的分片中平均散布这些块，确保有效的散布。

在MongoDB的近期版本中，对分片性能启动了清楚修正：

分片战略： MongoDB支持两种分片战略，用于在分片集群中散布数据：

MongoDB 4.4引入了经常使用单个哈希字段构建复合索引的才干。要创立这样的复合哈希索引，在索引创立时期，将任何单个索引键的值指定为哈希。复合哈希索引为复合索引中的单个字段计算哈希值；这个值连同索引中的其余字段一同用作您的分片键。以下是一个示例：

db.planets.createIndex({ "name":1, "_id": "hashed" })sh.shardCollection("sample_guides.planets", { "name": 1, "_id": "hashed" })

上述命令在name字段上创立了一个升序的复合哈希索引，_id作为哈希字段，并分片了planets汇合。

分片键索引： 要分片一个已填充的汇合，该汇合须要有一个以分片键扫尾的索引。但是，在分片一个空汇合时，假设汇合还没有为指定的分片键预备适宜的索引，MongoDB会智能生成所需的支持索引。

块： MongoDB将分片数据组织成不同的局部，称为块或范畴（从MongoDB 5.2开局，自动大小为128MB；在此版本之前为64MB）。每个块由分片键定义的蕴含下限和不蕴含下限所特色。这些块蕴含特定分片内一系列不连续的分片键值。从MongoDB 6.1开局，块不再智能宰割。相反，块仅在跨分片移动时宰割。

留意： 在MongoDB 6.1之前，当块大小超越最大块大小时，块会被智能宰割器宰割。

平衡器敌对均块散布： 从MongoDB 6.0.3开局，分片集群中的数据散布基于数据大小而非块的数量。为了确保块的平衡散布，一个名为平衡器的后盾进程跟踪每个分片上每个分片汇合的数据量，并在不同分片之间移动块。当特定分片上的分片汇合的数据量到达特定的迁徙限度时，平衡器尝试从新调配跨分片的数据，目的是在遵守区域的同时成功每个分片上的数据平均散布。自动状况下，这个平衡环节是继续生动的。

平衡器在性能主机正本集（CSRS）的主节点上运转。关于分片集群的平衡环节对用户和运行层是齐全透明的，虽然在口头时期或许会观察到细微的性能影响。

为了减轻这种影响，平衡器尝试：

当特定分片汇合的最重载分片与最轻载分片之间的数据差异到达迁徙阈值时，开局一轮平衡。当分片之间的数据差异（关于该特定汇合）小于汇合的已建设范畴大小的三倍时，以为汇合是平衡的。假设范畴大小设置为自动的128MB，则假设某个汇合的任何两个分片之间的数据大小差异至少为384MB，将触发迁徙。

可以为平衡器的操作设置特定时期框架，以防止其搅扰消费流量。这称为平衡窗口或平衡器窗口。

块治理： 在某些状况下，须要手动治理块。

要手动肃清标志，在治理数据库中，动员clearJumboFlag命令，提供分片汇合的命名空间和以下任一选项：

db.adminCommand({clearJumboFlag: "sample.customers",bounds: [{ "x": 5 }, { "x": 6 }]});

db.adminCommand({clearJumboFlag: "sample.customers",find: { "x": 5 }});

假设汇合经常使用哈希分片键，请防止在经常使用clearJumboFlag时经常使用find字段。关于具备哈希分片键的汇合，经常使用边界字段更为适宜。

假设您行将向新的分片集群加载少量数据，预宰割可以协助从一开局就将数据平均散布在各个分片上。这可以防止单个分片成为瓶颈。

留意： 倡导仅对为空的汇合预宰割范畴。尝试为曾经蕴含数据的汇合手动宰割范畴或许造成不规定的范畴边界和大小，并且也或许造成平衡行为运转效率低下或基本不运转。

要手动宰割空范畴，可以经常使用宰割命令。该命令将分片集群中的一个块宰割成两个独自的块。宰割命令必定在治理数据库中口头。

让咱们来看一个例子。假定您有一个名为myapp.products的汇合，您宿愿依据指定的宰割点将范畴预宰割为四个不同的多少钱类别。分片键设置在多少钱字段上。可以经常使用以下代码在mongosh中成功：

// 依据指定的宰割点将汇合宰割为块var splitPoints = [20, 50, 100];// 留意：'split'命令可以驳回middle、find或bounds作为选项。// 在这个例子中，您经常使用middle选项来指定宰割点。for(var i = 0; i < splitPoints.length; i++) {db.adminCommand({split: "myapp.products",middle: {price: splitPoints[i]}});}

这段代码将数据分为四个多少钱类别：

从MongoDB 6.0开局，平衡器依据数据大小在分片之间调配数据。仅仅宰割范畴或许无法确保数据在分片之间平均散布。因此，您必定手动移动块以确保平衡散布：

// 您宿愿将块移动到的分片列表var shards = ["shard0000", "shard0001", "shard0002", "shard0003"];for (var i = 0; i < splitPoints.length; i++) {var lowerBound = { price: MinKey };if (i > 0) {lowerBound = { price: splitPoints[i-1] };}var upperBound = { price: MaxKey };if (i < splitPoints.length - 1) {upperBound = { price: splitPoints[i] };}// 手动将块移动到所需的分片db.adminCommand({moveChunk: "myapp.products",find: lowerBound,to: shards[i],bounds: [lowerBound, upperBound]});}

这种方法有助于从一开局就在分片之间平均调配数据。

查问分片数据：查问MongoDB分片集群中的数据与在单主机部署或正本集中查问数据不同。您不是衔接到单个主机或正本集的主节点，而是衔接到mongos，它充任查问路由器并选择向哪个分片恳求数据。在下一节中，您将探求mongos路由器的上班原理。

mongos路由器：mongos实例提供对您的MongoDB集群的惟一接口和入口点。运行程序衔接到mongos而不是间接衔接究竟层的分片。mongos口头查问，搜集结果，并将它们传递给运行程序。mongos进程不持有任何耐久形态，通常也不会经常使用少量的系统资源。它作为恳求的代理。当查问出去时，mongos审核它，选择须要在哪些分片上口头查问，并在一切目的分片上建设游标。

find：假设查问蕴含分片键或分片键的前缀，mongos将口头针对性操作，只查问蕴含您要查找的键的分片。

假定用户汇合的复合分片键是_id

db.user.find({ _id: 1 })db.user.find({ _id: 1, "email": "packt@packt.com" })db.user.find({ _id: 1, "email": "packt@packt.com" , "country": "UK" })

这些查问蕴含前缀（前两个查问的状况）或完整的分片键。另一方面，对{ email, country }或{ country }的查问将无法定位正确的分片，造成广播操作。广播操作是任何不蕴含分片键或分片键前缀的操作，造成mongos查问每个分片。它们也称为散布-搜集操作或扇出查问。

sort(), limit(), 和 skip()：假设您想对结果启动排序，您有两种选用：

查问的limit在每个独自的分片上强迫口头，而后在mongos级别再次口头，由于或许有来自多个分片的结果。另一方面，skip运算符不能传递给单个分片，并将由mongos在检索一切结果后本地运行。

假设您组合经常使用skip()和limit()游标方法，mongos将经过将两个值传递给单个分片来优化查问。这在分页等状况下特意有用。假设您在没有sort()的状况下启动查问，并且结果来自多个分片，mongos将为结果在分片之间启动轮询。

更新和删除从MongoDB 7.0开局，文档修正操作（如更新和删除）的处置流程已被简化。假设修正操作中的find()局部蕴含分片键，mongos可以继续将查问路由到适当的分片。但是，假设find局部中缺少分片键，它不再像早期版本那样触发扇收操作。

关于updateOne()、deleteOne()或findAn dModify()操作，不再严厉要求蕴含分片键或_id值。可以经常使用任何字段来婚配文档，相似于非分片汇合。但是，经常使用分片键启动这些操作依然更有效率，由于它准许针对性查问。

例如，在MongoDB 6.0中，您必定传递一个分片键来口头updateOne()：

db.cities.updateOne({ "city": "New York City" }, { $set: { "population" : 8500000 }});

在这个例子中，city代表分片键。但是，在MongoDB 7.0中，您可以在不蕴含过滤条件中的分片键的状况下运转updateOne()操作：

db.cities.updateOne({ "population" : 293200 }, { $set: { "areaSize" : 211 }});

表2.3总结了MongoDB 7.0中可用于分片的操作：

可以蕴含分片键，但不是必定的

后盾启动散布-搜集操作

索引排序，查问带分片键

索引排序，查问不带分片键

可以经常使用任何字段启动婚配，但经常使用分片键更有效

表2.1：分片操作

包全性读取从MongoDB 4.4开局，mongos实例可以对经常使用非主读取偏好的读取操作启动包全性读取。mongos实例将每个查问分片的读取操作定向到正本集中的两个成员，而后前往每个分片的第一个照应结果。

支持包全性读取的操作包括：collStats、count、dataSize、dbStats、distinct、filemd5、find、listCollections、listIndexes和planCacheListFilters。

分片方法为了治理数据的 散布，MongoDB提供了一组辅佐方法。这些方法用于启用分片、定义数据应如何散布以及监控分片的形态。它们是治理分片MongoDB部署的关键工具，准许在多台机器上高效地裁减数据。以下是各种mongosh shell辅佐方法的列表：

包括数据大小，包括度量单位

报告分片中的文档数量

反映分片的每个块的预计数据大小，包括度量单位

反映分片的每个块的预计文档数量

报告分片汇合中数据的总大小，包括度量单位

报告分片汇合中的总文档数量

报告一切分片的块数量

示意每个分片的预计数据大小占汇合总数据大小的百分比

反映每个分片的预计文档数量占汇合总文档数量的百分比

MongoDB 7.0继续简化了分片集群的治理和了解，无论是关于运维还是开发用例。这个版本提供了额外的洞察力，协助为初始和未来的分片键选用做出最佳决策。此外，从MongoDB 7.0开局，开发者在经常使用这些命令时可以在分片和非分片集群上体验到分歧的接口，同时在必要时依然保管优化性能的选项。让咱们看看MongoDB 7.0中引入的新分片个性。

由于复杂的数据形式和掂量，选用分片键是一项复杂的义务。但是，MongoDB 7.0中的新个性旨在简化这项义务：

AutoMerger是一个智能兼并合乎某些可兼并要求的块的个性。此环节作为平衡操作的一局部在后盾运转。除非被禁用，否则AutoMerger在初次启用平衡器时启动，并在每次运转后暂停固定距离（autoMergerIntervalSecs）。它在启用时的每个距离口头智能兼并。关于每个汇合，它确保延续兼并之间的最小提前（autoMergerThrottlingMS）。假设定义了平衡窗口，AutoMerger仅在该窗口内运转。在满足以下一切条件的状况下，同一汇合中的两个或多个延续块是可兼并的：

您可以经常使用以下方法来控制AutoMerger的行为：

无需分片键的命令支持

在分片和非分片集群上经常使用updateOne、deleteOne和findAndModify等命令的经常使用将是分歧的，同时在须要时提供优化性能的选项。

MongoDB中的复制是一个经过在多个主机间同步数据来提供冗余和提高数据可用性的环节。这是经过正本集成功的，正本集是一组保养相反数据集的MongoDB主机。在正本集中，一个节点作为主节点，接纳一切写操作，而辅佐节点将主节点的操作复制到它们自己的数据集中。这种结构为缺点转移和复原提供了一个强健的系统。假设主节点失败，辅佐节点之间的选举将确定一个新的主节点，准许客户端操作的延续性。

MongoDB中的分片是一种将数据宰割和散布到多个主机或分片上的方法。每个分片是一个独立的正本集，并且分片共同组成一个繁多的逻辑数据库——分片集群。这种方法用于支持具备十分大数据集和高吞吐量操作的部署，有效地处置可裁减性疑问。