Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

Release Notes for MongoDB 3.4

On this page

  • Patch Releases
  • Sharded Cluster
  • Replica Set
  • Decimal Type
  • Aggregation
  • Collation and Case-Insensitive Indexes
  • Views
  • Security Enhancement
  • MongoDB Tools
  • General Enhancements
  • Platform Support
  • MongoDB Enterprise Features
  • Changes Affecting Compatibility
  • Upgrade Procedures
  • Download
  • Known Issues in 3.4.0


MongoDB 3.4 Released Nov 29, 2016

MongoDB 3.4 is now available. Key features include linearizable read concerns, views, and collation.

OpsManager 3.4 is also available. See the Ops Manager documentation and the Ops Manager Release Notes for more information.

Issues fixed:

Issues fixed:

Issues fixed:


Fixed issues include those that resolve the following Common Vulnerabilities and Exposures (CVEs):

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

  • SERVER-32999: Platform Support: Remove Debian 7 builds.

  • SERVER-29301: Upgrade MozJS to ESR 45.9.0

  • SERVER-5461: Add syncSourceHost field to replSetGetStatus output.

  • 3.4.16 Changelog

  • All JIRA issues closed in 3.4.16

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Issues fixed:

Starting in 3.4, sharded cluster components (shards, config servers, mongos instances) recognize their membership in a sharded cluster, including the name of the sharded cluster, the location of the config servers.

To support this awareness:

shardsvr Requirement

For a 3.4 sharded cluster, mongod instances for the shards must explicitly specify its role as a shardsvr, either via the configuration file setting sharding.clusterRole or via the command line option --shardsvr.


Default port for mongod instances with the shardsvr role is 27018. To use a different port, specify net.port setting or --port option.

3.4 mongos Incompatibility with Earlier Versions of mongod
Version 3.4 mongos instances cannot connect to earlier versions of mongod instances.

The balancer process has moved from the mongos to the primary member of the config server replica set. Associated with this change:

  • The primary of the CSRS config server holds the "balancer" lock, using a process id named "ConfigServer", which is never released.

  • MongoDB 3.4 adds:

  • MongoDB 3.4 deprecates mongo shell method sh.getBalancerHost(). A 3.2 or earlier mongo shell method sh.getBalancerHost() is incompatible with a 3.4 sharded cluster.

  • MongoDB 3.4 removes the following configuration options from the mongos:

    • sharding.chunkSize configuration file setting and --chunkSize command-line option

    • sharding.autoSplit configuration file setting and --noAutoSplit command-line option

Starting in MongoDB 3.4:

  • For WiredTiger, the default value secondaryThrottle is false for all chunk migrations. The balancer does not wait for replication to a secondary and instead continues with the next document.

  • MongoDB can perform parallel chunk migrations. Similar to earlier versions, a shard can participate in at most one migration at a time. Observing this restriction, for a sharded cluster with n shards, MongoDB can perform at most n/2 (rounded down) simultaneous chunk migrations.

3.4 sharded clusters no longer support the use of mirrored (SCCC) mongod instances as config servers. The use of SCCC config servers, deprecated in the 3.2 release, is no longer valid. Instead, deploy your config servers as a replica set (CSRS).

To upgrade your sharded cluster to version 3.4, the config servers must be running as a replica set.

To convert your existing config servers from SCCC to CSRS, see the Upgrade Config Servers to Replica Set.

MongoDB 3.4 introduces Zones, which supersedes tag-aware sharding available in earlier versions.

To support zones, MongoDB introduces the following commands and mongo shell helpers:

mongo Shell Methods

A new replica set configuration setting writeConcernMajorityJournalDefault determines whether an acknowledgement for a write concern of majority returns after the majority of the voting members apply the write in memory or to the on-disk journal if the j option is unspecified in the write concern.

A new replica set configuration setting settings.catchUpTimeoutMillis defines the time limit for a newly elected primary to catch up with the other replica set members that may have more recent writes.

MongoDB 3.4 introduces a read concern level of "linearizable" to read data that reflects all successful writes issued with a "majority" and acknowledged prior to the start of the read operation. Linearizable read concern guarantees only apply if read operations specify a query filter that uniquely identifies a single document.

Linearizable read concern is available for all MongoDB supported storage engines.

Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.

Reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns. Always use maxTimeMS with linearizable read concern, in case a majority of data bearing members are unavailable. For example:

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
find: "restaurants",
filter: { _id: 5 },
readConcern: { level: "linearizable" },
maxTimeMS: 10000
} )

For more information on read concern, including operations that support read concerns, see Read Concern.

  • MongoDB 3.4 improves the performance of initial sync by having initial sync build the indexes as the documents are copied.

  • MongoDB 3.4 improves the initial sync retry logic to be more resilient to intermittent failures on the network.

  • To avoid potential data corruption, MongoDB 3.4 fails and restarts initial sync if a collection is renamed on the sync source during the initial sync. With MongoDB 3.2.11 or earlier, initial syncs did not fail and restart but instead continued the process, which could lead to potential data corruption.

    For details, see Initial Sync and renameCollection.

  • Modified replSetGetStatus command to accept the optional initialSync: 1 in the command to report on initial sync status and progress if run on the secondary:

    db.adminCommand( { replSetGetStatus: 1, initialSync: 1 } )

3.4 adds support for the decimal128 format with the new decimal data type. The decimal128 format supports numbers with up to 34 decimal digits (i.e. significant digits) and an exponent range of −6143 to +6144.

To support the format, the mongo shell adds the NumberDecimal wrapper.

db.inventory.insert( {_id: 1, item: "The Scream", price: NumberDecimal("9.99"), quantity: 4 } )

When performing comparisons among different numerical types, MongoDB performs comparison on the exact stored numerical values without first converting values to a common type.

Unlike the double data type, which only stores an approximation of the decimal values, the decimal data type stores the exact value. For example, a decimal NumberDecimal("9.99") has a precise value of 9.99 where as a double 9.99 would have an approximate value of 9.9900000000000002131628....

To test for decimal type, use the $type operator with the literal "decimal" or 19.

db.inventory.find( { price: { $type: "decimal" } } )

To use the new decimal data type with a MongoDB driver, an upgrade to a driver version that supports the feature is necessary.

3.4 introduces a stage to the aggregation pipeline that allows for recursive search.

Performs a recursive search on a collection. To each output document, adds a new array field that contains the traversal results of the recursive search for that document.


Faceted search allows for the categorization of documents into classifications. For example, given a collection of inventory documents, you may want to classify items by a single category, such as by the price range, or by multiple categories, such as by price range as well as separately by the departments.

3.4 introduces stages to the aggregation pipeline that allow for faceted search.

Categorizes or groups incoming documents into buckets that represent a range of values for a specified expression.
Categorizes or groups incoming documents into specified number of buckets that represent a range of values for a specified expression. MongoDB automatically determines the bucket boundaries.
Processes multiple pipelines on the input documents and outputs a document that contains the results of these pipelines. By specifying facet-related stages ($bucket, $bucketAuto, and $sortByCount) in these pipelines, $facet allows for multi-faceted search.
Categorizes or groups incoming documents by a specified expression to compute the count for each group. Output documents are sorted in descending order by the count.

3.4 introduces stages to the aggregation pipeline that faciliate replacing documents as well as adding new fields.

Adds new fields to documents. The stage outputs documents that contains all existing fields from the input documents as well as the newly added fields.
Replaces a document with the specified document. You can specify a document embedded in the input document to promote the embedded document to the top level.

3.4 introduces a new stage to the aggregation pipeline that faciliate counting document.

Returns a document that contains a count of the number of documents input to the stage.
Returns a boolean that indicates if a specified value is in an array.
Searches an array for an occurrence of a specified value and returns the array index (zero-based) of the first occurrence.
Returns an array whose elements are a generated sequence of numbers.
Returns an output array whose elements are those of the input array but in reverse order.
Takes an array as input and applies an expression to each element in the array to return the final result of the expression.
Returns an output array where each element is itself an array, consisting of elements in the corresponding array index position from the input arrays.
Searches a string for an occurrence of a substring and returns the UTF-8 byte index (zero-based) of the first occurrence.
Searches a string for an occurrence of a substring and returns the UTF-8 code point index (zero-based) of the first occurrence.
Splits a string by a specified delimiter into string components and returns an array of the string components.
Returns the number of UTF-8 bytes for a string.
Returns the number of UTF-8 code points for a string.
Returns the substring of a string. The substring starts with the character at the specified UTF-8 byte index (zero-based) in the string for the length specified.
Returns the substring of a string. The substring starts with the character at the specified UTF-8 code point index (zero-based) in the string for the length specified.
Evaluates, in sequential order, the case expressions of the specified branches to enter the first branch for which the case expression evaluates to true.
Returns the ISO 8601 weekday number, ranging from 1 (for Monday) to 7 (for Sunday).
Returns the ISO 8601 week number, which can range from 1 to 53. Week numbers start at 1 with the week (Monday through Sunday) that contains the year's first Thursday.
Returns the ISO 8601 year number, where the year starts with the Monday of week 1 (ISO 8601) and ends with the Sundays of the last week (ISO 8601).
Returns statistics regarding a collection or view.
Returns a string which specifies the BSON Types of the argument.

$project stage adds support for field exclusion in the output document. Previously, you could only exclude the _id field in the stage. If you specify the exclusion of a field or fields,

  • All other fields are returned in the output documents.

  • You cannot specify new fields or the inclusion of other fields.

To allow for language-specific rules for string comparison, MongoDB 3.4 introduces collation to its query language and indexes.

The following operations support collation:

mongosh Methods
cursor.collation() to specify collation for db.collection.find()
Individual update, replace, and delete operations in db.collection.bulkWrite().

For details, see Collation.

[1](1, 2) Some index types do not support collation. See Collation and Unsupported Index Types for details.

MongoDB 3.4 adds support for creating read-only views from existing collections or other views. To specify or define a view, MongoDB 3.4 introduces:

  • the viewOn and pipeline options to the existing create command:

    db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline> } )

    or if specifying a default collation for the view:

    db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline>, collation: <collation> } )
  • and a corresponding mongo shell helper db.createView():

    db.createView(<view>, <source>, <pipeline>, <collation>)

For more information on creating views, see Views.

MongoDB 3.4 adds support for rolling transition to internal authentication for replica sets and sharded clusters. For details, see security.transitionToAuth setting and --transitionToAuth command line option for mongod and mongos.

The privileges of the following built-in roles no longer apply to the local and config databases:

Starting in 3.4, to provide read privileges on the local database, create a user in the admin database with read role in the local database. See also clusterManager and clusterMonitor role for access to the config and local databases.
Starting in 3.4, to provide readWrite privileges on the local database, create a user in the admin database with readWrite role in the local database. See also clusterManager and clusterMonitor role for access to the config and local databases.
Starting in 3.4, to provide dbAdmin privileges on the local database, create a user in the admin database with dbAdmin role in the local database. See also clusterManager and clusterMonitor role for access to the config and local databases.

Correspondingly, the following built-in roles include additional read and write privileges on local and config databases:

MongoDB introduces mongoreplay, a workload capture and analysis tool that replaces mongosniff. You can use mongoreplay to inspect and record commands sent to a MongoDB instance, and then replay the commands back onto another host at a later time.

mongoreplay is available for Linux and macOS.

MongoDB 3.4 includes the following enhancements:

db.currentOp() and the database profiler report the same basic diagnostic information for all CRUD operations, including the following:

  • MongoDB 3.4 introduces support for ARM64, PPC64LE, and s390x architectures. See Supported Platforms to see the full platform support matrix.

  • Starting in version 3.4, MongoDB removes support for Red Hat Enterprise Linux 5.

For earlier MongoDB Enterprise versions that support Ubuntu 16.04 POWER/PPC64LE:

Due to a lock elision bug present in older versions of the glibc package on Ubuntu 16.04 for POWER, you must upgrade the glibc package to at least glibc 2.23-0ubuntu5 before running MongoDB. Systems with older versions of the glibc package will experience database server crashes and misbehavior due to random memory corruption, and are unsuitable for production deployments of MongoDB

The following summarizes the supported architecture for the latest version of MongoDB products:

POWER8 (little endian)
MongoDB 3.4
MongoDB Enterprise only
MongoDB Enterprise only
Automation Agent
Monitoring Agent
Backup Agent

For details, refer to the individual documentation for the products.

MongoDB Enterprise adds support for log redaction for use in conjunction with MongoDB's encrypted storage engine. Log redaction prevents potentially sensitive information from being written to the diagnostic log; however, diagnostics on redacted logs may be more difficult due to the lack of data related to a log event.

To enable log redaction, see the security.redactClientLogData setting and the --redactClientLogData option for mongod.

MongoDB Enterprise supports the use of Lightweight Directory Access Protocol (LDAP) service to authorize (i.e. determine access) a user authenticated via one of the following authentication mechanism:

For more information, see LDAP Authorization.

MongoDB Enterprise provides a new tool mongoldap for testing your MongoDB LDAP configuration options against a running LDAP server or set of servers. When configuring options related to LDAP authentication, you can use mongoldap to ensure that the authentication operation works as expected.

MongoDB 3.4 supports binding to an LDAP server via operating system libraries. This allows Linux and Windows MongoDB 3.4 servers to use an LDAP server for authentication.

Linux MongoDB deployments continue to support binding via saslauthd.

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

If you need guidance on upgrading to 3.4, MongoDB offers major version upgrade services to help ensure a smooth transition without interruption to your MongoDB application.

To download the MongoDB 3.4, go to the MongoDB Download Center

List of known issues in the 3.4.0 release:

←  Downgrade 3.6 Sharded Cluster to 3.43.4 Changelog →