Compatibility Changes in MongoDB 3.6

The following 3.6 changes can affect the compatibility with older versions of MongoDB.

Localhost Binding Compatibility Changes

Starting in MongoDB 3.6, MongoDB binaries, mongod and mongos, bind to localhost (127.0.0.1) by default. If the net.ipv6 configuration file setting or the --ipv6 command line option is set for the binary, the binary additionally binds to the IPv6 address ::1.

Previously, starting from MongoDB 2.6, only the binaries from the official MongoDB RPM (Red Hat, CentOS, Fedora Linux, and derivatives) and DEB (Debian, Ubuntu, and derivatives) packages bind to localhost by default.

When bound only to the localhost, these MongoDB 3.6 binaries can only accept connections from clients (including the mongo shell, other members in your deployment for replica sets and sharded clusters) that are running on the same machine. Remote clients cannot connect to the binaries bound only to localhost.

To override and bind to other ip addresses, you can use the net.bindIp configuration file setting or the --bind_ip command-line option to specify a list of ip addresses.

Warning

Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.

For example, the following mongod instance binds to both the localhost and the sample ip address 198.51.100.1:

mongod --bind_ip localhost,198.51.100.1

In order to connect to this instance, remote clients must specify the ip address 198.51.100.1 or the hostname associated with the ip address:

mongo --host 198.51.100.1

mongo --host My-Example-Associated-Hostname

To bind to all IPv4 addresses, you can specify the bind ip address of 0.0.0.0. To bind to all IPv4 and IPv6 addresses, you can specify the bind ip address of 0.0.0.0,:: or alternatively, use the new net.bindIpAll setting or the new command-line option --bind_ip_all.

Shard Replica Set

Starting in 3.6, shards must be replica sets. To upgrade your sharded cluster to version 3.6, the shard servers must be running as a replica set.

To convert an existing shard standalone instance to a shard replica set, see Convert a Shard Standalone to a Shard Replica Set.

HTTP Interface and REST API

MongoDB 3.6 removes the deprecated HTTP interface and REST API to MongoDB.

Configuration Settings mongod/mongos option
net.http.enabled
net.http.JSONPEnabled
net.http.port
net.http.RESTInterfaceEnabled
httpinterface
nohttpinterface
jsonp
rest

Tools Changes

MongoDB 3.6 removes the deprecated mongooplog tool.

Array Operation Compatibility Changes

$type: "array" Behavior Change

Starting in 3.6, $type: "array" and $type: 4 expressions match array fields that contain any element type.

In earlier versions, $type : "array" only matches array fields that contain nested arrays.

For example, a collection named c contains two documents:

{ "_id": 1, "a": [ 1, 2, 3 ] },
{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

The following operation queries by type on field a:

db.c.find( { "a": { $type : "array" } } )

Starting in 3.6, the query returns both documents in the collection because the $type query can now detect that field a is itself an array.

{ "_id": 1, "a": [ 1, 2, 3 ] },
{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

In 3.4 and earlier versions of MongoDB, the query only returns those documents in which the array field a contains an element of BSON type array.

{ "_id": 2, "a": [ 1, 2, [ 3, 4 ] ] }

If upgrading from a MongoDB 3.4.x deployment that has partial indexes whose partialFilterExpression includes a $type : "array" or $type : 4 expression, you must rebuild these indexes after upgrading to avoid conflicting $type : 'array' semantics.

For more information on the $type: "array" expression, see Querying by Array Type.

Array Sort Behavior

Starting in 3.6, when sorting a field containing an array, MongoDB orders the field with the lowest-valued element of the array first for ascending sorts and the highest-valued element of the array first for descending sorts. A sort no longer takes the query predicate into account when choosing the array element which will act as the sort key. This behavior change applies to both the find command and the aggregation pipeline.

As a result of this change, applications that currently sort by an array field may experience a different sort order.

Important

As a result of changes to sorting behavior on array fields in MongoDB 3.6, when sorting on an array indexed with a multikey index the query plan includes a blocking SORT stage. The new sorting behavior may negatively impact performance.

In a blocking SORT, all input must be consumed by the sort step before it can produce output. In a non-blocking, or indexed sort, the sort step scans the index to produce results in the requested order.

find Method Sorting

A sort key is the array element MongoDB uses during the sorting process to compare and ultimately order documents containing an array. In an ascending sort, documents containing arrays with the lowest-valued sort keys are ordered first. Likewise, in a descending sort, documents containing arrays with the highest-valued sort keys are ordered first.

In MongoDB 3.4 and earlier, a sort by an array field took into account the query predicate when determining the sort key.

For example, a collection coll has the following documents:

{ _id: 0, a: [-3, -2, 2, 3] }
{ _id: 1, a: [ 5, -4 ] }

Consider following sort operation on the array field a of the collection:

db.coll.find({a: {$gte: 0}}).sort({a: 1});

In MongoDB 3.6, the sort operation no longer takes into account the query predicate when determining its sort key. As a result, the sort key is the lowest-valued element for each document:

  • -3 for the document with _id: 0 and
  • -4 for the document with _id: 1.

The operation returns the documents in the following order:

{ "_id" : 1, "a" : [ 5, -4 ] }
{ "_id" : 0, "a" : [ -3, -2, 2, 3 ] }

Previous MongoDB versions use the lowest-valued array element that matches the query predicate of {$gte: 0} as the sort key:

  • 2 for the document with _id: 0 and
  • 5 for the document with _id: 1,

and would return the documents in the following order:

{ _id: 0, a