Translation MongoDB 3.0 Release Notes

This is a creation in Article, where the information may have evolved or changed.

Originally from: http://docs.mongodb.org/manual/release-notes/3.0/

March 3, 2015

MongoDB 3.0 is now available for use. Key new features include support for the Wiredtiger storage engine, a plug-in storage engine api,scram-sha-1 authentication mechanism, and improved explain capabilities.

MongoDB Operations Manager (MongoDB Ops manager), including automation, backup, monitoring is now available for use. Review the operations Manager and Operations Manager Release notes for more information.

Small version released

3.0.1-2015 year March 17

• Fixed loss of records due to insertion and checkpoint race conditions in Wiredtiger: SERVER-17506
• Resolves a server crash problem caused by improper wiredtiger set-up set: SERVER-17345
• Resolve _id issues that cause duplicates when initializing synchronization: SERVER-17487
• Fixed the issue of log lock and Oplog lock deadlock in MMAPV1: SERVER-17416
• All issues in version 3.0.1 are closed

Main changes

Plug-in storage engine API

MongoDB 3.0 introduces a plug-in storage engine API that allows third parties to implement the storage engine for MongoDB.

Wiredtiger

MongoDB 3.0 introduces support for Wiredtiger storage engines. With support for Wiredtiger, MongoDB now supports two storage engines:

• The storage engine supported in previous versions of Mmapv1,mongodb, which is the default storage engine for MongoDB 3.0, and:
• Wiredtiger, supported only in the 64-bit version of MongoDB 3.0.

Wiredtiger use

Wiredtiger is an optional alternative to the MMAPV1 storage engine. Wiredtiger supports all MongoDB features, including all server, database, and aggregate statistics. However, switching to Wiredtiger requires a disk storage format conversion. To learn more about switching the storage engine to Wiredtiger, see the corresponding section for upgrading to MongoDB 3.0.

MongoDB3.0 replica sets and members of a shard cluster can use different storage engines. However, their performance varies depending on the load. For more information, please see the corresponding section for upgrading to MongoDB 3.0.

The Wiredtiger storage engine requires the latest official MongoDB driver. For more information, see Wiredtiger and Driver version compatibility.

Extended reading:

Touch command support, storing Wiredtiger storage engine chapters in documents

Wiredtiger Configuration

To configure the properties and behavior of the Wiredtiger storage Engine, review the Storage.wiredtiger configuration options. You can set the Wiredtiger option at the command line.

Extended reading:

Wiredtiger Storage Engine chapters in a stored document

Wiredtiger Concurrency and compression

The 3.0 Wiredtiger Storage Engine provides document-level locking and compression.

By default, Wiredtiger uses the Snappy compression library to compress collection data. Wiredtiger uses prefix compression for all indexes by default.

Extended reading:

Wiredtiger chapters in the production environment notes

MMAPV1 improvements

MMAPV1 Concurrency Improvements

In version 3.0, the MMAPV1 storage engine joined a collection-level lock.

MMAPV1 configuration Changes

To support multiple storage engines, some MMAPV1 configuration options change somewhat. Please see the section on configuration file options changes.

MMAPV1 Record allocation behavior changes

MongoDB 3.0 no longer implements dynamic record allocations, and whitespace factors are also marked as expired. In an instance that uses MMAPV1, the default allocation policy for the collection is 2 of the sub-party allocation, which has proven to perform better when working with large document sizes. In 3.0, theusepowerof2sizes option is ignored, so 2 of the Sub-party allocation policy is applied to all collections that do not have nopadding settings.

For collections that have only inserts and updates (such as the growth count) workload, you can choose to disable the 2 sub-party policy. To disable 2 of the sub-party policy for a collection, use the Collmod command labeled Nopadding, or the Db.createcollection () method with nopadding .

Warning:

Do not set the nopadding option if the workload contains updates that delete or cause changes to the document size. For more information, please read the no-blank allocation policy .

When disk space is low, MongoDB 3.0 no longer generates errors on all writes, and only generates errors when the required space cannot be allocated. Therefore, when disk space is low, MongoDB is still allowed to change the size of the update and delete operations.

Extended reading:

Dynamic record Assignment

Copy set

Increase the maximum number of members of a replica set

There can be up to 50 members in a replica set in MongoDB 3.0 [1]. The following drivers support large replication sets:

• C # (. NET) Driver 1.10
• Java Driver 2.13
• Python Drive (Pymongo) 3.0+
• Ruby Driver 2.0+
• node. JS Driver 2.0+

Because c,c++,perl,php and previous versions of Ruby,python and node. JS drivers are sequential discovery and monitoring of replica set members, these drivers are not suitable for use in large replication sets.

Pymongo 3.0 is currently under development.

[1] The maximum number of voting members is still 7

Replication Set downgrade behavior change

The primary member demotion process for a replica set has the following changes:

• Before downgrading, Replsetstepdown will attempt to end long-running user tasks that block the demotion of the primary member, such as indexing, writing, or map/reduce work.
• To prevent rollback, the Replsetstepdown will wait for eligible fallback members to overtake the current primary member's synchronization state in a downgrade. Prior to the demotion, the primary member waits within 10 seconds for the fallback member to catch up with the synchronization state (for example, the fallback member synchronization delay is within 10 seconds).
• Replsetstepdown now allows the user to specify the secondarycatchupperiodsecs parameter to set how long the primary member should wait for the fallback member before downgrading.

Additional replication Set optional changes

• Initial synchronization now uses multithreading to build indexes and apply Oplog records more efficiently to collections.
• Definition W: "majority" writes the meaning of the present to refer to most of the nodes that have the right to vote.
• The replica set configuration now has a stronger constraint. Read the Copy Set Configuration verification section for more information.
• MongoDB 3.0 no longer automatically constructs a missing _id Index on a collection that already exists on the fallback member.

Extended reading:

Changes to the replica set in MongoDB 3.0 compatibility changes

Shard Cluster

MongoDB 3.0 provides the following enhancements for a shard cluster:

• Added a new Sh.removetagrange () Help method to change the management of a tagged collection of incoming shards. The new Sh.removetagrange () method complements the Sh.addtagrange () method.
• Makes the behavior of read preferences more predictable. When a read operation occurs, the MONGOs instance no longer secures the connection to the members of the replica set. Instead, MONGOs re-evaluates the read preferences for each operation, providing a more predictable read preference behavior when the read preference changes (a bit difficult to understand, first interpreting preferences).
• Provides a new Writeconcern setting to configure write attention for data fragment migration operations. You can configure independent write concerns for Balancers as well as for Movechunk and cleanuporphaned commands.
• Improved transparency of balancer operations. Sh.status () contains the state information of the balancer. Check out Sh.status () for more details.

Extended reading:

Shard Cluster settings in MongoDB 3.0 compatibility changes

Security improvements

MongoDB 3.0 contains the following security enhancements:

• Add a new Scram-sha-1 user authentication mechanism.
• Additional constraints are added when using local exceptions to access MongoDB. For more information, please see local exception changes.

Extended reading:

Security Changes

Improved

New Inquiry self-test system

MongoDB 3.0 includes a new query self-test system that provides better output formatting and better application of self-test information to query plans and query execution.

For more information, see the new Db.collection.explain () method and the new explain command, as well as the updated Cursor.explain () method.

To learn more about the new output format, see the explain results.

Enhanced logs

To increase the availability of log messages during diagnostics, MongoDB classifies log messages for specific components or operations, providing the ability to set the log detail level for these components. For more information, please read the log messages.

MongoDB Tool Improvements

All MongoDB tools are now written in the go language and are maintained as standalone projects.

• Parallel new options for Mongodump and Mongorestore. You can use the--numparallelcollections option to specify the number of concurrent recovery sets for Mongorestore.
• New options-excludecollection and--excludecollectionswithprefix can specify excluded collections for Mongodump.
• Mongorestore now supports accepting Bson data from a standard input stream in addition to reading Bson data from a file.
• Mongostat and Mongotop can now specify the output JSON format using the--json option.
• To add configurable write attention to Mongoimport,mongorestore,mongofiles, use the--writeconcern option.
• Mongofiles now allows you to configure the GRIDFS prefix with the--prefix option, so you can now use a custom namespace to store multiple Gridfs namespaces in the same database.

Extended reading:

MongoDB Tool Improvements

Index

• The background build index is now not interrupted because the dropdatabase,drop,dropindexes operation affects the associated database or collection. The Dropdatabase,drop and Dropindexes commands are now the same as in version 2.6, and will return " background operations in progress" and fail.
• If you specify multiple indexes for the createindexes command,
  
  • command will only scan the collection once, and
  • If at least one collection needs to be built in the foreground, the operation builds all indexes in the foreground.
  • For a split collection, now if the index contains a sharding key, you can overwrite the query for MONGOs.

Extended reading:

Index chapters in MongoDB 3.0 compatibility improvements

Query enhancement

MongoDB 3.0 contains the following query enhancements:

• The earth location query adds a convex polygon support for $geointersects and $geowithin queries.

Release version

Most non-enterprise MongoDB distributions now contain SSL support. Previously only the MongoDB Enterprise release comes with SSL support, and for non-enterprise releases, you can only use the--ssl identity to natively compile MongoDB (for example, SCons--ssl).

MongoDB Enterprise Edition features

Audit

The auditing features in MongoDB Enterprise Edition can be filtered by any field in the audit message, including the fields in the Param document. This enhancement, coupled with the auditauthorizationsuccess parameter, enables the audit to filter crud operations. However, when Auditauthorizationsuccess is turned on only when authentication fails, a successful audit of all authorizations will degrade performance.

Additional Information

Improvements that affect compatibility

Some of the changes in 3.0 may affect compatibility and may require user attention. To read all modifications that affect compatibility, refer to MongoDB 3.0 compatibility improvements.

Upgrade process

Review the upgrade to MongoDB 3.0 for the full upgrade instructions.

Download

To download MongoDB 3.0 please go to the download page.

Additional Resources

• All third-party license descriptions
• All Jira issues resolved in 3.0