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.tgz
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 doing this rolling upgrade to a GemFire version of 9.1.1 or a more recent version, the
SecurityManagerinterface is implemented, and clients are still running a version of GemFire earlier than 9.1.1, start the server with this extra system property such that those clients can talk to the upgraded servers:
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. See Uninstalling GemFire for instructions.