Product SiteDocumentation Site

Appendix E. Upgrading Cluster Software

Table of Contents

E.1. Version Compatibility
E.2. Complete Cluster Shutdown
E.2.1. Procedure
E.3. Rolling (node by node)
E.3.1. Procedure
E.3.2. Version Compatibility
E.3.3. Crossing Compatibility Boundaries
E.4. Disconnect and Reattach
E.4.1. Procedure
E.4.2. Notes

E.1. Version Compatibility

When releasing newer versions we take care to make sure we are backwards compatible with older versions. While you will always be able to upgrade from version x to x+1, in order to continue to produce high quality software it may occasionally be necessary to drop compatibility with older versions.
There will always be an upgrade path from any series-2 release to any other series-2 release.
There are three approaches to upgrading your cluster software:
  • Complete Cluster Shutdown
  • Rolling (node by node)
  • Disconnect and Reattach
Each method has advantages and disadvantages, some of which are listed in the table below, and you should chose the one most appropriate to your needs.

Table E.1. Summary of Upgrade Methodologies

Type Available between all software versions Service Outage During Upgrade Service Recovery During Upgrade Exercises Failover Logic/Configuration Allows change of cluster stack type [a]
Shutdown
yes
always
N/A
no
yes
Rolling
no
always
yes
yes
no
Reattach
yes
only due to failure
no
no
yes
[a] For example, switching from Heartbeat to Corosync. Consult the Heartbeat or Corosync documentation to see if upgrading them to a newer version is also supported.