Product SiteDocumentation Site

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 backwardly 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