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 環境よりも保護レベルの低いモデルを使用するのが一般的です。

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

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 FUSE は、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 を使用したバックアップ

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

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

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

ブロンズ デプロイの Google Cloud のバックアップと DR。

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

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

シルバー

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

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

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

Silver モデルでは、四半期のパッチ適用アクティビティ中にダウンタイムまたはメンテナンスの時間枠が発生することがあります。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 Cloud Compute Engine で実行されているインスタンスに同期レプリケーションを提供するゴールドモデルを選択できます。

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

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

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

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

Oracle Gold の遠隔同期。

図の構成例は、us-west2 で実行されているプライマリ RAC データベースと、Compute Engine で実行されているアプリケーションを示しています。us-west2 内の Compute Engine インスタンスが遠隔同期インスタンスを実行し、同期再実行を受信しています。ファー シンク インスタンスは、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 クライアントを実行します。オブザーバーがプライマリ データベースの障害を検出すると、いずれかのスタンバイ データベースへのフェイルオーバーを開始します。Gold ティアのデプロイを使用する場合は、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