Upgrade with Cluster Downtime
Use this upgrade procedure when a rolling upgrade cannot be implemented.
A rolling upgrade is not possible for a cluster that has partitioned regions without redundancy. Without the redundancy, region entries would be lost when individual servers were taken out of the cluster during a rolling upgrade.
The Upgrade Procedure, Step by Step
Stop any connected clients.
Make backup copies of all existing disk-stores, server-side code, configuration files, and data across the entire cluster. To get a backup of the data that includes the most recent changes may require that traffic across the cluster is stopped before the backup is made.
Shut down the cluster running with the prior version. Open a
Connect to the locator:
gfsh>connect --locator=localhost Connecting to Locator at [host=localhost, port=10334] .. Connecting to Manager at [host=192.0.2.0, port=1099] .. Successfully connected to: [host=192.0.2.0, port=1099] gfsh>list members Name | Id ------- | ------------------------------------------- server2 | 192.0.2.0(server2:29368)<v2>:35840 locator | 192.0.2.0(locator:29181:locator):36278 server1 | 192.0.2.0(server1:29285)<v1>:40574
Shut down the entire cluster (by pressing Y at the prompt, this will lose no persisted data):
gfsh>shutdown --include-locators=true As a lot of data in memory will be lost, including possibly events in queues, do you really want to shutdown the entire distributed system? (Y/n): Y succeeded in shutting down
Since GemFire is a Java process, to check before continuing that all GemFire members successfully stopped, it is useful to use the JDK-included
jpscommand to check running java processes:
% jps 29664 Jps
On each machine in the cluster, download the new version of GemFire from the Pivotal GemFire downloads page.
On each machine in the cluster, move the compressed download to the desired installation directory, and uncompress or expand it. For example, to expand the compressed tar file, where current version numbers substitute for
% tar -xzf pivotal-gemfire-9.X.Y.tar.gz
On each machine in the cluster, reset all GemFire-related environment variables to point to the new installation. For example:
export JAVA_HOME=/usr/java/jdk1.8.0_92 export GEMFIRE=<PATH TO INSTALL LOCATION>/pivotal-gemfire-9.X.Y export PATH=$JAVA_HOME/bin:$GEMFIRE/bin:$PATH
To check that the system finds the new installation, open a
gfshprompt and check the GemFire version:
% gfsh --version v9.1.0
On each machine in the cluster, redeploy your environment’s configuration files to the new version installation.
On each machine in the cluster, install any updated server code. Point all client applications to the new installation of GemFire.
Restart all system members.
Once all systems are functioning normally and all tests are successful, restart client applications.
If the clients have also been upgraded to GemFire version 9.1.1 or a more recent version and the
SecurityManagerinterface or the deprecated
Authenticatorinterface is implemented, restart all servers with this extra system property:
gfsh>start server --name=server_name --dir=server_config_dir --J=-Dgeode.disallow-internal-messages-without-credentials=true
Remove the old version of GemFire from each machine in the cluster, to reduce possibility of version complications in the future.
- If the old version of GemFire was installed from a ZIP file, uninstall that old version by deleting its product tree.
- If the old version of GemFire was installed with an RPM, uninstall using
rpm -e Pivotal_GemFire_XXX
XXXis replaced by the GemFire version number and also corresponds to the name of the product installation directory. As an example, the command for removing the GemFire 8.2.5 release would be
rpm -e Pivotal_GemFire_825
- If the old version of GemFire was installed with DEBs, uninstall using
dpkg --remove pivotal-gemfire