Oracle RAC (Real Application Cluster) は、シェアードエブリシングアーキテクチャをベースとした Oracle Database の構成の 1 つである。 RAC 構成では、各ノードが共有されたデータベースにアクセスする active/active 構成をとり、データベースのファイルはクラスタ間で共有するストレージに保管される。
RAC は下記に示す 2 種類のネットワークから構成される。
RAC 構成ではすべてのノードが同じデータベースを管理している。複数のノード間でデータの一貫性を保つためには、異なるノードで発生したデータの変更を管理し、どのノードでも常に最新バージョンのデータを得られるよう調整 (coordinate) する必要がある。 これをインターコネクトを使って高速に実現する Oracle RAC の機能を Cache Fusion という。
各データブロックには、ハッシュアルゴリズムに基づいてそのデータブロックを GRD で管理するノード (リソースマスター, resource master) が割り当てられる。 あるデータブロックに対して、必ず 1 つのリソースマスターが存在する。
データブロックのリソースマスターは下記に示すタイミングで再決定 (remaster) される。
加えて、データブロックのリソースマスターは DRM (Dynamic Resource Mastering) によって再構成される。 DRM はデータブロックの親和性 (affinity) を分析し、そのブロックのリソースマスターを再決定する。
例えば、あるデータブロックの GRD エントリが頻繁に他のインスタンスから参照されるのであれば、そのインスタンスをブロックのリソースマスターとする。
Cache Fusion におけるノード間の調整は下記のコンポーネントにより実現されている。
トランザクションロックやテーブルロックなど、グローバルなリソースの待ち行列を管理するサービス。
GCS と GES は、複数のノードによるデータブロックへのアクセス競合を防ぐため、データブロックの ID とそのブロックの最新バージョンをもっているノード (ホルディングノード, holding node) の情報を、そのブロックのリソースマスターの GRD (Global Resource Directory) という特別なメモリ領域に記録する。 1 つ以上のノードに障害を検知すると、残りのインスタンスは GRD を自動的に再構築するため、Cache Fusion はシングルノードになっても正常に動作を継続する。
データブロックがどのノードのバッファキャッシュにも存在しなければ、ブロックは物理ディスクからバッファキャッシュに読み込まれる。
バッファキャッシュ内で更新されたブロックは DBWR によってディスクに一括で書き込まれる。 (ライトバック) バッファキャッシュのライトバックが発生する条件を下記に示す。
Cache Fusion を使ってリクエストを受けたノード (以下リクエストノード) が、他のノードから最新バージョンのデータブロックを取得するまでの内部動作を下記に示す。