Performing a Rolling Upgrade

A rolling upgrade allows you to keep your existing distributed system running while you upgrade your members gradually.

Supported Versions for Rolling Upgrade

GemFire currently supports a rolling upgrade between minor versions. A minor version corresponds to an increment in the third place position in a version number. For example, you can perform a rolling upgrade from Pivotal GemFire 6.6.1 to 6.6.4 or GemFire 7.0.1 to 7.0.2.

A rolling upgrade is not supported between major versions. A major version corresponds to an increment in either the second or the first position in a version number. For example, you cannot perform a rolling upgrade from Pivotal GemFire 6.5 to 6.6 or a rolling upgrade from GemFire 6.6.3 to 7.0.2.

Note: Rolling upgrade applies only to the peer members or cache servers within a distributed system cluster. It does not apply to overall multi-site (WAN) or client-server deployments since the version interoperability is looser between clients and servers and between different WAN sites. See Pivotal GemFire Version Compatibility Rules for more details on how different versions of GemFire can interoperate.


Review this section before you begin the upgrade.
  • Rolling upgrade should only be used in distributed systems where all partitioned regions have been fully configured with redundancy. You should check the redundancy state of all your regions before you begin the rolling upgrade and before stopping any members. See Checking Redundancy in Partitioned Regions for details.
  • Schedule your upgrade during a period of low user activity for your system and network.
  • Before you start the rolling upgrade, verify that all members that you wish to upgrade are in fact members of the same distributed system cluster.
  • Locators must be rolled first, one at time. To ensure your cluster stays available while you upgrade, make sure that your cluster is running more than one locator.
  • You should only upgrade one data server at a time.
  • When you perform a rolling upgrade, your online cluster will have a mix of members running different versions of GemFire. During this time period, we recommend that you do not execute region operations such as region rebalancing (unless you have startup-recovery-delay set to -1), region creation or region destruction.
  • Additionally, do not modify region attributes or data either via gfsh or cache.xml configuration during the upgrade process.
  • Make a backup copy of your persistent data stores prior to upgrade.
  • If you have start-recovery-delay=-1 configured for your partitioned region, you will need to perform a rebalance on your region after you restart each member. If you have start-recovery-delay set to a low number, you may need to wait extra time until the region has recovered redundancy.
  • If you have recovery-delay configured for your partitioned region, you may need to perform a region rebalance after completing the rolling upgrade process.