Skip to content

Commit 770e57c

Browse files
author
Sam Kleinman
committed
merge: release notes upgrade
2 parents 925b630 + a331d67 commit 770e57c

File tree

1 file changed

+81
-3
lines changed

1 file changed

+81
-3
lines changed

source/release-notes/2.2.txt

Lines changed: 81 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -11,10 +11,88 @@ Release Notes for MongoDB Version 2.2
1111
Upgrading
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

1997
Changes
2098
-------

0 commit comments

Comments
 (0)