mongodb 后台创建索引避免阻塞

2019独角兽企业重金招聘Python工程师标准>>>

By default, creating an index blocks all other operations on a database. When building an index on a collection, the
database that holds the collection is unavailable for read or write operations until the index build completes. Any
operation that requires a read or write lock on all databases (e.g. listDatabases) will wait for the foreground index
build to complete.
For potentially long running index building operations, consider the background operation so that the MongoDB
database remains available during the index building operation. For example, to create an index in the background of
the zipcode field of the people collection, issue the following:

db.people.createIndex( { zipcode: 1}, {background: true} )

 

By default, background is false for building MongoDB indexes.
You can combine the background option with other options, as in the following:
 

db.people.createIndex( { zipcode: 1}, {background: true, sparse: true } )

 

Behavior
As of MongoDB version 2.4, a mongod instance can build more than one index in the background concurrently.
Changed in version 2.4: Before 2.4, a mongod instance could only build one background index per database at a time.
Changed in version 2.2: Before 2.2, a single mongod instance could only build one index at a time.
Background indexing operations run in the background so that other database operations can run while creating the
index. However, the mongo shell session or connection where you are creating the index will block until the index
build is complete. To continue issuing commands to the database, open another connection or mongo instance.
Queries will not use partially-built indexes: the index will only be usable once the index build is complete.

Note: If MongoDB is building an index in the background, you cannot perform other administrative
operations involving that collection, including running repairDatabase, dropping the collection (i.e.
db.collection.drop()), and running compact. These operations will return an error during background
index builds.

Performance
The background index operation uses an incremental approach that is slower than the normal “foreground” index
builds. If the index is larger than the available RAM, then the incremental process can take much longer than the
foreground build.
If your application includes createIndex() operations, and an index doesn’t exist for other operational concerns,
building the index can have a severe impact on the performance of the database.
To avoid performance issues, make sure that your application checks for the indexes at start up using the
getIndexes() method or the equivalent method for your driver7 and terminates if the proper indexes do not exist.
Always build indexes in production instances using separate application code, during designated maintenance
windows.
Interrupted Index Builds
If a background index build is in progress when the mongod process terminates, when the instance restarts the index
build will restart as foreground index build. If the index build encounters any errors, such as a duplicate key error, the
mongod will exit with an error.
To start the mongod after a failed index build, use the storage.indexBuildRetry or
--noIndexBuildRetry to skip the index build on start up.

 

Building Indexes on Secondaries
Changed in version 2.6: Secondary members can now build indexes in the background. Previously all index builds on
secondaries were in the foreground.
Background index operations on a replica set secondaries begin after the primary completes building the index. If
MongoDB builds an index in the background on the primary, the secondaries will then build that index in the background.
To build large indexes on secondaries the best approach is to restart one secondary at a time in standalone mode and
build the index. After building the index, restart as a member of the replica set, allow it to catch up with the other
members of the set, and then build the index on the next secondary. When all the secondaries have the new index, step
down the primary, restart it as a standalone, and build the index on the former primary.
The amount of time required to build the index on a secondary must be within the window of the oplog, so that the
secondary can catch up with the primary.
Indexes on secondary members in “recovering” mode are always built in the foreground to allow them to catch up as
soon as possible.

 

 

 

转载于:https://my.oschina.net/zhiyonghe/blog/1490477