Deprecation

This document is DEPRECATED.

Please consider any information here as out of date. DO NOT use this document.

Instead, refer to http://infinispan.org/documentation.

Please update your bookmarks accordingly.

Skip to end of metadata
Go to start of metadata

Rolling upgrades for remote clients using Hot Rod

This process is used for installations making use of Infinispan as a remote grid, via Hot Rod.  This assumes an upgrade of the Infinispan grid, and not the client application.

In the following description we will refer to the Source and Target clusters, where the Source cluster is the old cluster which is currently in use and the Target cluster is the new cluster to which the data will be migrated to. 

Steps

  1. Start a new cluster (Target Cluster) with the new version of Infinispan, using either different network settings or JGroups cluster name so that the old cluster (Source Cluster) and the new one don't overlap.
  2. For each cache to be migrated, the Target Cluster is configured with a RemoteCacheStore with the following settings:
    1. servers should point to the Source Cluster
    2. remoteCacheName must coincide with the name of the cache on the Source Cluster
    3. hotRodWrapping must be enabled (true)
  3. Configure clients to point to the Target Cluster instead of the Source Cluster, and one by one, restart each client node.  Gradually, all requests will be handled by the Target Cluster rather than the Source Cluster. The Target Cluster will lazily load data from the Source Cluster on demand via the RemoteCacheStore.
  4. Once all connections have switched to using the Target Cluster the keyset on the Source Cluster must be dumped. This can be achieved either via a JMX operation or via the CLI:
    1. JMX: invoke the recordKnownGlobalKeyset operation on the RollingUpgradeManager MBean on the Source Cluster for all of the caches that need to be migrated
    2. CLI: invoke the upgrade --dumpkeys command on the Source Cluster for all of the caches that need to be migrated (additionally the --all switch can be used to dump all caches in the cluster)
  5. At this point the Target Cluster needs to fetch all remaining data from the Source Cluster:
    1. JMX: invoke the synchronizeData operation specifying the "hotrod" parameter on the RollingUpgradeManager MBean on the Target Cluster for all of the caches that need to be migrated
    2. CLI: invoke the upgrade --synchronize=hotrod command on the Target Cluster for all of the caches that need to be migrated (additionally the --all switch can be used to synchronize all caches in the cluster)
  6. Once the above operation is complete, the RemoteCacheStore on the Target Cluster must be disabled as follows:
    1. JMX: invoke the disconnectSource operation specifying the "hotrod" parameter on the RollingUpgradeManager MBean on the Target Cluster for all of the caches that have been migrated
    2. CLI: invoke the upgrade --disconnectsource=hotrod command on the Target Cluster for all of the caches that have been migrated (additionally the --all switch can be used to disconnect all caches in the cluster)
  7. The Source Cluster can be decomissioned now.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.