Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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

    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>

  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.

    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
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben