Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

インメモリはサーバがダウンしたら終わり・・・じゃない

edited by DB Online   2015/07/24 06:00

 インメモリのデータベースはサーバが落ちたら終わり。そんなふうに考えていた時期が私にもありました。でもOracle Database In-Memoryにはそうならないための構成が用意されているのです。検証シリーズ最終回となる今回は、実際に障害を発生させてその動きを追っていきます。

インメモリと聞いて一番気になること

 セミナーや勉強会などで、「Oracle Database In-Memoryはメモリ上にデータがあるのだから、サーバがダウンしたら復旧が大変ではないか?」というご質問をいただくことがあります。仕組みを考えればこうした懸念は当然です。サーバがダウンすればもちろんRAMの中身は消えますし、インスタンスがダウンすればデータベースから見たキャッシュは空になってしまいます。データの整合性はどうなるのか、インメモリの状態に復旧するまでどの程度かかるのかといった情報は、採用を検討する上で必ず抑えておかなければいけません。

 まず、データの整合性についてですが、Oracle Database In-Memoryでは更新処理にこれまでどおりデータベース・バッファ・キャッシュを使用しています。もしサーバがダウンしたとしてもクラッシュリカバリによってデータの整合性が維持されるため、Oracle Database In-Memoryならではの懸念事項というのはありません。それよりも問題なのは、クラッシュリカバリが終わってもディスクからメモリ上にデータを配置(ポピュレーション)し直さなければ、インメモリの状態には戻らないということです。

 これまでの検証でご紹介したように、ポピュレーションは行フォーマットから列フォーマットへの変換と圧縮を行うため、それなりに時間のかかる作業です。ポピュレーションの途中でもクエリを発行できますが、部分的にインメモリになった状態では本来期待する性能を発揮することができません。

図1:可用性構成ではない場合のOracle Database In-Memory
図1:可用性構成ではない場合のOracle Database In-Memory

 これはOracle Database In-Memoryに限った話ではなく、インメモリ技術全般に当てはまります。メモリにデータを配置する以上、常に「消える」というリスクと戦わなければいけません。特にクリティカルなシステムの場合は、ダウンタイムを短く抑えるための可用性構成を組めるかどうかが、採用可否を大きく左右します。

Oracle Database In-Memory + RAC

 Oracle Databaseの代表的な可用性構成と言えば、Real Application Clusters(RAC)です。RACは全てのサーバ(ノード)で読み取りと書き込みが可能なアクティブ-アクティブ型のクラスタ構成なので、もし1台のノードがダウンしても生き残ったノードに接続すれば処理を継続できます。

 Oracle Database In-MemoryはRAC上でも動作しますので、可用性を確保したい場合はRACの構成を選択するのが最も良い方法です。ただし、話はそれほど単純ではなく、各ノードのメモリ上でどのようにデータを保持するか、3つのパターンから選択する必要があります。それが以下の図です。

図2:Oracle Database In-Memory をRAC上で使う場合の設定
図2:Oracle Database In-MemoryをRAC上で使う場合の設定

 「NO DUPLICATE」は、各ノード上のインメモリ・カラムストアにデータを分散します。データの複製を保持しないため、より多くのデータをメモリ上に配置できますが、例えば図のノード1がダウンしてしまうと、P1のデータにはインメモリでのアクセスができなくなってしまいます。

 「DUPLICATE」と「ALL DUPLICATE」は、異なるノード上に複製を保持します。「NO DUPLICATE」と比べて使えるメモリ量は減ってしまいますが、いずれか一つのノードがダウンしたとしても別のノードに複製が存在するため可用性に優れています。ただし、この構成がとれるのは、Oracle Exadata Database Machine(Exadata)やOracle Database Applianceなどの、Engineered Systemsのみになっています。機材の選定と可用性のレベルが密接に関わってきますので、特に「DUPLICATE」と「ALL DUPLICATE」を選択する場合は注意が必要です。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 関 俊洋(セキ トシヒロ)

    株式会社アシスト データベース技術本部 データベース・エバンジェリスト データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やソリューションの立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆や講演活動を行っている。

バックナンバー

連載:既存の概念を覆す!Oracle Database In-Memoryのテクノロジー
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5