Release Notes for MongoDB 3.0

March 3, 2015

MongoDB 3.0 is now available. Key features include support for theWiredTiger storage engine, pluggable storage engine API,SCRAM-SHA-1 authentication mechanism, and improved explainfunctionality.

MongoDB Ops Manager, which includes Automation, Backup, and Monitoring,is now also available. See the Ops Manager documentation and the Ops Managerrelease notesfor more information.

Minor Releases

3.0.15 – May 15, 2017

Issues fixed:

  • SERVER-27164: Deadlock during initial sync or steady statereplication when CRUD operations implicitly create collections on thesame database.
  • SERVER-28548: In MMAPv1, index readers/writers can returninvalid data if record no longer exists.
  • All issues closed in 3.0.15%20AND%20fixVersion%20%3D%203.0.15%20AND%20resolution%20%3D%20Fixed%20)

3.0.14 – Nov 4, 2016

Issues fixed:

  • Incorrect memory access on 3.0.13 triggers segmentation fault: SERVER-26889

3.0.13 – Oct 31, 2016

Issues fixed:

3.0.12 – May 9, 2016

Issues fixed:

  • Background index build may result in extra index key entries that donot correspond to indexed documents: SERVER-22970
  • Documents that contain embedded null characters can be created:SERVER-7005
  • IX GlobalLock being held while waiting for WiredTiger cache eviction:SERVER-22964
  • All issues closed in 3.0.12%20AND%20fixVersion%20%3D%203.0.12%20AND%20resolution%20%3D%20Fixed%20)

3.0.11 – Mar 31, 2016

Issues fixed:

  • For MongoDB 3.0.9 and MongoDB 3.0.10, during chunk migration, insertand update operations to documents in the migrating chunk are notreflected in the destination shard: SERVER-23425

3.0.10 – Mar 8, 2016

Issues fixed:

  • Read preference of secondaryPreferred can end up usingunversioned connections: SERVER-18671
  • For MMAPv1 journaling, the “last sequence number” file (lsn file)may be ahead of what is synced to the data files:SERVER-22261.
  • Data size change for oplog deletes can overflow 32-bit int:SERVER-22634
  • High fragmentation on WiredTiger databases under write workloads:SERVER-22898.
  • All issues closed in 3.0.10%20AND%20fixVersion%20%3D%203.0.10%20AND%20resolution%20%3D%20Fixed%20)

3.0.9 – Jan 26, 2016

Issues fixed:

  • Queries which specify sort and batch size can return results out oforder if documents are concurrently updated. SERVER-19996
  • Large amounts of create and drop collections can causelistDatabases to be slow under WiredTiger. SERVER-20961
  • Authentication failure message includes server IP address instead ofthe client IP address. SERVER-22054
  • All issues closed in 3.0.9%20AND%20fixVersion%20%3D%203.0.9%20AND%20resolution%20%3D%20Fixed%20)

3.0.8 – Dec 15, 2015

Issues fixed:

3.0.7 – Oct 13, 2015

Issues fixed:

3.0.6 – August 24, 2015

Issues fixed:

3.0.5 – July 28, 2015

Issues fixed and improvements:

3.0.4 – June 16, 2015

Issues fixed:

  • Missed writes with concurrent inserts during chunk migration fromshards with WiredTiger primaries: SERVER-18822
  • Write conflicts with multi-update updates with upsert=true withthe Wired Tiger Storage engine: SERVER-18213
  • Secondary reads could block replication: SERVER-18190
  • Performance on Windows with WiredTiger and documents larger than16kb: SERVER-18079
  • WiredTiger data files are not correctly recovered followingunexpected system restarts: SERVER-18316
  • All issues closed in 3.0.4

3.0.3 – May 12, 2015

Issues fixed:

3.0.2 – April 9, 2015

Issues fixed:

3.0.1 – March 17, 2015

Issues fixed:

  • Race condition in WiredTiger between inserts and checkpoints thatcould result in lost records: SERVER-17506.
  • WiredTiger’s capped collections implementation causes a server crash:SERVER-17345.
  • Initial sync with duplicate _id entries: SERVER-17487.
  • Deadlock condition in MMAPv1 between the journal lock and the oplogcollection lock: SERVER-17416.
  • All issues closed in 3.0.1

Major Changes

Pluggable Storage Engine API

MongoDB 3.0 introduces a pluggable storage engine API that allows thirdparties to develop storage engines for MongoDB.

WiredTiger

MongoDB 3.0 introduces support for the WiredTiger storage engine. With the support forWiredTiger, MongoDB now supports two storage engines:

  • MMAPv1, the storage engine available in previous versions of MongoDBand the default storage engine for MongoDB 3.0, and
  • WiredTiger, available only in the 64-bitversions of MongoDB 3.0.

WiredTiger Usage

WiredTiger is an alternate to the default MMAPv1 storage engine.WiredTiger supports all MongoDB features, including operations thatreport on server, database, and collection statistics. Switching toWiredTiger, however, requires a change to the on-disk storageformat. For instructions on changing thestorage engine to WiredTiger, see the appropriate sections in theUpgrade MongoDB to 3.0 documentation.

MongoDB 3.0 replica sets and sharded clusters can have members withdifferent storage engines; however, performance can vary according toworkload. For details, see the appropriate sections in theUpgrade MongoDB to 3.0 documentation.

The WiredTiger storage engine requires the latest official MongoDBdrivers. For more information, seeWiredTiger and Driver Version Compatibility.

See also

Support for touch Command, WiredTiger Storage Enginedocumentation

WiredTiger Configuration

To configure the behavior and properties of the WiredTiger storageengine, see storage.wiredTiger configuration options. Youcan set WiredTiger options on the command line.

See also

WiredTiger Storage Engine

WiredTiger Concurrency and Compression

The 3.0 WiredTiger storage engine provides document-level locking andcompression.

By default, WiredTiger compresses collection data using thesnappy compression library. WiredTiger uses prefixcompression on all indexes by default.

See also

WiredTiger section in theProduction Notes, the blog postNew Compression Options in MongoDB 3.0

MMAPv1 Improvements

MMAPv1 Concurrency Improvement

In version 3.0, the MMAPv1 storage engine adds support forcollection-level locking.

MMAPv1 Configuration Changes

To support multiple storage engines, some configuration settings forMMAPv1 have changed. See Configuration File Options Changes.

MMAPv1 Record Allocation Behavior Changes

MongoDB 3.0 no longer implements dynamic record allocation anddeprecates paddingFactor. The default allocationstrategy for collections in instances that use MMAPv1 is powerof 2 allocation, which has beenimproved to better handle large document sizes. In 3.0, theusePowerOf2Sizes flag is ignored, so the power of 2 strategy isused for all collections that do not have noPadding flag set.

For collections with workloads that consist only of inserts or in-placeupdates (such as incrementing counters), you can disable the power of 2strategy. To disable the power of 2 strategy for a collection, use thecollMod command with thenoPadding flag or the db.createCollection() method with the noPaddingoption.

Warning

Do not set noPadding if the workload includes removes or anyupdates that may cause documents to grow. For more information, seeNo Padding Allocation Strategy.

When low on disk space, MongoDB 3.0 no longer errors on all writes butonly when the required disk allocation fails. As such, MongoDB nowallows in-place updates and removes when low on disk space.

See also

Dynamic Record Allocation

Replica Sets

Increased Number of Replica Set Members

In MongoDB 3.0, replica sets can have up to 50members. [1] The following drivers support the largerreplica sets:

  • C# (.NET) Driver 1.10
  • Java Driver 2.13
  • Python Driver (PyMongo) 3.0
  • Ruby Driver 2.0
  • Node.JS Driver 2.0

The C, C++, Perl, and legacy PHP drivers, as well as the earlier versions ofthe Ruby, Python, and Node.JS drivers, discover and monitor replica setmembers serially, and thus are not suitable for use with large replicasets.

[1]The maximum number of voting members remains at 7.

Replica Set Step Down Behavior Changes

The process that a primary member of a replica setuses to step down has the following changes:

  • Before stepping down, replSetStepDown will attempt toterminate long running user operations that would block the primaryfrom stepping down, such as an index build, a write operation or amap-reduce job.
  • To help prevent rollbacks, the replSetStepDown will waitfor an electable secondary to catch up to the state of the primarybefore stepping down. Previously, a primary would wait for asecondary to catch up to within 10 seconds of the primary (i.e. asecondary with a replication lag of 10 seconds or less) beforestepping down.
  • replSetStepDown now allows users to specify asecondaryCatchUpPeriodSecs parameter to specify how long theprimary should wait for a secondary to catch up before steppingdown.

Other Replica Set Operational Changes

  • Initial sync builds indexes more efficiently for each collection andapplies oplog entries in batches using threads.
  • Definition of w: “majority” write concern changed tomean majority of voting nodes.
  • Stronger restrictions onReplica Set Configuration. For details, seeReplica Set Configuration Validation.
  • For pre-existing collections on secondary members, MongoDB 3.0 nolonger automatically builds missing _id indexes.

See also

Replication Changes inCompatibility Changes in MongoDB 3.0

Sharded Clusters

MongoDB 3.0 provides the following enhancements to sharded clusters:

  • Adds a new sh.removeTagRange() helper to improve managementof sharded collections with tags. The newsh.removeTagRange() method acts as a complement tosh.addTagRange().
  • Provides a more predictable read preference behavior.mongos instances no longer pin connections to members ofreplica sets when performing read operations. Instead,mongos reevaluates read preferences for every operation to provide a morepredictable read preference behavior when read preferences change.
  • Provides a new writeConcern setting to configure the writeconcern of chunk migration operations. You canconfigure the writeConcern setting for the balancer as well as formoveChunk and cleanupOrphaned commands.
  • Improves visibility of balancer operations. sh.status()includes information about the state of the balancer. Seesh.status() for details.

See also

Sharded Cluster Setting inCompatibility Changes in MongoDB 3.0

Security Improvements

MongoDB 3.0 includes the following security enhancements:

  • MongoDB 3.0 adds a new SCRAM-SHA-1 challenge-response user authenticationmechanism. SCRAM-SHA-1 requires a driver upgrade if your currentdriver version does not support SCRAM-SHA-1. For the driverversions that support SCRAM-SHA-1, seeRequirements.
  • Increases restrictions when using the Localhost Exception toaccess MongoDB. For details, see Localhost Exception Changed.

See also

Security Changes

Improvements

New Query Introspection System

MongoDB 3.0 includes a new query introspection system that provides animproved output format and a finer-grained introspection into bothquery plan and query execution.

For details, see the new db.collection.explain() method andthe new explain command as well as the updatedcursor.explain() method.

For information on the format of the new output, seeExplain Results.

Enhanced Logging

To improve usability of the log messages for diagnosis, MongoDBcategorizes some log messages under specific components, or operations,and provides the ability to set the verbosity level for thesecomponents. For information, see Log Messages.

MongoDB Tools Enhancements

All MongoDB tools except for mongosniff andmongoperf are now written in Go and maintained as a separateproject.

  • New options for parallelized mongodump andmongorestore. You can control the number of collectionsthat mongorestore will restore at a time with the—numParallelCollections option.
  • New options -excludeCollection and—excludeCollectionsWithPrefix for mongodump toexclude collections.
  • mongorestore can now accept BSON data input from standardinput in addition to reading BSON data from file.
  • mongostat and mongotop can now return outputin JSON format with the —json option.
  • Added configurable write concern to mongoimport,mongorestore, and mongofiles. Use the—writeConcern option. The default writeConcern has beenchanged to ‘w:majority’.
  • mongofiles now allows you to configure the GridFS prefixwith the —prefix option so that you can use custom namespacesand store multiple GridFS namespaces in a single database.

See also

MongoDB Tools Changes

Indexes

  • Background index builds will no longer automatically interrupt ifdropDatabase, drop,dropIndexes operations occur for the database orcollection affected by the index builds. ThedropDatabase, drop, anddropIndexes commands will still fail with the errormessage a background operation is currently running, as in 2.6.
  • If you specify multiple indexes to the createIndexescommand,
    • the command only scans the collection once, and
    • if at least one index is to be built in the foreground, theoperation will build all the specified indexes in the foreground.
  • For sharded collections, indexes can now cover queries that execute against themongos if the index includes the shard key.

See also

Indexes inCompatibility Changes in MongoDB 3.0

Query Enhancements

MongoDB 3.0 includes the following query enhancements:

  • For geospatial queries, adds support for “big” polygons for$geoIntersects and $geoWithin queries. “Big”polygons are single-ringed GeoJSON polygons with areas greater thanthat of a single hemisphere. See $geometry,$geoIntersects, and $geoWithin for details.
  • For aggregate(), adds a new$dateToString operator to facilitate converting a dateto a formatted string.
  • Adds the $eq query operator to query for equality conditions.

See also

2d Indexes and Geospatial Near Queries

Distributions and Supported Versions

Most non-Enterprise MongoDB distributions now include support for TLS/SSL.Previously, only MongoDB Enterprise distributions came with TLS/SSL supportincluded; for non-Enterprise distributions, you had to build MongoDBlocally with the —ssl flag (i.e. scons —ssl).

32-bit MongoDB builds are available for testing, but are not forproduction use. 32-bit MongoDB builds do not include the WiredTigerstorage engine.

MongoDB builds for Solaris do not support the WiredTiger storageengine.

MongoDB builds are available for Windows Server 2003 and Windows Vista(as “64-bit Legacy”), but the minimum officially supported Windowsversion is Windows Server 2008.

See also

Platform Support

Package Repositories

Non-Enterprise MongoDB Linux packages for 3.0 and later are in a newrepository. Follow the appropriate Linux installationinstructions to install the 3.0packages from the new location.

MongoDB Enterprise Features

Auditing

Auditing in MongoDB Enterprise can filter on anyfield in the audit message, including thefields returned in the paramdocument. This enhancement, along with theauditAuthorizationSuccess parameter, enables auditing tofilter on CRUD operations. However, enablingauditAuthorizationSuccess to audit of all authorizationsuccesses degrades performance more than auditing only theauthorization failures.

Additional Information

Changes Affecting Compatibility

Some changes in 3.0 can affect compatibility and may require user actions. For adetailed list of compatibility changes, seeCompatibility Changes in MongoDB 3.0.

Upgrade Process

See Upgrade MongoDB to 3.0 for full upgrade instructions.

Download

To download MongoDB 3.0, go to the downloads page.

See also