Pivotal Knowledge Base

フォローする

パーティションリージョンの Eviction 設定で local-destroy を指定し CQ を登録している場合に CQ イベント処理に不整合が発生

適用範囲

パーティションリージョン、Continuous Query、Eviction の機能をもつ全てのバージョンの GemFire

目的

現状、GemFire において、Eviction 設定で local-destroy を指定したパーティションリージョンに対して、CQ(Continuous Query)登録を許可している。この構成は、一般論として動作するが、当該パーティションリージョンを保持する各メンバーからの CQ イベント送信に不整合が生じる可能性がある。本記事においては、その不整合の発生原因について詳細な解説を提供する。

事象と原因

GemFire における Eviction 機能の特性のため、Eviction のアクションとして local-destroy が指定されている場合、同一パーティションリージョンを保持する各メンバーは local-destroy を個別に実行し、同期的動作を行わない。結果として、CQ クライアントは、接続先メンバーによって受信するイベントが異なる可能性がある。

例えば、以下のような例で考察してみよう:

  • 2 つのメンバーがあり、それぞれ MemberA、MemberB とする。各メンバーは Eviction 設定でアクションとして local-destroy を指定する同一パーティションリージョンを保持し、冗長コピーを 1 つ保持ものとする。
  • MemberA はあるデータエントリーにおいてプライマリーで、MemberB はその冗長コピーをもつセカンダリーとする。
  • 2 つの CQ クライアントがあり、それぞれ ClientA、ClientB とする。ClientA は MemberA に接続し、ClientB は MemberB に接続するものとする。
  • Eviction 設定に応じて、セカンダリーの当該データエントリーに対して先に local-destroy が実行されたものとする。次にプライマリーの当該データエントリーに対して同様に Eviction 設定にて local-destroy がまさに実行される直前に、destroy リージョン操作により当該データエントリーが削除されたものとする。(このような状況は、各メンバーのメモリ使用量や負荷、設定等の違いによって発生し得る)

この状況では、destroy リージョン操作が実行された際に、プライマリーの MemberA には当該データエントリーが存在していたので、接続元である ClientA には CQ イベントが送信される。一方、セカンダリーの MemberB には当該データエントリーは Eviction によって local-destroy されているため、接続元である ClientB には CQ イベントは送信されない。

解決策

現状、あらゆる状況において CQ イベントを確実に送信する唯一の方法は、CQ を実行するパーティションリージョンに対して Eviction 設定にて local-destroy を指定しないことである。

コメント

Powered by Zendesk