此内容没有您所选择的语言版本。

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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部