Oracle データベース ワークロードの障害復旧オプション

このガイドでは、Bare Metal Solution 環境でミッション クリティカルな Oracle データベース ワークロードを実行するユーザーが利用できる障害復旧オプションについて説明します。

このガイドでは、Oracle Enterprise Edition を実行していることを前提としています。このガイドで説明する機能の一部は、Enterprise Edition ライセンスとは別にライセンスが必要です。これらの機能には、次のものがありますが、これらに限定されるものではありません。

  • Oracle Real Application Clusters
  • Oracle Active Data Guard
  • Oracle Advanced Compression
  • Oracle GoldenGate

障害復旧と高可用性の計画時に使用できる機能を確認するには、Oracle ライセンス契約をご覧ください。

アプリケーションの RTO と RPO

Oracle データベース テクノロジーの障害復旧は、アプリケーションの目標復旧時間（RTO）と目標復旧時点（RPO）に基づいて決定する必要があります。一般に、RTO はシステムで許容されるダウンタイムの量を表し、RPO は許容されるデータ損失の量を表します。これらの各値が小さくなるほど、システムの費用と複雑さが増します。RTO と RPO の詳細については、DR 計画の基本をご覧ください。

「RPO = 0」または「ゼロデータ損失」とラベル付けされたアーキテクチャでは、データベースに「commit」されたと見なされるには、まずデータが複数のロケーションに書き込まれる必要があります。RPO がゼロに近づくにつれて、レイテンシが問題になります。

設計フェーズで適切に考慮しないと、ゼロデータ損失アーキテクチャを実装すると、アプリケーションの全体的なパフォーマンスに悪影響を及ぼす可能性があります。

高可用性と障害復旧

高可用性と障害復旧は、信頼性の高いデータベース アーキテクチャを設計する際の補完的なコンセプトです。このガイドのコンテキストでは、高可用性とは、システムの個々の障害や連鎖障害から自動的に復旧するシステムの能力を指します。一方、障害復旧は全体的な事業継続計画の一部であり、システムのグループ全体が使用できなくなる可能性のある大規模な障害に適用されます。障害発生時に復元する必要がある統合コンポーネントの数が多いため、障害復旧の範囲は広くなります。

信頼性の高いシステムを設計する際は、高可用性を「最初の防衛線」と見なす必要があります。高可用性データベース アーキテクチャは、個々の障害を維持し、アプリケーションのダウンタイムを引き起こすことなく実行を継続できる必要があります。システムの高可用性コンポーネントには、次の対象が含まれている必要があります（ただし、これらに限定されません）。

  • サーバー、ネットワーク、ストレージ ハードウェアへの冗長電源
  • 複数のネットワーク インターフェース、スイッチ、ケーブル
  • 冗長なストレージ ファブリック、コントローラ、ディスク デバイス
  • Google Cloud と Bare Metal Solution リージョン拡張との間のフォールト トレラントな Partner Interconnect
  • サーバー障害によるデータベースの無効化を防止する Oracle RAC

障害復旧設計には、コンポーネントを使用できなくする複数のカスケード障害から復旧するプロセスを配置する必要があります。障害復旧計画では、次の点を考慮する必要があります。

  • リージョンの停止
  • 自然災害
  • アプリケーションの 1 つ以上のコンポーネントが完全に停止するインシデント

Oracle の障害復旧ツールと高可用性ツール

Oracle の障害復旧ツールと高可用性ツールは次のとおりです。

Oracle Real Application Clusters

Oracle Real Application Clusters（RAC）は、複数のデータベース サーバーによって処理されるようにデータベース ワークロードを水平方向にスケーリングするために使用されます。RAC を使用するデータベースでは、リージョン拡張機能内のサーバー間でアクティブ / アクティブ構成を使用できます。

RAC は通常、単一のサーバー障害から保護する必要があるシステムに高可用性を確保するために使用されます。クラスタリングに対する「すべて共有」アプローチ（共有ストレージと共有ネットワーク）のため、Bare Metal Solution 環境で実行される RAC クラスタは、単一の Bare Metal Solution Pod 内に存在する必要があります。これにより、RAC は高可用性に関する懸念事項のソリューションになりますが、障害復旧の要件は解決されません。

Bare Metal Solution の RAC の設定方法については、Bare Metal Solution に Oracle RAC をインストールするをご覧ください。

Oracle Recovery Manager

Oracle Recovery Manager（RMAN）は、Oracle 独自のデータファイル形式を読み取ることができるため、Oracle データベースのバックアップと復元に使用される主なツールです。これを使用して、データベースのクローン作成、ポイントインタイム リカバリ、さらには Oracle データベース内の単一テーブルの復元を行うことができます。

データベースが開いている間にバックアップを取得できるツールは RMAN のみです。また、復元に使用できるバックアップ ファイルのカタログをメンテナンスするためにも使用されます。

Oracle Data Guard

Oracle Data Guard は、リモート RAC クラスタまたは他のデータベース インストールへのデータベース レプリケーションを実行します。Data Guard は、物理構成または論理構成のいずれかでスタンバイ データベースをサポートしています。

物理スタンバイ データベースはブロック単位のコピーであり、データベースの 1 つのコピーを書き込み用に開くことができます。他のすべてのコピーは、変更を適用するためにマウントされます（開かれません）。または、レポート アプリケーションをサポートするために読み取り専用で開かれます。

Bare Metal Solution で Data Guard を設定する方法については、Bare Metal Solution に Oracle Data Guard をデプロイするをご覧ください。

FLASHBACK DATABASE

Oracle Enterprise Edition の FLASHBACK DATABASE 機能を使用すると、管理者は時間のかかるデータベース復元を実行しなくても、データベースを特定の時点に迅速に巻き戻すことができます。

障害復旧のコンテキストでは、FLASHBACK DATABASE は通常、フェイルオーバー オペレーション中に Data Guard と組み合わせて使用され、データベースの復元を高速化します。障害が発生したデータベースは、新しいプライマリ上のログと一致する特定の時点にフラッシュバックされ、REDO が送信されて完全に再同期されます。

Oracle GoldenGate

Oracle GoldenGate は、アクティブ / アクティブのマルチサイト デプロイの有効化や、ハードウェア プラットフォーム間でのデータの移動に一般的に使用される論理レプリケーション ツールです。GoldenGate を使用する場合、ソース データベースの extract プロセスはオンライン REDO ログの変更をキャプチャし、変更を追跡ファイルに書き込みます。この変更はターゲット データベースに転送されます。ターゲット データベースの replicat プロセスは、トランザクションをテールファイルから SQL に変換し、ターゲット データベースで SQL を実行します。

このアーキテクチャにより、GoldenGate はデータベース プラットフォーム間でのデータの移動や、レプリケーション時のデータの変換を行うための強力なツールになります。Data Guard とは異なり、GoldenGate では、ソースシステムとターゲット システムに別々のソフトウェアをインストールしてメンテナンスする必要があります。トランザクションがターゲット データベースで SQL として変換され、適用されるため、GoldenGate を同期レプリケーションに使用することはできません。GoldenGate はレプリケーションの遅延を最小限に抑えることができますが、GoldenGate だけでは RPO をゼロにすることはできません。

障害復旧のデプロイモデル（データベースのみ）

Oracle は、アプリケーションとデータベースのデプロイに推奨される障害復旧モデルを提供するために、Maximum Availability Architecture（MAA）フレームワークを作成しました。

次の各モデルには、特定の RTO と RPO の目標が設定されています。

モデルは、計画的な停止と計画外の停止のイベントで RPO と RTO を満たす特定のデプロイ パターンにマッピングされます。各データベース ワークロードの可用性要件を評価し、対応するモデルで設計する必要があります。開発データベースでは、本番環境や QA 環境よりも保護レベルの低いモデルを使用するのが一般的です。

ブロンズモデルは、分単位の RTO を必要としないデータベースを対象としています。シルバー以上のモデルには、リモートサイトで実行されるスタンバイ データベースが含まれています。各モデルには、下位レベルのモデルの機能が組み込まれています。たとえば、ブロンズモデルでは、スタンバイ データベースがデプロイされている場合でも、バックアップと復元のコンセプトに従う必要があります。

Copper モデル

Copper モデルは、データベースをローカル ストレージ メディアにバックアップし、リージョン拡張の外部にあるストレージにコピーするための最小限のデプロイを提供します。このデプロイには 2 段階のアプローチが必要ですが、Google Cloud SDK を使用してバックアップの転送を自動化するようにスクリプトを作成できます。

このデプロイを使用すると、2 段階の復元が必要になるため、RTO も増加します。RMAN はバックアップに直接アクセスできないため、復元を開始する前に、RMAN が使用できる場所にバックアップを移動する必要があります。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間
障害: 破損 RE から転送された最後のアーカイブログ、増分バックアップ、またはフル バックアップ データベースのサイズと Partner Interconnect に割り当てられた帯域幅に応じて数時間
障害: リージョン拡張の失敗 RE から転送された最後のアーカイブログ、増分バックアップ、またはフル バックアップ リージョン拡張をオンラインに戻すために必要な時間に応じて、数日または数週間
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間
データベースのメジャー アップグレード 0 1～2 時間

ブロンズモデル

ブロンズモデルには、2 つのデプロイ オプションがあります。どちらも、Google Cloudネイティブ ストレージを使用してデータベースのバックアップを保持します。

ブロンズ デプロイ 1: リージョン ストレージのバックアップ

このデプロイでは、バックアップはオフサイト メディアに直接書き込まれます。ほとんどの場合、バックアップの宛先には Cloud Storage FUSE を使用した Cloud Storage が推奨されます。この方法では、Cloud Storage バケットがファイル システムとして提示されます。

Cloud Storage FUSE の使用に関する推奨事項については、NFS と Cloud Storage を使用した Oracle のバックアップをご覧ください。Bare Metal Solution インスタンスに NFS 共有を提供する Google Cloud Filestore も使用できます。

次の図は、デプロイの例を示しています。

リージョン ストレージでメンテナンスされるバックアップを含む Oracle Bronze モデルのデプロイ。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間
障害: 破損 最後のアーカイブログ、増分バックアップまたはフル バックアップ データベースのサイズと Partner Interconnect に割り当てられた帯域幅に応じて数時間
障害: リージョン拡張の失敗 最後のアーカイブログ、増分バックアップまたはフル バックアップ リージョン拡張をオンラインに戻すために必要な時間に応じて、数日または数週間
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間
データベースのメジャー アップグレード 0 1～2 時間

ブロンズ デプロイ 2: バックアップと DR を使用したバックアップ

このデプロイでは、Backup and DR サービスを使用してGoogle Cloudにバックアップを保存します。Backup and DR は、バックアップに永久増分方式を採用しています。バックアップは、長期保持のために Cloud Storage を基盤とする高パフォーマンスのメディアに保存されます。

また、Backup and DR では、データベース ファイルのイメージを Oracle インスタンスですぐに使用できるため、Filestore や Cloud Storage にバックアップを保存する場合よりも RTO が短くなります。マウントと移行機能を使用すると、本番環境ストレージ メディアにコピーしながらデータベースを迅速にオンラインに復元できるため、RTO を大幅に短縮できます。

次の図は、デプロイの例を示しています。

ブロンズ デプロイの Google Cloud Backup and DR。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間

RAC を使用している場合は数秒
障害: 破損 最後のアーカイブログ、増分バックアップまたはフル バックアップ パフォーマンス要件、データベースのサイズ、Partner Interconnect に割り当てられた帯域幅に応じて数分から数時間
障害: リージョン拡張の失敗 最後のアーカイブログ、増分バックアップまたはフル バックアップ リージョン拡張をオンラインに戻すまでの時間や、お客様が別のリージョン拡張に移行できるかどうかに応じて、数日または数週間。
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間
データベースのメジャー アップグレード 0 1～2 時間

シルバー

シルバーモデルでは、Oracle Data Guard を使用したデータベース レプリケーションが導入されます。Data Guard は、1 つ以上のデータベースがスタンバイ データベースとして機能するリアルタイム データベース レプリケーションを提供します。Data Guard は、データベースの変更が発生したときにその変更を転送して適用するため、RPO はほぼゼロにできます。シルバーモデルは非同期レプリケーションに依存しています。同期レプリケーションを使用するとデータ損失をゼロにできますが、リージョン間でデータを送信する時間により、通常、アプリケーションのレスポンス時間が許容範囲を超えてしまいます。

Data Guard のファスト スタート フェイルオーバー機能では、プライマリ データベースがユーザー定義の期間使用できなくなった場合に自動フェイルオーバー オペレーションを実行できます。構成は、実行可能な Data Guard オブザーバー プロセスによってモニタリングされます。

シルバーモデルには、リージョン全体で障害が発生した場合でもデータベースを利用できるという利点があります。ただし、アプリケーション サーバーとデータベース間のネットワーク レイテンシが増加するため、フェイルオーバー オペレーションとスイッチオーバー オペレーションがアプリケーションのパフォーマンスに影響する可能性があります。アプリケーションとサポート データベースを異なるリージョンで実行することは、ほとんど推奨されません。データベースの RTO は 1 分未満ですが、アプリケーションのフェイルオーバーの場合、サービスが完全に機能するまでに数分から数時間かかることがあります。ほとんどの場合、クロスリージョン障害復旧フェイルオーバー プランの実行には、移動されるコンポーネントの数が多いため、手動プロセスが伴います。

シルバーモデルでは、四半期のパッチ適用アクティビティ中にダウンタイムまたはメンテナンスの時間枠が発生することがあります。Oracle RAC を導入すると、パッチ適用やサーバー障害によるダウンタイムを短縮できます。

次の図は、構成の例を示しています。

VRF を使用したデフォルトのマッピング。

図の構成例は、us-west2 リージョンと us-east4 リージョンで実行されている RAC データベースを示しています。レプリケーションは、非同期 Data Guard を使用して構成されます。Bare Metal Solution と Google Cloud間のすべてのトラフィックは Partner Interconnect を通過し、リージョン間のトラフィックは Google ネットワーク バックボーンを経由します。アプリケーション サーバーは各リージョンに構成されますが、通常はフェイルオーバー イベントが宣言されるまで障害復旧リージョンでシャットダウンされます。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間

RAC を使用している場合は数秒
障害: 破損 60 秒未満 アプリケーションのフェイルオーバーに応じて数分から数時間。
障害: リージョン拡張の失敗 60 秒未満 アプリケーションのフェイルオーバーに応じて数分から数時間。
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間。

RAC を使用している場合は数秒
データベースのメジャー アップグレード 0 1～2 時間

DBMS_ROLLING を使用してアップグレードを実行する場合は分単位。

ゴールドモデル

シルバーモデルでのデータ損失が懸念される場合は、遠隔同期インスタンスを使用して Google CloudCompute Engine で実行されているインスタンスに同期レプリケーションを提供するゴールドモデルを選択できます。

遠隔同期インスタンスには、データベース制御ファイルと、プライマリ データベースに地理的に近接した場所で実行される一連のスタンバイ REDO ログが含まれています。このインスタンスは、低レイテンシで REDO を同期的に受信するように構成されているため、すべての変更をプライマリ データベースのリージョン拡張の外部に記録できます。その後、遠隔同期インスタンスはリモート リージョンのスタンバイ データベースに REDO を転送して、非同期で適用します。

遠隔同期インスタンスはデータベースの完全なコピーではないため、アプリケーション トラフィックを処理できません。遠隔同期インスタンスは、データベースの変更を同期的に書き込むためのフォールト トレラントなロケーションを提供するために使用され、データ損失のないソリューションを実現します。遠隔同期インスタンスへの同期レプリケーションを実行する場合、変更が受信されて遠隔同期インスタンスで commit されるまで、プライマリ データベースでトランザクションは commit されません。

通常、Compute Engine インスタンスは、遠隔同期インスタンスのホストの候補として選択されます。遠隔同期インスタンスをプライマリ データベースに近接する Compute Engine ゾーンに配置すると、レイテンシが最小限に抑えられ（通常は 1.5 ms 未満）、リージョン拡張内の障害から保護されます。

次の図は、デプロイの例を示しています。

Oracle Gold の遠隔同期。

図の構成例は、us-west2 で実行されているプライマリ RAC データベースと、Compute Engine で実行されているアプリケーションを示しています。us-west2 内の Compute Engine インスタンスが遠隔同期インスタンスを実行し、同期 REDO を受信します。遠隔同期インスタンスは、us-east4 リージョンで実行されている RAC データベースに非同期で REDO を送信するように構成されています。アプリケーション インスタンスは、障害発生時にアプリケーション トラフィックを処理するように Compute Engine の us-east4 リージョンに構成されています。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間

RAC を使用している場合は数秒
障害: 破損 0 アプリケーションのリージョン フェイルオーバーに応じて数分から数時間。
障害: リージョン拡張の失敗 0 アプリケーションのリージョン フェイルオーバーに応じて数分から数時間。
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間。

RAC を使用している場合は数秒
データベースのメジャー アップグレード 0 1～2 時間

DBMS_ROLLING を使用してアップグレードを実行する場合は分単位。

プラチナモデル

プラチナモデルには、2 つのデプロイ オプションがあります。各デプロイ オプションは、異なるテクノロジーを使用して保護を提供し、異なる RTO と RPO の特性を持っています。

プラチナ デプロイ 1: ファスト スタート フェイルオーバーを使用する Data Guard

プラチナ デプロイ 1 は、ゴールドモデルのデプロイ上に構築され、Compute Engine インスタンスで実行されるローカル リージョンに 2 つ目の Data Guard スタンバイ データベースが追加されます。この構成では、プライマリ データベースと Compute Engine で実行されているスタンバイ間の同期レプリケーションを使用して、プライマリ リージョン内でのデータ損失ゼロを保証します。

リージョン内のスタンバイ データベースを作成すると、アプリケーションに影響を与えることなくデータベースのフェイルオーバーとスイッチオーバー オペレーションを実行できます。データベースのロール変更中、Oracle のクライアントに関する考慮事項に従って構成されたアプリケーションは、手動操作を必要とせずに新しいプライマリ データベースに自動的に再接続します。適切に構成されたアプリケーションでは、フェイルオーバー イベント中のダウンタイムは 2 分未満です。

Compute Engine のスタンバイ データベースは RAC を実行しませんが、プライマリ データベースとして実行されているときに通常のアプリケーション トラフィックをサポートするようにサイズを設定する必要があります。このインスタンスは、スタンバイとして動作している間は小さいシェイプで実行し、フェイルオーバー イベント中にスケールアップするか、常にフル容量で実行できます。フェイルオーバー イベント中にインスタンスのサイズを変更すると、サイズ変更オペレーション中にインスタンスを再起動する必要があるため、RTO に悪影響を与えます。

ファスト スタート フェイルオーバーは、オブザーバーを使用して Data Guard ブローカーを実行している Compute Engine インスタンスで構成されます。オブザーバーは、すべてのプライマリ データベースとスタンバイ データベースに接続する基本的な Oracle クライアントを実行します。オブザーバーがプライマリ データベースの障害を検出すると、いずれかのスタンバイ データベースへのフェイルオーバーを開始します。ゴールドティアのデプロイを使用する場合は、Compute Engine で実行されているスタンバイ データベースを優先フェイルオーバー ターゲットとして構成する必要があります。

オブザーバーは、プライマリ データベースとスタンバイ データベースとは別のリージョンに配置することを Oracle は推奨しています。これにより、リージョン障害やネットワーク分割イベントに対する最適な保護が提供されます。3 つ目のリージョンを使用できない場合は、オブザーバーをプライマリ リージョンにインストールし、ニアサイト スタンバイとは異なるゾーンで実行する必要があります。

次の図は、デプロイの例を示しています。

高速フェイルオーバーを備えた Oracle プラチナ デプロイの Data Guard。

図に示すデプロイの例は次のとおりです。

  • us-west2 リージョンの Bare Metal Solution サーバーで RAC が実行されているプライマリ データベース。
  • us-west2 リージョンの Compute Engine インスタンスで実行されているニアサイト スタンバイ データベース。
  • us-east4 リージョンの Bare Metal Solution サーバーで実行されているリモート スタンバイ データベース。
  • us-central1 リージョンの Compute Engine インスタンスで実行されている Data Guard オブザーバー。

同期レプリケーションは、Compute Engine インスタンスで実行されているリージョン内のスタンバイ データベース用に構成され、非同期レプリケーションはリモート リージョン用に構成されます。いずれの場合も、REDO はプライマリ データベースからスタンバイに送信されます。REDO はスタンバイ データベース間で転送されません。オーブザーバーは 3 番目のリージョンに構成され、構成内のすべてのデータベースへの接続を維持します。アプリケーション インスタンスはプライマリ リージョンで構成され、Bare Metal Solution サーバー上のプライマリ データベース（または、フェイルオーバーとスイッチオーバー オペレーション中の Compute Engine インスタンス上のデータベース）に接続します。アプリケーション インスタンスは、障害発生時にアプリケーション トラフィックを処理するように、Compute Engine の us-east4 リージョンに構成されています。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間

RAC を使用している場合は数秒
障害: 破損 0 60 秒未満
障害: リージョン拡張の失敗 0 60 秒未満
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間。

RAC を使用している場合は数秒
データベースのメジャー アップグレード 0 1～2 時間

DBMS_ROLLING を使用してアップグレードを実行する場合は分単位。

プラチナ デプロイ 2: レプリケーション用の GoldenGate

プラチナ デプロイ 2 では、レプリケーションに Oracle GoldenGate を使用します。GoldenGate はブロックレベルでレプリケートしないためです。これにより、各データベースがアプリケーション セッションの読み取りと書き込みを独立して処理できます。変更が双方向にレプリケートされるため、アクティブ / アクティブ データベース構成が可能です。

アクティブ / アクティブのデプロイに commit する前に、アプリケーションを徹底的に検証し、競合の検出と解決を考慮する必要があります。

Data Guard とは異なり、GoldenGate では Oracle データベース サーバーに追加のソフトウェアをインストールしてメンテナンスする必要があります。アクティブ / アクティブのデプロイでは、通常、マルチサイト データベース デプロイを活用するために、高度なスキーマとアプリケーションの設計が必要です。多くの事前パッケージ化されたアプリケーションは、このタイプのアーキテクチャをサポートしていません。

すべてのレプリケーションについて GoldenGate に依存するデプロイでは、論理レプリケーションの非同期性により、データ損失なしの RPO をサポートできません。Data Guard を使用して Compute Engine で実行されているローカル スタンバイ データベースをデプロイすると、同期レプリケーションで RPO をゼロにできます。

次の図は、デプロイの例を示しています。

Oracle プラチナ デプロイの GoldenGate によるレプリケーション。

サービス停止 サービス停止の種類 RPO RTO
計画外 復元可能なノードまたはインスタンスの障害 0 インスタンスの再起動に必要な時間
障害: 破損 数秒～数分

各ロケーションで Data Guard を使用している場合は 0

 0
障害: リージョン拡張の失敗 数秒～数分

各ロケーションで Data Guard を使用している場合は 0

 0
計画済み データベース パッチ、OS / FW のアップデート 0 インスタンスの更新と再起動にかかる時間。

RAC を使用している場合は数秒
データベースのメジャー アップグレード 0 0