LATEST VERSION: 9.3.0 - RELEASE NOTES
Pivotal GemFire® v9.3

Planning an Upgrade

Before you upgrade your system, back it up. 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. The discussion at Creating Backups for System Recovery and Operational Management explains the process, and the backup disk-store command reference page describes how to use the gfsh backup disk-store command to make a backup.

Guidelines for Upgrading

  • Schedule your upgrade during a period of low user activity for your system and network.
  • Important: After all locators have been upgraded, do not start or restart any processes that use the older version of the software. The older process will either not be allowed to join the distributed system or, if allowed to join, can potentially cause a deadlock.
  • Verify that all members that you wish to upgrade are members of the same distributed system cluster. A list of cluster members will be output with the gfsh command:

    gfsh>list members
    
  • Locate a copy of your system’s startup script, if your site has one (most do). The startup script can be a handy reference for restarting upgraded locators and servers with the same gfsh command lines that were used in your current installation.

  • Identify how your current cluster configuration was specified. The way in which your cluster configuration was created determines which commands you use to save and restore that cluster configuration during the upgrade procedure. There are two possibilites:

  • Do not modify region attributes or data, either via gfsh or cache.xml configuration, during the upgrade process.

Version Compatibilities

Your choice of upgrade procedure depends, in part, on the versions of Pivotal GemFire involved.

  • Version Compatibility Between Peers and Cache Servers

    For best reliability and performance, all server components of a GemFire system should run the same version of the software. For the purposes of a rolling upgrade, you can have peers or cache servers running different minor versions of Pivotal GemFire at the same time, as long as the major version is the same. For example, some components can continue to run under version 9.0 while you are in the process of upgrading to version 9.1.

  • Version Compatibility Between Clients and Servers

    GemFire clients can run version 8.2.3 or a more recent 8.2 version of GemFire and still connect to GemFire servers running version 9.x. Version 9.x clients, however, cannot connect to servers running older versions of GemFire.

  • Version Compatibility Between Sites in Multi-Site (WAN) Deployments

    In multi-site (WAN) deployments, one site can be running GemFire 8.2.3 or a more recent GemFire 8.2 version, and another site can be running GemFire 9.x. The sites should still be able to communicate with one another.

Upgrade to the Latest Version 9 from an Earlier Version 9

If possible, follow the Rolling Upgrade procedure. A multi-site installation can also do rolling upgrades within each site. If a rolling upgrade is not possible, follow the Off-Line Upgrade procedure. A rolling upgrade is not possible for a cluster that has partitioned regions without redundancy. Without the redundancy, region entries will be lost when individual servers are taken out of the cluster during a rolling upgrade.

Upgrade to Version 9 from Version 8.2.3 or a More Recent 8.2 Version

To upgrade all servers from version 8.2.3 or a more recent version of 8.2 to this version of Pivotal GemFire 9, follow the Upgrade from Version 8.2 to Version 9 procedure.

Upgrade to Version 9 from Version 8.2.2 or an Earlier Version

All upgrades to this Pivotal GemFire version 9 from Pivotal GemFire versions earlier than version 8.2.3 follow a two-step process:

  1. Upgrade all servers to the most recent version of Pivotal GemFire version 8.2 (which must be 8.2.3 or later). If possible, follow the Rolling Upgrade procedure. If a rolling upgrade is not possible, follow the Off-Line Upgrade procedure.

    A rolling upgrade is not possible for a cluster that has partitioned regions without redundancy. Without the redundancy, region entries will be lost when individual servers are taken out of the cluster during a rolling upgrade.

  2. Upgrade all servers from the most recent version of 8.2 to this version of Pivotal GemFire 9. Follow the Upgrade from Version 8.2 to Version 9 procedure.

Upgrade a Multi-Site System to Version 9 from Version 8.2.3 or Later

Multi-site systems that have both persistent disk stores and use bidirectional WAN gateways to replicate data among sites may be able to avoid taking the entire system down to upgrade to version 9. This Multi-site Upgrade from Version 8.2 to Version 9 procedure requires multiple reconfigurations during the upgrade as one site at a time is upgraded.

Java Notes

  • To check your current Java version, type java -version at a command-line prompt.

  • Pivotal GemFire 9.x requires Java SE 8, version 92 or a more recent version. Pivotal GemFire 8.0 was the last GemFire release to support Java SE 6, and Java SE 7 is in End-of-Life status.

  • The Pivotal GemFire product download does not include Java. You must download and install a supported JRE or JDK on each system running GemFire. To obtain best performance with commands such as gfsh status and gfsh stop, install a full JDK (not just a JRE).