@@ -26,7 +26,7 @@ limitations under the License.
26
26
This guide covers topics related to RabbitMQ installation upgrades.
27
27
28
28
1 . [ An overview] ( #basics ) of several common approaches to upgrading RabbitMQ
29
- 1 . [ RabbitMQ version upgradability] ( #rabbitmq-version-upgradability ) , version upgrading from and version upgrading to
29
+ 1 . [ RabbitMQ version upgradability] ( #rabbitmq-version-upgradability ) : explains what versions or series can be upgraded to what later series
30
30
1 . [ Erlang version requirement] ( #rabbitmq-erlang-version-requirement )
31
31
1 . [ Plugin compatibility between versions] ( #rabbitmq-plugins-compatibility )
32
32
1 . Features [ that do not support in-place upgrade] ( #unsupported-inplace-upgrade )
@@ -37,12 +37,13 @@ This guide covers topics related to RabbitMQ installation upgrades.
37
37
1 . [ Caveats] ( #caveats )
38
38
1 . [ Handling node restarts] ( #rabbitmq-restart-handling ) in applications
39
39
40
- Changes between RabbitMQ versions are documented in the [ change log] ( /release-information ) .
40
+ See [ Release Information] ( /release-information ) to find out what RabbitMQ release series are supported.
41
+ Release notes of individual releases are [ published on GitHub] ( https://github.com/rabbitmq/rabbitmq-server/releases ) .
41
42
42
43
## Important Note on Upgrading to 3.12 and 3.13
43
44
44
- ::: warning
45
- RabbitMQ 3.12 requires all previously existing feature flags to be enabled before the upgrade.
45
+ ::: important
46
+ RabbitMQ 3.12 requires all previously existing feature flags to be [ enabled] ( ./feature-flags#how-to-enable-feature-flags ) before the upgrade.
46
47
47
48
The upgrade will fail if you miss this step.
48
49
:::
@@ -58,6 +59,8 @@ as well as several most commonly used strategies:
58
59
59
60
Below is a brief overview of the common strategies. The rest of the guide covers each strategy in more detail.
60
61
62
+ The [ RabbitMQ version upgradability] ( #rabbitmq-version-upgradability ) section explains what versions or series can be upgraded to what later series.
63
+
61
64
### In-place Upgrades {#in-place}
62
65
63
66
::: tip
@@ -120,15 +123,45 @@ Similarly to [rolling upgrades](#rolling-upgrades), grow-and-shrink upgrades bet
120
123
121
124
## RabbitMQ Version Upgradability {#rabbitmq-version-upgradability}
122
125
123
- When an upgrade jumps multiple release series (e.g. goes from ` 3.9.x ` to ` 3.13.x ` ), it may be necessary to perform
124
- one or more intermediate upgrades first. For example, when upgrading from ` 3.9.x ` to ` 3.13.x ` , it would be necessary to
125
- first upgrade to 3.10.x, then to 3.11.x, then to 3.12.x, and finally upgrade to 3.13.0,
126
- or consider a [ The Blue/Green deployment] ( ./blue-green-upgrade ) upgrade.
127
-
128
126
All versions starting with ` 3.7.27 ` support [ rolling upgrades] ( #rolling-upgrades ) to compatible
129
127
later versions using [ feature flags] ( ./feature-flags ) .
130
128
131
- A [ full cluster stop] ( #full-stop-upgrades ) may be required for feature version upgrades.
129
+ A [ full cluster stop] ( #full-stop-upgrades ) may be required for feature version upgrades
130
+ but such cases are rare in modern release series thanks to feature flags.
131
+
132
+ ::: important
133
+ As a rule of thumb, upgrade to the latest patch release in the target series,
134
+ and then [ enable all stable feature flags] ( ./feature-flags#how-to-enable-feature-flags )
135
+ after all cluster nodes have been upgraded.
136
+ :::
137
+
138
+ ::: important
139
+ When an upgrade jumps multiple release series (e.g. goes from ` 3.9.x ` to ` 3.13.x ` ), it may be necessary to perform
140
+ one or more intermediate upgrades first.
141
+
142
+ For each intermediary upgrade, upgrade to the latest patch release in the target series,
143
+ and then [ enable all stable feature flags] ( ./feature-flags#how-to-enable-feature-flags )
144
+ after all cluster nodes have been upgraded.
145
+ :::
146
+
147
+ When an upgrade jumps multiple release series (e.g. goes from ` 3.9.x ` to ` 3.13.x ` ), it may be necessary to perform
148
+ one or more intermediate upgrades first. For each intermediary upgrade, upgrade to the latest patch release in the target series,
149
+ and then [ enable all stable feature flags] ( ./feature-flags#how-to-enable-feature-flags )
150
+ after all cluster nodes have been upgraded.
151
+
152
+ For example, when upgrading from ` 3.9.x ` to ` 3.13.x ` , it would be necessary to
153
+
154
+ 1 . First upgrade to the latest 3.10.x patch release
155
+ 2 . Then to the latest patch release of 3.11.x
156
+ 3 . Then to the latest patch release of 3.12.x
157
+ 4 . Finally, upgrade to the latest release in the 3.13.x
158
+
159
+ Don't forget to [ enable all stable feature flags] ( ./feature-flags#how-to-enable-feature-flags ) every step of
160
+ the process or the follow step may fail because some feature flags have [ graduated] ( ./feature-flags#graduation ) (became mandatory).
161
+
162
+ Or consider a [ The Blue/Green deployment] ( ./blue-green-upgrade ) upgrade in one go.
163
+
164
+ ### Release Series Upgradeability with Rolling Upgrades
132
165
133
166
Current release series upgrade compatibility with ** rolling** upgrade:
134
167
@@ -141,6 +174,8 @@ Current release series upgrade compatibility with **rolling** upgrade:
141
174
| 3.8.x | 3.9.x | |
142
175
| 3.7.18 | 3.8.x | |
143
176
177
+ ### Release Series Upgradeability with Full Stop Upgrades
178
+
144
179
Current release series upgrade compatibility with ** full stop** upgrade:
145
180
146
181
| From | To | Notes |
0 commit comments