Ivan Seidel
Ivan Seidel

Reputation: 2362

Should I ensure MongoDB indexes on startup or in a script?

I'm using GeddyJs to build an application that will be scalable.

I'm going to use MongoDB, and doing some db.model.ensureIndex(...) is something that I got to do.

Is this something I should place inside, a Jake script for example? Is this something I should always run when server starts up?

Should I do it once from my command line, to configure the production db? Is there any design pattern for such thing?

Upvotes: 3

Views: 1684

Answers (1)

Stennie
Stennie

Reputation: 65333

Caveats on index builds

Foreground index builds in MongoDB (as at 2.6) are a blocking operation preventing all reads & writes to the affected database while the index builds. You need to exercise some caution when ensuring indexes on existing collections which have a reasonable amount of data. As at MongoDB 2.6, only one concurrent foreground index build per database is supported.

Background index builds take longer for the initial build and will typically be less efficient in terms of initial space usage, but will avoid unexpected downtime if you accidentally trigger an index build. Once built these indexes are functionally identical to any other index (the "background" aspect only applies to the initial index creation, not subsequent updates). MongoDB 2.4 or newer supports multiple concurrent background index builds.

Ensuring indexes for new/empty collections

If you are ensuring indexes for a new/empty collection, it's safe to ensure indexes on startup.

Ensuring indexes for existing collections with data

If you are ensuring indexes for a collection which may have data, I would recommend you either:

  • Build indexes via a maintenance script so you can control when new indexes are built (i.e. as part of your production deployment).

OR

Ensuring indexes with a replica set deployment

If your MongoDB deployment is a replica set, there are a few further considerations:

  • MongoDB 2.6 added support for background builds on secondaries.

  • In MongoDB 2.4 or older a background index build on a primary will become a foreground index build on secondaries. This can be a serious problem if all your secondaries end up building large indexes in the foreground at the same time, since replication to affected databases will be blocked until foreground index builds complete on the secondaries.

  • You can minimise the impact of large index builds by building on one node at time with a rolling update (i.e. building the index on a secondary at a time in standalone mode, and then finally stepping down and adding the index on the former primary).

  • For more information see: Build Indexes on Replica Sets.

Upvotes: 3

Related Questions