이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 14. Rolling Upgrades


In Red Hat JBoss Data Grid, rolling upgrades permit a cluster to be upgraded from one version to a new version without experiencing any downtime. This allows nodes to be upgraded without the need to restart the application or risk losing data.
In JBoss Data Grid, rolling upgrades can only be performed in Remote Client-Server mode.

14.1. Rolling Upgrades Using Hot Rod

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
  • For JBoss Data Grid 6.3, use Hot Rod protocol version 2.0
  • For JBoss Data Grid 6.4, use Hot Rod protocol version 2.0
  • For JBoss Data Grid 6.5, use Hot Rod protocol version 2.0
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.

  1. Configure the Target Cluster

    Use either different network settings or a different JGroups cluster name to set the Target Cluster (consisting of nodes with new JBoss Data Grid) apart from the Source Cluster. For each cache, configure a RemoteCacheStore with the following settings:
    1. Ensure that remote-server points to the Source Cluster.
    2. Ensure that the cache name matches the name of the cache on the Source Cluster.
    3. Ensure that hotrod-wrapping is enabled (set to true).
    4. Ensure that purge is disabled (set to false).
    5. Ensure that passivation is disabled (set to false).

    Figure 14.1. Configure the Target Cluster with a RemoteCacheStore

    Note

    See the $JDG_HOME/docs/examples/configs/standalone-hotrod-rolling-upgrade.xml file for a full example of the Target Cluster configuration for performing Rolling Upgrades.
  2. Start the Target Cluster

    Start the Target Cluster's nodes. Configure each client to point to the Target Cluster instead of the Source Cluster. Eventually, the Target Cluster handles all requests instead of the Source Cluster. The Target Cluster then lazily loads data from the Source Cluster on demand using the RemoteCacheStore.

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

  3. 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.
  4. 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.
  5. 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.
  6. Decommission the Source Cluster

    As a final step, decommission the Source Cluster.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat