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

  1. Stop any connected clients.

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

  3. Shut down the cluster running with the prior version. Open a gfsh prompt:

    % gfsh

    Connect to the locator:

    gfsh>connect --locator=localhost[10334]
    Connecting to Locator at [host=localhost, port=10334] ..
    Connecting to Manager at [host=, port=1099] ..
    Successfully connected to: [host=, port=1099]
    gfsh>list members
     Name   | Id
    ------- | -------------------------------------------
    server2 |<v2>:35840
    locator |
    server1 |<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 jps command to check running java processes:

    % jps
    29664 Jps
  4. On each machine in the cluster, download the new version of GemFire from the Pivotal GemFire downloads page.

  5. 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 X.Y:

    % tar -xzf pivotal-gemfire-9.X.Y.tar.gz
  6. 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 gfsh prompt and check the GemFire version:

    % gfsh --version
  7. On each machine in the cluster, redeploy your environment’s configuration files to the new version installation.

  8. On each machine in the cluster, install any updated server code. Point all client applications to the new installation of GemFire.

  9. Restart all system members.

  10. 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 SecurityManager interface or the deprecated Authenticator interface is implemented, restart all servers with this extra system property:

    gfsh>start server --name=server_name --dir=server_config_dir
  11. 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

    where XXX is 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