Akka supports rolling updates between two consecutive patch versions unless an exception is mentioned on this page. For example updating Akka version from 2.5.15 to 2.5.16. Many times it is also possible to skip several versions and exceptions to that are also described here. For example it’s possible to update from 2.5.14 to 2.5.16 without intermediate 2.5.15.
It’s not supported to have a cluster with more than two different versions. Roll out the first update completely before starting next update.
Rolling update from classic remoting to Artery is not supported since the protocol is completely different. It will require a full cluster shutdown and new startup.
See migration guide when updating from 2.4.x to 2.5.x.
Incompatible change was introduced in 2.5.10 and fixed in 2.5.11.
This means that you can’t do a rolling update from 2.5.9 to 2.5.10 and must instead do update from 2.5.9 to 2.5.11.
Incompatibility was introduced in in 2.5.10 and fixed in 2.5.15.
That means that you should do rolling update from 2.5.9 directly to 2.5.15 if you need to be able to join 2.5.9 nodes during the update phase.
Intentional change was done in 2.5.14.
This change required a two phase update where the data was duplicated to be compatible with both old and new nodes.
- 2.5.13 - old format, before the change. Can communicate with intermediate format and with old format.
- 2.5.14, 2.5.15, 2.5.16 - intermediate format. Can communicate with old format and with new format.
- 2.5.17 - new format. Can communicate with intermediate format and with new format.
This means that you can’t update from 2.5.13 directly to 2.5.17. You must first update to one of the intermediate versions 2.5.14, 2.5.15, or 2.5.16.
Intentional change was done in 2.5.22.
Changed serializer for classes:
This change required a two phase update where new serializer was introduced but not enabled in an earlier version.
- 2.5.18 - serializer was added but not enabled,
- 2.5.22 -
ClusterShardingMessageSerializerwas enabled for these classes
This means that you can’t update from 2.5.17 directly to 2.5.22. You must first update to one of the intermediate versions 2.5.18, 2.5.19, 2.5.20 or 2.5.21.
See migration guide when updating from 2.5.x to 2.6.x.
In preparation of switching away from class based manifests to more efficient letter codes the
ClusterMessageSerializer has been prepared to accept those shorter forms but still emits the old long manifests.
- 2.6.2 - shorter manifests accepted
- 2.6.3 - shorter manifests emitted (not released yet)
This means that a rolling upgrade will have to go through 2.6.2 and 2.6.3 when upgrading to 2.6.3 or higher or else cluster nodes will not be able to communicate during the rolling upgrade.