Chapter 30. 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.

30.1. Rolling Upgrades Using REST

The following procedure outlines using Red Hat JBoss Data Grid installations as a remote grid using the REST protocol. This procedure applies to rolling upgrades for the grid, not the client application.

Procedure 30.1. Perform Rolling Upgrades Using REST

In the instructions, the Source Cluster refers to the old cluster that is currently in use and the Target Cluster refers to the destination cluster for our data.
  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 RestCacheStore with the following settings:
    1. Ensure that the host and port values point to the Source Cluster.
    2. Ensure that the path value points to the Source Cluster's REST endpoint.
  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 RestCacheStore.
  3. Dump the Key Set

    When all connections have shifted to the Target Cluster, remove the Source Cluster key set. This is done either using JMX or the CLI as follows:
    1. Using JMX

      Invoke the recordKnownGlobalKeyset operation on the RollingUpgradeManager MBean on the Source Cluster for all caches to be migrated.
    2. Using the CLI

      Run the upgrade --dumpkeys command on the Source Cluster for all caches to be migrated. Optionally, use the --all switch to dump all the caches in the cluster.
  4. Fetch the Remaining Data

    The Target Cluster must fetch all the remaining data from the Source Cluster. This is done either using JMX or the CLI as follows:
    1. Using JMX

      Invoke the synchronizeData operation with the rest parameter specified on the RollingUpgradeManager MBean on the Target Cluster for all caches to be migrated.
    2. Using the CLI

      Run the upgrade --synchronize=rest on the Target Cluster for all caches to be migrated. Optionally, use the --all switch to synchronize all caches in the cluster.
  5. Disable the RestCacheStore

    Disable the RestCacheStore on the Target Cluster using either JMX or the CLI as follows:
    1. Using JMX

      Invoke the disconnectSource operation with the rest parameter specified on the RollingUpgradeManager MBean on the Target Cluster.
    2. Using the CLI

      Run the upgrade --disconnectsource=rest command on the Target Cluster. Optionally, use the --all switch to disconnect all caches in the cluster.
Result

Migration to the Target Cluster is complete. The Source Cluster can now be decommissioned.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.