Chapter 13. Rolling Upgrades
13.1. Rolling Upgrades Using Hot Rod
Important
- For JBoss Data Grid 6.1, use Hot Rod protocol version 1.2
- For JBoss Data Grid 6.2, use Hot Rod protocol version 1.3
- For JBoss Data Grid 6.3, use Hot Rod protocol version 2.0
- For JBoss Data Grid 6.4, use Hot Rod protocol version 2.0
This procedure assumes that a cluster is already configured and running, and that it is using an older version of JBoss Data Grid. This cluster is referred to below as the Source Cluster and the Target Cluster refers to the new cluster to which data will be migrated.
Configure the Target Cluster
Use either different network settings or a different JGroups cluster name to set the Target Cluster (consisting of nodes with new JBoss Data Grid) apart from the Source Cluster. For each cache, configure aRemoteCacheStore
with the following settings:- Ensure that
remote-server
points to the Source Cluster. - Ensure that the cache name matches the name of the cache on the Source Cluster.
- Ensure that
hotrod-wrapping
is enabled (set totrue
). - Ensure that
purge
is disabled (set tofalse
). - Ensure that
passivation
is disabled (set tofalse
).
Figure 13.1. Configure the Target Cluster with a RemoteCacheStore
Note
See the$JDG_HOME/docs/examples/configs/
standalone-hotrod-rolling-upgrade.xml
file for a full example of the Target Cluster configuration for performing Rolling Upgrades.Start the Target Cluster
Start the Target Cluster's nodes. Configure each client to point to the Target Cluster instead of the Source Cluster. Eventually, the Target Cluster handles all requests instead of the Source Cluster. The Target Cluster then lazily loads data from the Source Cluster on demand using theRemoteCacheStore
.Figure 13.2. Clients point to the Target Cluster with the Source Cluster as
RemoteCacheStore
for the Target Cluster.Dump the Source Cluster keyset
When all connections are using the Target Cluster, the keyset on the Source Cluster must be dumped. This can be done using either JMX or the CLI:JMX
Invoke therecordKnownGlobalKeyset
operation on theRollingUpgradeManager
MBean on the Source Cluster for every cache that must be migrated.CLI
Invoke theupgrade --dumpkeys
command on the Source Cluster for every cache that must be migrated, or use the--all
switch to dump all caches in the cluster.
Fetch remaining data from the Source Cluster
The Target Cluster fetches all remaining data from the Source Cluster. Again, this can be done using either JMX or CLI:JMX
Invoke thesynchronizeData
operation and specify thehotrod
parameter on theRollingUpgradeManager
MBean on the Target Cluster for every cache that must be migrated.CLI
Invoke theupgrade --synchronize=hotrod
command on the Target Cluster for every cache that must be migrated, or use the--all
switch to synchronize all caches in the cluster.
Disabling the
RemoteCacheStore
Once the Target Cluster has obtained all data from the Source Cluster, theRemoteCacheStore
on the Target Cluster must be disabled. This can be done as follows:JMX
Invoke thedisconnectSource
operation specifying thehotrod
parameter on theRollingUpgradeManager
MBean on the Target Cluster.CLI
Invoke theupgrade --disconnectsource=hotrod
command on the Target Cluster.
Decommission the Source Cluster
As a final step, decommission the Source Cluster.