@@ -11,10 +11,88 @@ Release Notes for MongoDB Version 2.2
11
11
Upgrading
12
12
---------
13
13
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 .
16
16
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.
18
96
19
97
Changes
20
98
-------
0 commit comments