Docs Menu
Docs Home
/
MongoDB Manual
/
Release Notes

Release Notes for MongoDB 3.2

On this page

  • Patch Releases
  • WiredTiger as Default
  • Replication Election Enhancements
  • Sharded Cluster Enhancements
  • readConcern
  • Partial Indexes
  • Document Validation
  • Aggregation Pipeline Enhancements
  • MongoDB Tools Enhancements
  • Encrypted Storage Engine
  • Text Search Enhancements
  • New Storage Engines
  • General Enhancements
  • Changes Affecting Compatibility
  • Upgrade Process
  • Known Issues in 3.2.1
  • Known Issues in 3.2.0
  • Download

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.

Patch Releases

3.2.22 - Dec 28, 2018

  • SERVER-38425 Oplog Visibility Query is a collection scan in 3.2.21

  • 3.2.22 Changelog

  • All JIRA issues closed in 3.2.22

3.2.21 - Sep 7, 2018

3.2.20 - May 10, 2018

3.2.19 - Feb 6, 2018

3.2.18 - Nov 29, 2017

3.2.17 - Sept 28, 2017

Issues fixed:

3.2.16 - Jul 27, 2017

Issues fixed:

3.2.15 - Jul 5, 2017

Issues fixed:

3.2.14 -Jun 13, 2017

Issues fixed:

3.2.13 -- May 1, 2017

Issues fixed:

3.2.12 -- Feb 1, 2017

Issues fixed:

3.2.11 -- Nov 18, 2016

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

3.2.10 -- Sep 30, 2016

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

3.2.9 -- Aug 16, 2016

Issues fixed:

3.2.8 -- Jul 12, 2016

Issues fixed:

3.2.7 -- Jun 7, 2016

Issues fixed:

3.2.6 -- Apr 28, 2016

Issues fixed:

3.2.5 -- Apr 14, 2016

Issues fixed:

3.2.4 -- Mar 8, 2016

Issues fixed:

3.2.3 -- Feb 17, 2016

Issues fixed:

3.2.2 -- Feb 16, 2016

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.

3.2.1 -- Jan 12, 2016

Issues fixed:

WiredTiger as Default

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:

    storage:
       engine: mmapv1

Note

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.

Tip

See also:

Default Storage Engine Change

WiredTiger Default Cache Size

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.

WiredTiger Journal Write Frequency

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.

Replication Election Enhancements

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.

Tip

See also:

Replica Set Protocol Version

Sharded Cluster Enhancements

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.

readConcern

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.

Partial Indexes

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.

Document Validation

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.

Aggregation Pipeline Enhancements

MongoDB introduces:

New Aggregation Stages

Stage
Description
Syntax
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.
{
   $lookup:
     {
       from: <collection to join>,
       localField: <fieldA>,
       foreignField: <fieldB>,
       as: <output array field>
     }
}

New Accumulators for $group Stage

Accumulator
Description
Syntax
Calculates standard deviation.
{ $stdDevSamp: <array> }
Calculates population standard deviation.
{ $stdDevPop: <array> }

New Aggregation Arithmetic Operators

Operator
Description
Syntax
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> }

New Aggregation Array Operators

Operator
Description
Syntax
Returns a subset of an array.

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

or

{ $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.
{
  $filter:
    {
      input: <array>,
      as: <string>,
      cond: <expression>
    }
}

Accumulator Expression Availability

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>, ... ]

General Enhancements

  • In MongoDB 3.2, $project stage supports using the square brackets [] to directly create new array fields. For an example, see Project New Array Fields.

  • MongoDB 3.2 introduces the minDistance option for the $geoNear stage.

  • $unwind stage no longer errors on non-array operand. If the operand does not resolve to an array but is not missing, null, or an empty array, $unwind treats the operand as a single element array.

    $unwind stage can:

    • include the array index of the array element in the output by specifying a new option includeArrayIndex in the stage specification.

    • output those documents where the array field is missing, null or an empty array by specifying a new option preserveNullAndEmptyArrays in the stage specification.

    To support these new features, $unwind can now take an alternate syntax. See $unwind for details.

Optimization

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.

Compatibility

For compatibility changes, see Aggregation Compatibility Changes.

MongoDB Tools Enhancements

Encrypted Storage Engine

Note

Enterprise Feature

Available in MongoDB Enterprise only.

Important

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.

Text Search Enhancements

text Index Version 3

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.

Tip

See also:

Text Index Version 3 Compatibility

$text Operator Enhancements

The $text operator adds support for:

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

Support for Additional Languages

Note

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.

New Storage Engines

inMemory Storage Engine

Note

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

  • inMemory for the --storageEngine option or the storage.engine setting.

  • --dbpath. Although the in-memory storage engine does not write data to the filesystem, it maintains in the --dbpath small metadata files and diagnostic data as well temporary files for building large indexes.

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

ephemeralForTest 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.

Warning

For test purposes only. Do not use in production.

To select this storage engine, specify

  • ephemeralForTest for the --storageEngine option or the storage.engine setting.

  • --dbpath. Although the for-test storage engine does not write data to the filesystem, it maintains small metadata files in the --dbpath.

The ephemeralForTest storage engine uses collection-level locking.

General Enhancements

Bit Test Query Operators

MongoDB 3.2 provides new query operators to test bit values:

SpiderMonkey JavaScript Engine

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.

Tip

See also:

SpiderMonkey Compatibility Changes

mongo Shell and CRUD API

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:

New API
Description

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.

WiredTiger and fsyncLock

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.

Platform Support

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

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

explain() Support for distinct() Operation

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

explain Support for findAndModify and distinct Commands

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

Deprecation of the HTTP Interface

Starting in 3.2, MongoDB deprecates its HTTP interface.

keysExamined Count Includes the Last Scanned Key

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 inputStage.

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

Geospatial Optimization

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.

Tip

See also:

2dsphere Index Version 3 Compatibility

Diagnostic Data Capture

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 diagnostic.data 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 diagnostic.data 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.

Write Concern

  • For replica sets using protocolVersion: 1, secondaries acknowledge write operations after the secondary members have written to their respective on-disk journals, regardless of the j option.

  • For replica sets using protocolVersion: 1, w: "majority" implies j: true.

  • With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. Previously j: true write concern in a replica set only requires the primary to write to the journal, regardless of the w: <value> write concern.

journalCommitInterval for WiredTiger

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.

Changes Affecting Compatibility

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.

Upgrade Process

See Upgrade MongoDB to 3.2 for full upgrade instructions.

Known Issues in 3.2.1

List of known issues in the 3.2.1 release:

  • Clients may fail to discover new primaries when clock skew between nodes is greater than electionTimeout: SERVER-21744

  • fromMigrate flag never set for deletes in oplog: SERVER-21678

  • Running explain with a read preference in a v3.2 mongo shell connected to a v3.0 mongos or in a v3.0 mongo shell connected to a v3.0 mongos but with v3.2 shards is incompatible: SERVER-21661

  • Results of the connPoolStats command are no longer correct: SERVER-21597

  • ApplyOps background index creation may deadlock: SERVER-21583

  • Performance regression for w:majority writes with replica set protocolVersion 1: SERVER-21581

  • Performance regression on unicode-aware text processing logic (text index v3): SERVER-19936

  • Results from the $indexStats operator do not take into account queries which use the $match or mapReduce functions: SERVER-22048

Known Issues in 3.2.0

List of known issues in the 3.2.0 release:

  • findAndModify operations not captured by the profiler: SERVER-21772

  • getMore command does not set "nreturned" operation counter: SERVER-21750

  • Clients may fail to discover new primaries when clock skew between nodes is greater than electionTimeout: SERVER-21744

  • fromMigrate flag never set for deletes in oplog: SERVER-21678

  • Running explain with a read preference in a v3.2 mongo shell connected to a v3.0 mongos or in a v3.0 mongo shell connected to a v3.0 mongos but with v3.2 shards is incompatible: SERVER-21661

  • Results of the connPoolStats command are no longer correct: SERVER-21597

  • ApplyOps background index creation may deadlock: SERVER-21583

  • Performance regression for w:majority writes with replica set protocolVersion 1: SERVER-21581

  • Performance regression on unicode-aware text processing logic (text index v3): SERVER-19936

  • Severe performance regression in insert workload under Windows with WiredTiger: SERVER-21792

  • Results from the $indexStats operator do not take into account queries which use the $match or mapReduce functions: SERVER-22048

Download

To download MongoDB 3.2, go to the downloads page.

Tip

See also:

Back

Downgrade 3.4 Sharded Cluster to 3.2