davebarnes97 commented on a change in pull request #6134:
URL: https://github.com/apache/geode/pull/6134#discussion_r594702306
##########
File path: geode-docs/getting_started/upgrade/upgrade_offline.html.md.erb
##########
@@ -0,0 +1,92 @@
+---
+title: Offline Upgrade
+---
+
+Use the offline upgrade procedure when you cannot, or choose not to, perform a
rolling upgrade.
+For example, 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.)
+
+## <a id="offline-upgrade-guidelines" class="no-quick-link"></a>Offline
Upgrade Guidelines
+
+**Versions**
+
+For best reliability and performance, all server components of a
<%=vars.product_name%> system should run the same version of the software.
+See [Version Compatibilities](upgrade_planning.html#version_compatibilities)
for more details on how different versions of GemFire can interoperate.
+
+**Data member interdependencies**
+
+When you restart your upgraded servers, interdependent data members may hang
on startup waiting for each other. In this case, start the servers in
+separate command shells so they can start simultaneously and communicate with
one another to resolve dependencies.
+
+## <a id="offline-upgrade-procedure" class="no-quick-link"></a>Offline Upgrade
Procedure
+
+1. Stop any connected clients.
+
+1. On a machine hosting a locator, open a terminal console.
+
+1. Start a `gfsh` prompt, using the version from your current GemFire
installation, and connect to a currently running locator.
+ For example:
+
+ ``` pre
+ gfsh>connect --locator=locator_hostname_or_ip_address[port]
+ ```
+
+1. Use `gfsh` commands to characterize your current installation so you can
compare your post-upgrade system to the current one.
+For example, use the `list members` command to view locators and data members:
+
+ ```
+ Name | Id
+ -------- | ------------------------------------------------
+ locator1 | 172.16.71.1(locator1:26510:locator)<ec><v0>:1024
+ locator2 | 172.16.71.1(locator2:26511:locator)<ec><v1>:1025
+ server1 | 172.16.71.1(server1:26514)<v2>:1026
+ server2 | 172.16.71.1(server2:26518)<v3>:1027
+ ```
+
+1. Save your cluster configuration.
+ - If you are using the cluster configuration service, use the gfsh `export
cluster-configuration` command. You only need to do this once, as the
newly-upgraded locator will propagate the configuration to newly-upgraded
members as they come online.
+ - For an XML configuration, save `cache.xml`, `gemfire.properties`, and any
other relevant configuration files to a well-known location. You must repeat
this step for each member you upgrade.
+
+1. Shut down the entire cluster (by pressing Y at the prompt, this will lose
no persisted data):
+
+ ``` pre
+ 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
+ Shutdown is triggered
+
+ gfsh>
+ No longer connected to 172.16.71.1[1099].
+ gfsh>quit
+ ```
+
+ Since GemFire is a Java process, to check before continuing that all
GemFire members successfully stopped,
Review comment:
Thank you
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
