- Release Notes >
- Release Notes for MongoDB 3.2
Release Notes for MongoDB 3.2¶
On this page
- Minor Releases
- WiredTiger as Default
- Replication Election Enhancements
- Sharded Cluster Enhancements
- readConcern
- Partial Indexes
- Document Validation
- Aggregation Framework 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
- Additional Resources
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.
Minor Releases¶
3.2.3 – Feb 17, 2016¶
- Fixed issue with MMAPv1 journaling where the “last sequence number” file (lsn file) may be ahead of what is synced to the data files: SERVER-22261.
- Fixed issue where in some cases, insert operations fails to add the _id field to large documents: SERVER-22167.
- Increased timeout for querying oplog to 1 minute: SERVER-22456.
- All issues closed in 3.2.3
3.2.1 – Jan 12, 2016¶
- Fixed error where during a regular shutdown of a replica set, secondaries may mark certain replicated but yet to be applied operations as successfully applied: SERVER-21868.
- Improve insert workload performance with WiredTiger on Windows: SERVER-20262.
- Fixed long-running transactions during chunk moves: SERVER-21366
- All issues closed in 3.2.1
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.
See also
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.
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.
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.
Only replica sets using protocol version 1 support "majority" read concern. Replica sets running protocol version 0 do not support "majority" read concern.
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:
- equality expressions (i.e. field: value or using the $eq operator),
- $exists: true expression,
- $gt, $gte, $lt, $lte expressions,
- $type expressions,
- $and operator at the top-level only
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 Document 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:
- applyOps command
- findAndModify command and db.collection.findAndModify() method
- mapReduce command and db.collection.mapReduce() method
- insert command
- update command
- $out for the aggregate command and db.collection.aggregate() method
For deployments that have enabled access control, you must have bypassDocumentValidation action. The built-in roles dbAdmin and restore provide this action.
Aggregation Framework Enhancements¶
MongoDB introduces:
- New stages, accumulators, and expressions.
- Availability of accumulator expressions in $project stage.
- Performance improvements on sharded clusters.
New Aggregation Stages¶
Stage | Description | Syntax |
---|---|---|
$sample | Randomly selects N documents from its input. | { $sample: { size: <positive integer> } } |
$indexStats | Returns statistics on index usage. | { $indexStats: { } } |
$lookup | 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 |
---|---|---|
$stdDevSamp | Calculates standard deviation. | { $stdDevSamp: <array> } |
$stdDevPop | Calculates population standard deviation. | { $stdDevPop: <array> } |
New Aggregation Arithmetic Operators¶
Operator | Description | Syntax |
---|---|---|
$sqrt | Calculates the square root. | { $sqrt: <number> } |
$abs | Returns the absolute value of a number. | { $abs: <number> } |
$log | Calculates the log of a number in the specified base. | { $log: [ <number>, <base> ] } |
$log10 | Calculates the log base 10 of a number. | { $log10: <number> } |
$ln | Calculates the natural log of a number. | { $ln: <number> } |
$pow | Raises a number to the specified exponent. | { $pow: [ <number>, <exponent> ] } |
$exp | Raises e to the specified exponent. | { exp: <number> } |
$trunc | Truncates a number to its integer. | { $trunc: <number> } |
$ceil | Returns the smallest integer greater than or equal to the specified number. | { $ceil: <number> } |
$floor | Returns the largest integer less than or equal to the specified number. | { floor: <number> } |
New Aggregation Array Operators¶
Operator | Description | Syntax |
---|---|---|
$slice | Returns a subset of an array. | { $slice: [ <array>, <n> ] } or { $slice: [ <array>, <position>, <n> ] } |
$arrayElemAt | Returns the element at the specified array index. | { $arrayElemAt: [ <array>, <idx> ] } |
$concatArrays | Concatenates arrays. | {
$concatArrays: [ <array1>, <array2>, ... ]
}
|
$isArray | Determines if the operand is an array. | { $isArray: [ <expression> ] } |
$filter | 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¶
- mongodump and mongorestore add support for archive files and standard output/input streams with a new --archive option. This enhancement allows for the streaming of the dump data over a network device via a pipe. For examples, see
- mongodump and mongorestore add support for compressed data dumps with a new --gzip option. This enhancement reduces storage space for the dump files. For examples, see:
Encrypted Storage Engine¶
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:
- Improved case insensitivity.
- Diacritic insensitivity.
- Additional delimiters for tokenization.
Starting in MongoDB 3.2, version 3 is the default version for new text indexes.
See also
$text Operator Enhancements¶
The $text operator adds support for:
- case sensitive text search with the new $caseSensitive option, and
- diacritic sensitive text search with the new $diacriticSensitive option.
For more information and examples, see the $text operator reference sections Case Insensitivity and Diacritic Insensitivity.
Support for Additional Languages¶
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¶
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 storge engine allows for more predictable latency of database operations.
Warning
Currently in beta. Do not use in production.
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.
See also
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 |
---|---|
db.collection.bulkWrite() | Equivalent to initializing Bulk() operations builder, using Bulk methods to add operations, and running Bulk.execute() to execute the operations. |
db.collection.deleteMany() | Equivalent to db.collection.remove(). |
db.collection.deleteOne() | Equivalent to db.collection.remove() with the justOne set to true; i.e. db.collection.remove( <query>, true ) or db.collection.remove( <query>, { justOne: true } ). |
db.collection.findOneAndDelete() | Equivalent to db.collection.findAndModify() method with remove set to true. |
db.collection.findOneAndReplace() | Equivalent to db.collection.findAndModify() method with update set to a replacement document. |
db.collection.findOneAndUpdate() | Equivalent to db.collection.findAndModify() method with update set to a document that specifies modifications using update operators. |
db.collection.insertMany() | Equivalent to db.collection.insert() method with an array of documents as the parameter. |
db.collection.insertOne() | Equivalent to db.collection.insert() method with a single document as the parameter. |
db.collection.replaceOne() | Equivalent to db.collection.update( <query>, <update> ) method with a replacement document as the <update> parameter. |
db.collection.updateMany() | 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. |
db.collection.updateOne() | 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 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().
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 :data:` ~explain.executionStats.executionStages.inputStage.keysExamined`.
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.
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 acknowlege 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
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
Download¶
To download MongoDB 3.2, go to the downloads page.
Additional Resources¶
Thank you for your feedback!
We're sorry! You can Report a Problem to help us improve this page.