Compatibility Changes in MongoDB 3.0

Configuration File Options Changes

With the introduction of additional storage engines in 3.0, some configuration file options have changed:

Previous Setting	New Setting
storage.journal.commitIntervalMs	storage.mmapv1.journal.commitIntervalMs
storage.journal.debugFlags	storage.mmapv1.journal.debugFlags
storage.nsSize	storage.mmapv1.nsSize
storage.preallocDataFiles	storage.mmapv1.preallocDataFiles
storage.quota.enforced	storage.mmapv1.quota.enforced
storage.quota.maxFilesPerDB	storage.mmapv1.quota.maxFilesPerDB
storage.smallFiles	storage.mmapv1.smallFiles

3.0 mongod instances are backward compatible with existing configuration files, but will issue warnings when if you attempt to use the old settings.

Data Files Must Correspond to Configured Storage Engine

The files in the dbPath directory must correspond to the configured storage engine (i.e. --storageEngine). mongod will not start if dbPath contains data files created by a storage engine other than the one specified by --storageEngine.

WiredTiger and Driver Version Compatibility

For MongoDB 3.0 deployments that use the WiredTiger storage engine, the following operations return no output when issued in previous versions of the mongo shell or drivers:

• db.getCollectionNames()
• db.collection.getIndexes()
• show collections
• show tables

Use the 3.0 mongo shell or the 3.0 compatible version of the official drivers when connecting to 3.0 mongod instances that use WiredTiger. The 2.6.8 mongo shell is also compatible with 3.0 mongod instances that use WiredTiger.

db.fsyncLock() is not Compatible with WiredTiger

With WiredTiger the db.fsyncLock() and db.fsyncUnlock() operations cannot guarantee that the data files do not change. As a result, do not use these methods to ensure consistency for the purposes of creating backups.

Support for touch Command

If a storage engine does not support the touch, then the touch command will return an error.

• The MMAPv1 storage engine supports touch.
• The WiredTiger storage engine does not support touch.

Dynamic Record Allocation

MongoDB 3.0 no longer supports dynamic record allocation and deprecates paddingFactor.

MongoDB 3.0 deprecates the newCollectionsUsePowerOf2Sizes parameter such that you can no longer use the parameter to disable the power of 2 sizes allocation for a collection. Instead, use the collMod command with the noPadding flag or the db.createCollection() method with the noPadding option. Only set noPadding for collections with workloads that consist only of inserts or in-place updates (such as incrementing counters).

For more information, see MMAPv1 Record Allocation Behavior Changes.

Replica Set Oplog Format Change

MongoDB 3.0 is not compatible with oplog entries generated by versions of MongoDB before 2.2.1. If you upgrade from one of these versions, you must wait for new oplog entries to overwrite all old oplog entries generated by one of these versions before upgrading to 3.0.0 or earlier.

Secondaries may abort if they replay a pre-2.6 oplog with an index build operation that would fail on a 2.6 or later primary.

Replica Set Configuration Validation

MongoDB 3.0 provides a stricter validation of replica set configuration settings and replica sets invalid replica set configurations.

Stricter validations include:

• Arbiters can only have 1 vote. Previously, arbiters could also have a value of 0 for members[n].votes. If an arbiter has any value other than 1 for members[n].votes, you must fix the setting.
• Non-arbiter members can only have value of 0 or 1 for members[n].votes. If a non-arbiter member has any other value for members[n].votes, you must fix the setting.
• _id in the Replica Set Configuration must specify the same name as that specified by --replSet or replication.replSetName. Otherwise, you must fix the setting.
• Disallows 0 for settings.getLastErrorDefaults value. If settings.getLastErrorDefaults value is 0, you must fix the setting.
• settings can only contain the recognized settings. Previously, MongoDB ignored unrecognized settings. If settings contains unrecognized settings, you must remove the unrecognized settings.

To fix the settings before upgrading to MongoDB 3.0, connect to the primary and reconfigure your replica set to valid configuration settings.

If you have already upgraded to MongoDB 3.0, you must downgrade to MongoDB 2.6 first and then fix the settings. Once you have reconfigured the replica set, you can re-upgrade to MongoDB 3.0.

Change of w: majority Semantics

A write concern with a w: majority value is satisfied when a majority of the voting members replicates a write operation. In previous versions, majority referred a majority of all voting and non-voting members of the set.

Remove local.slaves Collection

MongoDB 3.0 removes the local.slaves collection that tracked the secondaries’ replication progress. To track the replication progress, use the rs.status() method.

Replica Set State Change

The FATAL replica set state does not exist as of 3.0.0.

HTTP Interface

The HTTP Interface (i.e. net.http.enabled) no longer reports replication data.

Require a Running MongoDB Instance

The 3.0 versions of MongoDB tools, mongodump, mongorestore, mongoexport, mongoimport,