Menu Close

Data Grid のアップグレード

Red Hat Data Grid 8.1

Data Grid から 8.1 へのアップグレード

Red Hat Customer Content Services

概要

以前のバージョンからの移行に影響する Data Grid 8.1 の変更を確認し、デプロイメントをアップグレードしてデータを移行する手順を完了します。

第1章 Red Hat Data Grid

Data Grid は、高パフォーマンスで分散型のインメモリーデータストアです。

スキーマレスデータ構造
異なるオブジェクトをキーと値のペアとして保存する柔軟性。
グリッドベースのデータストレージ
クラスター全体でデータを分散および複製するように設計されています。
柔軟スケーリング
サービスの中断なしに要求を満たすようにノードの数を動的に調整します。
データの相互運用性
異なるエンドポイントからグリッドにデータを保存、取得、およびクエリーします。

1.1. Data Grid のドキュメント

Data Grid のドキュメントは、Red Hat カスタマーポータルから入手できます。

1.2. Data Grid のダウンロード

Red Hat カスタマーポータルで Data Grid Software Downloads にアクセスします。

注記

Data Grid ソフトウェアへアクセスおよびダウンロードするには、Red Hat アカウントが必要です。

第2章 Data Grid 8.1 への移行

以前のリリースからの移行に影響する Data Grid 8.1 の変更を確認してください。

2.1. メモリーの設定

Data Grid 8.1 は、データコンテナーの簡素化された設定を提供します。binary 設定要素は不要となり、非推奨になりました。代わりに、キャッシュエントリーをバイナリーストレージ形式でエンコードできます。この変更により、Data Grid はプリミティブとbyte[] と組み合わされた文字列を格納しなくなりましたが 、byte[] のみを保存します。

重要

これまでの Data Grid バージョンからのメモリーおよびエビクション設定は引き続きサポートされ、有効です。ただし、XML 形式または JSON 形式にシリアライズされた Data Grid キャッシュ設定は常に 8.1 設定を使用します。

たとえば、前の設定を使用して Data Grid Console でエントリーを作成すると、Data Grid は自動的に 8.1 memory 設定に変換します。

既存のキャッシュ設定を変換して、Data Grid 8.1 への移行の一部として新しい memory 設定を使用するように計画する必要があります。

JVM ヒープのオブジェクトストレージ

8.0:

<memory>
   <object size="1000000" strategy="REMOVE"/>
</memory>

8.1:

<!-- Perform eviction at 1000000 entries. -->
<memory max-count="1000000" when-full="REMOVE"/>
注記

上記の例は、デフォルトであるため storage="HEAP" 属性を表示しません。Off-Heap ストレージを使用する場合のみ storage 値を設定する必要があります。

JVM ヒープのバイナリーストレージ

8.0:

<cache>
   <memory>
      <binary size="500000000" strategy="EXCEPTION" eviction="MEMORY"/>
   </memory>
</cache>

8.1:

<cache>
   <!-- Encode keys and values in the cache with any binary format. -->
   <encoding media-type="application/x-protostream"/>
   <!-- Throw an exception when you reach the maximum size for the cache. -->
   <memory max-size="500 MB" when-full="EXCEPTION"/>
</cache>

Off-Heap ストレージ

8.0:

<cache>
   <memory>
      <off-heap size="10000000" eviction="COUNT"/>
   </memory>
</cache>

8.1:

<!-- Store a maximum number of entries outside the JVM heap. -->
<memory storage="OFF_HEAP" max-count="10000000"/>

2.2. Data Grid Operator 8.1

Data Grid Operator は、Red Hat OpenShift サービス CA によって署名された TLS 証明書を自動的に生成します。その後、Data Grid Operator は証明書および鍵をシークレットに保存し、それらを取得し、リモートクライアントで使用できるようにします。

デフォルトでは、OpenShift サービス CA が利用可能な場合、Data Grid Operator は CA を使用してクライアント接続を暗号化します。8.0 では、Data Grid Operator は暗号化を自動的に有効にしません。

8.0 からアップグレードする場合は、Data Grid Operator が生成する tls.crt 証明書を取得し、これを使用してクライアントトラストストアを作成する必要があります。

注記

OpenShift サービス CA が存在する場合は暗号化を使用する必要があります。

Securing Data Grid Connections」を参照してください。

2.3. Data Grid 8.1 サーバー

Data Grid 8.1 サーバーの移行の詳細を確認します。

2.3.1. デフォルトのセキュリティーレルム

Data Grid サーバー、ユーザー認証を実施するデフォルトのプロパティーレルムを提供します。Data Grid 8.1 サーバーを起動する前に、Data Grid CLI user コマンドを使用してクレデンシャルを追加します。

テスト目的でのみセキュアなネットワークで実行する必要がある匿名 (非認証) 接続を許可する場合は、Data Grid サーバーエンドポイント設定から security-realm 属性を削除します。

重要

既存の Data Grid Server デプロイメントを、セキュリティーのベストプラクティスとして 8.1 にアップグレードする必要があります。

以下を参照してください。

2.3.2. リモートキャッシュのエンコード

リモートキャッシュを作成する場合は、MediaType をキーおよび値に設定する必要があります。キャッシュ用に MediaType を設定すると、データのストレージ形式が保証されます。

手順

  • 必要に応じて Data Grid キャッシュ定義に MediaType を指定します。他の要件がない限り、ProtoStreamを使用する必要があります。ProtoStreamは、言語に依存しない、下位互換性のある形式でデータを保存します。

    <encoding media-type="application/x-protostream"/>

エンコーディングでの分散キャッシュ設定

<infinispan>
    <cache-container>
        <distributed-cache name="myCache" mode="SYNC">
          <encoding media-type="application/x-protostream"/>
          <memory max-count="1000000" when-full="REMOVE"/>
        </distributed-cache>
    </cache-container>
</infinispan>

重要

リモートキャッシュをエンコードしない場合、Data Grid サーバーは以下のメッセージをログに記録します。

WARN  (main) [org.infinispan.encoding.impl.StorageConfigurationManager] ISPN000599: Configuration for cache 'mycache' does not define the encoding for keys or values. If you use operations that require data conversion or queries, you should configure the cache with a specific MediaType for keys or values.

今後のバージョンでは、データ変換が実行される操作にはキャッシュエンコーディングが必要になります。たとえば、データコンテナーのインデックス化と検索、リモートタスクの実行、Hot Rod および REST エンドポイントとは異なる形式のデータの読み取りおよび書き込み、さらにリモートフィルター、コンバーター、およびリスナーの使用などにキャッシュエンコーディングが必要になります。

2.3.3. REST API への POST 要求のあるアクション URL パラメーター

?action URL パラメーターで Data Grid REST API を呼び出すことが POST メソッドでサポートされるようになりました。応答にコンテンツが含まれていれば、呼び出しによってステータス 200 が返され、含まれていなければステータス 204 が返されます。

GET メソッドを使用した ?action URL パラメーターのサポートは、今後のバージョンで削除される予定です。

2.5. 非推奨の機能

非推奨となった機能のサポートは、非推奨となったリリース以降は利用できません。

重要

Red Hat は、新規デプロイメントで非推奨になった機能の追加、有効化、設定を行うことを推奨しません。

2.5.1. 非推奨

Data Grid 8.1 では、以下の機能が非推奨になりました。

JBoss マーシャリング

JBoss マーシャリングは非推奨となり、infinispan-jboss- marshalling モジュールをクラスパスに追加しても、Hot Rod Java クライアントは GenericJBossMarshaller を自動的に設定しなくなりました。

シリアル化ベースのマーシャリングの代わりに Protostream を使用する必要があります。ただし、jboss-marshalling が必要な場合は以下を行います。

  1. infinispan-jboss-marshalling 依存関係をクラスパスに追加します。
  2. RemoteCacheManager の作成時に org.infinispan.jboss.marshalling.commons.GenericJBossMarshaller を明示的に設定します。
注記

起動時に、Data Grid サーバーは以下のログメッセージを書き込みます。

WARN  (main) [org.infinispan.PERSISTENCE] ISPN000554: jboss-marshalling is deprecated and planned for removal

このメッセージは無視しても問題ありません。これは、JBoss マーシャリングの非推奨に関する通知として機能します。

Red Hat JBoss EAP の Data Grid モジュール

Data Grid モジュールは非推奨となり、削除される予定です。

jgroupsinfinispan および endpoint 拡張機能が削除されます。すべてのコンポーネントは 1 つの org.infinispan モジュールで利用できます。

メモリーの設定

binary 設定と、<object><binary>、および <off-heap> 要素が非推奨になりました。

クロスサイトレプリケーション

org.infinispan.xsite.CustomFailurePolicy インターフェースは非推奨になりました。代わりに org.infinispan.configuration.cache.CustomFailurePolicy インターフェースを使用する必要があります。

リモートクラスターから更新を送受信できないため、ローカルキャッシュのバックアップの場所は設定できなくなりました。

OSGi

OSGi サポートは非推奨となり、削除される予定です。

ClusterLoader および Lazy Retrieval

org.infinispan.persistence.cluster.ClusterLoader クラスは非推奨になりました。これは、ClusterLoader クラスを使用するため、Hot Rod クライアントの LAZY_RETRIEVAL オプションが含まれます。どちらも直接的な代替がないまま削除される予定です。

Persistence SPI

CacheLoader および CacheWriter を含む、Persistence SPI の複数のインターフェースが非推奨になりました。代わりに NonBlockingStore を使用する必要があります。

2.5.2. 削除された機能

Data Grid 8.1 には、以前のリリースで非推奨となった、または新しいコンポーネントで置き換えられた以下の機能が削除されました。

  • 非同期クロスサイトレプリケーションの属性が更新されなくなったため、Data Grid 8.1 は JMX 経由で公開しません。これには AsyncXSiteRequestsReceivedAsyncXSiteAcksCountAsyncXSiteCountAverageAsyncXSiteReplicationTimeAverageXSiteReplicationTime、および MinimumAsyncXSiteReplicationTime が含まれます。非同期バックアップを設定する場合でも、同期クロスサイトレプリケーション属性を代わりに使用します。
  • Total Order トランザクションプロトコル。
  • ThreadGroup のプログラムによる設定groupName() メソッドの ThreadFactoryConfigurationBuilder を使用して、宣言的な設定と一致するようにします。
  • 単一ファイルキャッシュストアの relative-to 属性。キャッシュストア設定にこの属性が含まれる場合、Data Grid はこれを無視し、ストアの場所を設定する場合に path のみを使用します。
  • Write-Behind モードの thread-pool-size 属性が削除されました。
  • グローバル JMX 設定の allowDuplicateDomains は削除されました。

第3章 Data Grid サーバーのローリングアップグレードの実行

Data Grid クラスターのローリングアップグレードを実行し、ダウンタイムやデータ損失を発生せずにバージョン間で変更します。ローリングアップグレードでは、Hot Rod 経由で Data Grid サーバーとデータをターゲットバージョンに移行します。

3.1. ターゲットクラスターの設定

ターゲット Data Grid バージョンを実行するクラスターを作成し、リモートキャッシュストアを使用してソースクラスターからデータをロードします。

前提条件

  • ターゲットアップグレードバージョンで Data Grid クラスターをインストールします。
重要

ターゲットクラスターのネットワークプロパティーがソースクラスターのネットワークプロパティーと重複しないようにします。JGroups トランスポート設定で、ターゲットおよびソースクラスターに一意の名前を指定する必要があります。環境によっては、異なるネットワークインターフェースを使用し、ターゲットクラスターとソースクラスターを分離するためにポートオフセットを指定することもできます。

手順

  1. ソースクラスターから移行する各キャッシュのターゲットクラスターで RemoteCacheStore を追加します。

    リモートキャッシュストアは Hot Rod プロトコルを使用して、リモート Data Grid クラスターからデータを取得します。リモートキャッシュストアをターゲットクラスターに追加すると、クライアント要求を処理するためにソースクラスターからデータが遅れてロードされます。

  2. クライアントをターゲットクラスターに切り替え、すべての要求の処理を開始します。

    1. ターゲットクラスターの場所でクライアント設定を更新します。
    2. クライアントを再起動します。

3.1.1. ローリングアップグレード用のリモートキャッシュストア

以下のように、ローリングアップグレードを実行するには、特定のリモートキャッシュストア設定を使用する必要があります。

<persistence passivation="false"> 1
   <remote-store xmlns="urn:infinispan:config:store:remote:8.1"
                 cache="myDistCache" 2
                 protocol-version="2.5" 3
                 hotrod-wrapping="true" 4
                 raw-values="true" 5
                 segmented="false"> 6
      <remote-server host="127.0.0.1" port="11222"/> 7
   </remote-store>
</persistence>
1
パッシベーションを無効にします。ローリングアップグレードのリモートキャッシュストアは、パッシベーションを無効にする必要があります。
2
ソースクラスターのキャッシュの名前と一致します。ターゲットクラスターは、リモートキャッシュストアを使用してこのキャッシュからデータをロードします。
3
ソースクラスターの Hot Rod プロトコルバージョンと一致します。2.5 は最小バージョンで、すべてのアップグレードパスに適しています。別の Hot Rod バージョンを設定する必要はありません。
4
エントリーが Hot Rod プロトコルに適した形式でラップされるようにします。
5
リモートキャッシュストアにデータを raw 形式で格納します。これにより、クライアントがリモートキャッシュストアから直接データを使用できるようにします。
6
リモートキャッシュストアのセグメンテーションを無効にします。リモートキャッシュストアのセグメンテーションは、ターゲットクラスターのセグメント数がソースクラスターのキャッシュのセジメント数と一致する場合にのみ有効にする必要があります。
7
ソースクラスターの場所を示します。

3.2. ターゲットクラスターへのデータの同期

ターゲットクラスターが実行中であり、リモートキャッシュストアを使用してクライアント要求をオンデマンドでロードする場合、ソースクラスターからターゲットクラスターにデータを同期できます。

この操作は、ソースクラスターからデータを読み取り、ターゲットクラスターに書き込みます。データはターゲットクラスター内のすべてのノードに並行して移行し、各ノードはデータのサブセットを受信します。Data Grid 設定の各キャッシュの同期を実行する必要があります。

手順

  1. ターゲットクラスターに移行する Data Grid 設定の各キャッシュの同期操作を開始します。

    Data Grid REST API を使用して、?action=sync- data パラメーターで POST リクエストを呼び出します。たとえば、「myCache」というキャッシュのデータをソースクラスターからターゲットクラスターに同期するには、以下の手順を実施します。

    POST /v2/caches/myCache?action=sync-data

    操作が完了すると、Data Grid はターゲットクラスターにコピーされたエントリーの合計数で応答します。

    または、RollingUpgradeManager MBean で synchronizeData(migratorName=hotrod) を呼び出すと、JMX を使用できます。

  2. ソースクラスターからターゲットクラスターの各ノードを切断します。

    たとえば、ソースクラスターから「myCache」キャッシュを切断するには、以下の POST リクエストを実行します。

    POST /v2/caches/myCache?action=disconnect-source

    JMX を使用するには、RollingUpgradeManager MBean で disconnectSource(migratorName=hotrod) を呼び出します。

次のステップ

ソースクラスターのすべてのデータを同期した後に、ローリングアップグレードプロセスが完了します。ソースクラスターを廃止できるようになりました。

第4章 Data Grid サーバーインストールへのパッチ適用

Data Grid サーバーインストールのパッチをインストールし、管理します。

異なるバージョンを持つ複数の Data Grid サーバーにパッチを適用し、必要なターゲットバージョンにアップグレードすることができます。ただし、Data Grid サーバーが稼働している場合、パッチは有効になりません。このため、サーバーがオフラインのときにパッチをインストールします。ダウンタイムなしで Data Grid クラスターをアップグレードする場合は、ターゲットバージョンで新規クラスターを作成し、パッチの代わりにそのバージョンへのローリングアップグレードを実行します。

4.1. Data Grid サーバーのパッチ

Data Grid サーバーのパッチは、問題を修正し、新機能を追加するために $RHDG_HOME ディレクトリーに適用できるアーティファクトが含まれる .zip アーカイブです。

また、パッチはサーバーインストールを変更する Data Grid のルールセットも提供します。パッチを適用すると、Data Grid は、ターゲットバージョンに必要かどうかに応じて、一部のファイルを上書きし、他のファイルを削除します。

ただし、Data Grid は、パッチの適用時に作成または変更した設定ファイルに変更を加えません。サーバーパッチはカスタム設定やデータを変更または置き換えしません。

4.2. サーバーパッチのダウンロード

Data Grid サーバーに適用できるパッチをダウンロードします。

手順

  1. Red Hat カスタマーポータルにログインします。
  2. ソフトウェアのダウンロードセクションから適切な Data Grid サーバーパッチをダウンロードします。
  3. ターミナルウィンドウを開き、$RHDG_HOME に移動します。
  4. CLI を起動します。

    $ bin/cli.sh
    [disconnected]>
  5. ダウンロードしたパッチファイルを記述します。

    [disconnected]> patch describe /path/to/redhat-datagrid-$version-server-patch.zip
    Red Hat Data Grid patch target=$target_version source=$source_version created=$timestamp
    • $target_version は、サーバーにパッチをインストールする際に適用される Data Grid バージョンです。
    • $source_version は、パッチをインストールできる 1 つ以上の Data Grid サーバーバージョンです。

検証

チェックサムを使用して、ダウンロードの整合性を確認します。

  1. ダウンロードしたパッチを引数として指定して、md5sum または sha256sum コマンドを実行します。以下に例を示します。

    $ sha256sum redhat-datagrid-$version-server-patch.zip
  2. Data Grid Software Details ページの MD5 または SHA-256 チェックサム値と比較します。

4.3. サーバーパッチの作成

既存のサーバーインストールから Data Grid サーバーのパッチを作成できます。

8.0.1 から始まる Data Grid サーバーのパッチを作成できます。8.0 GA サーバーを 8.0.1 でパッチできます。ただし、8.0.1 以上のサーバーで 7.3.x 以上のサーバーにパッチを適用することはできません。

また、Data Grid サーバーバージョンをアップグレードまたはダウングレードするパッチを作成することもできます。たとえば、バージョン 8.0.1 からパッチを作成し、これを使用してバージョン 8.0 GA をアップグレードしたり、新しいバージョンをダウングレードしたりできます。

重要

Red Hat は、Red Hat カスタマーポータルからダウンロードしたパッチのみが適用されたサーバーのデプロイメントをサポートしています。Red Hat は、ユーザーが作成したサーバーパッチをサポートしません。

手順

  1. 作成するパッチのターゲットバージョンがある Data Grid サーバーインストールの $RHDG_HOME に移動します。
  2. CLI を起動します。

    $ bin/cli.sh
    [disconnected]>
  3. patch create コマンドを使用してパッチアーカイブを生成し、パッチを記述する意味のある修飾子と共に -q オプションを追加します。

    [disconnected]> patch create -q "this is my test patch" path/to/mypatch.zip \
    path/to/target/server/home path/to/source/server/home

    上記のコマンドにより、指定されたディレクトリーに .zip アーカイブが生成されます。パスはターゲットサーバーの $RHDG_HOME に対して相対的なパスです。

    ヒント

    複数の異なる Data Grid バージョンに単一のパッチを作成します。以下に例を示します。

    [disconnected]> patch create -q "this is my test patch" path/to/mypatch.zip \
    path/to/target/server/home \
    path/to/source/server1/home path/to/source/server2/home

    server1 および server2 は、mypatch.zip をインストールできる Data Grid のバージョンに置き換えます。

  4. 生成されたパッチアーカイブを記述します。

    [disconnected]> patch describe path/to/mypatch.zip
    
    Red Hat Data Grid patch target=$target_version(my test patch)  source=$source_version created=$timestamp
    • $target_version は、パッチが作成された Data Grid サーバーバージョンです。
    • $source_version はパッチを適用できる 1 つ以上の Data Grid サーバーバージョンです。

      $source_version のみに一致する Data Grid サーバーにパッチを適用できます。他のバージョンにパッチを適用しようとすると、以下の例外が発生します。

      java.lang.IllegalStateException: The supplied patch cannot be applied to `$source_version`

4.4. サーバーパッチのインストール

Data Grid サーバーにパッチを適用して、既存のバージョンをアップグレードまたはダウングレードします。

前提条件

  • ターゲットバージョンのサーバーパッチをダウンロードします。

手順

  1. パッチを適用する Data Grid サーバーの $RHDG_HOME に移動します。
  2. サーバーを実行している場合は停止します。

    注記

    実行中にサーバーにパッチを適用すると、バージョンの変更は再起動後に有効になります。サーバーを停止したくない場合は、ターゲットバージョンで新規クラスターを作成し、パッチの代わりにそのバージョンへのローリングアップグレードを実行します。

  3. CLI を起動します。

    $ bin/cli.sh
    [disconnected]>
  4. パッチをインストールします。

    [disconnected]> patch install path/to/patch.zip
    
    Red Hat Data Grid patch target=$target_version source=$source_version \
    created=$timestamp installed=$timestamp
    • $target_version パッチがインストールされている Data Grid バージョンを表示します。
    • $source_version パッチをインストールする前の Data Grid バージョンを表示します。
  5. サーバーを起動して、パッチがインストールされていることを確認します。

    $ bin/server.sh
    ...
    ISPN080001: Red Hat Data Grid Server $version

    パッチが正常にインストールされた場合、 $version$target_version と一致します。

ヒント

--server オプションを使用して、別の $RHDG_HOME ディレクトリーにパッチをインストールします。以下に例を示します。

[disconnected]> patch install path/to/patch.zip --server=path/to/server/home

4.5. サーバーパッチのロールバック

パッチをロールバックし、以前のバージョンの Data Grid を復元して、Data Grid サーバーからパッチを削除します。

重要

サーバーに複数のパッチがインストールされている場合は、最後にインストールされたパッチのみをロールバックできます。

パッチをロールバックしても、Data Grid サーバーに加えた設定変更は元に戻りません。パッチをロールバックする前に、設定がロールバックするバージョンと互換性があることを確認する必要があります。

手順

  1. ロールバックする Data Grid サーバーインストールの $RHDG_HOME に移動します。
  2. サーバーを実行している場合は停止します。
  3. CLI を起動します。

    $ bin/cli.sh
    [disconnected]>
  4. インストールされたパッチを一覧表示します。

    [disconnected]> patch ls
    
    Red Hat Data Grid patch target=$target_version source=$source_version
    created=$timestamp installed=$timestamp
    • $target_version は、パッチの適用後の Data Grid サーバーバージョンです。
    • $source_version は、パッチが適用される前の Data Grid サーバーのバージョンです。パッチをロールバックすると、サーバーがこのバージョンに復元されます。
  5. 最後にインストールされたパッチをロールバックします。

    [disconnected]> patch rollback
  6. CLI を終了します。

    [disconnected]> quit
  7. サーバーを起動して、パッチが直前のバージョンにロールバックされていることを確認します。

    $ bin/server.sh
    ...
    ISPN080001: Data Grid Server $version

    パッチが正常にロールバックされた場合、 $version$source_version と一致します。

ヒント

--server オプションを使用して、別の $RHDG_HOME ディレクトリーでパッチをロールバックします。以下に例を示します。

[disconnected]> patch rollback --server=path/to/server/home

第5章 キャッシュストア間のデータ移行

Data Grid は、キャッシュストア間で永続化されたデータを移行するために Java ユーティリティーを提供します。

Data Grid をアップグレードする場合は、メジャーバージョン間の機能的な違いにより、キャッシュストア間の後方互換性は許可されません。StoreMigrator を使用して、ターゲットバージョンとの互換性を持つようににデータを変換できます。

たとえば、Data Grid 8.0 へのアップグレードにより、デフォルトのマーシャラーが Protostream に変更します。以前の Data Grid バージョンでは、キャッシュストアはマーシャリングの変更と互換性のないバイナリー形式を使用します。つまり、Data Grid 8.0 はこれまでの Data Grid バージョンを持つキャッシュストアから読み取ることができません。

その他の場合、Data Grid は JDBC Mixed や Binary ストアなどのキャッシュストア実装を非推奨または削除します。このような場合に StoreMigrator を使用して、異なるキャッシュストア実装を変換します。

5.1. キャッシュストアの移行

Data Grid は、最新の Data Grid キャッシュストア実装のデータを再作成する StoreMigrator.java ユーティリティーを提供します。

StoreMigrator 以前のバージョンの Data Grid のキャッシュストアをソースとして取り、キャッシュストア実装をターゲットとして使用します。

StoreMigrator の実行時、EmbeddedCacheManager インターフェースを使用して定義するキャッシュストアタイプでターゲットキャッシュを作成します。次に StoreMigrator は、エントリーをソースストアからメモリーにロードし、ターゲットキャッシュに配置します。

また、StoreMigrator はあるタイプのキャッシュストアから別のタイプのキャッシュストアにデータを移行することもできます。たとえば、JDBC の String ベースのキャッシュストアから単一ファイルキャッシュストアに移行できます。

重要

StoreMigrator は、データをセグメント化されたキャッシュストアから以下に移行できません。

  • セグメント化されていないキャッシュストア。
  • 異なる数のセグメントがあるセグメント化されたキャッシュストア。

5.2. ストアマイグレーターの取得

StoreMigrator は、Data Grid ツールライブラリー infinispan-tools の一部として利用でき、Maven リポジトリーに含まれています。

手順

  • StoreMigratorpom.xml を以下のように設定します。

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
        <groupId>org.infinispan.example</groupId>
        <artifactId>jdbc-migrator-example</artifactId>
        <version>1.0-SNAPSHOT</version>
    
        <dependencies>
          <dependency>
            <groupId>org.infinispan</groupId>
            <artifactId>infinispan-tools</artifactId>
          </dependency>
          <!-- Additional dependencies -->
        </dependencies>
    
        <build>
          <plugins>
            <plugin>
              <groupId>org.codehaus.mojo</groupId>
              <artifactId>exec-maven-plugin</artifactId>
              <version>1.2.1</version>
              <executions>
                <execution>
                  <goals>
                    <goal>java</goal>
                  </goals>
                </execution>
              </executions>
              <configuration>
                <mainClass>org.infinispan.tools.store.migrator.StoreMigrator</mainClass>
                <arguments>
                  <argument>path/to/migrator.properties</argument>
                </arguments>
              </configuration>
            </plugin>
          </plugins>
        </build>
    </project>

5.3. ストアマイグレーターの設定

migrator.properties ファイルにソースおよびターゲットキャッシュストアのプロパティーを設定します。

手順

  1. migrator.properties ファイルを作成します。
  2. migrator.properties にソースキャッシュストアを設定します。

    1. 以下の例のように、すべての設定プロパティーの最初に source. を追加します。

      source.type=SOFT_INDEX_FILE_STORE
      source.cache_name=myCache
      source.location=/path/to/source/sifs
  3. migrator.properties でターゲットキャッシュストアを設定します。

    1. 以下の例のように、すべての設定プロパティーの最初に target. を追加します。

      target.type=SINGLE_FILE_STORE
      target.cache_name=myCache
      target.location=/path/to/target/sfs.dat

5.3.1. ストアマイグレータープロパティー

StoreMigrator プロパティーでソースおよびターゲットキャッシュストアを設定します。

表5.1 キャッシュストアタイププロパティー

プロパティー説明必須/任意

type

ソースまたはターゲットのキャッシュストアタイプを指定します。

.type=JDBC_STRING

.type=JDBC_BINARY

.type=JDBC_MIXED

.type=LEVELDB

.type=ROCKSDB

.type=SINGLE_FILE_STORE

.type=SOFT_INDEX_FILE_STORE

.type=JDBC_MIXED

必須

表5.2 共通プロパティー

プロパティー説明値の例必須/任意

cache_name

ストアがサポートするキャッシュの名前。

.cache_name=myCache

必須

segment_count

セグメンテーションを使用できるターゲットキャッシュストアのセグメント数を指定します。

セグメント数は Data Grid 設定の clustering.hash.numSegments と一致する必要があります。

つまり、キャッシュストアのセグメント数は、対応するキャッシュのセグメント数と一致する必要があります。セグメントの数が同じでない場合、Data Grid はキャッシュストアからデータを読み取れません。

.segment_count=256

任意

表5.3 JDBC プロパティー

プロパティー説明必須/任意

dialect

基礎となるデータベースの方言を指定します。

必須

version

ソースキャッシュストアのマーシャラーバージョンを指定します。以下の値のいずれかを設定します。

* Data Grid 7.2.x の場合は 8

* Data Grid 7.3.x の場合は 9

* Data Grid 8.x は 10

ソースストアにのみ必要です。

例: source.version=9

marshaller.class

カスタムのマーシャラークラスを指定します。

カスタムマーシャラーを使用する場合に必須です。

marshaller.externalizers

[id]:<Externalizer class> の形式で読み込むカスタム AdvancedExternalizer 実装のコンマ区切りリストを指定します。

任意

connection_pool.connection_url

JDBC 接続 URL を指定します。

必須

connection_pool.driver_class

JDBC ドライバーのクラスを指定します。

必須

connection_pool.username

データベースのユーザー名を指定します。

必須

connection_pool.password

データベースユーザー名のパスワードを指定します。

必須

db.major_version

データベースのメジャーバージョンを設定します。

任意

db.minor_version

データベースのマイナーバージョンを設定します。

任意

db.disable_upsert

データベースの upsert を無効にします。

任意

db.disable_indexing

テーブルインデックスが作成されるかどうかを指定します。

任意

table.string.table_name_prefix

テーブル名の追加の接頭辞を指定します。

任意

table.string.<id|data|timestamp>.name

列名を指定します。

必須

table.string.<id|data|timestamp>.type

列タイプを指定します。

必須

key_to_string_mapper

TwoWayKey2StringMapper クラスを指定します。

任意

注記

古い Data Grid バージョンの Binary キャッシュストアから移行するには、以下のプロパティーで table.string.*table.binary.\* に変更します。

  • source.table.binary.table_name_prefix
  • source.table.binary.<id\|data\|timestamp>.name
  • source.table.binary.<id\|data\|timestamp>.type
# Example configuration for migrating to a JDBC String-Based cache store
target.type=STRING
target.cache_name=myCache
target.dialect=POSTGRES
target.marshaller.class=org.example.CustomMarshaller
target.marshaller.externalizers=25:Externalizer1,org.example.Externalizer2
target.connection_pool.connection_url=jdbc:postgresql:postgres
target.connection_pool.driver_class=org.postrgesql.Driver
target.connection_pool.username=postgres
target.connection_pool.password=redhat
target.db.major_version=9
target.db.minor_version=5
target.db.disable_upsert=false
target.db.disable_indexing=false
target.table.string.table_name_prefix=tablePrefix
target.table.string.id.name=id_column
target.table.string.data.name=datum_column
target.table.string.timestamp.name=timestamp_column
target.table.string.id.type=VARCHAR
target.table.string.data.type=bytea
target.table.string.timestamp.type=BIGINT
target.key_to_string_mapper=org.infinispan.persistence.keymappers. DefaultTwoWayKey2StringMapper

表5.4 RocksDB プロパティー

プロパティー説明必須/任意

location

データベースディレクトリーを設定します。

必須

compression

使用する圧縮タイプを指定します。

任意

# Example configuration for migrating from a RocksDB cache store.
source.type=ROCKSDB
source.cache_name=myCache
source.location=/path/to/rocksdb/database
source.compression=SNAPPY

表5.5 SingleFileStore プロパティー

プロパティー説明必須/任意

location

キャッシュストア .dat ファイルが含まれるディレクトリーを設定します。

必須

# Example configuration for migrating to a Single File cache store.
target.type=SINGLE_FILE_STORE
target.cache_name=myCache
target.location=/path/to/sfs.dat

表5.6 SoftIndexFileStore プロパティー

プロパティー説明

必須/任意

location

データベースディレクトリーを設定します。

必須

index_location

データベースインデックスディレクトリーを設定します。

# Example configuration for migrating to a Soft-Index File cache store.
target.type=SOFT_INDEX_FILE_STORE
target.cache_name=myCache
target.location=path/to/sifs/database
target.location=path/to/sifs/index

5.4. キャッシュストアの移行

StoreMigrator を実行して、データをあるキャッシュストアから別のキャッシュストアに移行します。

前提条件

  • infinispan-tools.jar を取得します。
  • ソースおよびターゲットキャッシュストアを設定する migrator.properties ファイルを作成します。

手順

  • ソースから infinispan-tools.jar をビルドする場合は、以下を実行します。

    1. JDBC ドライバーなどのソースおよびターゲットデータベースの infinispan-tools.jar および依存関係をクラスパスに追加します。
    2. migrator.properties ファイルを StoreMigrator の引数として指定します。
  • Maven リポジトリーから infinispan-tools.jar をプルする場合は、以下のコマンドを実行します。

    mvn exec:java

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.