Release Notes for MongoDB 3.2

On this page

Dec 8, 2015

MongoDB 3.2 is now available. Key features include WiredTiger as the default storage engine, replication election enhancements, config servers as replica sets, readConcern, and document validations.

OpsManager 2.0 is also available. See the Ops Manager documentation and the Ops Manager release notes for more information.

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

  • SERVER-26182: In a mixed version replica set with v3.2 and v3.0 members, a sync of a v3.2 member from a v3.0 member can result in a query response that exceed 16 MB BSON size limit and crash the v3.2 member.
  • SERVER-24662: Upgrade to Perl compatible regular expressions (PCRE 8.39).
  • SERVER-26652 Invalid definitions in systemd configuration for Debian.
  • SERVER-24386: killCursor operation during aggregation pipeline can cause segmentation fault.
  • 3.2.11 Changelog
  • All JIRA issues closed in 3.2.11

Issues fixed:

  • SERVER-25974: When WT cache utilization is full, application threads can stall for an extended period of time.
  • SERVER-20306: MongoDB with WiredTiger may experience excessive memory fragmentation, leading to swapping and/or out-of-memory errors.
  • SERVER-16801: When updating a field of one numerical type to the same number of different numerical type, update operation considers it as a noop.
  • 3.2.10 Changelog
  • All JIRA issues closed in 3.2.10

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Replaced by MongoDB 3.2.3. Users wishing to run MongoDB 3.2 should skip 3.2.2 and upgrade directly to 3.2.3.

Issues fixed:

Starting in 3.2, MongoDB uses the WiredTiger as the default storage engine.

To specify the MMAPv1 storage engine, you must specify the storage engine setting either:

  • On the command line with the --storageEngine option:

    mongod --storageEngine mmapv1
  • Or in a configuration file, using the storage.engine setting:

    engine: mmapv1

For existing deployments, if you do not specify the --storageEngine or the storage.engine setting, MongoDB 3.2 can automatically determine the storage engine used to create the data files in the --dbpath or storage.dbPath.

If specifying --storageEngine or storage.engine, mongod will not start if dbPath contains data files created by a storage engine other than the one specified.

See also:

Starting in MongoDB 3.2, the WiredTiger internal cache, by default, will use the larger of either:

  • 60% of RAM minus 1 GB, or
  • 1 GB.

For more information, see WiredTiger and Memory Use.

MongoDB 3.2 configures WiredTiger to write to the journal files at every 50 milliseconds. This is in addition to the existing journal write intervals and conditions. For more information, see Journaling Process.

Starting in MongoDB 3.2, MongoDB reduces replica set failover time and accelerates the detection of multiple simultaneous primaries.

As part of this enhancement, MongoDB introduces a version 1 of the replication protocol. New replica sets will, by default, use protocolVersion: 1. Previous versions of MongoDB use version 0 of the protocol.

In addition, MongoDB introduces a new replica set configuration option electionTimeoutMillis. electionTimeoutMillis specifies the time limit in milliseconds for detecting when a replica set's primary is unreachable.

electionTimeoutMillis only applies if using the version 1 of the replication protocol.

MongoDB 3.2 deprecates the use of three mirrored mongod instances for config servers.

Instead, starting in 3.2, the config servers for a sharded cluster can be deployed as a replica set. The replica set config servers must run the WiredTiger storage engine.

This change improves consistency across the config servers, since MongoDB can take advantage of the standard replica set read and write protocols for sharding config data. In addition, this allows a sharded cluster to have more than 3 config servers since a replica set can have up to 50 members.

For more information, see Config Servers. To deploy a new sharded cluster with replica set config servers, see Deploy a Sharded Cluster.

MongoDB 3.2 deprecates the use of master-slave replication for components of sharded clusters.

Starting in 3.2, mongos, during its startup, will continue to try to contact the config servers until one becomes available. In previous versions, mongos, during its startup, would shut down if it could not find a config server.

MongoDB 3.2 introduces the readConcern query option for replica sets and replica set shards. For the WiredTiger storage engine, the readConcern option allows clients to choose a level of isolation for their reads. You can specify a readConcern of "majority" to read data that has been written to a majority of nodes and thus cannot be rolled back. By default, MongoDB uses a readConcern of "local" to return the most recent data available to the node at the time of the query, even if the data has not been persisted to a majority of nodes and may be rolled back. With the MMAPv1 storage engine, you can only specify a readConcern of "local".

readConcern requires MongoDB drivers updated for MongoDB 3.2.

For details on readConcern, including operations that support the option, see Read Concern.

MongoDB 3.2 provides the option to create indexes that only index the documents in a collection that meet a specified filter expression. By indexing a subset of the documents in a collection, partial indexes have lower storage requirements and reduced performance costs for index creation and maintenance. You can specify a partialFilterExpression option for all MongoDB index types.

The partialFilterExpression option accepts a document that specifies the condition using:

For details, see Partial Indexes.

Starting in 3.2, MongoDB provides the capability to validate documents during updates and insertions. Validation rules are specified on a per-collection basis.

To specify document validation on a new collection, use the new validator option in the db.createCollection() method. To add document validation to an existing collection, use the new validator option in the collMod command. For more information, see Schema Validation.

To view the validation specifications for a collection, use the db.getCollectionInfos() method.

The following commands can bypass validation per operation using the new option bypassDocumentValidation:

For deployments that have enabled access control, you must have bypassDocumentValidation action. The built-in roles dbAdmin and restore provide this action.

MongoDB introduces:

Randomly selects N documents from its input.
{ $sample: { size: <positive integer> } }
Returns statistics on index usage.
{ $indexStats: { } }
Performs a left outer join with another collection.
from: <collection to join>,
localField: <fieldA>,
foreignField: <fieldB>,
as: <output array field>
Calculates standard deviation.
{ $stdDevSamp: <array> }
Calculates population standard deviation.
{ $stdDevPop: <array> }
Calculates the square root.
{ $sqrt: <number> }
Returns the absolute value of a number.
{ $abs: <number> }
Calculates the log of a number in the specified base.
{ $log: [ <number>, <base> ] }
Calculates the log base 10 of a number.
{ $log10: <number> }
Calculates the natural log of a number.
{ $ln: <number> }
Raises a number to the specified exponent.
{ $pow: [ <number>, <exponent> ] }
Raises e to the specified exponent.
{ exp: <number> }
Truncates a number to its integer.
{ $trunc: <number> }
Returns the smallest integer greater than or equal to the specified number.
{ $ceil: <number> }
Returns the largest integer less than or equal to the specified number.
{ floor: <number> }
Returns a subset of an array.

{ $slice: [ <array>, <n> ] }


{ $slice: [ <array>, <position>, <n> ] }

Returns the element at the specified array index.
{ $arrayElemAt: [ <array>, <idx> ] }
Concatenates arrays.
$concatArrays: [ <array1>, <array2>, ... ]
Determines if the operand is an array.
{ $isArray: [ <expression> ] }
Selects a subset of the array based on the condition.
input: <array>,
as: <string>,
cond: <expression>

Starting in version 3.2, the following accumulator expressions, previously only available in the $group stage, are now also available in the $project stage:

When used as part of the $project stage, these accumulator expressions can accept either:

  • A single argument: <accumulator> : <arg>
  • Multiple arguments: <accumulator> : [ <arg1>, <arg2>, ... ]

Indexes can cover aggregation operations.

MongoDB improves the overall performance of the pipeline in large sharded clusters.

If the pipeline starts with an exact $match on a shard key, the entire pipeline runs on the matching shard only. Previously, the pipeline would have been split, and the work of merging it would have to be done on the primary shard.

For aggregation operations that run on multiple shards, if the operations do not require running on the database's primary shard, these operations can route the results to any shard to merge the results and avoid overloading the primary shard for that database. Aggregation operations that require running on the database's primary shard are the $out stage and $lookup stage.

For compatibility changes, see Aggregation Compatibility Changes.

Enterprise Feature

Available in MongoDB Enterprise only.

Available for the WiredTiger Storage Engine only.

Encryption at rest, when used in conjunction with transport encryption and good security policies that protect relevant accounts, passwords, and encryption keys, can help ensure compliance with security and privacy standards, including HIPAA, PCI-DSS, and FERPA.

MongoDB Enterprise 3.2 introduces a native encryption option for the WiredTiger storage engine. This feature allows MongoDB to encrypt data files such that only parties with the decryption key can decode and read the data. For detail, see Encrypted Storage Engine.

MongoDB 3.2 introduces a version 3 of the text index. Key features of the new version of the index are:

Starting in MongoDB 3.2, version 3 is the default version for new text indexes.

The $text operator adds support for:

For more information and examples, see the $text operator reference sections Case Insensitivity and Diacritic Insensitivity.

Enterprise Feature

Available in MongoDB Enterprise only.

Starting in 3.2, MongoDB Enterprise provides support for the following languages: Arabic, Farsi (specifically Dari and Iranian Persian dialects), Urdu, Simplified Chinese, and Traditional Chinese.

For details, see Text Search with Basis Technology Rosette Linguistics Platform.

Enterprise Feature

Available in MongoDB Enterprise only.

MongoDB Enterprise 3.2 provides an in-memory storage engine. Other than some metadata, the in-memory storage engine does not maintain any on-disk data. By avoiding disk I/O, the in-memory storage engine allows for more predictable latency of database operations.

To select this storage engine, specify

The inMemory storage engine uses document-level locking. For more details, see In-Memory Storage Engine.

MongoDB 3.2 provides a new for-test storage engine. Other than some metadata, the for-test storage engine does not maintain any on-disk data, removing the need to clean up between test runs. The for-test storage engine is unsupported.

For test purposes only. Do not use in production.

To select this storage engine, specify

The ephemeralForTest storage engine uses collection-level locking.

MongoDB 3.2 provides new query operators to test bit values:

MongoDB 3.2 uses SpiderMonkey as the JavaScript engine for the mongo shell and mongod server. SpiderMonkey provides support for additional platforms and has an improved memory management model.

This change affects all JavaScript behavior including the commands mapReduce, group, and the query operator $where; however, this change should be completely transparent to the user.

To provide consistency with the MongoDB drivers' CRUD (Create/Read/Update/Delete) API, the mongo shell introduces additional CRUD methods that are consistent with the drivers' CRUD API:


Equivalent to initializing Bulk() operations builder, using Bulk methods to add operations, and running Bulk.execute() to execute the operations.

MongoDB 3.2 deprecates Bulk() and its associated methods.

Equivalent to db.collection.findAndModify() method with remove set to true.
Equivalent to db.collection.findAndModify() method with update set to a replacement document.
Equivalent to db.collection.findAndModify() method with update set to a document that specifies modifications using update operators.
Equivalent to db.collection.insert() method with an array of documents as the parameter.
Equivalent to db.collection.insert() method with a single document as the parameter.
Equivalent to db.collection.update( <query>, <update> ) method with a replacement document as the <update> parameter.
Equivalent to db.collection.update( <query>, <update>, { multi: true, ... }) method with an <update> document that specifies modifications using update operators and the multi option set to true.
Equivalent to db.collection.update( <query>, <update> ) method with an <update> document that specifies modifications using update operators.

Starting in MongoDB 3.2, the WiredTiger storage engine supports the fsync command with the lock option or the mongo shell method db.fsyncLock(). That is, for the WiredTiger storage engine, these operations can guarantee that the data files do not change, ensuring consistency for the purposes of creating backups.

Starting in 3.2, 32-bit binaries are deprecated and will be unavailable in future releases.

MongoDB 3.2 also deprecates support for Red Hat Enterprise Linux 5.

$type operator accepts string aliases for the BSON types in addition to the numbers corresponding to the BSON types.

db.collection.explain() adds support for db.collection.distinct() method. For more information, see db.collection.explain().

explain adds support for the distinct and findAndModify commands. For more information, see explain.

Starting in 3.2, MongoDB deprecates its HTTP interface.

For explain operations run in executionStats or allPlansExecution mode, the explain output contains the keysExamined statistic, representing the number of index keys examined during index scans.

Prior to 3.2, keysExamined count in some queries did not include the last scanned key. As of 3.2 this error has been corrected. For more information, see :data:` ~explain.executionStats.executionStages.inputStage.keysExamined`.

The diagnostic logs and the system profiler report on this statistic.

MongoDB 3.2 introduces version 3 of 2dsphere indexes, which index GeoJSON geometries at a finer gradation. The new version improves performance of 2dsphere index queries over smaller regions. In addition, for both 2d indexes and 2dsphere indexes, the performance of geoNear queries has been improved for dense datasets.

To facilitate analysis of the MongoDB server behavior by MongoDB engineers, MongoDB 3.2 introduces a diagnostic data collection mechanism for logging server statistics to diagnostic files at periodic intervals. By default, the mechanism captures data at 1 second intervals. To modify the interval, see diagnosticDataCollectionPeriodMillis.

MongoDB creates a directory under the mongod instance's --dbpath or storage.dbPath. The diagnostic data is stored in files under this directory.

The maximum size of the diagnostic files is configurable with the diagnosticDataCollectionFileSizeMB, and the maximum size of the directory is configurable with diagnosticDataCollectionDirectorySizeMB.

The default values for the capture interval and the maximum sizes are chosen to provide useful data to MongoDB engineers with minimal impact on performance and storage size. Typically, these values will only need modifications as requested by MongoDB engineers for specific diagnostic purposes.

MongoDB 3.2 adds support for specifying the journal commit interval for the WiredTiger storage engine. See --journalCommitInterval option. In previous versions, the option is applicable to MMAPv1 storage engine only.

For the corresponding configuration file setting, MongoDB 3.2 adds the storage.journal.commitIntervalMs setting and deprecates storage.mmapv1.journal.commitIntervalMs. The deprecated storage.mmapv1.journal.commitIntervalMs setting acts as an alias to the new storage.journal.commitIntervalMs setting.

Some MongoDB 3.2 changes can affect compatibility and may require user actions. For a detailed list of compatibility changes, see Compatibility Changes in MongoDB 3.2.

See Upgrade MongoDB to 3.2 for full upgrade instructions.

List of known issues in the 3.2.1 release:

List of known issues in the 3.2.0 release:

To download MongoDB 3.2, go to the downloads page.

Give Feedback

On this page