マルチマスター・トポロジーでのローダーについての考慮事項

マルチマスター・トポロジーでローダーを使用する場合は、起こり得る衝突および改訂情報の維持についての問題を考慮する必要があります。データ・グリッドはその中の各項目について改訂情報を維持しており、構成内の他のプライマリー断片がデータ・グリッドにエントリーを書き込むときに衝突を検出できるようになっています。エントリーがローダーから追加されると、この改訂情報は含められず、エントリーは新しい改訂を持つようになります。エントリーの改訂は新規挿入に見えるため、別のプライマリー断片もこの状態を変更したり、ローダーから同じ情報を引き込んだりした場合に、偽の衝突が発生する場合があります。

レプリカ生成の変更は、データ・グリッド内に今はないが、レプリカ生成トランザクション中に変更されるキーのリストを使用して、ローダーに対して get メソッドを呼び出します。 レプリカ生成が行われると、これらのエントリーは衝突エントリーとなります。 衝突をアービトレーションし、改訂を適用すると、バッチ更新がローダーで呼び出されて変更内容がデータベースに適用されます。改訂ウィンドウで変更されたマップはすべて、同じトランザクションで更新されます。

プリロードの問題

データ・センター A とデータ・センター B を使用した 2 つのデータ・センター・トポロジーがあるとします。2 つのデータ・センターはそれぞれ独立したデータベースを持っていますが、データ・センター A にのみ、実行中のデータ・グリッドがあります。マルチマスター構成でデータ・センター間のリンクを確立すると、データ・センター A 内のデータ・グリッドがデータ・センター B 内の新規データ・グリッドにデータをプッシュし始め、すべてのエントリーとの衝突を引き起こします。別の大きな問題は、データ・センター A 内のデータベースには存在せず、データ・センター B 内のデータベースにあるすべてのデータで発生します。これらの行にはデータが取り込まれず、アービトレーションされません。結果として、解決されない不整合が発生します。

プリロードの問題に対する解決策

データベース内にのみ存在するデータは改訂を持つことができないため、常にローカル・データベースからデータ・グリッドを完全にプリロードした後、マルチマスター・リンクを設定する必要があります。次に、両方のデータ・グリッドはデータを改訂し、アービトレーションすることができ、最終的に整合した状態に達します。

スパース・キャッシュの問題

スパース・キャッシュを使用すると、アプリケーションはまずデータ・グリッド内のデータの検索を試みます。データがデータ・グリッド内にないと、ローダーを使用してデータベースでデータが検索されます。キャッシュ・サイズを小規模に維持するために、エントリーは定期的にデータ・グリッドから除去されます。

このキャッシュ・タイプは、マルチマスター構成シナリオでは問題となる場合があります。なぜなら、データ・グリッド内のエントリーは、衝突が発生するときやどちら側が変更を行ったかを検出するのを助ける、改訂用メタデータを持っているためです。データ・センター間のリンクが機能していない場合、一方のデータ・センターがエントリーを更新し、最終的にデータ・グリッド内のデータベースを更新し、エントリーを無効化することができます。リンクが復旧すると、データ・センターは互いに改訂を同期しようとします。しかし、データベースが更新され、データ・グリッド・エントリーが無効化されているため、ダウンしていたデータ・センターの観点から見ると、変更が失われています。結果として、両側のデータ・グリッドで同期がとれず、整合性がなくなります。

スパース・キャッシュの問題に対する解決策

ハブおよびスポーク・トポロジー:

ハブおよびスポーク・トポロジーのハブでのみローダーを実行し、結果として、データの整合性を維持しながら、データ・グリッドをスケールアウトすることができます。ただし、このデプロイメントを検討している場合は、ローダーがデータ・グリッドを部分的にロードできることに注意してください。これは、Evictor が構成済みであることを意味します。構成のスポークがスパース・キャッシュだが、ローダーがない場合は、どのキャッシュ・ミスもデータベースからデータを取り出すことができません。この制約事項のため、ハブおよびスポーク構成では、完全に取り込まれたキャッシュ・トポロジーを使用する必要があります。

無効化および除去

無効化により、データ・グリッドとデータベース間の不整合が発生します。プログラマチックに、または除去機能を使用して、データ・グリッドからデータを削除できます。アプリケーションの開発時に、改訂処理では無効化された変更内容は複製されず、プライマリー断片間で不整合が発生しないよう注意する必要があります。

無効化イベントは、キャッシュ状態変更ではなく、レプリカ生成は生じません。 いかなる構成済み Evictor も構成内の他の Evictor と独立して実行されます。例えば、カタログ・サービス・ドメインでのメモリーしきい値について構成済みの Evictor が 1 つあるが、リンクされている他のカタログ・サービス・ドメインに異なるタイプのあまり活動的でない Evictor がある場合があります。データ・グリッド・エントリーがメモリーしきい値ポリシーのために削除されても、他のカタログ・サービス・ドメイン内のエントリーは影響を受けません。

データベースの更新およびデータ・グリッドの無効化

問題が発生するのは、バックグラウンドで直接データベースを更新しながら、マルチマスター構成で更新済みエントリーについてデータ・グリッドに対して無効化を呼び出しているときです。 この問題は、いくつかのタイプのキャッシュ・アクセスがエントリーをデータ・グリッドに移動するまで、データ・グリッドが別のプライマリー断片への変更を複製できないために発生します。

単一論理データベースへの複数の書き込みプログラム

ローダーを介して接続された複数のプライマリー断片と一緒に単一データベースを使用していると、トランザクションの競合が発生します。ローダーの実装は、特にこれらのタイプのシナリオを処理する必要があります。

マルチマスター・レプリカ生成を使用したデータのミラーリング

独立したカタログ・サービス・ドメインに接続された独立したデータベースを構成できます。この構成では、ローダーはあるデータ・センターの変更内容を別のデータ・センターにプッシュできます。