What’s new on MongoDB 2.6

MongoDB 2.6

Although MongoDB 2.6 has not yet been published yet, are already know some new features that can now be tested in the 2.5.4 Development Releases (MongoDB reserves the odd-numbered versions for Development Releases and even-numbered as Production Releases)

Until MongoDB 2.6 is released, we’ve prepared a short summary of some of the most relevant new features it will have.

Background Indexes on Secundaries

Before version 2.6 of MongoDB, indexing into large databases on production environments could become a serious problem.

Imagine an application that is based on a Replica Set and in its collections there are store a huge amount of data and also receives a high volume of reads and writes to its primary node but due to a recent change requires a new index .

The solution, apparently would run it by enabling the background indexing to not block other operations taking place in the database

But there is something else we should know about indexes in the background before version 2.6:

Background indexes become foreground indices executed in Secondary Replica Set members and all operations performed in the secondary indexing block the replication.

At this point, the best way to deal with the problem is running the operating independently on each member of the replica set.

All this is about to change:

Thanks to MongoDB 2.6 Indexes executed in the background on primary members of the Replica Set will become background indexes on the secondary members.

In any case, it is important to remember that generally, the background indexes tend to take longer and consume more resources than the indexes in the foreground because they allow the execution of other operations simultaneously, and duration of the operation will depend on the size of the collections, number of documents, system load… so for production environments we recommend running indexes independently on each member, by disconnecting the Replica Set or otherwise, in the foreground taking advantage of maintenance windows.

Orphaned documents cleanup on Sharding

MongoDB provides horizontal growth through Sharding, that facilitates the distribution of groups of documents (chunks) of collections over a number of nodes, evenly distributed.

Sometimes, due to system failures, backup or bulk operations, some of these documents become “orphans” in sharding nodes, causing problems such as repeated query results.

To solve this kinds of incidents was created cleanupOrphaned() that allow you to delete orphaned documents in a shard, given a data range.

This command must be run on the primary server, changing the data range and running it from time to time to ensure that these documents have been removed.

By default cleanupOrphaned () will wait to finish all the operations on the secondaries before returning control, but this behavior can be modified through the secondaryThrottle that run every delete operation with the W:2 method (wait for a secondary)

César Trigo

Backend Development Director @ Gigigo Group

You may also like...

Leave a Reply