Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

13.2. Rolling Upgrades Using Hot Rod (Remote Client-Server Mode)

The following process is used to perform rolling upgrades on JBoss Data Grid running in Remote Client-Server mode, using Hot Rod. This procedure is designed to upgrade the data grid itself, and does not upgrade the client application.
Prerequisite

This procedure assumes you have a cluster 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", where as the "Target Cluster" refers to the new cluster to which data will be migrated.

  1. Begin a new cluster (Target Cluster)

    Start the Target Cluster with the new version of JBoss Data Grid.
    Use either different network settings or JGroups cluster name to avoid overlap with the Source Cluster.

  2. Configure the Target Cluster with a RemoteCacheStore

    The Target Cluster is configured with a RemoteCacheStore with the following settings for each cache to be migrated:
    1. servers must point to the Source Cluster.
    2. cache name must coincide with the name of the cache on the Source Cluster.
    3. hotrod-wrapping must be enabled ("true").
    4. purge must be disabled ("false").
    5. passivation must be disabled ("false").
    Configure the Target Cluster with a RemoteCacheStore
    View larger image
    Configure the Target Cluster with a RemoteCacheStore

    Figure 13.1. Configure the Target Cluster with a RemoteCacheStore

    Note

    Refer to the $JDG_HOME/server/docs/examples/configs/standalone-hotrod-rolling-upgrade.xml file for a full example of the Target Cluster configuration for performing Rolling Upgrades.
    Target Cluster configuration example assumes the Source Cluster is running with standalone.xml configuration: 
    <subsystem xmlns="urn:jboss:datagrid:infinispan:6.1" 
           default-cache-container="local">
    <cache-container name="local"                         
	             default-cache="default">
        <local-cache name="default"                         
		     start="EAGER">
            <locking isolation="NONE"                         
                     acquire-timeout="30000"                         
                     concurrency-level="1000"                         
                     striping="false"/>
            <transaction mode="NONE"/>
            <remote-store cache="default"                         
                          socket-timeout="60000"                         
                          tcp-no-delay="true"                         
                          hotrod-wrapping="true">
                <remote-server outbound-socket-binding="remote-store-hotrod-server"/>
	    </remote-store>
        </local-cache>
    </cache-container>
    <cache-container name="security"/>
</subsystem>
    Copy to Clipboard Toggle word wrap

  3. Configure clients to point to the Target Cluster

    Configure clients to point to the Target Cluster instead of the Source Cluster, restarting each client node one by one.
    Eventually all requests will be handled by the Target Cluster, which will lazily load data from the Source Cluster on demand. The Source Cluster is now the RemoteCacheStore for the Target Cluster.
    Clients point to the Target Cluster with the Source Cluster as RemoteCacheStore for the Target Cluster.
    View larger image
    Clients point to the Target Cluster with the Source Cluster as RemoteCacheStore for the Target Cluster.

    Figure 13.2. Clients point to the Target Cluster with the Source Cluster as RemoteCacheStore for the Target Cluster.

  4. 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 the recordKnownGlobalKeyset operation on the RollingUpgradeManager MBean on the Source Cluster for every cache that needs to be migrated.

    • CLI

      Invoke the upgrade --dumpkeys command on the Source Cluster for every cache that needs to be migrated, or use the --all switch to dump all caches in the cluster.

  5. Fetch remaining data from the Source Cluster

    The Target Cluster now needs to fetch all remaining data from the Source Cluster. Again, this can be done using either JMX or CLI:

    • JMX

      Invoke the synchronizeData operation and specify the hotrod parameter on the RollingUpgradeManager MBean on the Target Cluster for every cache that needs to be migrated.

    • CLI

      Invoke the upgrade --synchronize=hotrod command on the Target Cluster for every cache that needs to be migrated, or use the --all switch to synchronize all caches in the cluster.

  6. Disabling the RemoteCacheStore

    Once the Target Cluster has obtained all data from the Source Cluster, the RemoteCacheStore on the Target Cluster must be disabled. This can be done as follows:

    • JMX

      Invoke the disconnectSource operation specifying the hotrod parameter on the RollingUpgradeManager MBean on the Target Cluster.

    • CLI

      Invoke the upgrade --disconnectsource=hotrod command on the Target Cluster.
  7. Decommission the Source Cluster.
Report a bug
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat