Pick Upテクノロジー

データベースの災害対策はバックアップだけで万全か？ 障害からの高速リカバリに威力を発揮するOracle Database 11g Enterprise Editionの標準機能「Oracle Data Guard」

今年3月に発生した東日本大震災では、東北地方を中心に甚大な被害が生じた。これを受け、改めて災害対策の重要性を認識した企業は少なくないだろう。当然 のことながら、こうした災害により事業活動の中核を担うデータベースが停止し、重要なデータが失われるようなことがあれば、業務の継続は難しくなり、顧客 や自社の業績にも大きな影響を与えることになる。そのため、本サイトをご覧のデータベース管理者の中には、この震災を機に、改めて自身が預かるデータ資産 の保護対策を見直している方も多いはずだ。実はOracle Database 11g Enterprise Editionには、そんなデータベース管理者の悩みに応えるデータ・レプリケーション機能「Oracle Data Guard」が用意されている。日本オラクルでOracle Data Guard担当エンジニアを務める後藤陽介氏（テクノロジー製品事業統括本部 アライアンス技術本部 アライアンス技術部 シニアエンジニア）に、その有効な活用法を聞いた。
 
TECHJP_0525_goto.png
日本オラクル
テクノロジー製品事業統括本部
アライアンス技術本部
アライアンス技術部
シニアエンジニア
後藤 陽介氏

 

■リアルタイムのデータ複製と高速切り替えを可能にするOracle Data Guard
 
　「災害対策の基本はバックアップを遠隔地に保持すること。そして最新のデータを常に遠隔地に保持したい場合にはレプリケーションという考え方 になる。しかし、対象がデータベースの場合には、それでも十分だとは言えない。データベースの災害対策では、さまざまな要因によるデータベースの停止時間 を極小化するために高速なリカバリと切り替え自動化の仕組みが必要になる。Oracle Data Guardは、データベースの可用性とデータ保護を徹底して追求しながら進化してきた機能であり、リアルタイムのデータ複製と、必要なときには高速なリカ バリと切り替えを行う仕組みを備えている。Oracle Database 11g Enterprise Editionの標準機能として利用できるこの機能を、今こそ活用していただきたい」（後藤氏）
 
　Oracle Data Guardが提供するのは、データベースのスタンバイ機能だ。具体的には、本番データベース（プライマリ・データベース）のトランザクション・ログを転送 し、スタンバイ・データベースと同期させることができる。転送はメモリ間の通信によって高速かつ低負荷で実行される。本番環境のデータベースが何らかの理 由で停止した、あるいは本番環境を止めなければならない事態になった場合に、待機側のデータベースを本番環境の代わりに使えるようになるのだ。

TECHJP_0525_01.png
 
　このOracle Data Guardの用途として、まず想定されるのは、遠隔地に待機用のデータベースを構築し、地震などの自然災害に備えるといったケースだ。ただし、データベー スに生じる突発的なトラブルは、何も自然災害だけではない。例えば、ハードウェア障害が発生し、クラスタやサーバがダメージを受ければ、データベースを利 用することはできなくなる。また、ストレージやネットワークに障害が生じた際にも、データベースへのアクセスは不可能になるだろう。そうした障害を考慮し て、近距離／同一サイト内にスタンバイ・データベースが構築されるケースもある。Oracle Data Guardでは、本番環境に対して複数のスタンバイ・データベースを構築することができるので、複数拠点にスタンバイを配置したり、同一サイトと遠隔地に スタンバイを配置したりといったことが可能だ。
 
　そのほかにも、さまざまな理由でデータベースを利用できなくなる状況が起こりうる。そうした多種多様なトラブルに対処できる仕組みを備えているのがOracle Data Guardなのである。
 
■データベースに"ロール"を持たせ、高速かつ確実な切り替えの自動化を可能に
 
　Oracle Data Guardにはさまざまな特徴があるが、その1つとして、本番環境と待機環境を迅速に切り換えられる点が挙げられる。
 
　今日、データベースを複製する方法は数多くあり、またそのためのソリューションも多数提供されている。ただし、実際の運用では、単に複製を作れるだけでなく、必要な際には素早く本番環境／待機環境を切り換えられることが極めて重要となる。
 
　本番環境と同期した待機系データベースを作る方法としては、例えばストレージ製品に備わるレプリケーション機能を利用することが考えられる。 だが、そうした機能を使った場合、本番環境と待機系を切り換えるために、まずマウント／アンマウントといった処理を行ってストレージを切り換え、そのうえ でデータベースを起動してといった具合に、多くの手順を1つずつ進めていかなければならない。手順が多くなれば、その分、オペレーション・ミスのリスクは 増えるだろう。
 
　Oracle Data Guardがそうしたソリューションと大きく異なるのは、通常はシステム管理者が管理する「本番」、「待機」の役割（ロール）を、データベース自身が管理 するところだ。そのため、同期可能なトランザクションをすべて適用した後、待機を本番に昇格させる「フェイルオーバー」もデータベース内部で自動化でき る。しかも、これらの処理はインスタンスを起動したままの状態で行われるので、再起動の必要がなく、高速な切り替えが可能である。
 
　さらに、このロール管理機能を活用した優れた機能が、本番環境と待機環境の役割そのものを入れ替える「スイッチオーバー」だ。この機能を利用 すると、例えばメンテナンスなどを行う際に待機環境を一時的に本番環境として使い、メンテナンスが終わったら元の本番環境に戻すといったことができる。こ う書くと簡単なことに聞こえるかもしれないが、これを実現するにはロールの入れ替え前に本番環境のトランザクションがすべて待機環境に反映されていること や、待機環境には更新が入らないことを保証しなければならない。それらを手動で管理すると非常に煩雑になるが、Oracle Data Guardならばこれらの処理もデータベース内部で自動化できる。このスイッチオーバーを使えば、バージョンアップやパッチ適用時、まずは待機環境で実施 し、そのうえで本番環境にも適用するローリング・アップデートが実現可能なこともメリットだと言えよう。
 
　なお、これらフェイルオーバーやスイッチオーバーの処理は、管理用SQLや、運用管理ツール「Oracle Enterprise Manager」のマウス操作によって簡単に実行できる。監視サーバを用意することで、障害の検知から切り替えの完了までを完全に自動化することも可能 だ。加えて、Oracle Databaseが提供するビューやOracle Enterprise Managerを使えば、Oracle Data Guardの詳細な稼働状況を管理者自身が確認することもできる。
 
TECHJP_0525_02.png
 
■ネットワークの有効利用でWAN回線のコストを削減
 
　前述したように、Oracle Data Guardではトランザクション・ログ（REDOログ）を使って本番環境のデータベースを複製する。実は、このトランザクション・ログの転送に関しても、効率化のためにさまざまな仕組みが盛り込まれている。
 
　遠隔地に待機環境を構築した際に必要となるWAN回線は、使用する帯域幅によってコストが大きく変わってくる。大容量のデータを高速に送ろう とすれば相応の帯域幅が必要となり、コストも高くつくというわけだ。例えば、ストレージのレプリケーション機能はディスク・ボリュームの遠隔地ミラーを構 築するための優れた仕組みだと言えるが、データベースに適用する場合、ネットワーク・コストが高くなることが懸念される。
 
TECHJP_0525_03.png
 
　しかし、Oracle Data Guardならばトランザクション・ログを送るだけなので、広帯域のネットワークを用意する必要はなく、WAN回線のコストを抑え、本番環境への影響も最 小限にとどめられる。また、Oracle Data Guardでは、トランザクション・ログを送信する際、ディスクを介さずメモリからダイレクトに送信する。そのため、ディスクI/Oが発生せず、パフォー マンスに大きな影響が及ぶことはないのである。システム要件に合わせて、同期／非同期から転送モードを選択することも可能だ。
 
TECHJP_0525_04.png
 
　加えて、データ保護の強化とネットワーク・コストの削減につながるデータ圧縮機能を備えている点もポイントである。例えば、ネットワークの帯 域幅が十分ではないのにもかかわらず本番環境への更新が頻繁に行われるような環境では、トランザクション・ログの転送が追いつかず、本番環境と待機環境の 内容に大きな差異が生じるおそれがある。この差異分のデータは障害発生時には失われてしまうため、データ保護の観点からは大きな問題だ。しかし、データ圧 縮機能を使えば転送量が抑制されるので、帯域幅が十分にない場合でも、本番環境と待機環境の差異を最小化できる。当然、ネットワーク・コストの観点でも、 データ圧縮機能は大きなメリットをもたらすだろう。
 
TECHJP_0525_05.png
 
■待機系を積極的に活用する機能群
 
　さて、遠隔地にデータベースの複製を用意しておけば、本番環境に障害が発生したときでもサービスを継続して提供できるメリットがある一方で、 トラブルが生じなければコスト負担だけが発生し続けることになる。もちろん、これは災害対策に必要なコストではあるのだが、せっかく本番環境の複製がある のなら、それを有効に活用したいところだろう。
 
　Oracle Databaseのオプション製品であるOracle Active Data Guardを使えば、待機系にトランザクション・ログを適用しつつ、同時に検索処理にも使うといったことが可能になる。最新のデータ保護の仕組みを利用し て、常時最新データを参照可能なレポーティング・データベースを構築できるのである。Oracle Data Guardの持つデータ保護や切り替えの性能／機能性を一切犠牲にせずに待機環境を活用できることが最大の特徴だ。
 
　検索処理のほかに、テストや開発といった書き込みも伴う処理で待機環境を使いたいというニーズもあるだろう。そうしたニーズにはOracle Database 11g Enterprise Editionの標準機能として提供される「スナップショット・スタンバイ」が有効である。スナップショット・スタンバイでは、トランザクション・ログの 適用を停止し、待機環境を読み書き可能な状態にする。この時点で本番環境とはまったく別のデータベースになるが、この間もトランザクション・ログは受信 し、データの保護を継続する。そして、待機環境での作業が完了したら、待機環境をトランザクション・ログの適用を停止した時点まで戻して同期を再開すれば よい。ちなみに、待機環境を戻す際には、Oracle Databaseが持つフラッシュバック・データベース機能が内部的に使用される。
 
　Oracle Active Data Guardは、本番環境の部分障害の復旧にも威力を発揮する。OSやハードウェアのI/Oスタックの障害によってデータ・ブロックの破損が生じると、次に そのブロックにアクセスがあったときにはエラーとなってしまう。しかし、Oracle Active Data Guardでは、ブロック破損を検知すると本番環境が待機環境に対して正常なブロックを要求。すると、待機環境は正常なブロックを本番環境に転送し、ただ ちにリカバリが行われる。結果として、データにアクセスしたユーザーは障害に気づくこともなく処理を継続できるわけである。
 
TECHJP_0525_06.png
 
■Oracle Data Guardを触ってみる
 
　以上のような特徴を備えるOracle Data Guard / Oracle Active Data Guardは、Oracle Database内のデータの保護に活用できるほか、運用の手間を減らすためのツールとしても極めて有用だ。データベースに関わる技術者としては、一度操 作を経験しておきたいという方も多いだろう。そんな方にぜひお勧めしたいのが、日立製作所と日本オラクルが共同で作成したドキュメント「Oracle Data Guard 11g フィジカル・スタンバイ設定ガイド」である。このドキュメントでは、Oracle GRID Centerでの共同検証作業をベースに、スタンバイ・データベースの構築手順やフェイルオーバー／スイッチオーバーの手順などが詳しく解説されている。 本記事でOracle Data Guardに興味持たれた方は、ぜひ一読されたい。
 
《GRID Center》シリーズをお見逃しなく！