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. 前台索引构建速度快，生成的索引数据结构更高效，但需要在构建期间阻止对正在索引的集合的父数据库的所有读写访问。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()和createIndex() and 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提示

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 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有限，在修改mongod RAM使用之前，您可能需要安排一个维护期以增加总系统RAM。

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

Note注意
Requires featureCompatibilityVersion 4.4+要求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.primary需要最少数量的数据承载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.主节点接收createIndexes命令，并立即创建与索引构建关联的“startIndexBuild”oplog条目。
  2. The secondaries start the index build after they replicate the "startIndexBuild" oplog entry.二级数据库在复制“startIndexBuild”oplog条目后开始索引构建。
  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”oplog条目。
    • 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”oplog条目。

  6. The secondaries replicate the "commitIndexBuild" oplog entry and complete the index build.二级复制“commitIndexBuild”oplog条目并完成索引构建。

    If the secondaries instead replicate an "abortIndexBuild" oplog entry, they abort the index build and discard the build job.如果二级复制的是“abortIndexBuild”oplog条目，它们将中止索引构建并放弃构建作业。

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().要使用非默认提交仲裁启动索引生成，请将commitQuorum参数指定给createIndexes或其shell助手db.collection.createIndex()和db.collection.createIndexes()。

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.滚动索引生成需要至少选择一个副本集。

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.生成将保持暂停状态，直到手动调用dropIndexes删除。

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 3.2.6）开始，配置服务器primary定期检查分片集合的分片之间的索引不一致性。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，以报告在配置服务器primary上运行时的索引不一致。

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助手dropIndex()或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 indexor 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会为该文档生成一个键，并将其存储在side write表中，以供以后处理。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向主节点提交“投票”以提交索引。Specifically, it writes the "vote" to an internal replicated collection on the 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”或“AbortIndexBuld”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复制了一个“CommittenDexBuild”oplog条目，它将完成对side writes表的排空，并转移到索引构建过程的下一阶段。
  • 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在删除side writes表之前应用该表中的所有剩余操作。

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将删除该表并创建“CommittenDexBuild”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 mustsuccessfully drain the constraint violation table prior to creating the "commitOplogEntry" oplog entry, the secondary can safely assume that no violations exist.由于在创建“commitOplogEntry”oplog条目之前，主服务器必须成功地清空约束冲突表，因此辅助服务器可以安全地假设不存在冲突。

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

←  Sparse IndexesRolling Index Builds on Replica Sets →