LATEST VERSION: 9.5.0 - CHANGELOG
Pivotal GemFire® v9.5

Off-Line Upgrade

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=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 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.tgz
    
  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
    v9.1.0
    
  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 doing this rolling upgrade to a GemFire version of 9.1.1 or a more recent version, the SecurityManager interface 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
    
  11. 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.