RACのキャッシュフュージョン(Cache Fusion)について調査しました。
RAC触ったことある人なら誰でも知っているよ！と言われそうな気がしますが、復習がてら備忘録に残します。
こちらは参考文献を自分なりに解釈してほとんど写経したものです。
キャッシュフュージョンとは、インスタンス間でデータブロックを転送して、インスタンス間のキャッシュ一貫性を保つ仕組みです。(あたかも1つのキャッシュのように扱う仕組みです)
データブロックを保持しているインスタンスから、データを要求しているインスタンスにインターコネクト経由でデータブロックを転送します。
GRD (Global Resource Directory)
各インスタンスのSGA(共有プール)に存在する
リソースマスターやグローバルリソース(データブロック、ロックなど)を格納する
GCS (Global Cache Service)
データベース・バッファ・キャッシュのグローバルリソース(データブロック)を保護するためのロックを管理する
主なGCSプロセス…LMSn
GES (Global Enqueue Service)
データベース・バッファ・キャッシュのデータブロック以外のグローバルリソースを保護するためのロックを管理する
主なGESプロセス…LMON、LMD0、LCK0
GCS・GESの主なバックグラウンドプロセス
LMON (Global Enqueue Service Manager)
主にインスタンスリスト(メンバーシップ)管理を担当
・インスタンス追加/削除によるインスタンスのメンバーシップを管理(インスタンス障害時はGRD再構成する)
・Global Enqueue(ロックの一種)、クラスタ全体のリソースを監視
LMD0 (Global Enqueue Service Daemon)
主にGES関連操作を担当
・デッドロック管理、ロックモード(排他モード/共有モード)変換などGESリソースを調整
LCK0 (Lock Process)
主にGES要求処理
・不正ロック(解放されるべきロックなど)、使用中のロックリストなどを作成し、GESリソース要求を処理
・ライブラリ・キャッシュやディクショナリ・キャッシュなどキャッシュフュージョンに関連しないリソース要求を管理
LMSn (Global Cache Service Process)
主にGCS関連操作を担当
・インスタンス間でメッセージの流れを制御
・キャッシュ一貫性のためのデータブロック転送などGCSリソースを調整
・CPU数によって複数起動できる(GCS_SERVER_PROCESSES初期化パラメータ)
・キャッシュフュージョンに関連するGCSリソース要求を管理
★黒本に「未コミットのままでもキャッシュフュージョンによるブロック転送が行われる」と書かれており、「update(未コミット)された時点で別インスタンスからupdate後のデータは見れるのか？」という疑問がわいたため、軽く検証しました。
【検証手順】
1. インスタンス1でempをselect
2. インスタンス1でempを1行update(未コミット)
3. インスタンス2でempをselect
※サンプルスキーマ(scott)を使用しています
【想定】
インスタンス2で「3」の時点でupdate後のデータが見れる(selectで取得できる)はず
【検証結果】
インスタンス2でupdate後のデータは見れなかった(selectで取得できなかった)
未コミットでもブロック転送されていれば別インスタンスから見れると思っていたのですが、そもそもselectはCRバッファからデータを取得するため、update後のデータは見れなくて正しいですね…(見れたらダーティリードですね)
DMLはCURRENTバッファ(最新バージョンのデータブロック)を使用しますが、SELECTはCR、ConsistentReadバッファ(特定の時点(SCN)のデータブロック。CURRENTバッファコピー後、UNDOデータ適用したもの)を使用するというのを失念していました。
Twitterで有識者の方から助言いただいて解決しました。助言いただいた有識者の方、ありがとうございました。
※CURRENTブロック(現行ブロック)は、一つのデータブロックと1対1
※CRブロック(読取り一貫性ブロック)は、一つのデータブロックに対して複数ある(都度生成される)
リソースマスター
GCSリソース(データブロック)を保持しているインスタンスを把握しているインスタンス
いずれかのインスタンスからリソースマスターにリソース要求メッセージ(GCSメッセージ)が届くと、リソースマスターがリソースの保持側(リソースホルダー)に対してリソースの要求側(リクエスター)にリソースを渡すよう指示する
要求側のリソース取得が完了すると、完了メッセージ(リソースを受け取った)がリソースマスターに届き、リソースマスターの情報が更新される
リソースマスターは自動的に決定され、DLM(分散ロックサービス)に則ったリソース制御を行う
(例) インスタンス2で「A」を取得しようとしたが、インスタンス2のキャッシュに「A」がなかった場合
動的再マスタリング (Dynamic Re-Mastering)
特定インスタンスからのみ使用しているリソースの場合、毎回異なるインスタンスのリソースマスターにリソース要求メッセージ(GCSメッセージ)するのは無駄です
リソースの参照頻度が多いインスタンスにリソースマスターを再配置する仕組み
そうすればリソース要求メッセージ(GCSメッセージ)送信も不要になるため、キャッシュフュージョンが抑えられる
(例) インスタンス1のリソースの参照頻度が高い場合
動的再マスタリングにて、BとDのリソースマスターがインスタンス1に移動します
→BとDもインスタンス1内で要求と取得許可が完結する(GCSメッセージ送信も不要)
※再マスタリングはインスタンス起動/停止のタイミングにも行われます。インスタンス数が変動する場合、GRD再構成されます。
GRD再構成は、追加/削除されたインスタンスが担当すべきリソースマスターの再マスタリングだけ行われます(レイジー再マスタリングと言います)
■参考資料
・オラクルマスター教科書 Oracle Expert RAC 11gR2
・Oracle Database 11g Release 2 RAC実践ガイド 基礎から学ぶRAC構築･管理
