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