Performing a Rolling Upgrade

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 introduced 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 Pivotal GemFire XD 1.4 without shutting down the entire distributed system.

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.

Guidelines

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 to GemFire XD 1.4:
  • 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.
  • To ensure that your cluster stays available while you upgrade, make sure that your cluster runs more than one locator.
  • Before you start the rolling upgrade, verify that all members that you wish to upgrade are in fact members of the same distributed system.
  • Make a backup copy of your persistent data stores prior to upgrade.
  • Schedule your upgrade during a period of low user activity for your system and network.
  • 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.
  • Upgrade locators members first, one at time.
    Note: After you begin the rolling upgrade process by starting a locator with the version 1.4 software, you can no longer start GemFire XD members that use the version 1.3 software. GemFire XD members at version 1.3 will fail to connect to the distributed system with the message:
    Rejecting the attempt of a member using an older version of the product to join an upgraded distributed system.  
    Please restart the process using the new version of the product
  • 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 statements (for example, do not create, alter, or drop tables or other database objects).
  • If you have default-recovery-delay=-1 configured for partitioned tables, you will need to rebalance those tables after you restart each member with the new software. If you have default-recovery-delay set to a low number, you may need to wait until the table has recovered redundancy.
  • If you have RECOVERYDELAY configured for a partitioned table, you may need to perform a manual rebalance operation after completing the rolling upgrade process.
  • During a rolling upgrade GemFire XD does not support cancelling statements on members that run the older version of the GemFire XD software.