/
3.6-downgrade-sharded-cluster.txt
126 lines (81 loc) · 3.48 KB
/
3.6-downgrade-sharded-cluster.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
====================================
Downgrade 3.6 Sharded Cluster to 3.4
====================================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
Before you attempt any downgrade, familiarize yourself with the content
of this document.
Downgrade Path
--------------
.. include:: /includes/3.6-downgrade-path.rst
.. |downgrading| replace:: downgrading
Create Backup
-------------
*Optional but Recommended.* Create a backup of your database.
Considerations
--------------
While the downgrade is in progress, you cannot make changes to the
collection metadata. For example, during the downgrade, do
**not** do any of the following:
- :method:`sh.enableSharding()`
- :method:`sh.shardCollection()`
- :method:`sh.addShard()`
- :method:`db.createCollection()`
- :method:`db.collection.drop()`
- :method:`db.dropDatabase()`
- any operation that creates a database
- any other operation that modifies the cluster metadata in any
way. See :doc:`/reference/sharding` for a complete list of
sharding commands. Note, however, that not all commands on the
:doc:`/reference/sharding` page modify the cluster metadata.
Prerequisites
-------------
Before downgrading the binaries, you must downgrade the feature
compatibility version and remove any |newversion| features :ref:`incompatible
<3.6-compatibility-enabled>` with |oldversion| or earlier versions as outlined
below. These steps are necessary only if
``featureCompatibilityVersion`` has ever been set to ``"3.6"``.
.. |target| replace:: :binary:`~bin.mongos` instance
.. _3.6-downgrade-feature-compatibility-sharded-cluster:
1. Downgrade Feature Compatibility Version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Connect a :binary:`~bin.mongo` shell to the |target|.
#. .. include:: /includes/3.6-downgrade-fcv.rst
To ensure that all members of the sharded cluster reflect the updated
``featureCompatibilityVersion``, connect to each shard replica set
member and each config server replica set member and check the
``featureCompatibilityVersion``:
.. tip::
For a sharded cluster that has access control enabled, to run the
following command against a shard replica set member, you must
connect to the member as a :ref:`shard local user
<shard-local-users>`.
.. code-block:: javascript
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
All members should return a result that includes:
.. code-block:: javascript
"featureCompatibilityVersion" : { "version" : "3.4" }
If any member returns a ``featureCompatibilityVersion`` that includes
either a ``version`` value of ``"3.6"`` or a ``targetVersion`` field,
wait for the member to reflect version ``"3.4"`` before proceeding.
For more information on the returned ``featureCompatibilityVersion``
value, see :ref:`view-fcv`.
2. Remove Backwards Incompatible Persisted Features
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/remove-3.6-fcv-features.rst
Procedure
---------
Downgrade a Sharded Cluster
~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. warning::
Before proceeding with the downgrade procedure, ensure that all
members, including delayed replica set members in the sharded
cluster, reflect the prerequisite changes. That is, check the
``featureCompatibilityVersion`` and the removal of incompatible
features for each node before downgrading.
.. include:: /includes/steps/3.6-downgrade-sharded-cluster.rst
.. include:: /includes/3.6-upgrade-replacements.rst