From 1436bbfd8bfd30982ebd1190b60b7b0be905f25e Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Mon, 1 Oct 2012 11:26:44 -0400 Subject: [PATCH] edits: release notes --- source/release-notes/2.2.txt | 44 ++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/source/release-notes/2.2.txt b/source/release-notes/2.2.txt index d9fe7fbafdf..f14b9e89d6c 100644 --- a/source/release-notes/2.2.txt +++ b/source/release-notes/2.2.txt @@ -13,8 +13,8 @@ Release Notes for MongoDB 2.2 Upgrading --------- -The MongoDB 2.2 series is the production release series of MongoDB -series that succeeds the 2.0 series. +MongoDB 2.2 is a production release series and succeeds the 2.0 +production release series. MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process. However, always perform the upgrade process for replica @@ -27,16 +27,19 @@ Synopsis replacement. - For all deployments using authentication, you *must* upgrade the - drivers (i.e. client libraries,) before upgrading the + drivers (i.e. client libraries), before upgrading the :program:`mongod` instance or instances. -- You can upgrade the members of a replica set, one-by-one +.. To keep with what people are used to, we really should move the comma + outside the parens. + +- You can upgrade the members of a replica set one-by-one [#secondaries-first]_ **except** when using authentication. In - deployments that use authentication, (i.e. where the - :program:`mongod` runs with :option:`--keyFile `,) + deployments that use authentication (i.e. where the + :program:`mongod` runs with :option:`--keyFile `), you must shut down the entire set and perform the upgrade at once. - The 2.2.1 release will remove this requirement, see + The 2.2.1 release will remove this requirement. See :issue:`SERVER-6897` for more information. - For all upgrades of sharded clusters, turn off the balancer during @@ -50,11 +53,11 @@ Synopsis - Second, upgrade all :program:`mongos` instances. - - Finally, upgrade all :program:`mongod` instances. + - Last, upgrade all :program:`mongod` instances. Other than the above restrictions, 2.2 processes can interoperate with -2.0 and 1.8 tools and processes. You can safely upgrade a the -:program:`mongod` and :program:`mongos` components of a deployment, +2.0 and 1.8 tools and processes. You can safely upgrade the +:program:`mongod` and :program:`mongos` components of a deployment one by one while the deployment is otherwise operational. Be sure to read the detailed upgrade procedures below before upgrading production systems. @@ -82,24 +85,25 @@ Upgrading a Replica Set ~~~~~~~~~~~~~~~~~~~~~~~ For replica sets running with authentication, (i.e. :option:`--keyFile -`,) upgrade the entire set from a release of 2.0 to -2.2.0 at once. Shut down all :program:`mongod` instances in the set +`), upgrade the entire set to +2.2 at once. Shut down all :program:`mongod` instances in the set cleanly, upgrade the binaries, and then restart all instances. The 2.2.1 release, will remove this "hard" upgrade requirement, see :issue:`SERVER-6897`. -If your set does not run with authentication may perform a "rolling" +If your set does not run with authentication, then to minimize downtime you may perform a "rolling" upgrade of the set by upgrading the members individually while the -other members are available to minimize downtime. Use the following +other members are available. Use the following procedure: #. Upgrade the :term:`secondary` members of the set one at a time by shutting down the :program:`mongod` and replacing the 2.0 binary with the 2.2 binary. After upgrading a :program:`mongod` instance, - wait for the member to recover to ``SECONDARY`` state by checking - the output of :method:`rs.status()` in the :program:`mongo` shell + wait for the member to recover to ``SECONDARY`` state before upgrading the next instance. + To check the member's state, issue :method:`rs.status()` in the + :program:`mongo` shell. #. Use the :program:`mongo` shell method :method:`rs.stepDown()` to step down the :term:`primary` to allow the normal :ref:`failover @@ -113,9 +117,9 @@ procedure: :program:`mongod` binary with the 2.2 binary and start the new process. - .. note:: Replica set failover is not instantaneous, but will - render the set unavailable to read and writes sent to the set - util failover process completes. Typically this takes tens of + .. note:: Replica set failover is not instantaneous but will + render the set unavailable to read or accept writes + until the failover process completes. Typically this takes tens of seconds, so you may wish to plan the upgrade during a non-critical time of day. @@ -144,7 +148,7 @@ Use the following procedure to upgrade a sharded cluster: Balancing is not currently supported in *mixed* 2.0.x and 2.2.0 deployments. Thus you will want to reach a consistent version for all - shards within a reasonable period of time, e.g., same-day. + shards within a reasonable period of time, e.g. same-day. See :issue:`SERVER-6902` for more information. Changes