Maintenance Window¶
If your installation includes replica sets, plan the upgrade during a predefined maintenance window.
On this page本页内容
MongoDB versioning have the form X.Y.Z where Z refers to the revision/patch number. Revisions provide security patches, bug fixes, and new or changed features that generally do not contain any backward breaking changes. Always upgrade to the latest revision in your release series.
For more information on versioning, see MongoDB Versioning.
Ensure you have an up-to-date backup of your data set. See MongoDB Backup Methods.
Important
If your installation includes replica sets, plan the upgrade during a predefined maintenance window.
Starting in MongoDB 4.0.7, change streams use a version 1 v1 resume tokens. MongoDB versions earlier than 4.0.7 use v0 resume tokens.
When upgrading from MongoDB 4.0.6 or earlier to MongoDB 4.0.7 or later, a client may try to resume change streams using the new v1 resume token when connected to a member that has not been updated (i.e. only accepts v0 or BinData token) and fail. In such cases, the client must wait for the upgrade to complete before resuming change streams.
Starting in MongoDB 3.6, MongoDB enables support for "majority" read concern by default.
You can disable read concern "majority" to prevent the storage cache pressure from immobilizing a deployment with a primary-secondary-arbiter (PSA) architecture. However,
"majority" read concern disables support for Change Streams for MongoDB 4.0 and earlier. For MongoDB 4.2+, disabling read concern "majority" has no effect on change streams availability."majority" read concern prevents collMod commands which modify an index from rolling back. If such an operation needs to be rolled back, you must resync the affected nodes with the primary node."majority" read concern affects support for transactions on sharded clusters. Specifically:
"snapshot" if the transaction involves a shard that has disabled read concern “majority”."majority".However, it does not affect transactions on replica sets. For transactions on replica sets, you can specify read concern "majority" (or "snapshot" or "local" ) for multi-document transactions even if read concern "majority" is disabled.
For more information, see Disable Read Concern Majority.
Before you upgrade a production environment, use the procedures in this document to upgrade a staging environment that reproduces your production environment, to ensure that your production configuration is compatible with all changes.
Important
Always backup all of your data before upgrading MongoDB.
Upgrade each mongod and mongos binary separately, using the procedure described here. When upgrading a binary, use the procedure Upgrade a MongoDB Instance.
Follow this upgrade procedure:
To upgrade a mongod or mongos instance, use one of the following approaches:
Important
Always backup all of your data before upgrading MongoDB.
This section describes how to upgrade MongoDB by replacing the existing binaries. The preferred approach to an upgrade is to use the operating system’s package management tool and the official MongoDB packages, as described in Install MongoDB.
To upgrade a mongod or mongos instance by replacing the existing binaries:
To upgrade a replica set, upgrade each member individually, starting with the secondaries and finishing with the primary. Plan the upgrade during a predefined maintenance window.
Note
Starting in MongoDB 4.0.7, change streams use a version 1 v1 resume tokens. MongoDB versions earlier than 4.0.7 use v0 resume tokens or BinData resume tokens.
When upgrading from MongoDB 4.0.0-4.0.6 to MongoDB 4.0.7 or later, a client may try to resume change streams using the new v1 resume token when connected to a member that has not been updated (i.e. only accepts v0 token or BinData) and fail. In such cases, the client must wait for the upgrade to complete before resuming change streams.
Upgrade each secondary separately as follows:
mongod binary by following the instructions in Upgrade a MongoDB Instance.SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell.
The secondary may briefly go into STARTUP2 or RECOVERING. This is normal. Make sure to wait for the secondary to fully recover to SECONDARY before you continue the upgrade.
rs.stepDown() helper in the mongo shell.replSetStepDown database command.During failover, the set cannot accept writes. Typically this takes 10-20 seconds. Plan the upgrade during a predefined maintenance window.
Note
Stepping down the primary is preferable to directly shutting down the primary. Stepping down expedites the failover procedure.
rs.status() method from the mongo shell until you see that another member has assumed the PRIMARY state.Changed in version 3.4.在版本3.4中更改。The procedure applies to 4.4. To make revision upgrades for other versions of MongoDB sharded clusters, refer to the appropriate version of the manual.
Note
Starting in MongoDB 4.0.7, change streams use a version 1 v1 resume tokens. MongoDB versions earlier than 4.0.7 use v0 resume tokens or BinData resume tokens.
When upgrading from MongoDB 4.0.6 or earlier to 4.0.7 or later, the members of the sharded clusters will continue to produce v0 or BinData resume tokens until the mongos instance(s)
are updated. Upgraded mongos instances will begin producing v1 change stream resume tokens. These tokens cannot be used to resume a stream on a mongos that has not yet been upgraded to 4.0.7 or later.
To upgrade a 4.4 sharded cluster:
To upgrade the config server replica set, use the procedures in Upgrade Replica Sets.
mongos instance by following the instructions in Upgrade a MongoDB Instance. You can upgrade the mongos instances in any order.