Rolling Upgrade Support

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

Rolling upgrade means that you can upgrade your entire distributed system to the latest GemFire XD release without experiencing any system downtime. You upgrade one member at a time, and each upgraded member can communicate with other members that are running earlier versions of GemFire XD.

Supported Versions for Rolling Upgrade

Pivotal GemFire XD 1.3 introduces the ability to perform rolling upgrades between major release versions. A major version corresponds to an increment in either the second or the first position in a version number. For example, you can perform a rolling upgrade from Pivotal GemFire XD 1.3 to the next major (or minor) version of Pivotal GemFire XD.

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


Even when using GemFire XD versions that are compatible with rolling upgrade, a successful rolling upgrade is possible only when you follow these guidelines. Review this section to ensure that you can perform a rolling upgrade toa future release:
  • A successful rolling upgrade requires all partitioned tables to have been fully configured with redundancy. Without redundancy, stopping individual members causes table data to become unavailable for query processing. Check the redundancy state of all your tables before you begin the rolling upgrade and before stopping any members. See Configure High Availability for a Partitioned Table 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.
  • To ensure that your cluster stays available while you upgrade, make sure that your cluster runs more than one locator.
  • Upgrade locators members first, one at time.
  • After upgrading locators, upgrade data stores one member at a time.
  • During a rolling upgrade, your online cluster will have a mix of members running different versions of GemFire XD. During this time, do not execute DDL such as table rebalancing (unless you have startup-recovery-delay set to -1), creating tables, altering tables, or dropping tables.
  • Make a backup copy of your persistent data stores prior to upgrade.
  • If you have default-recovery-delay=-1 configured for partitioned tables, you will need to perform a rebalance on your tables after you restart each member. If you have default-recovery-delay set to a low number, you may need to wait extra time until the table has recovered redundancy.
  • If you have RECOVERYDELAY configured for a partitioned table, you may need to perform a table rebalance after completing the rolling upgrade process.
  • If you use a WAN configuration or deploy AsyncEventListener implementations where the gateway sender or listener queue is not persisted, then you should wait for non-persistent queues to drain before you begin the rolling upgrade procedure.
  • During a rolling upgrade GemFire XD does not support cancelling statements on members that run the older version of the GemFire XD software.