この章の内容は次のとおりです。
PersistenceManagerMBean
MBeanを使用して手動で管理する必要がある、キャッシュ・サービスの内容のバックアップです。PersistenceManagerMBean
MBeanには、アプリケーションが永続性操作の監視に使用できる一連の通知タイプが含まれます。親トピック: 高度な管理
永続性モード
永続性は次の2つのモードで動作できます。
オンデマンド永続性モード – キャッシュ・サービスは手動で永続化され、リクエスト時に永続性コーディネータを使用してリカバリされます。永続性コーディネータは、キャッシュ・サービスのスナップショットの作成、アーカイブおよびリカバリの操作を提供するMBeanインタフェースとして公開されています。
アクティブ永続性モード – このモードでは、キャッシュの内容はすべてのミューテーションで自動的に永続化され、クラスタ/サービスの起動時に自動的にリカバリされます。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、オンデマンド・スナップショットを実行できます。
ディスク・ベースの永続記憶域
永続性では、データベースを永続性ストアに使用します。このデータベースは、パーティション・サービスのバッキング・マップ・パーティションの格納に使用されます。データベース・ファイルの場所は、各キャッシュ・サーバーのローカル・ディスク、もしくはストレージ・エリア・ネットワーク(SAN)またはネットワーク・ファイル・システム(NFS)の共有ディスクに格納できます。「SAN/NFS永続記憶域の計画」を参照してください。
注意:
データベース・ファイルは手動で編集しないでください。データベース・ファイルを編集すると、永続性エラーが発生する場合があります。
ローカル・ディスク・オプションにより、各クラスタ・メンバーが所有するサービス・パーティションの永続化データに各メンバーがアクセスできます。永続性は、キャッシュ・サーバー・ホスト・アドレスのリストを使用して、すべての記憶域メンバー間で調整されます。アドレス・リストにより、永続化されたすべてのパーティションがリカバリ中に検出されます。ローカル・ディスク記憶域では、高スループットと低遅延の記憶域メカニズムを提供しますが、パーティション・サービスでは、メモリー内バックアップ(ゼロより大きいbackup-count
値)を利用して、マシンの安全性を保つ必要があります。
共有ディスク・オプションとアクティブ永続性モードの組合せにより、各クラスタ・メンバーがすべてのサービス・パーティションの永続化データにアクセスできます。共有ディスクを使用する利点は、記憶域が有効なすべてのメンバーが共有記憶域からパーティションをリカバリできるため、マシンの安全性を維持するために、パーティション・サービスでメモリー内バックアップ(backup-count
値がゼロ以上)が不要になることです。メモリー内バックアップを無効にすると、ノードの障害発生時にリカバリの遅延を高める犠牲を払って、クラスタのキャッシュ容量が増加します。一般に、共有ディスクを使用すると、スループットと遅延が影響を受ける場合があるため、テストと監視を行うようにしてください。
注意:
サービスstatusHA統計では、メモリー内バックアップの置換えとして永続性が使用されている場合でも、バックアップ回数がゼロに設定されていると、ENDAGERED
ステータスを示します。
ローカル・ディスクと共有ディスクの両方のアプローチでは、リカバリの開始前に永続性操作を実行するため必要な、クラスタ・メンバーの数を制御するクォーラム・ポリシーを利用できます。クォーラム・ポリシーにより、データ・リカバリが開始される前に、クラスタの起動の時間を考慮できます。
永続性構成
永続性は、Coherence構成ファイルを使用して宣言的に構成されるため、アプリケーション・コードを変更する必要はありません。オペレーション・オーバーライド・ファイルは、デフォルトの設定が受入れ可能でない場合は、基礎となる永続性実装の構成に使用されます。キャッシュ構成ファイルは、分散キャッシュでの永続性プロパティの設定に使用されます。
管理および監視
永続性は、MBean属性および操作を使用して監視および管理されます。スナップショットの作成やアーカイブなどの永続性操作は、PersistenceManagerMBean
MBeanを使用して実行されます。永続性の属性は、サービスの属性の一部に含まれ、ServiceMBean
MBeanを使用して表示できます。
永続性の属性と統計は、persistence
およびpersistence-details
レポートで集計されます。永続性の統計は、Java VisualVMプラグインでも集計されます。どちらのツールでも、発生する可能性のあるリソースおよびパフォーマンス問題をトラブルシューティングできます。
PartitionAssignment
MBeanのStrategyName
属性をチェックして、分散キャッシュに現在構成されている戦略を確認します。Oracle Coherenceでのアプリケーションの開発のパーティション分散戦略の変更を参照してください。キャッシュをオンデマンドで永続化する手順:
キャッシュをアクティブに永続化する手順:
PersistenceManagerMBean
MBeanを使用して手動で管理する必要がある、キャッシュ・サービスの内容のバックアップです。注意:
この項の手順は、JDK Java VisualVMツール用VisualVM-MBeansプラグインを使用して作成されています。Coherence-Java VisualVMプラグインをスナップショット操作の実行に使用することもできます。
この項には次のトピックが含まれます:
スナップショットを作成すると、オペレーション・オーバーライド構成ファイルの永続性環境定義内で指定したスナップショット・ディレクトリに、キャッシュ・サービスの内容が書き込まれます。スナップショットは、実行中のサービス(リクエストを受信および処理中のサービス)または停止中のサービス上に作成できます。前者はパーティション・レベルの一貫性を提供し、後者はグローバルな一貫性を提供します。
デフォルトで、スナップショット操作はパーティション・レベルの一貫性を想定します。グローバルな一貫性を実現するには、サービスへのリクエストがブロックされるようにサービスを明示的に停止する必要があります。
パーティション整合性のスナップショット
次のようにして、パーティション整合性のスナップショットを作成します。
MBeanのリストから、「永続性」ノードを選択して展開します。
スナップショットを作成するサービスを展開し、PersistenceCoordinatorを選択します。
「操作」タブから、createSnapshot操作のフィールドにスナップショットの名前を入力します。
createSnapshotをクリックします。
グローバルな整合性のスナップショット
次のようにして、グローバルな整合性のスナップショットを作成します。
MBeanのリストから、ClusterMBeanノードを選択します。
「操作」タブで、suspendService操作のフィールドに停止するサービスの名前を入力します。
suspendServiceをクリックします。
MBeanのリストから、「永続性」ノードを選択して展開します。
スナップショットを作成するサービス(停止中)を展開し、PersistenceCoordinatorを選択します。
「操作」タブから、createSnapshot操作のフィールドにスナップショットの名前を入力します。
createSnapshotをクリックします。
注意:
スナップショットJMX通知をサブスクライブすることで、操作の完了時にアプリケーションに通知することができます。「永続性JMX通知のサブスクライブ」を参照してください。
MBeanのリストから、ClusterMBeanノードを選択します。
「操作」タブで、resumeService操作のフィールドに再開するサービスの名前を入力します。
resumeServiceをクリックします。
スナップショットをリカバリすると、キャッシュ・サービスの内容がスナップショットからリストアされます。
注意:
永続性スナップショットからリカバリしたCoherenceサービスはフェデレーテッド・クラスタに伝播されません。元のクラスタ上のデータはリカバリされますが、宛先クラスタ上のキャッシュされたデータは影響を受けず、リカバリの前にあったデータが含まれたままになることがあります。スナップショット・データを伝播するには、スナップショット・リカバリの完了後にフェデレーションReplicateAll
の操作が必要です。ReplicateAll
操作は、FederationManagerMBean
MBeanで使用可能です。Oracle Coherenceの管理のFederationManagerMBean操作を参照してください。
スナップショットをリカバリする手順:
PersistenceManagerMBean
MBeanを使用して実行されます。アーカイブの作成はスナップショットよりも低速ですが、スナップショットと異なり、アーカイブは移植可能です。この項には次のトピックが含まれます:
スナップショットがアーカイブされるディレクトリは、ディレクトリ・スナップショット・アーカイバ定義を使用して、オペレーション・オーバーライド・ファイルに定義されます。必要に応じて、複数の定義を作成できます。
注意:
アーカイブ・ディレクトリの場所と名前は、すべてのメンバー間で同一である必要があります。アーカイブ・ディレクトリの場所は、すべてのメンバーからアクセス可能な共有ディレクトリである必要があります。
スナップショット・アーカイバ・ディレクトリを定義するには、<directory-archiver>
要素を<snapshot-archivers>
要素内に含めます。<archiver-directory>
要素を使用して、スナップショット・アーカイブが格納されるディレクトリを入力します。id
属性を使用して、一意の名前を定義に指定します。次に例を示します。
<snapshot-archivers> <directory-archiver id="archiver1"> <archive-directory>/mydirectory</archive-directory> </directory-archiver> </snapshot-archivers>
ディレクトリ・スナップショット・アーカイバを指定するには、分散スキーム内の永続性定義を編集して、オペレーション・オーバーライド構成ファイルに定義されるディレクトリ・スナップショット・アーカイバの名前を含めます。次に例を示します。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <persistence> <archiver>archiver1</archiver> </persistence> <autostart>true</autostart> </distributed-scheme>
スナップショットのアーカイブは、PersistenceManagerMBean
MBeanを使用して手動で管理されます。MBeanには、スナップショットをアーカイブおよび取得するための非同期操作が含まれ、アーカイブをリストおよび削除するための操作も含まれます。
この項には次のトピックが含まれます:
アーカイブされたスナップショットを取得する手順:
アーカイブされたスナップショットを削除する手順:
アーカイブされた現在のスナップショットのリストを取得する手順:
listArchivedSnapshots
操作をクリックします。アーカイブされたスナップショットのリストが返されます。アーカイブされたスナップショットの個別のストア、または一部をリストする手順:
デフォルトのディレクトリ・スナップショット・アーカイバ実装以外の方法を使用して、カスタム・スナップショット・アーカイバ実装を作成して、必要に応じてアーカイブを格納できます。たとえば、アーカイブを外部データベースに永続化し、Webサービスを使用してアーカイブをストレージ・エリア・ネットワークに格納したり、アーカイブをコンテンツ・リポジトリに格納したりできます。
この項には次のトピックが含まれます:
カスタム・スナップショット・アーカイバ実装を作成するには、AbstractSnapshotArchiver
クラスを拡張するクラスを作成します。
カスタム・スナップショット・アーカイバ定義を作成するには、<custom-archiver>
要素を<snapshot-archivers>
要素内に含め、id
属性を使用して、一意の名前を定義に指定します。実装クラスの完全修飾名を含む<custom-archiver>
要素内に<class-name>
要素を追加します。次の例では、MyCustomArchiver
という名前のカスタム実装の定義を作成します。
<snapshot-archivers> <custom-archiver id="custom1"> <class-name>package.MyCustomArchiver</class-name> </custom-archiver> </snapshot-archivers>
アーカイバ・インスタンスの作成を処理するファクトリ・クラスが実装で使用されている場合は、<class-factory-name>
要素を使用します。<method-name>
要素を使用して、オブジェクトのインスタンス化を実行するファクトリ・クラスに静的ファクトリ・メソッドを指定します。次の例では、MyArchiverFactory
クラスのgetArchiver
メソッドを使用して、スナップショット・アーカイバ・インスタンスを取得します。
<snapshot-archivers> <custom-archiver id="custom1"> <class-factory-name>package.MyArchiverFactory</class-factory-name> <method-name>getArchiver</method-name> </custom-archiver> </snapshot-archivers>
実装に必要な初期化パラメータはすべて、<init-params>
要素を使用して指定できます。次の例では、UserName
パラメータをAdmin
に設定します。
<snapshot-archivers> <custom-archiver id="custom1"> <class-name>package.MyCustomArchiver</class-name> <init-params> <init-param> <param-name>UserName</param-name> <param-value>Admin</param-value> </init-param> </init-params> </custom-archiver> </snapshot-archivers>
カスタム・スナップショット・アーカイバを指定するには、分散スキーム内の永続性定義を編集して、オペレーション・オーバーライド構成ファイルに定義されるカスタム・スナップショット・アーカイバの名前を含めます。次に例を示します。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <persistence> <archiver>custom1</archiver> </persistence> <autostart>true</autostart> </distributed-scheme>
この項には次のトピックが含まれます:
アクティブ永続性は、すべてのサービスまたは特定のサービスに対して有効化できます。すべてのサービスでアクティブ永続性を有効にするには、coherence.distributed.persistence.mode
システム・プロパティをactive
に設定します。次に例を示します。
-Dcoherence.distributed.persistence.mode=active
値が指定されていない場合のデフォルト値は、on-demand
です(オンデマンドの永続性を有効にします)。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、キャッシュのスナップショットを取得できます。
特定のサービスでアクティブ永続性を有効にするには、分散スキーム定義を変更し、<environment>
要素を<persistence>
要素内に含めます。<environment>
要素の値をdefault-active
に設定します。次に例を示します。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <persistence> <environment>default-active</environment> </persistence> <autostart>true</autostart> </distributed-scheme>
値が指定されていない場合のデフォルト値は、default-on-demand
です(オンデマンドの永続性をサービスに対して有効にします)。
アクティブ永続性操作の実行中に発生する可能性のある永続性の失敗に対する、パーティション・キャッシュ・サービスのレスポンス方法を変更します。デフォルトのレスポンスは、サービスを即座に停止します。この動作は、永続性がサービスにとって重要な場合(例: キャッシュがデータ・バックアップの永続性に依存している場合)に最適です。ただし、永続性が重要でない場合は、サービスでリクエストを続行するように選択できます。
アクティブな永続化の失敗に対するサービスのレスポンスを変更するには、分散スキーム定義を編集して、<active-failure-mode>
要素を<persistence>
要素内に含め、値をstop-persistence
に設定します。値を指定しない場合は、デフォルト値(stop-service
)が自動的に使用されます。次の例では、アクティブ永続性失敗時のレスポンスをstop-persistence
に変更します。
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<active-failure-mode>stop-persistence</active-failure-mode>
</persistence>
<autostart>true</autostart>
</distributed-scheme>
アクティブ永続性を使用している場合は、パーティション数を変更できません。サービスのパーティション数を変更すると、サービスの再起動時に、アクティブなすべてのデータが永続性のごみ箱に移動するため、元のパーティション数のリストア後にリカバリする必要があります。永続化されるデータは、同じパーティション数で実行されているサービスにのみリカバリできます。
アクティブ永続性が使用されている場合は、パーティション数が変更されていないことを確認します。パーティション数が変更されると、サービスの起動時に、次のようなメッセージが表示されます。
<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つの永続性環境定義が含まれます。
default-active
– アクティブ永続性が有効な場合に使用されます。
default-on-demand
– オンデマンド永続性が有効な場合に使用されます。
オペレーション・オーバーライド・ファイルまたはシステム・プロパティは、事前定義済の永続性環境のデフォルト設定のオーバーライドに使用されます。事前定義済の永続性環境には、次の構成があります。
<persistence-environments> <persistence-environment id="default-active"> <persistence-mode>active</persistence-mode> <active-directory system-property="coherence.distributed.persistence.active.dir"> </active-directory> <snapshot-directory system-property="coherence.distributed.persistence.snapshot.dir"> </snapshot-directory> <trash-directory system-property="coherence.distributed.persistence.trash.dir"> </trash-directory> </persistence-environment> <persistence-environment-environment id="default-on-demand"> <persistence-mode>on-demand</persistence-mode> <active-directory system-property="coherence.distributed.persistence.active.dir"> </active-directory> <snapshot-directory system-property="coherence.distributed.persistence.snapshot.dir"> </snapshot-directory> <trash-directory system-property="coherence.distributed.persistence.trash.dir"> </trash-directory> </persistence-environment> </persistence-environments>
事前定義済の永続性環境では、USER_HOME
ディレクトリ内のcoherence
の名前のベース・ディレクトリを使用して、永続性ファイルを保存します。この場所には、アクティブ永続性ファイル、スナップショット永続性ファイルおよびごみ箱ファイルのディレクトリが含まれます。異なるローカル・ディレクトリまたはネットワーク上の共有ディレクトリに場所を変更できます。
注意:
永続性ディレクトリおよびファイル(meta.properties
ファイルを含む)は、手動で編集しないでください。ディレクトリおよびファイルを編集すると、永続性エラーが発生する場合があります。
永続性ファイルの事前定義済の場所を変更するには、<active-directory>
、<snapshot-directory>
および<trash-directory>
要素を含めます(各要素は、永続性ファイルが保存されるそれぞれのディレクトリに設定されています)。次の例では、事前定義済のオンデマンド永続性環境を変更し、すべてのディレクトリの場所を/persistence
ディレクトリに変更します。
<persistence-environments> <persistence-environment id="default-on-demand"> <active-directory system-property="coherence.distributed.persistence.active.dir"> /persistence/active</active-directory> <snapshot-directory system-property="coherence.distributed.persistence.snapshot.dir"> /persistence/snapshot</snapshot-directory> <trash-directory system-property="coherence.distributed.persistence.trash.dir"> /persistence</trash</trash-directory> </persistence-environment> </persistence-environments>
次のシステム・プロパティは、オペレーション・オーバーライド・ファイルを使用するかわりに、永続性ファイルの事前定義済の場所の変更に使用されます。
-Dcoherence.distributed.persistence.active.dir=/persistence/active -Dcoherence.distributed.persistence.snapshot.dir=/persistence/snapshot -Dcoherence.distributed.persistence.trash.dir=/persistence/trash
coherence.distributed.persistence.base.dir
システム・プロパティを使用して、デフォルトのディレクトリをUSER_HOME
ディレクトリから変更します。
-Dcoherence.distributed.persistence.base.dir=persistence
この項には次のトピックが含まれます:
永続性環境を定義するには、<persistence-environment>
要素が含まれる<persistence-environments>
要素を含めます。<persistence-environment>
要素には、永続性環境の構成が含まれます。id
属性を使用して環境に名前を付けます。id
属性は、分散スキーム定義から永続性環境を参照する場合に使用されます。次の例では、environment1
の名前の永続性環境を作成します。
<persistence-environments>
<persistence-environment id="enviornment1">
<persistence-mode></persistence-mode>
<active-directory></active-directory>
<snapshot-directory></snapshot-directory>
<trash-directory></trash-directory>
</persistence-environment>
</persistence-environments>
永続性環境では、オンデマンドとアクティブの2つの永続性モードをサポートしています。オンデマンド永続性では、キャッシュ・サービスの永続化およびリカバリに永続性コーディネータを使用する必要があります。アクティブ永続性では、キャッシュ・サービスを自動的に永続化およびリカバリします。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、キャッシュ・サービスを定期的に永続化できます。
永続性モードを構成するには、on-demand
またはactive
のいずれかに設定されている<persistence-mode>
要素を含めます。値が指定されていない場合のデフォルト値は、on-demand
です。次の例では、アクティブ永続性を構成します。
<persistence-environments> <persistence-environment id="enviornment1"> <persistence-mode>active</persistence-mode> <persistence-mode></persistence-mode> <active-directory></active-directory> <snapshot-directory></snapshot-directory> <trash-directory></trash-directory> </persistence-environment> </persistence-environments>
永続性環境では、キャッシュ・サービス・データをディスクに保存します。場所は必要に応じて構成可能で、ローカル・ドライブまたはネットワーク共有ドライブのいずれかにすることができます。ローカル・ドライブを構成している場合は、キャッシュ・サーバーで所有されるパーティションのみが、それぞれのローカル・ディスクに永続化されます。ネットワーク共有ドライブを構成している場合は、すべてのパーティションが同じ共有ディスクに永続化されます。
注意:
永続性ディレクトリおよびファイル(meta.properties
ファイルを含む)は、手動で編集しないでください。ディレクトリおよびファイルを編集すると、永続性エラーが発生する場合があります。
永続性がNFSマウント・ファイル・システムを使用するように構成されている場合、NFSマウントは、多くのオペレーティング・システムでデフォルトである非同期IOではなく同期IOを使用するよう構成される必要があります。非同期IOを使用すると、ファイル・システムが停止により応答しなくなった場合、データの損失を起こす可能性があります。構成の詳細は、オペレーティング・システムのmount
に関するドキュメントを参照してください。
様々なディレクトリがアクティブ、スナップショットおよびごみ箱のファイルに使用され、それぞれ名前が付けられています。最上位のディレクトリのみを指定する必要があります。永続性ディレクトリを構成するには、<active-directory>
、<snapshot-directory>
および<trash-directory>
要素を含めます(各要素は、永続性ファイルが保存されるディレクトリ・パスに設定されています)。値が指定されていない場合のデフォルト値は、USER_HOME
ディレクトリです。次の例では、すべての永続性ファイルに/env1
ディレクトリを構成します。
<persistence-environments> <persistence-environment id="enviornment1"> <persistence-mode>on-demand</persistence-mode> <active-directory>/env1</active-directory> <snapshot-directory>/env1</snapshot-directory> <trash-directory>/env1</trash-directory> </persistence-environment> </persistence-environments>
キャッシュ・サービスで使用される永続化環境を変更するには、分散スキーム定義を変更し、<environment>
要素を<persistence>
要素内に含めます。<environment>
要素の値を、オペレーション・オーバーライド構成ファイルに定義される永続性環境の名前に設定します。次に例を示します。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <persistence> <environment>environment1</environment> </persistence> <autostart>true</autostart> </distributed-scheme>
Coherenceにはクオーラム・ポリシーが含まれ、これを使用してリカバリが進行するように適切な数のクラスタ記憶域メンバーを有効化します。
この項には次のトピックが含まれます:
パーティション化されたキャッシュ・リカバリ・クォーラムは、永続性リカバリの開始前に使用可能にする必要があるクラスタ記憶域メンバーの数を定義するために使用します。クォーラムを使用することで、クラスタの起動の時間を考慮し、少なすぎる記憶域メンバーが過負荷になることなく、または孤立したパーティションが間違って削除されることなく、パーティションを正常にリカバリできます。
リカバリ・クォーラムが満たされない場合、永続性リカバリは続行されず、サービスまたはクラスタがブロックされているように見えることがあります。このシナリオをチェックするには、ServiceMBean
MBeanのQuorumPolicy
属性を表示し、recover
がアクションのリストに含まれているかどうかを確認します。クラスタの起動後にデータがリカバリされていない場合は、次のログ・メッセージが表示され(新しいサービス・メンバーが起動するたび)、クォーラムが満たされていないことが示されます。
<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1): Action recover disallowed; all-disallowed-actions: recover(4)
クォーラムが満たされると、次のメッセージが表示されます。
<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1): All actions allowed
アクティブ永続性の場合、リカバリ・クォーラムはデフォルトで有効になり、動的リカバリ・クォーラム・ポリシーが自動的に使用されます。動的リカバリ・クォーラム・ポリシーの使用を参照してください。
パーティション化されたキャッシュ・クォーラムの詳細は、Oracle Coherenceでのアプリケーションの開発のパーティション化されたキャッシュ・クォーラムの使用を参照してください。
永続性のためにリカバリ・クォーラムを構成するには、分散スキーム定義を変更し、<recover-quorum>
要素を<partitioned-quorum-policy-scheme>
要素内に含めます。<recover-quorum>
要素値を、リカバリの開始前に使用可能にする必要がある記憶域メンバーの数に設定します。次に例を示します。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <partitioned-quorum-policy-scheme> <recover-quorum>2</recover-quorum> </partitioned-quorum-policy-scheme> <autostart>true</autostart> </distributed-scheme>
注意:
アクティブ永続性モードでは、<recover-quorum>
要素に0
を設定すると、動的リカバリ・クォーラム・ポリシーが有効になります。動的リカバリ・クォーラム・ポリシーの使用を参照してください。
共有ディスク・シナリオでは、すべてのパーティションが永続化され、単一の場所からリカバリされます。ただし、ローカル・ディスクのシナリオでは、各記憶域メンバーがローカル・ディスクからパーティションをリカバリします。ローカル・ディスク・ベースの記憶域でリカバリ・クォーラムを使用している場合は、永続性記憶域から孤立パーティションをリカバリするか、空のパーティションを割り当てる(永続性記憶域が使用できない、または失われている場合)必要があるクラスタに、記憶域が有効なホストのリストを定義する必要があります。
注意:
リカバリ・ホストを指定して、すべての永続化状態が使用可能になる前にリカバリが開始されないようにする必要があります。
アドレスのリストを定義するには、オペレーション・オーバーライド構成ファイルを編集し、<address>
要素を使用してそれぞれ定義されたアドレスのリストが含まれる<address-provider>
要素を含めます。id
要素を使用して、アドレス・プロバイダ・リストに名前を付けます。id
属性は、分散スキーム定義からリストを参照する場合に使用されます。次の例では、2つのメンバー・アドレスが含まれ、persistence_hosts
という名前のアドレス・プロバイダ・リストを作成します。
<address-providers> <address-provider id="persistence-host-list"> <address>HOST_NAME</address> <address>HOST_NAME</address> </address-provider> </address-providers>
アドレス・プロバイダ・リストを参照するには、分散スキーム定義を変更し、<recovery-hosts>
要素を<partitioned-quorum-policy-scheme>
要素内に含め、値をアドレス・プロバイダ・リストの名前に設定します。次に例を示します。
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<recover-quorum>2</recover-quorum>
<recovery-hosts>persistence-hosts</recovery-hosts>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>
動的リカバリ・クォーラム・ポリシーはアクティブ永続性で使用され、事前定義されたアルゴリズムに基づいて永続性リカバリ・クォーラムが自動的に構成されます。動的リカバリ・クォーラム・ポリシーはアクティブ永続性モードのデフォルトのクォーラム・ポリシーであり、明示的に有効にする必要はありません。ポリシーは、<recover-quorum>
値が指定されていない場合、または値に0
が設定されている場合に自動的に使用されます。次の例は、動的リカバリ・クォーラム・ポリシーを明示的に有効にする方法を説明のために示しています。
<distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>Service1</service-name> <backing-map-scheme> <local-scheme/> </backing-map-scheme> <partitioned-quorum-policy-scheme> <recover-quorum>0</recover-quorum> </partitioned-quorum-policy-scheme> <autostart>true</autostart> </distributed-scheme>
注意:
動的リカバリ・クォーラム・ポリシーを使用する場合は、<recovery-hosts>
要素を<partitioned-quorum-policy-scheme>
要素内で使用しないでください。他のすべてのクォーラム・ポリシー(たとえば、読取りクォーラム・ポリシー)は引き続き有効です。
動的リカバリ・アルゴリズムの理解
動的リカバリ・クォーラム・ポリシーは、メンバーがクラスタに参加して、パーティションの配分が安定化するたびにクラスタのメンバーシップ情報が記録されることによって機能します。メンバーシップは、サービスが一時停止されておらず、他のすべてのパーティション化されたキャッシュ・アクション(読取り、書込み、復元、分散など)がポリシーによって許可される場合にのみ記録されます。クラスタのメンバーシップが変更されるたびに、PersistenceManagerMBean
MBeanのサブスクライバにJMX通知が送信されます。
リカバリ・シナリオ中に、サービスは次の条件が満たされる場合にのみデータを回復します。
すべてのパーティションの永続的なイメージにクラスタのメンバーがアクセスできる
ストレージが有効にされたノードの数が、最後に記録されたメンバーシップの少なくとも2/3以上である
永続性データがローカル・ディスクに格納されている(共有されておらず、すべてのホストが表示できる)場合は、最後にメンバーシップが記録されたときの各ホストのメンバー数の少なくとも2/3以上である
いずれかの条件が満たされない場合、パーティション化されたキャッシュ・サービスはクライアント側のリクエストをブロックします。ただし、欠落しているパーティションがあるため完全なリカバリは不可能であると管理者が判断した場合、またはクォーラムによって予期されるサーバー数を開始する必要がないと管理者が判断した場合は、PersistenceManagerMBean
MBeanのforceRecovery
操作を呼び出すことによって強制できます。
リカバリ・アルゴリズムは、com.tangosol.net.ConfigurableQuorumPolicy.PartitionedCacheQuorumPolicy
クラスを拡張するカスタム・クォーラム・ポリシー・クラスを使用することによってオーバーライドできます。ハードコーディングされている2/3の比率を変更するには、PartitionedCacheQuorumPolicy.calculateMinThreshold
メソッドをオーバーライドします。Oracle Coherenceでのアプリケーションの開発のカスタム・アクション・ポリシーの使用を参照してください。
PersistenceManagerMBean
MBeanには、アプリケーションが永続性操作の監視に使用できる一連の通知タイプが含まれます。『Oracle Coherenceのマネージメント』のPersistenceManagerMBeanに関する項を参照してください。永続性JMX通知をサブスクライブするには、JMX NotificationListener
インタフェースを実装し、リスナーを登録します。次のコード・スニペットは、通知リスナーの登録を示します。サンプルのリスナー実装を含む完全な例は、Coherenceの例を参照してください。
... MBeanServer server = MBeanHelper.findMBeanServer(); Registry registry = cluster.getManagement(); try { for (String sServiceName : setServices) { logHeader("Registering listener for " + sServiceName); String sMBeanName = getMBeanName(sServiceName); ObjectName oBeanName = new ObjectName(sMBeanName); NotificationListener listener = new PersistenceNotificationListener(sServiceName); server.addNotificationListener(oBeanName, listener, null, null); } ...
この項には次のトピックが含まれます:
データの永続化には、十分な量のディスク領域が必要です。必要な量のキャッシュ・データを永続化するために、十分な領域がプロビジョニングされていることを確認します。次のガイドラインは、永続性のディスクのサイズを設定する場合に使用してください。
アクティブ永続性のデータ記憶域のおおよそのオーバーヘッドは、パーティションごとに追加で10-30%の領域です。実際のオーバーヘッドは、データ・アクセス・パターン、キーと値のサイズ、およびその他の要因(ブロック・サイズ、重いシステム負荷など)によって異なります。
Coherence Java VisualVMプラグインと永続性レポートを使用して、領域可用性と使用状況を監視します。永続記憶域の使用の監視を参照してください。特に、ServiceMBean
MBeanのPersistenceActiveSpaceUsed
属性を使用して、各サービスとノードに使用される実際の永続性領域を監視します。
すべてのパーティションは同じ場所に永続化されるため、記憶域に共有ディスクを使用する永続性構成では、キャッシュの可能な最大サイズを計画するようにしてください。たとえば、キャッシュの最大容量が8GBの場合、共有ディスクで少なくとも8GBの永続データとオーバーヘッドに対応できるようにする必要があります。
ローカル・ディスクには、キャッシュ・サーバーで所有されるパーティションのみが永続化されるため、記憶域にローカル・ディスクを使用する永続性構成では、キャッシュ・サーバーの可能な最大キャッシュ容量を計画するようにしてください。たとえば、キャッシュ・サーバーの最大キャッシュ容量2GBの場合、ローカル・ディスクで少なくとも2GBの永続データとオーバーヘッドに対応できるようにする必要があります。
アクティブ・モードまたはオンデマンド・モードでスナップショットを作成する場合は、追加の領域を計画してください。キャッシュの各スナップショットにより、ディスク上の永続性ファイルのサイズが2倍になります。
スナップショット・アーカイブに追加の領域を計画します。スナップショットの各アーカイブは、ディスク上のスナップショットのサイズよりわずかに少なくなります。
永続記憶域を監視し、キャッシュ・データを永続化するための十分な領域がファイル・システムにあることを確認します。
Coherence-Java VisualVMプラグイン
Coherence-Java VisualVMプラグインの「永続性」タブを使用して、サービスでアクティブ永続性に使用されている領域の量を表示します。領域はバイトおよびメガバイトの両方の単位でレポートされます。このタブでは、サービスに使用可能な現在のスナップショットの現在の数がレポートされます。スナップショットの数を使用して、追加の領域使用を推定し、スナップショットを削除して空き領域を確保すべきかどうかを判断できます。
Coherenceレポート
永続性詳細レポート(persistence-detail.txt
)を使用して、サービスでアクティブ永続性および永続性スナップショットの両方に使用されている領域の量を表示します。ディスク領域に使用可能な量もレポートされ、ディスクが容量に達しているかどうかを監視できます。
Coherence MBean
ServiceMBean
MBeanの永続性の属性を使用して、サービスのすべての永続性記憶域の統計を表示します。MBeanには、アクティブ永続性および永続性スナップショットの両方の統計が含まれます。
アクティブ永続性を使用している場合の永続性の遅延を監視し、永続性操作によりキャッシュ操作が影響を受けていないことを確認します。高遅延は、ネットワークの問題により、共有ディスクへの永続性ファイルの書込みに遅延が発生しているか、ローカル・ディスク間の調整に遅延が発生していることを示す場合があります。
Coherence-Java VisualVMプラグイン
Coherence-Java VisualVMプラグインの「永続性」タブを使用して、永続性操作によりキャッシュ操作に加わっている遅延の量を表示します。時間はミリ秒でレポートされます。統計はサービスごとにレポートされ、すべての永続性操作の平均の遅延と最も高い遅延が表示されます。
Coherenceレポート
永続性詳細レポート(persistence-detail.txt
)を使用して、永続性操作によりキャッシュ操作に発生している遅延の量を表示します。時間はミリ秒でレポートされます。サービスの各クラスタ・ノードのすべての永続性操作の平均の遅延と、最も高い遅延の統計が表示されます。統計を使用して、他のノードよりも高遅延が発生しているノードがないかを確認できます。
Coherence MBean
ServiceMBean
MBeanの永続性の属性を使用して、永続性操作によりキャッシュ操作に発生している遅延の量を表示します。時間はミリ秒でレポートされます。サービスの各クラスタ・ノードのすべての永続性操作の平均の遅延と、最も高い遅延の統計が表示されます。統計を使用して、他のノードよりも高遅延が発生しているノードがないかを確認できます。
注意:
永続性リカバリ操作では、キャッシュ・サービス全体が永続状態からリカバリされ、一時的なものとして構成されているキャッシュがリセットされます。
キャッシュは、分散スキーム定義の<backing-map-scheme>
要素内の<transient>
要素を使用して、一時的なものとして構成されます。ただし、永続性がサービスで常に有効になっているため、パラメータ・マクロを使用して、キャッシュごとに一時設定を構成します。次に例を示します。
<caching-scheme-mapping> <cache-mapping> <cache-name>nonPersistedCache</cache-name> <scheme-name>distributed</scheme-name> <init-params> <init-param> <param-name>transient</param-name> <param-value>true</param-value> </init-param> </init-params> </cache-mapping> <cache-mapping> <cache-name>persistedCache</cache-name> <scheme-name>distributed</scheme-name> </cache-mapping> </caching-scheme-mapping> <distributed-scheme> <scheme-name>distributed</scheme-name> <service-name>DistributedService</service-name> <backing-map-scheme> <transient>{transient false}</transient> <local-scheme/> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme>
注意:
<transient>
要素のデフォルト値はfalse
で、キャッシュ・データが永続化されることを示します。