Database Reference
In-Depth Information
"query" : {
},
"client" : "127.0.0.1:53421",
"desc" : "conn",
"msg" : "index: (1/3) external sort 3999999/4308303 92%"
}
]
}
The last field,
msg
, describes the build's progress. Note also the
lockType
, which indi-
cates that the index build takes a write lock. This means that no other client can read
or write from the database at this time. If you're running in production, this is obvi-
ously a bad thing, and it's the reason why long index builds can be so vexing. We're
going to look right now at two possible solutions to this problem.
Background indexing
If you're running in production and can't afford to halt access to the database, you
can specify that an index be built in the background. Although the index build will
still take a write lock, the job will yield to allow other readers and writers to access the
database. If your application typically exerts a heavy load on MongoDB, then a back-
ground index build will degrade performance, but this may be acceptable under cer-
tain circumstances. For example, if you know that the index can be built within a time
window where application traffic is at a minimum, then background indexing in this
case might be a good choice.
To build an index in the background, specify
{background: true}
when you
declare the index. The previous index can be built in the background like so:
db.values.ensureIndex({open: 1, close: 1}, {background: true})
Offline indexing
If your production data set is too large to be indexed within a few hours, then you'll
need to make alternate plans. This will usually involve taking a replica node offline,
building the index on that node by itself, and then allowing the node to catch up with
the master replica. Once it's caught up, you can promote the node to primary and
then take another secondary offline and build
its
version of the index. This tactic pre-
sumes that your replication oplog is large enough to prevent the offline node from
becoming stale during the index build. The next chapter covers replication in detail
and should help you plan for a migration such as this.
B
ACKUPS
Because indexes are hard to build, you may want to back them up. Unfortunately, not
all backup methods include indexes. For instance, you might be tempted to use
mongodump
and
mongorestore
, but these utilities preserve collections and index decla-
rations only. This means that when you run
mongorestore
, all the indexes declared
for any collections you've backed up will be re-created. As always, if your data set is
large, the time it takes to build these indexes may be unacceptable.
