Navigation

Release Notes for MongoDB 3.4

On this page

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.

Minor Releases

3.4.24 - Jan 27, 2020

Issues fixed:

3.4.23 - Sep 16, 2019

Issues fixed:

3.4.22 - Aug 6, 2019

Issues fixed:

Note

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

3.4.21 - Jun 14, 2019

Issues fixed:

3.4.20 - Mar 13, 2019

Issues fixed:

3.4.19 - Jan 28, 2019

Issues fixed:

3.4.18 - Nov 7, 2018

Issues fixed:

3.4.17 - Sep 7, 2018

Issues fixed:

3.4.16 - Jul 10, 2018

Issues fixed:

3.4.15 - May 16, 2018

Issues fixed:

3.4.14 - March 20, 2018

Issues fixed:

3.4.13 - Feb 10, 2018

Issues fixed:

3.4.12 - Feb 8, 2018

Issues fixed:

3.4.11 - Jan 31, 2018

Issues fixed:

3.4.10 - Oct 31, 2017

Issues fixed:

3.4.9 - Sept 11, 2017

Issues fixed:

3.4.7 – Aug 8, 2017

Issues fixed:

3.4.6 – Jul 5, 2017

Issues fixed:

3.4.5 – Jun 14, 2017

Issues fixed:

3.4.4 – Apr 21, 2017

Issues fixed:

3.4.3 – Mar 28, 2017

Issues fixed:

3.4.2 – Feb 1, 2017

Issues fixed:

3.4.1 – Dec 20, 2016

Issues fixed:

Sharded Cluster

Membership Awareness

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.

    Note

    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.

Balancer on Config Server Primary

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

Faster Balancing

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.

Removal of Support for SCCC Config Servers

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.

Sharding Zones

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:

Commands mongo Shell Methods
addShardToZone sh.addShardToZone()
removeShardFromZone sh.removeShardFromZone()
updateZoneKeyRange
sh.updateZoneKeyRange()
sh.removeRangeFromZone()

Replica Set

Default Journaling Behavior of majority Write Concern

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.

Adjustable Catchup Period for Newly Elected Primary

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.

Linearizable Read Concern

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:

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

Improved Initial Sync

  • 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:

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

Decimal Type

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.

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

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

Aggregation

New Aggregation Stages to Facilitate Reshaping Documents

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

Stage Description
$addFields 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.
$replaceRoot 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.

New Aggregation Stage to Count

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

Stage Description
$count Returns a document that contains a count of the number of documents input to the stage.

New Aggregation Array Operators

Operator Description
$in Returns a boolean that indicates if a specified value is in an array.
$indexOfArray Searches an array for an occurrence of a specified value and returns the array index (zero-based) of the first occurrence.
$range Returns an array whose elements are a generated sequence of numbers.
$reverseArray Returns an output array whose elements are those of the input array but in reverse order.
$reduce Takes an array as input and applies an expression to each element in the array to return the final result of the expression.
$zip Returns an output array where each element is itself an array, consisting of elements in the corresponding array index position from the input arrays.

New Aggregation String Operators

Operator Description
$indexOfBytes Searches a string for an occurrence of a substring and returns the UTF-8 byte index (zero-based) of the first occurrence.
$indexOfCP Searches a string for an occurrence of a substring and returns the UTF-8 code point index (zero-based) of the first occurrence.
$split Splits a string by a specified delimiter into string components and returns an array of the string components.
$strLenBytes Returns the number of UTF-8 bytes for a string.
$strLenCP Returns the number of UTF-8 code points for a string.
$substrBytes 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.
$substrCP 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.

New Aggregation Control Flow Expression

Operator Description
$switch Evaluates, in sequential order, the case expressions of the specified branches to enter the first branch for which the case expression evaluates to true.

New Date Aggregation Operators

Operator Description
$isoDayOfWeek Returns the ISO 8601 weekday number, ranging from 1 (for Monday) to 7 (for Sunday).
$isoWeek 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.
$isoWeekYear 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).

New Monitoring Aggregation Sources

Operator Description
$collStats Returns statistics regarding a collection or view.

New Type Operator

Operator Description
$type Returns a string which specifies the BSON Types of the argument.

Additional Changes

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

Views

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:

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

    or if specifying a default collation for the view:

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

  • and a corresponding mongo shell helper db.createView():

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

For more information on creating views, see Views.

Security Enhancement

Transition to Auth

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.

See also

Update Replica Set to Keyfile Authentication (No Downtime)

User Roles Changes

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

readAnyDatabase 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.
readWriteAnyDatabase 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.
userAdminAnyDatabase  
dbAdminAnyDatabase 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 Tools

mongoreplay

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.

General Enhancements

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:

Platform Support

  • 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:

Product x86_64/amd64 s390x POWER8 (little endian) ARMv8-A
MongoDB 3.4 ✓ MongoDB Enterprise only MongoDB Enterprise only ✓
BI Connector ✓ ✓ ✓  
Compass ✓      
Spark Connector ✓      
Ops Manager ✓      
Automation Agent ✓   ✓  
Monitoring Agent ✓   ✓  
Backup Agent ✓   ✓  

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

MongoDB Enterprise Features

Log Redaction

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.

LDAP Enhancements

LDAP Authorization

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.

mongoldap

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.

Bind via OS Libraries

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.

Upgrade Procedures

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.

Known Issues in 3.4.0

List of known issues in the 3.4.0 release:

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.