2 既知の問題とその回避策

リリース時点での既知の問題について説明します。

この章の内容は次のとおりです。

2.1 アクティブな永続性を使用する場合のパーティション数の変更

アクティブ永続性を使用している場合は、パーティション数を変更できません。サービスのパーティション数を変更すると、サービスの再起動時に、アクティブなすべてのデータが永続性のごみ箱に移動するため、元のパーティション数のリストア後にリカバリする必要があります。永続化されるデータは、同じパーティション数で実行されているサービスにのみリカバリできます。

アクティブ永続性が使用されている場合は、パーティション数が変更されていないことを確認します。パーティション数が変更されると、サービスの起動時に、次のようなメッセージが表示されます。

<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1):
Failed to recover partition 0 from SafeBerkeleyDBStore(...); partition-count
mismatch 501(persisted) != 277(service); reinstate persistent store from
trash once validation errors have been resolved

このメッセージは、パーティション数の変更がサポートされておらず、現在アクティブなデータがごみ箱ディレクトリにコピーされたことを示しています。データをリカバリするには、次の手順を実行します。

クラスタ全体を停止します。
各クラスタ・メンバーで影響を受けたクラスタとサービスで現在アクティブなディレクトリの内容を削除します。
アクティブなディレクトリへのサービスごとに、ごみ箱ディレクトリの内容を(再帰的に)コピーします。
パーティション数を元の値にリストアします。
クラスタを再起動します。

2.2 スナップショット・リカバリ時のフェデレーテッド・キャッシュ内のデータの不整合

フェデレーテッド・キャッシュとキャッシュ永続化を同時に使用すると、データの整合性が取れなくなるという既知の問題があります。現在、リカバリされたサービスのスナップショットはフェデレーテッド・クラスタに伝播されません。元々のクラスタ上のキャッシュされたデータはリカバリされますが、宛先クラスタ上のキャッシュされたデータにはリカバリの前にあった、キャッシュされたデータが含まれたままになることがあります。この事例については、次のパッチ・リリースでサポートされる予定です。

2.3 ジェネリクスの影響

ランタイム・タイプ・チェックはフェデレーション内のクラスタ間で実行されないため、フェデレーションをまたがるフェデレーテッド・キャッシュは必ず同じタイプを使用するように構成する必要があります。
ランタイム・タイプ・チェックは実行されないため、リカバリ可能キャッシュは再起動時に同じタイプを使用するように必ず構成する必要があります。

2.4 JVisualVMプラグインのサポート

Coherence JvisualVMプラグインは、Coherence 3.7.1.X以上でサポートされます。プラグインを使用した古いクラスタへの接続はサポートされません。