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. primary需要最少数量的数据承载投票成员（即“提交法定人数”），包括它自己，这些成员必须在将索引标记为可供使用之前完成构建。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()和createIndexes()，MongoDB将忽略该选项。

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. 类似地，在索引构建过程中，应用程序可以成功地向inventory集合写入具有重复product_sku值的文档。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.停止无法保证无冲突写入操作的应用程序对集合的所有写入。

See also参阅

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

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 MB（对于4.2.3及更高版本）和500 MB（对于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在复制环境中构建索引

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.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.如果没有键约束冲突，则主索引将完成索引生成，将索引标记为可供使用，并创建关联的“CommittenDexBuild”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.createIndexes()和dbcollectioncreateIndexes()。

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上

If the primary mongod shuts down during the index build, the build progress is lost. 如果主mongod在索引生成期间关闭，则生成进度将丢失。The mongod automatically recovers the index build and restarts it from the beginning.mongod会自动恢复索引构建，并从头开始重新启动。

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

If a secondary shuts down during the index build, the index build job is persisted. 如果在索引生成过程中关闭了辅助系统，则索引生成作业将被持久化。Restarting the mongod automatically recovers the index build and restarts it from the beginning.重新启动mongod会自动恢复索引生成，并从头开始重新启动。

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.生成将保持暂停状态，直到手动删除（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 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. 当用户创建具有唯一键约束的索引时，一个碎片包含一个包含重复文档的区块。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 the mongo shell. 要查看索引生成操作的状态，可以在mongo shell中使用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字段包括索引构建过程中当前阶段的完整测量百分比。

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 Abort 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.一个临时表（“side writes table”），用于存储在生成过程中写入要编制索引的集合时生成的键。
  • 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在处理side write表中的密钥时遇到密钥生成错误，它会将该密钥存储在约束冲突表中，以供以后处理。

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向primary提交“投票”以提交索引。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是主要的，它会等到有了提交投票的法定人数（默认情况下，所有投票数据都包含成员）后再继续索引生成过程。

If the mongod is a secondary, it waits until it replicates either a “commitIndexBuild” or “abortIndexBuild” oplog entry:如果mongod是次要的，它会等待复制“CommittenDexBuild”或“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条目，它将完成对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会将写操作生成的任何附加键添加到要索引到side writes表的集合中，并定期清空该表。

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在处理side write表中的密钥时遇到密钥生成错误，它会将该密钥存储在约束冲突表中，以供以后处理。

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在处理side write表中的密钥时遇到密钥生成错误，它会将该密钥存储在约束冲突表中，以供以后处理。

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是主要的，它会使用先进先出优先级来清除约束冲突表。

  • 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. Secondaries can complete the associated index build after replicating the oplog entry.如果约束冲突表中没有键产生键生成错误，或者该表为空，则mongod会删除该表并创建“commitIndexBuild”oplog条目。在复制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是次要的，它会删除约束冲突表。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.因为在创建“CommitTopLogEntry”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锁。

See also参阅

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