@@ -11,10 +11,88 @@ Release Notes for MongoDB Version 2.2
1111Upgrading
1212---------
1313
14- .. TODO crib from 2.0, with caveat about mongos' before mongod with
15- auth .
14+ MongoDB 2.2 is a standard, incremental production release and works as
15+ a drop-in replacement for MongoDB 2.0 .
1616
17- also drivers need to upgrade to -next if using authentication.
17+ Preparation
18+ ~~~~~~~~~~~
19+
20+ If your MongoDB deployment uses authentication, upgrade your drivers
21+ (i.e. client libraries) and and :program:`mongos` instances before
22+ upgrading your :program:`mongod` instances.
23+
24+ .. TODO insert the following line if we eventually have a section on
25+ this change. See the :ref:`driver changes <2.2-driver-changes>`
26+ section for more information.
27+
28+ Read through all release notes before upgrading, and ensure that no
29+ changes will affect your deployment.
30+
31+ 2.2 processes can inter-operate with 2.0 and 1.8 tools and processes
32+ in replica sets and sharded clusters, if you are not running with
33+ authentication. As a result, you can safely upgrade the
34+ :program:`mongod` and :program:`mongos` components of your deployment
35+ in any order.
36+
37+ .. _2.2-upgrade-standalone:
38+
39+ Upgrading a Standalone ``mongod``
40+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
41+
42+ #. Download the v2.2 binaries from the `MongoDB Download Page`_.
43+
44+ #. Shutdown your :program:`mongod` instance, replace the existing
45+ binary with the 2.2 :program:`mongod` binary and restart MongoDB.
46+
47+ .. _`MongoDB Download Page`: http://downloads.mongodb.org/
48+
49+ .. _2.2-upgrade-replica-set:
50+
51+ Upgrading a Replica Set
52+ ~~~~~~~~~~~~~~~~~~~~~~~
53+
54+ While you may upgrade your replica set in any order, to minimize
55+ downtime, use the following procedure:
56+
57+ #. Upgrade the :term:`secondary` members of the set one at a time by
58+ shutting down the :program:`mongod` and replacing the binary with
59+ the 2.2 binary.
60+
61+ #. Use the :func:`rs.stepDown()` to step down the primary to allow
62+ normal :ref:`failover <replica-set-failover>` procedure.
63+
64+ :func:`rs.stepDown()` and :dbcommand:`replSetStepDown` provide for
65+ shorter and more consistent failover procedures than simply
66+ shutting down the primary directly.
67+
68+ When the primary has stepped down, shut the instance down and
69+ upgrade by replacing the :program:`mongod` binary with the 2.2
70+ binary.
71+
72+ Upgrading a Shard Cluster
73+ ~~~~~~~~~~~~~~~~~~~~~~~~~
74+
75+ If your cluster uses authentication, use the following upgrade
76+ procedure:
77+
78+ - Upgrade all :program:`mongos` instances *first*, in any order.
79+
80+ - Upgrade all of the :program:`mongod` config server instances *one at
81+ a time*. When you have *less* than *three* config servers active,
82+ the cluster will be read-only which will prevent (and abort) all
83+ chunk migrations and chunk splits.
84+
85+ - Upgrade all remaining cluster components. Use the :ref:`upgrade
86+ procedure for replica sets <2.2-upgrade-replica-set>` for each of
87+ the shards and the :ref:`stand alone <2.2-upgrade-standalone>`
88+ procedure for each of the config servers. You may upgrade the
89+ components of your cluster in any order.
90+
91+ If your cluster *does not* use authentication, you may upgrade the
92+ components of the cluster in any order, using the :ref:`upgrade
93+ procedure for replica sets <2.2-upgrade-replica-set>` for each of the
94+ shards and the :ref:`stand alone <2.2-upgrade-standalone>` procedure
95+ for each of the config servers.
1896
1997Changes
2098-------
0 commit comments