Release Notes for MongoDB 3.2 — MongoDB Manual 3.4

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:

SERVER-7285 : Support systemd in future compatible Ubuntu distributions.
WT-2798 : Create operations on WiredTiger when journaling is disabled may lead to inconsistent data in the event of a crash.
SERVER-17856 : On mongod instances, users can run currentOp and killOp on own operations.
3.2.9 Changelog
All JIRA issues closed in 3.2.9

3.2.8 – Jul 12, 2016 ¶

Issues fixed:

SERVER-18329 : Debian 8(Jessie) packages.
SERVER-24580 : Improve performance when WiredTiger cache is full.
WT-2696 : Race condition on unclean shutdown may miss log records with large updates.
WT-2706 : Race condition on log file switch can cause missing log records.
3.2.8 Changelog
All JIRA issues closed in 3.2.8

3.2.7 – Jun 7, 2016 ¶

Issues fixed:

SERVER-24054 : JS segmentation fault on load of certain NaNs.
SERVER-24058 : Connection pool asio doesn’t honor setup timeouts.
SERVER-24117 : Mongo binaries ELF stack has become executable.
3.2.7 Changelog
All JIRA issues closed in 3.2.7

3.2.6 – Apr 28, 2016 ¶

First production release of the in-memory storage engine .

Issues fixed:

SERVER-22970 : Background index build may result in extra index key entries that do not correspond to indexed documents.
SERVER-22043 : mongo shell method count() ignores read preference.
3.2.6 Changelog
All JIRA issues closed in 3.2.6

3.2.5 – Apr 14, 2016 ¶

Issues fixed:

SERVER-22964 : IX GlobalLock held while waiting for WiredTiger cache eviction.
SERVER-22831 : Low query rate with heavy cache pressure and an idle collection.
SERVER-21681 : Include index size stats for in-memory storage engine.
3.2.5 Changelog
All JIRA issues closed in 3.2.5

3.2.4 – Mar 8, 2016 ¶

Issues fixed:

SERVER-22495 , SERVER-22728 : Update optime when running with journaling disabled.
SERVER-22269 : Have read concern majority reflect journaled state on the primary
SERVER-22683 : replication.enableMajorityReadConcern ignores actual setting value and instead implies true .
SERVER-22043 : count() method in the mongo shell does not apply the read preferences.
3.2.4 Changelog
All JIRA issues closed in 3.2.4

3.2.3 – Feb 17, 2016 ¶

Issues fixed:

SERVER-22261 : For MMAPv1 journaling, the “last sequence number” file ( lsn file) may be ahead of what is synced to the data files.
SERVER-22167 : In some cases, insert operations fails to add the _id field to large documents.
SERVER-22456 : Increased timeout for querying oplog to 1 minute.
3.2.3 Changelog
All JIRA issues closed in 3.2.3

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:

SERVER-21868 : During a regular shutdown of a replica set, secondaries may mark certain replicated but yet to be applied operations as successfully applied.
SERVER-20262 : Improve insert workload performance with WiredTiger on Windows.
SERVER-21366 : Long-running transactions during chunk moves.
3.2.1 Changelog
All JIRA 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
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.
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 joural write
intervals and conditions. For more information, see 为了提高当前journal文件频繁的顺序写入速度，您可以将journal文件放在与数据库数据文件不同的文件系统下。.
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 配置服务器.
To deploy a new sharded cluster with replica set config servers,
see 部署一个集群.
MongoDB 3.2 deprecates the use of master-slave replication for
components of sharded clusters.
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:
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¶
$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>
Calculates the log of a number in the specified base.
{ $log: [ <number>, <base> ] }
$log10
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> }
$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> }
$arrayElemAt
Returns the element at the specified array index.
{ $arrayElemAt: [ <array>, <idx> ] }
$concatArrays
Concatenates arrays.
  $concatArrays: [ <array1>, <




    
array2>, ... ]
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:
$stdDevPop
$stdDevSamp
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 to an Archive File and mongodump an Archive to
Standard Output
Restore a Database from an Archive File and
Restore a Database from Standard Input.
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:
Compress mongodump Output
Restore from Compressed Data.
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.
Text Index Version 3 Compatibility
$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 使用基本技术Rosette语义平台的文本索引.
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 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 内存存储引擎.
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.
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:
$bitsAllSet
$bitsAllClear
$bitsAnySet
$bitsAnyClear
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.
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:
db.collection.bulkWrite()
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.
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().
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 :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.
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.
Compatibility Changes in MongoDB 3.2
Default Storage Engine Change
Index Changes
Version 0 Indexes
Text Index Version 3 Compatibility
2dsphere Index Version 3 Compatibility
Aggregation Compatibility Changes
SpiderMonkey Compatibility Changes
JavaScript Changes in MongoDB 3.2
Modernized JavaScript Implementation (ES6)
Changes to the mongo Shell
Removed Non-Standard V8 Features
Downgrade a Standalone mongod Instance
Download the latest 3.0 binaries.
Restart with the latest 3.0 mongod instance.
Downgrade a 3.2 Replica Set
Downgrade the protocolVersion.
Downgrade secondary members of the replica set.
Step down the primary.
Replace and restart former primary mongod.
Downgrade a 3.2 Sharded Cluster
Requirements
Downgrade a Sharded Cluster with SCCC Config Servers
Disable the Balancer.
Downgrade each shard, one at a time.
Downgrade the SCCC config servers.
Downgrade the mongos instances.
Re-enable the balancer.
Downgrade a Sharded Cluster with CSRS Config Servers
Disable the Balancer.
Check the minOpTimeUpdaters value.
Prepare CSRS Config Servers for downgrade.
Update the protocolVersion for each shard.
Downgrade the mongos instances.
Downgrade Config Servers.
Downgrade each shard, one at a time.
Re-enable the balancer.
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.
All Third Party License Notices.
All JIRA issues resolved in 3.2.

Try It Now

Minor Releases ¶

3.2.10 – Sep 30, 2016 ¶

3.2.9 – Aug 16, 2016 ¶

3.2.8 – Jul 12, 2016 ¶

3.2.7 – Jun 7, 2016 ¶

3.2.6 – Apr 28, 2016 ¶

3.2.5 – Apr 14, 2016 ¶

3.2.4 – Mar 8, 2016 ¶

3.2.3 – Feb 17, 2016 ¶

3.2.2 – Feb 16, 2016 ¶

3.2.1 – Jan 12, 2016 ¶

WiredTiger as Default ¶

WiredTiger Default Cache Size¶

WiredTiger Journal Write Frequency¶

Replication Election Enhancements¶

Sharded Cluster Enhancements¶

readConcern¶

Partial Indexes¶

Document Validation¶

Aggregation Framework Enhancements¶

New Aggregation Stages¶

Accumulator Expression Availability¶

General Enhancements¶

Optimization¶

Compatibility¶

MongoDB Tools Enhancements¶

Text Search Enhancements¶

text Index Version 3¶

$text Operator Enhancements¶

Support for Additional Languages¶

New Storage Engines¶

inMemory Storage Engine¶

ephemeralForTest Storage Engine¶

General Enhancements¶

Bit Test Query Operators¶

SpiderMonkey JavaScript Engine¶

mongo Shell and CRUD API¶

WiredTiger and fsyncLock¶

Platform Support¶

$type Operator Accepts String Aliases¶

explain() Support for distinct() Operation¶

explain Support for findAndModify and distinct Commands¶

Deprecation of the HTTP Interface¶

keysExamined Count Includes the Last Scanned Key¶

Geospatial Optimization¶

Diagnostic Data Capture¶

Write Concern¶

journalCommitInterval for WiredTiger¶

Changes Affecting Compatibility¶

Known Issues in 3.2.0¶

Download¶

`readConcern`¶

`text` Index Version 3¶

`$text` Operator Enhancements¶

`inMemory` Storage Engine¶

`ephemeralForTest` Storage Engine¶

`mongo` Shell and CRUD API¶

WiredTiger and `fsyncLock`¶

`$type` Operator Accepts String Aliases¶

`explain()` Support for `distinct()` Operation¶

`explain` Support for `findAndModify` and `distinct` Commands¶

`keysExamined` Count Includes the Last Scanned Key¶

`journalCommitInterval` for WiredTiger¶