Docs Home → MongoDB Manual

Index Builds on Populated Collections索引建立在已填充的集合上

On this page本页内容

Starting in MongoDB 4.2, index builds use an optimized build process that holds an exclusive lock on the collection at the beginning and end of the index build. 从MongoDB 4.2开始，索引构建使用优化的构建过程，该过程在索引构建的开始和结束时对集合持有独占锁。The rest of the build process yields to interleaving read and write operations. 构建过程的其余部分将产生交错的读写操作。For a detailed description of index build process and locking behavior, see Index Build Process.有关索引生成过程和锁定行为的详细描述，请参阅索引生成过程。

Starting in MongoDB 4.4, index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members. 从MongoDB 4.4开始，索引在副本集上构建，或者在所有承载数据的副本集成员之间同时构建分片集群。The primary requires a minimum number of data-bearing voting members (i.e. commit quorum), including itself, that must complete the build before marking the index as ready for use. 主索引需要最少数量的带有数据的投票成员（即提交法定人数），包括其本身，这些成员必须在将索引标记为可使用之前完成构建。A "voting" member is any replica set member where members[n].votes is greater than 0. “有投票权”成员是members[n].votes大于0的任何副本集成员。See Index Builds in Replicated Environments for more information.有关详细信息，请参阅复制环境中的索引生成。

Behavior行为

Comparison to Foreground and Background Builds前景和背景构建的比较

Previous versions of MongoDB supported building indexes either in the foreground or background. MongoDB的早期版本支持在前台或后台构建索引。Foreground index builds were fast and produced more efficient index data structures, but required blocking all read-write access to the parent database of the collection being indexed for the duration of the build. Foreground索引构建速度快，生成了更高效的索引数据结构，但需要在构建期间阻止对正在索引的集合的父数据库的所有读写访问。Background index builds were slower and had less efficient results, but allowed read-write access to the database and its collections during the build process.后台索引生成速度较慢，结果效率较低，但在生成过程中允许对数据库及其集合进行读写访问。

Starting in MongoDB 4.2, index builds obtain an exclusive lock on only the collection being indexed during the start and end of the build process to protect metadata changes. 从MongoDB 4.2开始，索引构建在构建过程的开始和结束期间仅对正在索引的集合获得独占锁定，以保护元数据更改。The rest of the build process uses the yielding behavior of background index builds to maximize read-write access to the collection during the build. 4.2 index builds still produce efficient index data structures despite the more permissive locking behavior.构建过程的其余部分使用后台索引构建的屈服行为，以在构建过程中最大限度地实现对集合的读写访问。4.2尽管有更宽松的锁定行为，但索引构建仍然会产生高效的索引数据结构。

The optimized index build performance is at least on par with background index builds. 优化的索引构建性能至少与后台索引构建相当。For workloads with few or no updates received during the build process, optimized index builds can be as fast as a foreground index build on that same data.对于在构建过程中几乎没有或根本没有收到更新的工作负载，优化的索引构建可以像基于相同数据的前台索引构建一样快。

Use db.currentOp() to monitor the progress of ongoing index builds.使用db.currentOp()可以监视正在进行的索引生成的进度。

MongoDB ignores the background index build option if specified to createIndexes or its shell helpers createIndex() and createIndexes().如果指定为createIndexes或其shell助手createIndex()和createIndexes()，MongoDB将忽略background索引构建选项。

Constraint Violations During Index Build索引生成过程中的约束冲突

For indexes that enforce constraints on the collection, such as unique indexes, the mongod checks all pre-existing and concurrently-written documents for violations of those constraints after the index build completes. 对于对集合强制执行约束的索引，如唯一索引，mongod会在索引构建完成后检查所有预先存在的和并发编写的文档是否违反了这些约束。Documents that violate the index constraints can exist during the index build. If any documents violate the index constraints at the end of the build, the mongod terminates the build and throws an error.在索引生成过程中，可能存在违反索引约束的文档。如果任何文档在构建结束时违反了索引约束，mongod将终止构建并抛出错误。

For example, consider a populated collection inventory. 例如，考虑一个已填充的集合inventory。An administrator wants to create a unique index on the product_sku field. 管理员希望在product_sku字段上创建一个唯一索引。If any documents in the collection have duplicate values for product_sku, the index build can still start successfully. 如果集合中的任何文档具有重复的product_sku值，则索引生成仍然可以成功启动。If any violations still exist at the end of the build, the mongod terminates the build and throws an error.如果在构建结束时仍然存在任何冲突，mongod将终止构建并抛出错误。

Similarly, an application can successfully write documents to the inventory collection with duplicate values of product_sku while the index build is in progress. 类似地，在索引构建过程中，应用程序可以成功地将具有重复值product_sku的文档写入inventory集合。If any violations still exist at the end of the build, the mongod terminates the build and throws an error.如果在构建结束时仍然存在任何冲突，mongod将终止构建并抛出错误。

To mitigate the risk of index build failure due to constraint violations:要降低由于违反约束而导致索引生成失败的风险，请执行以下操作：

  • Validate that no documents in the collection violate the index constraints.验证集合中是否没有文档违反索引约束。
  • Stop all writes to the collection from applications that cannot guarantee violation-free write operations.停止无法保证无冲突写入操作的应用程序对集合的所有写入。

Sharded Collections分片集合

For a sharded collection distributed across multiple shards, one or more shards may contain a chunk with duplicate documents. 对于分布在多个分片上的分片集合，一个或多个分片可能包含一个具有重复文档的区块。As such, the create index operation may succeed on some of the shards (i.e. the ones without duplicates) but not on others (i.e. the ones with duplicates). 因此，创建索引操作可能会在一些分片（即没有重复的分片）上成功，但在其他分片（即有重复的分片。）上不会成功。To avoid leaving inconsistent indexes across shards, you can issue the db.collection.dropIndex() from a mongos to drop the index from the collection.为了避免在分片之间留下不一致的索引，您可以从mongos发出db.collection.dropIndex()来从集合中删除索引。

To mitigate the risk of this occurrence, before creating the index:为了降低这种情况的风险，在创建索引之前：

  • Validate that no documents in the collection violate the index constraints.验证集合中是否没有文档违反索引约束。
  • Stop all writes to the collection from applications that cannot guarantee violation-free write operations.停止无法保证无冲突写入操作的应用程序对集合的所有写入。
Tip

See also: 另请参阅：

Index Consistency Checks for Sharded Collections分片集合的索引一致性检查

Maximum Concurrent Index Builds最大并发索引构建数

By default, the server allows up to three concurrent index builds. 默认情况下，服务器最多允许三个并发索引构建。To change the number of allowed concurrent index builds, modify the maxNumActiveUserIndexBuilds parameter.若要更改允许的并发索引生成数，请修改maxNumActiveUserIndexBuilds参数。

If the number of concurrent index builds reaches the limit specified by maxNumActiveUserIndexBuilds, the server blocks additional index builds until the number of concurrent index builds drops below the limit.如果并发索引生成的数量达到maxNumActiveUserIndexBuilds指定的限制，则服务器将阻止其他索引生成，直到并发索引生成数量降至该限制以下。

Index Build Impact on Database Performance索引生成对数据库性能的影响

Index Builds During Write-Heavy Workloads写入繁重工作负载期间索引生成

Building indexes during time periods where the target collection is under heavy write load can result in reduced write performance and longer index builds.在目标集合处于高写负载下的时间段内构建索引可能会导致写性能降低和索引构建时间延长。

Consider designating a maintenance window during which applications stop or reduce write operations against the collection. 考虑指定一个维护窗口，在此期间应用程序停止或减少对集合的写入操作。Start the index build during this maintenance window to mitigate the potential negative impact of the build process.在此维护窗口期间启动索引生成，以减轻生成过程的潜在负面影响。

Insufficient Available System Memory (RAM)可用系统内存（RAM）不足

createIndexes supports building one or more indexes on a collection. createIndexes支持在集合上构建一个或多个索引。createIndexes uses a combination of memory and temporary files on disk to complete index builds. 使用磁盘上的内存和临时文件的组合来完成索引构建。The default limit on memory usage for createIndexes is 200 megabytes (for versions 4.2.3 and later) and 500 (for versions 4.2.2 and earlier), shared between all indexes built using a single createIndexes command. createIndexes的内存使用默认限制为200兆字节（适用于4.2.3及更高版本）和500兆字节（用于4.2.2及更早版本），在使用单个createIndexes命令构建的所有索引之间共享。Once the memory limit is reached, createIndexes uses temporary disk files in a subdirectory named _tmp within the --dbpath directory to complete the build.一旦达到内存限制，createIndexes就会使用--dbpath目录中名为_tmp的子目录中的临时磁盘文件来完成构建。

You can override the memory limit by setting the maxIndexBuildMemoryUsageMegabytes server parameter. 您可以通过设置maxIndexBuildMemoryUsageMegabytes服务器参数来覆盖内存限制。Setting a higher memory limit may result in faster completion of index builds. 设置更高的内存限制可能会更快地完成索引构建。However, setting this limit too high relative to the unused RAM on your system can result in memory exhaustion and server shutdown.但是，相对于系统上未使用的RAM，将此限制设置得过高可能会导致内存耗尽和服务器关闭。

If the host machine has limited available free RAM, you may need to schedule a maintenance period to increase the total system RAM before you can modify the mongod RAM usage.如果主机的可用RAM有限，您可能需要安排一个维护期来增加系统的总RAM，然后才能修改mongod RAM的使用情况。

Index Builds in Replicated Environments复制环境中的索引构建

Note

Requires 需要featureCompatibilityVersion 4.4+

Each mongod in the replica set or sharded cluster must have featureCompatibilityVersion set to at least 4.4 to start index builds simultaneously across replica set members.副本集或分片集群中的每个mongod必须将featureCompatibilityVersion设置为至少4.4，才能在副本集成员之间同时启动索引构建。

MongoDB 4.4 running featureCompatibilityVersion: "4.2" builds indexes on the primary before replicating the index build to secondaries.MongoDB 4.4运行featureCompatibilityVersion: "4.2"在主数据库上构建索引，然后将索引构建复制到辅助数据库。

Starting with MongoDB 4.4, index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members. 从MongoDB 4.4开始，索引在副本集上构建，或者在所有承载数据的副本集成员之间同时构建分片集群。For sharded clusters, the index build occurs only on shards containing data for the collection being indexed. 对于分片集群，索引构建仅发生在包含要索引的集合的数据的分片上。The primary requires a minimum number of data-bearing voting members (i.e commit quorum), including itself, that must complete the build before marking the index as ready for use.主索引需要最少数量的带有数据的voting成员（即提交法定人数），包括其本身，这些成员必须在将索引标记为可使用之前完成构建。

The build process is summarized as follows:构建过程总结如下：

  1. The primary receives the createIndexes command and immediately creates a "startIndexBuild" oplog entry associated with the index build.primary接收createIndexes命令，并立即创建与索引构建相关联的“startIndexBuild”oplog条目。
  2. The secondaries start the index build after they replicate the "startIndexBuild" oplog entry.辅助设备在复制“startIndexBuild”操作日志条目后启动索引生成。
  3. Each member "votes" to commit the build once it finishes indexing data in the collection.一旦完成对集合中数据的索引，每个成员都会“投票”提交构建。
  4. Secondary members continue to process any new write operations into the index while waiting for the primary to confirm a quorum of votes.次要成员继续处理对索引的任何新写入操作，同时等待主要成员确认法定票数。
  5. When the primary has a quorum of votes, it checks for any key constraint violations such as duplicate key errors.当主投票达到法定票数时，它会检查是否存在任何违反键约束的情况，例如重复的键错误。

    • If there are no key constraint violations, the primary completes the index build, marks the index as ready for use, and creates an associated "commitIndexBuild" oplog entry.如果不存在违反键约束的情况，主索引将完成索引生成，将索引标记为可供使用，并创建关联的“commitIndexBuild”操作日志条目。
    • If there are any key constraint violations, the index build fails. 如果存在任何违反键约束的情况，则索引生成将失败。The primary aborts the index build and creates an associated "abortIndexBuild" oplog entry.主进程中止索引生成并创建一个关联的“abortIndexBuild”操作日志条目。
  6. The secondaries replicate the "commitIndexBuild" oplog entry and complete the index build.辅助设备复制“commitIndexBuild”操作日志条目并完成索引构建。

    If the secondaries instead replicate an "abortIndexBuild" oplog entry, they abort the index build and discard the build job.如果辅助复制“abortIndexBuild”操作日志条目，则它们将中止索引生成并放弃生成作业。

For sharded clusters, the index build occurs only on shards containing data for the collection being indexed.对于分片集群，索引构建仅发生在包含要索引的集合的数据的分片上。

For a more detailed description of the index build process, see Index Build Process.有关索引生成过程的更详细描述，请参阅索引生成过程。

By default, index builds use a commit quorum of "votingMembers", or all data-bearing voting members. 默认情况下，索引构建使用"votingMembers"的提交法定人数，或所有带有投票成员的数据。To start an index build with a non-default commit quorum, specify the commitQuorum parameter to createIndexes or its shell helpers db.collection.createIndex() and db.collection.createIndexes().要使用非默认提交仲裁启动索引构建，请给createIndexes或其shell助手db.collection.createIndex()和db.collection.createIndexes()指定commitQuorum参数。

To modify the commit quorum required for an in-progress simultaneous index build, use the setIndexCommitQuorum command.若要修改正在进行的同时索引生成所需的提交仲裁，请使用setIndexCommitQuorum命令。

Note

Index builds can impact replica set performance. 索引生成可能会影响复制副本集的性能。For workloads which cannot tolerate performance decrease due to index builds, consider performing a rolling index build process. 对于无法容忍由于索引构建而导致性能下降的工作负载，请考虑执行滚动索引构建过程。Rolling index builds take at most one replica set member out at a time, starting with the secondary members, and builds the index on that member as a standalone. 滚动索引构建从辅助成员开始，一次最多取出一个副本集成员，并在该成员上作为独立成员构建索引。Rolling index builds require at least one replica set election.滚动索引生成至少需要一个副本集选择。

Commit Quorum Contrasted with Write Concern提交法定人数与写入关注的对比

There are important differences between commit quorums and write concerns:提交法定人数和写入关注之间存在重要差异：

  • Index builds use commit quorums.索引构建使用提交法定人数。
  • Write operations use write concerns.写入操作使用写入关注。

Each data-bearing node in a cluster is a voting member.集群中的每个数据承载节点都是一个投票成员。

The commit quorum specifies how many data-bearing voting members, or which voting members, including the primary, must be prepared to commit a simultaneous index build. before the primary will execute the commit.提交法定人数指定有多少数据承载投票成员，或者必须准备哪些投票成员（包括主要成员）来提交同时索引构建。在主服务器执行提交之前。

The write concern is the level of acknowledgement that the write has propagated to the specified number of instances.写入关注是确认写入已传播到指定数量的实例的级别。

The commit quorum specifies how many nodes must be ready to finish the index build before the primary commits the index build. 提交仲裁指定在主提交索引生成之前，必须准备好多少节点才能完成索引生成。In contrast, when the primary has committed the index build, the write concern specifies how many nodes must finish the index build before the command returns.相反，当主节点提交了索引构建时，写入关注会指定在命令返回之前必须有多少节点完成索引构建。

Build Failure and Recovery生成失败和恢复

Interrupted Index Builds on a Primary mongod中断索引建立在主mongod上

Starting in MongoDB 5.0, if the primary mongod shuts down cleanly during the index build and the commitQuorum is set to the default votingMembers, then the index build progress is saved to disk. 从MongoDB 5.0开始，如果主mongod在索引构建过程中干净地关闭，并且commitQuorum设置为默认的votingMembers，那么索引构建进度将保存到磁盘。The mongod automatically recovers the index build when it is restarted and continues from the saved checkpoint. mongod在重新启动时自动恢复索引构建，并从保存的检查点继续。In earlier versions, if the index build was interrupted it had to be restarted from the beginning.在早期版本中，如果索引生成被中断，则必须从头开始重新启动。

Interrupted Index Builds on a Secondary mongod中断的索引建立在二级mongod上

Starting in MongoDB 5.0, if a secondary mongod shuts down cleanly during the index build and the commitQuorum is set to the default votingMembers, then the index build progress is saved to disk. 从MongoDB 5.0开始，如果辅助mongod在索引构建过程中干净地关闭，并且commitQuorum设置为默认的votingMembers，那么索引构建进度将保存到磁盘。The mongod automatically recovers the index build when it is restarted and continues from the saved checkpoint. mongod在重新启动时自动恢复索引构建，并从保存的检查点继续。In earlier versions, if the index build was interrupted it had to be restarted from the beginning.在早期版本中，如果索引生成被中断，则必须从头开始重新启动。

Prior to MongoDB 4.4, the startup process stalls behind any recovered index builds. 在MongoDB 4.4之前，启动过程在任何恢复的索引构建之后都会暂停。The secondary could fall out of sync with the replica set and require resynchronization. 辅助可能与副本集不同步，需要重新同步。Starting in MongoDB 4.4, the mongod can perform the startup process while the recovering index builds.从MongoDB 4.4开始，mongod可以在构建恢复索引的同时执行启动过程。

If you restart the mongod as a standalone (i.e. removing or commenting out replication.replSetName or omitting --replSetName), the mongod cannot restart the index build. 如果将mongod作为独立的重新启动（即删除或注释掉replication.replSetName或省略--replSetName），则mongod无法重新启动索引构建。The build remains in a paused state until it is manually dropped.在手动删除该生成之前，该生成一直处于暂停状态。

Interrupted Index Builds on Standalone mongod中断索引建立在独立mongod上

If the mongod shuts down during the index build, the index build job and all progress is lost. 如果mongod在索引构建过程中关闭，则索引构建作业和所有进度都将丢失。Restarting the mongod does not restart the index build. 重新启动mongod不会重新启动索引生成。You must re-issue the createIndex() operation to restart the index build.必须重新发出createIndex()操作才能重新启动索引生成。

Rollbacks during Build Process生成过程中的回滚

Starting in MongoDB 5.0, if a node is rolled back to a prior state during the index build, the index build progress is saved to disk. 从MongoDB 5.0开始，如果在索引构建过程中将节点回滚到以前的状态，则索引构建进度将保存到磁盘。If there is still work to be done when the rollback concludes, the mongod automatically recovers the index build and continues from the saved checkpoint.如果回滚结束时仍有工作要做，mongod会自动恢复索引构建，并从保存的检查点继续。

Starting in version 4.4, MongoDB can pause an in-progress index build to perform a rollback.从4.4版本开始，MongoDB可以暂停正在进行的索引构建以执行回滚。

  • If the rollback does not revert the index build, MongoDB restarts the index build after completing the rollback.如果回滚没有恢复索引构建，MongoDB会在完成回滚后重新启动索引构建。
  • If the rollback reverts the index build, you must re-create the index or indexes after the rollback completes.如果回滚还原索引生成，则必须在回滚完成后重新创建索引。

Prior to MongoDb 4.4, rollbacks could start only after all in-progress index builds finished.在MongoDb 4.4之前，回滚只能在所有正在进行的索引构建完成后才能开始。

Index Consistency Checks for Sharded Collections分片集合的索引一致性检查

A sharded collection has an inconsistent index if the collection does not have the exact same indexes (including the index options) on each shard that contains chunks for the collection. 如果一个分片集合在包含该集合块的每个分片上没有完全相同的索引（包括索引选项），则该集合具有不一致的索引。Although inconsistent indexes should not occur during normal operations, inconsistent indexes can occur, such as:尽管在正常操作期间不应出现不一致的索引，但也可能出现不一致索引，例如：

  • When a user is creating an index with a unique key constraint and one shard contains a chunk with duplicate documents. 当用户创建一个具有unique键约束的索引，并且一个分片包含一个具有重复文档的区块时。In such cases, the create index operation may succeed on the shards without duplicates but not on the shard with duplicates.在这种情况下，创建索引操作可能会在没有重复的分片上成功，但在有重复的分片中不会成功。
  • When a user is creating an index across the shards in a rolling manner (i.e. manually building the index one by one across the shards) but either fails to build the index for an associated shard or incorrectly builds an index with different specification.当用户以滚动方式（即，手动在分片之间逐个构建索引）在分片之间创建索引时，但未能为关联的分片构建索引，或者错误地构建了不同规范的索引。

Starting in MongoDB 4.4 (and in MongoDB 4.2.6), the config server primary periodically checks for index inconsistencies across the shards for sharded collections. 从MongoDB 4.4（以及MongoDB 4.2.6）开始，配置服务器主服务器定期检查分片集合的分片之间的索引不一致。To configure these periodic checks, see enableShardedIndexConsistencyCheck and shardedIndexConsistencyCheckIntervalMS.要配置这些定期检查，请参阅enableShardedIndexConsistencyCheck和shardedIndexConsistencyCheckIntervalMS。

The command serverStatus returns the field shardedIndexConsistency to report on index inconsistencies when run on the config server primary.当在配置服务器主服务器上运行时，命令serverStatus返回字段shardedIndexConsistency以报告索引不一致。

To check if a sharded collection has inconsistent indexes, see Find Inconsistent Indexes Across Shards.若要检查分片集合是否具有不一致的索引，请参阅查找跨分片的不一致索引。

Monitor In Progress Index Builds监控正在进行的索引生成

To see the status of an index build operation, you can use the db.currentOp() method in mongosh. 要查看索引构建操作的状态，可以使用mongosh中的db.currentOp()方法。To filter the current operations for index creation operations, see Active Indexing Operations for an example.要筛选索引创建操作的当前操作，请参阅活动索引操作以获取示例。

The msg field includes a percentage-complete measurement of the current stage in the index build process.msg字段包括索引构建过程中当前阶段的完成百分比度量。

Observe Stopped and Resumed Index Builds in the Logs观察日志中已停止和已恢复的索引生成

While an index is being built, progress is written to the MongoDB log. 在构建索引时，进度会写入MongoDB日志。If an index build is stopped and resumed there will be log messages with fields like these:如果停止并恢复索引生成，则会出现包含以下字段的日志消息：

 "msg":"Index build: wrote resumable state to disk",

 "msg":"Found index from unfinished build",

Terminate In Progress Index Builds终止正在进行的索引生成

Use the dropIndexes command or its shell helpers dropIndex() or dropIndexes() to terminate an in-progress index build. 使用dropIndexes命令或其shell助手dropIndexes或dropIndexes()终止正在进行的索引生成。See Stop In-Progress Index Builds for more information.有关详细信息，请参阅停止正在进行的索引生成。

Do not use killOp to terminate an in-progress index builds in replica sets or sharded clusters.不要使用killOp终止副本集中或分片集群中正在进行的索引构建。

Index Build Process索引生成过程

The following table describes each stage of the index build process:下表描述了索引生成过程的每个阶段：

Stage阶段Description描述
Lock锁The mongod obtains an exclusive X lock on the the collection being indexed. mongod在被索引的集合上获得一个独占的X锁。This blocks all read and write operations on the collection, including the application of any replicated write operations or metadata commands that target the collection. 这会阻止集合上的所有读写操作，包括应用任何复制的写操作或以集合为目标的元数据命令。The mongod does not yield this lock.mongod不交出这把锁。
Initialization初始化The mongod creates three data structures at this initial state:mongod在这个初始状态下创建三个数据结构：
  • The initial index metadata entry.初始索引元数据条目。
  • A temporary table ("side writes table") that stores keys generated from writes to the collection being indexed during the build process.一个临时表（“侧写表”），用于存储在生成过程中写入要索引的集合所生成的键。
  • A temporary table ("constraint violation table") for all documents that may cause a key generation error. Key generation errors occur when a document has invalid keys for the indexed fields. 一个临时表（“约束冲突表”），用于所有可能导致键生成错误的文档。当文档的索引字段的键无效时，会发生键生成错误。For example, a document with duplicate field values when building a unique index or malformed GeoJSON objects when building a 2dsphere index.例如，在构建唯一索引时具有重复字段值的文档，或者在构建2dsphere索引时具有格式错误的GeoJSON对象。
Lock锁The mongod downgrades the exclusive X collection lock to an intent exclusive IX lock. mongod将独占X集合锁降级为意念独占IX锁。The mongod periodically yields this lock to interleaving read and write operations.mongod周期性地将这个锁交给交错的读写操作。
Scan Collection扫描集合For each document in the collection, the mongod generates a key for that document and dumps the key into an external sorter.对于集合中的每个文档，mongod为该文档生成一个键，并将该键转储到外部分类器中。
If the mongod encounters a key generation error while generating a key during the collection scan, it stores that key in the constraint violation table for later processing.如果mongod在集合扫描期间生成键时遇到键生成错误，它会将该键存储在约束冲突表中以供稍后处理。
If the mongod encounters any other error while generating a key, the build fails with an error.如果mongod在生成键时遇到任何其他错误，则构建将失败并返回错误。
Once the mongod completes the collection scan, it dumps the sorted keys into the index. 一旦mongod完成集合扫描，它就会将排序后的键转储到索引中。
Process Side Writes Table进程侧写入表The mongod drains the side write table using first-in-first-out priority.mongod使用先进先出优先级来消耗侧写表。
If the mongod encounters a key generation error while processing a key in the side write table, it stores that key in the constraint violation table for later processing.如果mongod在处理侧写表中的键时遇到键生成错误，它会将该键存储在违反约束的表中，以供以后处理。
If the mongod encounters any other error while processing a key, the build fails with an error.如果mongod在处理键时遇到任何其他错误，则构建将失败并返回错误。
For each document written to the collection during the build process, the mongod generates a key for that document and stores it in the side write table for later processing. 对于在构建过程中写入集合的每个文档，mongod都会为该文档生成一个键，并将其存储在侧写表中以供稍后处理。The mongod uses a snapshot system to set a limit to the number of keys to process. mongod使用快照系统来设置要处理的键数量的限制。
Vote and Wait for Commit Quorum投票并等待提交法定人数A mongod that is not part of a replica set skips this stage.不属于复制集的mongod跳过此阶段。
Starting in MongoDB 4.4, the mongod submits a "vote" to the primary to commit the index. 从MongoDB 4.4开始，mongod向primary提交一个“投票”来提交索引。Specifically, it writes the "vote" to an internal replicated collection on the primary.具体地说，它将“投票”写入primary上的内部复制集合。
If the mongod is the primary, it waits until it has a commit quorum of votes (all voting data-bearing members by default) before continuing the index build process.如果mongod是primary，它会等待，直到它有了提交的法定投票数（默认情况下，所有投票数据都包含成员），然后再继续索引构建过程。
If the mongod is a secondary, it waits until it replicates either a "commitIndexBuild" or "abortIndexBuild" oplog entry:如果mongod是secondary，它会等待，直到复制“commitIndexBuild”或“abortIndexBuild“oplog条目：
  • If the mongod replicates a "commitIndexBuild" oplog entry, it finishes draining the side writes table and moves to the next stage in the index build process.如果mongod复制了一个“commitIndexBuild”oplog条目，它将完成侧写表的消耗，并进入索引构建过程的下一阶段。
  • If the mongod replicates an "abortIndexBuild" oplog entry, it aborts the index build and discards the build job.如果mongod复制了一个“abortIndexBuild”oplog条目，它将中止索引构建并丢弃构建作业。
While waiting for commit quorum, the mongod adds any additional keys generated from write operations to the collection being indexed to the side writes table and periodically drains the table. 在等待提交仲裁时，mongod会将写入操作生成的任何附加键添加到索引到侧写表的集合中，并定期清空该表。
Lock锁The mongod upgrades the intent exclusive IX lock on the collection to a shared S lock. mongod将集合上的意见独占IX锁升级为共享S锁。This blocks all write operations to the collection, including the application of any replicated write operations or metadata commands that target the collection.这会阻止对集合的所有写入操作，包括应用任何复制的写入操作或以集合为目标的元数据命令。
Finish Processing Temporary Side Writes Table完成处理临时侧面写入表The mongod continues draining remaining records in the side writes table. mongod继续排出side-writes表中的剩余记录。The mongod may pause replication during this stage.在此阶段，mongod可能会暂停复制。
If the mongod encounters a key generation error while processing a key in the side write table, it stores that key in the constraint violation table for later processing.如果mongod在处理侧写表中的键时遇到键生成错误，它会将该键存储在约束冲突表中，以供以后处理。
If the mongod encounters any other error while processing a key, the build fails with an error. 如果mongod在处理键时遇到任何其他错误，则构建将失败并返回错误。
Lock锁The mongod upgrades the shared S lock on the collection to an exclusive X lock on the collection. mongod将集合上的共享S锁升级为集合上的独占X锁。This blocks all read and write operations on the collection, including the application of any replicated write operations or metadata commands that target the collection. 这会阻止集合上的所有读写操作，包括应用任何复制的写操作或以集合为目标的元数据命令。The mongod does not yield this lock.mongod不交出这把锁。
Drop Side Write Table删除侧写入表The mongod applies any remaining operations in the side writes table before dropping it.mongod在删除侧写表之前应用该表中的任何剩余操作。
If the mongod encounters a key generation error while processing a key in the side write table, it stores that key in the constraint violation table for later processing.如果mongod在处理侧写表中的键时遇到键生成错误，它会将该键存储在约束冲突表中，以供以后处理。
If the mongod encounters any other error while processing a key, the build fails with an error.如果mongod在处理键时遇到任何其他错误，则构建将失败并返回错误。
At this point, the index includes all data written to the collection. 此时，索引包括写入集合的所有数据。
Process Constraint Violation Table流程约束违反表If the mongod is the primary, it drains the constraint violation table using first-in-first-out priority. 如果mongod是primary，它会使用先进先出优先级来耗尽约束冲突表。
  • If no keys in the constraint violation table produce a key generation error or if the table is empty, the mongod drops the table and creates a "commitIndexBuild" oplog entry. 如果约束冲突表中没有键产生键生成错误，或者表为空，则mongod将删除该表并创建一个“commitIndexBuild”oplog条目。Secondaries can complete the associated index build after replicating the oplog entry.复制oplog条目后，辅助人员可以完成关联的索引构建。
  • If any key in the constraint violation table still produces a key generation error, the mongod aborts the build and throws an error. 如果约束冲突表中的任何键仍然产生键生成错误，则mongod中止构建并抛出错误。The mongod creates an associated "abortIndexBuild" oplog entry to indicate that secondaries should abort and discard the index build job.mongod创建一个关联的“abortIndexBuild”oplog条目，指示辅助设备应该中止并放弃索引构建作业。
If the mongod is a secondary, it drops the constraint violation table. 如果mongod是secondary，它将删除约束冲突表。Since the primary must successfully drain the constraint violation table prior to creating the "commitOplogEntry" oplog entry, the secondary can safely assume that no violations exist. 由于在创建“commitOplogEntry”操作日志条目之前，主项必须成功地排出约束冲突表，因此辅助项可以安全地假设不存在冲突。
Mark the Index as Ready将索引标记为就绪The mongod updates the index metadata to mark the index as ready for use. mongod更新索引元数据，将索引标记为可供使用。
Lock锁The mongod releases the X lock on the collection.mongod释放集合上的X锁。
Tip

See also: 另请参阅：

FAQ: Concurrency常见问题解答：并发