Rolling Upgrade Procedure

This topic contains the step-by-step procedure for performing a rolling upgrade.

Use the following steps to perform the rolling upgrade.

  1. First upgrade one of the locators in the cluster. On the locator you wish to upgrade, install the new version of the software (alongside the older version of the software) either via ZIP.
    For example:
    $ unzip Pivotal_GemFire_XXX_bNNNNN.zip -d path_to_product

    See Windows/Unix/Linux: Install Pivotal GemFire from a ZIP File for example installation procedures.

  2. Open two terminal consoles on the machine of the locator you are upgrading. In the first console, start a gfsh prompt (from GemFire’s older installation) and connect to the currently running locator.
    For example:
    gfsh>connect --locator=locator_hostname_or_ip_address[port]
  3. Export the locator’s configuration files to a backup directory.
    For example:
    gfsh>export config --member=locator_name --dir=locator_config_dir
  4. Stop the locator that you are upgrading.
    For example:
    gfsh>stop locator --name=locator_name
  5. In the second console, modify the GEMFIRE environment variable to point to the new installation of GemFire. Make sure that the CLASSPATH points to the new GemFire application JAR files, and that your PATH points to the new installation.
  6. In the same console, start gfsh from the new GemFire installation and restart your locator with the configuration files you exported in step 3.
    For example:
    gfsh>start locator --name=locator_name --dir=locator_config_dir
  7. Confirm that the locator has started up and joined the cluster properly. For example, look in the locator log for a message similar to the following:
    [info 2014/01/28 14:32:34.672 PST locator1 <main> tid=0x1] Locator started on  192.168.129.251[10334]
    [info 2014/01/28 14:32:34.680 PST locator1 <main> tid=0x1] Starting server location for Distribution 
    Locator on 192.168.129.251[10334]
    Locator in /home/stymon/locator1_config on 192.168.129.251[10334] as locator1 is currently online.
    
  8. After upgrading the first locator, connect to this locator to ensure it becomes the new JMX Manager.
    For example:
    gfsh>connect --locator=locator_hostname_or_ip_address[port]
  9. Next upgrade all other locators. After you have confirmed the successful upgrade of one locator, you can then upgrade all other locators in the cluster using the same procedure described in steps 1 to 7 above. Confirm that each locator has joined the cluster successfully.
  10. After all locators are upgraded, upgrade one server at a time in the cluster. On the server you wish to upgrade, install the new version of the software (alongside the older version of the software) on the server via ZIP.
    For example:
    $ unzip Pivotal_GemFire_XXX_bNNNNN.zip -d path_to_product
    or
    prompt# sudo -u gemfire -E rpm -Uvh pivotal-gemfire-7.0.2-1.el6.noarch.rpm
  11. Open two terminal consoles on the server that you are upgrading.
  12. In the first console, start a gfsh prompt and connect to one of the locators you have already upgraded.
    gfsh>connect --locator=locator_hostname_or_ip_address[port]
  13. If you are upgrading a server with partitioned regions, check the redundancy state of the regions before stopping the server or exporting its configuration and data. See Checking Redundancy in Partitioned Regions for instructions.
  14. Export the server’s configuration files to a backup directory.
    gfsh>export config --member=server_name --dir=server_config_dir
  15. If desired, create a backup snapshot of the server’s in-memory region data.
    gfsh>export data --member=server_name --region=region_name --file=my_region_snapshot.gfd
  16. Stop the server that you are upgrading.
    gfsh>stop server --name=server_name
  17. If you have not done so already, backup your persistent disk store files.
  18. In the second console, modify the GEMFIRE environment variable to point to the new installation of GemFire. Make sure that the CLASSPATH points to the new GemFire JAR files, and that your PATH points to the new installation.
  19. Recreate your applications with the new gemfire.jar. You may need to do one or more of the following tasks depending on your application's configuration:
    • Modify applications to point to the new GemFire product tree location.
    • Copy the gemfire.jar file out of the new GemFire product tree location and replace the existing gemfire.jar file in your application.
    • Recompile your applications.
    • Redeploy your updated application JAR files.
  20. In the second console, start gfsh from the new GemFire installation and restart your server.
    For example:
    gfsh>start server --name=server_name --dir=server_config_dir
    By providing the exported configuration files directory to the upgraded server upon startup, the restarted server will use the same configuration of the server running the previous version.
  21. Confirm that the server has started up, joined the cluster properly and is communicating with the other members.
    For example, look in the server logs for a message similar to the following:
    [info 2014/01/28 15:21:41.759 PST server1 <main> tid=0x1] DistributionManager 19
    2.168.129.251(server1:6054):57354 started on 239.192.81.1[10334]. There were 0 other DMs. 
    others: []  ...
    [config 2014/01/28 15:21:53.434 PST server1 <main> tid=0x1] CacheServer Configuration:   
    port=40404 max-connections=800 max-threads=0 notify-by-subscription=true 
    socket-buffer-size=32768 maximum-time-between-pings=60000 
    maximum-message-count=230000 message-time-to-live=180 eviction-policy=none capacity=1 
    overflow directory=. groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000
    Server in /opt/pivotal/gemfire/Pivotal_GemFire_702/SampleCode/tutorial/server1 
    on 192.168.129.251[40404] as server1 is currently online.
    Process ID: 6054
    
  22. Check the server log for any severe error messages. You should debug these issues before proceeding with the next server upgrade.
  23. If you restarted a member with partitioned regions, verify that the member is providing redundancy buckets after the upgrade. See Checking Redundancy in Partitioned Regions for instructions. Note that the number of buckets without redundancy will change as the server recovers, so you need to wait until this statistic either reaches zero or stops changing before proceeding with the upgrade. If you have start-recovery-delay=-1 configured for your partitioned region, you will need to perform a rebalance after you start up each member.
  24. Update all the other server members. After confirming successful upgrade of a server member, repeat the process beginning with step 10 for the next member.
  25. If desired, upgrade GemFire clients. You can only do this after you have completed the upgrade on all locator and server members in the cluster.