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

The following process is used to perform rolling upgrades on Red Hat 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.

Important

Ensure that the correct version of the Hot Rod protocol is used with your JBoss Data Grid version:

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

Prerequisite

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.

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.

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:

servers must point to the Source Cluster.
cache name must coincide with the name of the cache on the Source Cluster.
hotrod-wrapping must be enabled ("true").
purge must be disabled ("false").
passivation must be disabled ("false").

Figure 16.1. Configure the Target Cluster with a RemoteCacheStore

Note

See 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:infinispan:server:core:6.0" 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" shared="true" hotrod-wrapping="true" purge="false" passivation="false">
                        <remote-server outbound-socket-binding="remote-store-hotrod-server"/>
                    </remote-store>
                </local-cache>
            </cache-container>
            <cache-container name="security"/>
        </subsystem>

<subsystem xmlns="urn:infinispan:server:core:6.0" 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" shared="true" hotrod-wrapping="true" purge="false" passivation="false">
                        <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

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.

View larger image

Figure 16.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 the recordKnownGlobalKeyset operation on the RollingUpgradeManager MBean on the Source Cluster for every cache that must be migrated.
- CLI
  Invoke the upgrade --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 the synchronizeData operation and specify the hotrod parameter on the RollingUpgradeManager MBean on the Target Cluster for every cache that must be migrated.
- CLI
  Invoke the upgrade --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, 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.
Decommission the Source Cluster.

Report a bug

返回顶部

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

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links