Autonomous Data Guardを使用したクリティカルなデータベースの障害や災害からの保護

Autonomous Data Guard機能を使用すると、障害、災害、ヒューマン・エラーまたはデータ破損があっても、ミッション・クリティカルなアプリケーションでクリティカルな本番データベースを継続的に使用することができます。このような機能は、ディザスタ・リカバリと呼ばれることがよくあります。

Autonomous AI Database on Dedicated Exadata Infrastructureでは、Autonomous Data GuardをAutonomous Container Databaseレベルで構成および管理します。

Autonomous Data Guardについて

Autonomous Data Guardは、完全に分離された2つのデータベース・コピー(アプリケーションが接続して使用するプライマリ・データベースと、プライマリ・データベースと同期されたコピーであるスタンバイ・データベース)を作成してメンテナンスします。その後、なんらかの理由でプライマリ・データベースが使用できなくなった場合は、Autonomous Data Guardはスタンバイ・データベースをプライマリ・データベースに変換できるため、アプリケーションへのサービス提供が開始されます。

プライマリ・データベースとスタンバイ・データベースは、お互いのピア・データベースと呼ばれることがよくあります。Autonomous Container Databaseごとに最大2つのスタンバイ・データベースを設定できます。

ノート: Autonomous Data Guardによって提供されるデータベース可用性機能の利性を最大限に得るためには、透過的アプリケーション・コンティニュイティ(TAC)を使用するようにアプリケーションを構成する必要があります。

次の図は、各スタンバイ・データベースとプライマリ・データベースの同期を維持する方法を示しています。

図autonomous-data-guard.pngの説明

プライマリ・データベースに対して行われた変更は、プライマリ・データベースのREDOログに記録されます。Autonomous Data Guardは、これらのREDOレコードをストリームとしてネットワーク経由でスタンバイ・データベースのREDOログに送信します。次に、スタンバイ・データベースがこれらのレコードをスタンバイ・データベースに適用します。このようにして、スタンバイ・データベースはプライマリ・データベースと常に同期されます。

同期はほぼ瞬時に行われますが、前述のプロセスで示したように、2つの操作(REDOレコードをスタンバイ・データベースに転送する操作と、REDOレコードをスタンバイ・データベースに適用する操作)に時間がかかります。このうち1つはトランスポート・ラグと呼ばれ、もう1つは適用ラグと呼ばれています。Autonomous AI Databaseの現在のラグ値は、データベースのAutonomous Data Guardの「詳細」ページから表示できます。コンテナ・データベース内のすべてのAutonomous AIデータベースの「詳細」ページから、コンテナ・データベース内のすべてのAutonomous AIデータベースの現在のラグ値を表示できます。

ノート:複数のスタンバイ・データベースでは、カスケードREDO転送はサポートされていません。

Autonomous Data Guardの構成

Autonomous AI Database on Dedicated Exadata Infrastructureでは、Autonomous Container Database (ACD)レベルでAutonomous Data Guardを構成および管理します。Oracle Cloud Infrastructureコンソールを使用して、すでにプロビジョニングされているACDに対してAutonomous Data Guardを有効にし、その「詳細」ページから最大2つのスタンバイACDを追加できます。手順については、Autonomous Container DatabaseでのAutonomous Data Guardの有効化および2番目のスタンバイAutonomous Container Databaseの追加を参照してください。

• Oracle Cloud Infrastructure (OCI)のACDとAmazon Web Services (AWS)のACDの間にAutonomous Data Guardを作成および管理できるようになりました。

• スタンバイACDをAWSリージョンからOCIリージョンですでにプロビジョニングされているACDに追加できます。または、OCIリージョンのスタンバイACDをAWSリージョンですでにプロビジョニングされているACDに追加することもできます。

Autonomous Data Guardを構成する前に、次の点に注意してください:

• Autonomous Data Guard設定でプライマリ・データベースとスタンバイ・データベース間のTCPトラフィックを許可するには、Exadata Cloud@CustomerにデプロイされたAutonomous AIデータベースのポート1522がオープンされている必要があります。

• 次の3日以内にアクティブなメンテナンス実行がスケジュールされているACDでAutonomous Data Guardを有効にすることはできません。最初にアクティブ・メンテナンスを実行してからAutonomous Data Guardを有効にするか、2番目のスタンバイ・データベースが追加されるまで開始されないようにメンテナンス実行スケジュールを変更できます。

• 2番目のスタンバイ・データベースを追加するには、1番目のスタンバイ・データベースの自動非ローリング再起動が必要です。プライマリ・データベースは、この非ローリング再起動の影響を受けません。

顧客管理キーを使用したAutonomous Data Guardの構成

Autonomous AI Database on Dedicated Exadata Infrastructureでは、Autonomous Container Database (ACD)レベルで顧客管理キーを使用してAutonomous Data Guardを構成および管理できます。Oracle Cloud Infrastructureコンソールを使用して、すでにプロビジョニングされているACDに対してAutonomous Data Guardを有効にし、その「詳細」ページから最大2つのスタンバイACDを追加できます。手順については、Autonomous Container DatabaseでのAutonomous Data Guardの有効化および2番目のスタンバイAutonomous Container Databaseの追加を参照してください。

顧客管理キーを使用してAutonomous Data Guardを構成する前に、次の点に注意してください:

• Oracle Cloud Infrastructure Key Management System (OCI KMS)を使用しており、クロスリージョンAutonomous Data Guardを有効にする場合:

  • 最初に、OCIボールトをスタンバイ・データベースを追加するリージョンにレプリケートする必要があります。詳細は、ボールトおよびキーのレプリケートを参照してください。

  • プライマリ・データベースとスタンバイ・データベースは、最大2つのリージョンにのみ含めることができます。つまり、2番目のスタンバイを追加し、1番目のスタンバイにクロスリージョンをすでに使用している場合、2番目のスタンバイはプライマリ・リージョンまたは1番目のスタンバイ・リージョンに存在する必要があります。

  ノート:クロスリージョン・ボールト・レプリケーション機能が導入される前に作成された仮想ボールトは、リージョン間でレプリケートできません。別のリージョンでレプリケートする必要のあるボールトがあり、そのボールトでレプリケーションがサポートされていない場合、新しいボールトおよび新しいキーを作成します。ただし、すべてのプライベート・ボールトはリージョン間レプリケーションをサポートしています。詳細は、仮想ボールトのクロス・リージョン・レプリケーションを参照してください。

• Oracle Key Vault (OKV)を使用しており、クロスリージョンAutonomous Data Guardを有効にする場合は、OKVクラスタの接続IPアドレスをキー・ストアに追加していることを確認してください。

ノート: OCIリージョンのACDとAWSリージョンのACDの間にAutonomous Data Guardを構成する場合は、Oracle管理キーまたはOracle Key Vaultのみを使用できます。OCI KMSキーまたはAWS KMSキーは使用できません。

ロールの遷移および操作

Autonomous Container Database (ACD)の作成後、スイッチオーバーまたはフェイルオーバー操作のいずれかを使用して、ピア・データベースのロールを変更できます。自動フェイルオーバーが有効な場合、Autonomous Data Guardは、なんらかの理由でプライマリ・データベースが使用できなくなったときに、フェイルオーバー操作を自動的に実行します。

スイッチオーバーは、プライマリ・データベースとそのスタンバイ・データベースのロールを交替させるものです。スイッチオーバーでは、データ損失がないことが保証されます。スイッチオーバー中、プライマリ・データベースはスタンバイ・ロールに遷移し、スタンバイ・データベースはプライマリ・ロールに遷移します。スイッチオーバー操作を実行するには、Autonomous Data Guard構成のロールの切替えを参照してください。

フェイルオーバーは、プライマリ・データベースが使用できなくなった場合に行われます。フェイルオーバーが行われると、スタンバイ・データベースがプライマリ・ロールに遷移します。自動フェイルオーバーが有効になっていない場合は、Autonomous Data Guard構成でのスタンバイへのフェイルオーバーの説明に従って、手動フェイルオーバーを実行できます。

フェイルオーバー操作後のデータベースの可用性およびステータスは、2つのリカバリ目標によって特徴付けられます:

• リカバリ時間目標(RTO)。RTOは、フェイルオーバー後にアプリケーションでデータベースが使用可能になるまでに必要な最大時間であり、ある程度は障害発生時の適用ラグに関連しています。Autonomous Data Guardの場合、RTOは数秒から2分までです。

• リカバリ・ポイント目標(RPO)。RPOは、障害が発生したプライマリ・データベースで起こる可能性のあるデータ損失の最大期間であり、ある程度は障害発生時のトランスポート・ラグに関連しています。Autonomous Data Guardの場合、RPOはほぼゼロです。

フェイルオーバー後、障害が発生したプライマリは無効化されたスタンバイになり、データベース接続に使用できなくなります。reinstate操作を実行すると、再度有効にし、正常なスタンバイに変更できます。障害が発生したプライマリがスタンバイとして回復されたら、スイッチオーバーを実行して元のプライマリ・ロールに戻すことができます。回復操作を実行するには、Autonomous Data Guard構成の無効なスタンバイの回復を参照してください。

自動フェイルオーバーまたはファストスタート・フェイルオーバー

自動フェイルオーバーでは、リージョン障害、可用性ドメインの障害、ExadataインフラストラクチャまたはAutonomousのExadata VMクラスタ(AVMC)の障害、またはACD自体の障害によってプライマリACDが使用できなくなったと、自動的にスタンバイACDにフェイルオーバーします。これは、ファストスタート・フェイルオーバーとも呼ばれます。

ACDでAutonomous Data Guardを構成している間は、自動フェイルオーバーを有効にできません。自動フェイルオーバーは、ACDの「詳細」ページからAutonomous Data Guard設定を更新するときにのみ有効または無効にできます。

ノート:クロスリージョンAutonomous Data Guard設定でExadata Cloud@CustomerにデプロイされたAutonomous AIデータベースでは、自動フェイルオーバーを有効にできません。

1つ目のスタンバイACDに対して自動フェイルオーバーが有効になっている2つ目のスタンバイACDを追加することはできません。そのため、2番目のスタンバイACDを作成する前にAutonomous Data Guard設定の更新を使用して自動フェイルオーバーを無効にし、必要に応じて後で再度有効にします。

最大パフォーマンス・モードと最大可用性保護モードの両方で、自動フェイルオーバーがサポートされています:

• 最大可用性モードでは、自動フェイルオーバーによってデータ損失ゼロを保証します。

• 最大パフォーマンス・モードでは、自動フェイルオーバーにより、スタンバイ・データベースが高速スタート・フェイルオーバー・ラグ制限に指定された値を超えてプライマリ・データベース遅れないことが保証されています。デフォルトでは、高速スタート・フェイルオーバー・ラグ制限は30秒に設定され、最大パフォーマンスのモードにのみ適用されます。この場合、自動フェイルオーバーは、スタンバイの適用ラグ(潜在的なデータ損失)が構成されたラグ制限を超えていない場合にのみ可能です。ファスト・スタート・フェイルオーバーのラグ制限は、5から3600までの任意の値に変更できます。

詳細は、Autonomous Data Guard設定の更新を参照してください。

ハードウェア障害、可用性ドメインの停止およびリージョンの停止の他に、次に示すように、ファストスタート・フェイルオーバーをトリガーする可能性のあるデータベースの状態がさらにいくつかあります:

データベース・ヘルス条件	説明
破損した制御ファイル	ディスク障害により、制御ファイルが完全に破損しました。
破損したディクショナリ	クリティカルなデータベースのディクショナリの破損。現時点では、この状態は、データベースが開いている場合にのみ検出されます。
データファイル書込みエラー	書き込みエラーは、一時ファイル、システム・データ・ファイル、UNDOファイルなど、あらゆるデータ・ファイルで発生します。

自動フェイルオーバーの結果、障害が発生したプライマリ・データベースのロールは無効スタンバイになり、しばらくすると、スタンバイ・データベースがプライマリ・データベースのロールを引き継ぎます。自動フェイルオーバーが終了すると、フェイルオーバーが発生したことを通知するメッセージが無効になっているスタンバイ・データベースの詳細ページに表示されます。

サービスが以前のプライマリAutonomous Container Databaseの問題を解決した後、手動スイッチオーバーを実行して、両方のデータベースを初期ロールに戻すことができます。スタンバイ・データベースをプロビジョニングしたら、次のようなスタンバイ・データベースに関連する様々な管理タスクを実行できます:

• プライマリ・データベースをスタンバイ・データベースに手動でスイッチオーバーします。

• プライマリ・データベースをスタンバイ・データベースに手動でフェイルオーバーします。

• フェイルオーバー後にプライマリ・データベースをスタンバイ・ロールに戻します。

• スタンバイ・データベースを終了します。

複数のスタンバイ・データベースおよび自動フェイルオーバーを使用するAutonomous Data Guard設定の場合:

• 手動フェイルオーバーでは、元のプライマリ・データベース(新しいスタンバイ・データベース)を手動で回復する必要があります。

• 自動フェイルオーバーが発生するたびに、Autonomous AI Database on Dedicated Exadata Infrastructureは、古いプライマリをスタンバイとして回復しようとします。ただし、その試行が失敗した場合は、手動で回復する必要があります。

スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、スタンバイAutonomous Container Database (ACD)をスナップショット・スタンドバイACDに変換することで作成される、完全に更新可能なスタンバイ・データベースです手順については、フィジカル・スタンバイからスナップショット・スタンバイへの変換を参照してください。

スナップショット・スタンバイ・データベースは、プライマリ・データベースからのREDOデータを受信およびアーカイブします。ただし、適用されません。ただし、プライマリ・データベースからのリアルタイムの変更が適用されないため、リカバリ時間目標(RTO)が増加します。

スナップショット・スタンバイ機能は様々なユース・ケースをサポートしていますが、主要なユース・ケースを次に示します:

• 初期構成を実行するには、プライマリおよびスタンバイ・アプリケーション・インスタンスを読取り/書込みモードでプライマリおよびスタンバイ・データベースに接続します。

• 最初にスナップショット・スタンバイ・データベースにパッチを適用し、スタンバイ・アプリケーション・インスタンスでテストして、パッチの安定性を確認します。そのため、まずフィジカル・スタンバイをスナップショット・スタンバイに変換して、パッチをスナップショット・スタンバイに適用する必要があります。

ノート:自動フェイルオーバーを有効にしてフィジカル・スタンバイAutonomous Container Databaseをスナップショット・スタンバイに変換することはできません。

スナップショット・スタンバイへの変換中に、スナップショット・モードでのみアクティブな新しいデータベース・サービスをアクティブ化するか、プライマリ・データベースで使用された同じサービス・セットを使用できます。ただし、スナップショット・スタンバイ・データベースでプライマリ・データベース・サービスをアクティブ化すると、スナップショット・スタンバイ接続リクエストがプライマリ・データベースに転送されるか、または誤ったデータベース接続文字列を使用した場合はその逆になる可能性があります。したがって、プライマリおよびスナップショット・スタンバイ・データベースへの接続時には、適切な接続文字列を使用するように注意する必要があります。

ノート:スナップショット・スタンバイを使用して新しいサービスを作成すると、スナップショット・スタンバイACD内のすべてのAutonomous AIデータベースのウォレットが更新されます。データベースにアクセスするには、スタンバイAutonomous AIデータベースからウォレットをリロードし、スナップショット・スタンバイ接続文字列を使用します。

Oracle Cloud Infrastructure (OCI)から、スナップショット・スタンバイACDをフィジカル・スタンバイACDに手動で戻すことができます。詳細な手順は、スナップショット・スタンバイからフィジカル・スタンバイへの変換を参照してください。スナップショット・スタンバイが手動でフィジカル・スタンバイに変換されない場合、作成から7日後に自動的にフィジカル・スタンバイに変換されます。いずれの場合も、スナップショット・スタンバイをフィジカル・スタンバイに変換すると、スナップショット・スタンバイ・データベースへのすべてのローカル更新が破棄され、プライマリ・データベースから受信したREDOデータが適用されます。

スタンバイACDがスナップショット・スタンバイ・モードの場合、プライマリACDで次の操作を実行できません。

• Autonomous AIデータベースの作成または終了

• Autonomous AI Databaseのスケールアップまたはスケールダウン

• Autonomous AIデータベースのリストア

状況に応じて、プライマリ・データベースからスナップショット・スタンバイに手動でフェイルオーバーできます。その場合、フェイルオーバーによって、スナップショット・スタンバイに対して行われたすべてのローカル更新が破棄され、プライマリ・データベースからデータが適用され、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに変換されます。ステップバイステップの手順については、Autonomous Data Guard構成でのスタンバイへのフェイルオーバーを参照してください。

プライマリ・データベースとそのスナップショット・スタンバイ・データベース間のスイッチオーバーは許可されません。スイッチオーバーを試行する前に、スナップショット・スタンバイをフィジカル・スタンバイに手動で変換する必要があります。

クライアント・アプリケーションからのスタンバイ・データベースへのアクセス

Autonomous Data Guard構成では、クライアント・アプリケーションは通常、プライマリ・データベースに接続して操作を実行します。

フィジカル・スタンバイ・データベースへの接続

この通常の接続に加えて、Autonomous Data Guardには、この通常の接続に加え、読取り専用操作を実行するクライアント・アプリケーションをスタンバイ・データベースに接続します。このオプションを利用するには、Autonomous AI Databaseの事前定義済データベース・サービス名の説明に従って、クライアント・アプリケーションが「_RO」(読取り専用)を含むデータベース・サービス名を使用してデータベースに接続します。

スナップショット・スタンバイ・データベースへの接続

Autonomous Data Guardでは、読取り/書込み操作を実行するクライアント・アプリケーションをスナップショット・スタンバイ・データベースに接続することもできます。これらの操作はスナップショット・スタンバイ・データベースにローカルであり、プライマリ・データベースを変更しません。スナップショット・スタンバイ・データベースに接続するために、クライアント・アプリケーションは、Autonomous AIデータベースの事前定義済データベース・サービス名の説明に従って、「_SS」(スナップショット・スタンバイの場合)を含むデータベース・サービス名を使用できます。

ノート:スタンバイ・データベースがスナップショット・スタンバイ・モードの場合、名前に"_RO"サービスを含むすべてのデータベース・サービスは非アクティブであり、接続に使用できません。

タイム・ラグのモニタリング

Autonomous Data Guardを使用するデータベースの実行中に、「Autonomous Data Guardグループ」を選択することで、データベース(またはコンテナ・データベース)の「詳細」ページからトランスポート・ラグおよび適用ラグ の時間をモニターできます。OCIコンソールまたは可観測性APIを使用して、トランスポート・ラグを監視し、アラームおよび通知を構成することもできます。詳細は、Autonomous AI Databaseメトリックを使用したデータベース可観測性を参照してください。

時間の経過とともに、データベースのワークロードの増減に伴って小さな変動はあるはずです。ただし、ラグの時間の継続的な上昇傾向に気付いた場合は、次のアクションを実行して状況を解決できます:

• 適用ラグの上昇傾向。 適用ラグの継続的な上昇傾向は、スタンバイ・データベースにプライマリ・データベースからのREDOレコードに対応するための十分な容量がないことを示します。この状況を解決するには、専用Autonomous AIデータベースへのCPUまたはストレージ・リソースの追加の説明に従って、データベースのOCPUのスケール・アップを行います。

• トランスポート・ラグの上昇傾向。 トランスポート・ラグの継続的な上昇傾向は、ネットワーク・パフォーマンスの問題を示します。Oracle Cloudの運用スタッフがネットワーク・パフォーマンスを常にモニターしているため、ユーザーは何もアクションを実行しなくても状況は解決します。ただし、必要な場合は、My Oracle Supportでのサービス・リクエストの作成の説明に従って、サービス・リクエストを発行し、運用スタッフに状況の対処を依頼することができます。

Autonomous Data Guard構成オプション

Autonomous Data Guardを構成するときに、スタンバイ・データベースを作成するExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースを指定し、使用するデータ保護モードを選択します。

スタンバイに使用するExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースを指定する場合、次の選択肢があります:

• プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタとは異なるリージョン:

  これを選択すると、リージョン全体への外部ネットワーク接続や電力の大幅な損失などの障害に対して最高レベルの保護が提供されます。

  このクロスリージョン保護を最大限に利用するには、クロスリージョン保護をサポートするようにアプリケーション層を構成する必要もあります。そのため、アプリケーション層がすでにこのように構成されている場合、またはクロスリージョン保護をサポートするようにアプリケーション層を再構成する場合は、このオプションを選択することをお薦めします。

  別のリージョンでスタンバイ・データベースを検索する場合、Oracleでは「最大パフォーマンス」保護モードを使用することをお薦めします。

• In a different availability domain (AD) from the primary database's Exadata Infrastructure and Autonomous Exadata VM Cluster:

  これを選択すると、外部ネットワーク接続やリージョン内の可用性ドメインの電力が壊滅的に失われたなど、災害に対する高いレベルの保護が提供されます。

  これを選択すると、データ保護とアプリケーション層の構成のシンプルさとのバランスをうまく取ることができます。

  別の可用性ドメインでスタンバイ・データベースを検索する場合、Oracleでは「最大可用性」保護モードを使用することをお薦めします。

• In the same availability domain (AD) as the primary database's Exadata Infrastructure and Autonomous Exadata VM Cluster:

  これを選択すると、障害に対する保護は最小レベルになります。これを選択することはお薦めしません。

  プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースが、可用性ドメインが1つのみのリージョンにある場合、Oracleでは「別のリージョン内」オプションを使用することをお薦めします。

  同じ可用性ドメインでスタンバイ・データベースを検索する場合、Oracleでは「最大可用性」保護モードを使用することをお薦めします。

• プライマリ・データベースExadataインフラストラクチャおよびAutonomous Exadata VMクラスタとは異なるテナンシ内:

  適用対象: Oracle Public Cloudのみ

  この選択により、プライマリ・データベースとは異なるテナンシにスタンバイ・データベースを追加できるため、データベースのフェイルオーバーまたはクロステナンシ・スタンバイ・データベースへのスイッチオーバーが可能になります。リモート・テナンシにスナップショット・スタンバイを作成することもできます。クロステナンシ・スタンバイ・データベースを持つことは、テナンシ間のデータベース移行に役立ちます。

  クロステナンシ・スタンバイ・データベース:

  • ECPUまたはOCPUコンピュート・モデルで有効にできます。スタンバイ・データベースは、プライマリ・データベースと同じコンピュート・モデルを使用する必要があります。

  • 自動フェイルオーバーをサポートします。ただし、自動フェイルオーバーは、クロスリージョンAutonomous Data Guard設定でExadata Cloud@CustomerにデプロイされたAutonomous AIデータベースに対して有効にできません。

  • Oracle Cloud Infrastructureコンソールを使用して追加することはできません。クロス・テナンシ・スタンバイ・データベースを追加できるのは、CLIまたはREST APIのみです。スタンバイ・データベースを追加すると、クロステナンシ・スタンバイ・データベースを表示し、Oracle Cloud Infrastructureコンソールからクロステナンシ・スタンバイ・データベースへのフェイルオーバーまたはスイッチオーバーを実行できます。

保護モードについて

Autonomous Data Guardには、次のデータ保護モードがあります:

• 最大可用性 この保護モードは、プライマリ・データベースの可用性に影響を与えない範囲の最上位レベルのデータ保護を提供します。

  プライマリ・データベースは、データが(ディスクに書き込まれたことではなく)スタンバイで受信されたことを確認するまで、トランザクションをコミットしません。プライマリ・データベースがこの確認を30秒以内に受信しない場合、最大パフォーマンス・モードのときと同じように動作して、再確認を再び適時に受信するまでプライマリ・データベースの可用性を保持する。

  この保護モードでは、特定の二重障害の場合(スタンバイ・データベースの障害発生後のプライマリ・データベースの障害など)を除いて、ゼロ・データ損失が保証されます。

• 最大パフォーマンス これはデフォルトの保護モードです。これは、プライマリ・データベースのパフォーマンスに影響を与えない範囲で可能な最高レベルのデータ保護を提供します。

  プライマリ・データベースは、トランザクションによって生成されたすべてのREDOデータがそのオンラインREDOログに書き込まれるとすぐに、そのトランザクションをコミットします。また、REDOデータをスタンバイ・データベースに送信しますが、これはトランザクション・コミットとは非同期に実行されるため、プライマリ・データベースのパフォーマンスはスタンバイ・データベースへのREDOデータの書込みの遅延の影響を受けません。

  この保護モードを使用すると、最大可用性モードよりもデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響は最小限になります。

Autonomous Data Guard設定の保護モードは、Oracle Cloud Infrastructure (OCI)コンソールから変更できます。ステップバイステップの手順については、Autonomous Data Guard設定の更新を参照してください。

(Autonomous Data Guard機能の基礎となる) Oracle Data Guardの保護モードの詳細は、『Oracle Data Guard概要および管理』のOracle Data Guardの保護モードに関する項を参照してください。

Autonomous Data Guardの構成時のベスト・プラクティス

Autonomous AI DatabaseではAutonomous Data Guardで最大2つのスタンバイACDを作成できますが、要件に応じて、単一または複数のスタンバイACDを使用することを選択できます。ただし、Autonomous AI Databaseが提供する最も回復力のあるディザスタ・リカバリ・オプションを使用するには、1つのローカル・スタンバイACDと1つのリモートまたはクロスリージョン・スタンバイACDをデータ保護モードとして最大可用性とともに追加できます。

この設計の利点について理解しましょう。

• ローカル・スタンバイ:

  • 同じリージョン内のローカル・スタンバイへの自動フェイルオーバーにより、ローカルな障害の大幅な分離とアプリケーション・フェイルオーバーを簡略化します。

  • ローカル・スタンバイ・データベースのビジネス価値は、データ損失ゼロのフェイルオーバーおよびアプリケーションの停止時間が数秒に短縮された状態で確認されます。

  • アプリケーションは、自動的に透過的にローカル・スタンバイにフェイルオーバーし、アプリケーション・サーバーとデータベース間で同じレイテンシを維持します。これは、OLTPおよびパッケージ・アプリケーションにとって特に重要です。レイテンシが大きいほど、スループットおよびアプリケーション全体のレスポンス時間が大きく影響する可能性があるためです。

• リモート・スタンバイ:

  • リージョン障害により、プライマリ・システムとローカル・スタンバイ・システムにアクセスできない場合、アプリケーションとデータベースはリモート・スタンバイにフェイルオーバーできます。

  • リージョン障害が発生したときにデータベースの停止時間がまだ非常に低い場合でも、DNS、アプリケーションおよびデータベースをセカンダリ・リージョンでフェイルオーバーする操作に必要な追加のオーケストレーションにより、アプリケーションの停止時間が大きくなる可能性があります。

• 最大可用性:

  • 自動フェイルオーバーまたはファスト・スタート・フェイルオーバー(FSFO)が有効な場合、プライマリACDが使用できなくなると、Autonomous Data Guardはデータ損失ゼロでローカル・スタンバイにフェイルオーバーし、アプリケーションのデータベース・レイテンシは変更されません。

  • 自動フェイルオーバーまたはファスト・スタート・フェイルオーバー(FSFO)が有効な場合、プライマリ・リージョン全体にアクセスできなくなると、データが失われる可能性があるため、システムはリモート・スタンバイにフェイルオーバーします。

Autonomous Data Guardが標準管理操作に与える影響

Autonomous Container DatabaseでAutonomous Data Guard構成のプライマリ・コンテナ・データベースおよびスタンバイ・コンテナ・データベースに実行する標準管理操作は、標準のコンテナ・データベースと比較して、その仕組みが異なる場合があります。次のリストでは、これらの違いについて説明します。

• メンテナンス・スケジュールの変更

  プライマリ・コンテナ・データベースとそのスタンバイのメンテナンス・スケジュールはリンクされています: スタンバイのメンテナンスは、プライマリ・コンテナ・データベースのメンテナンスの何日か前に実行されます。デフォルトは7日です。プライマリ・コンテナ・データベースを作成するとき、または後でメンテナンス詳細を編集するときに、1日から7日までの値を選択できます。

• メンテナンス・タイプの変更

  プライマリ・コンテナ・データベースとそのスタンバイのメンテナンス・タイプは同じである必要があります。プライマリ・コンテナ・データベースを作成するとき、または後でメンテナンス詳細を編集するときに、プライマリとスタンバイの両方のメンテナンス・タイプを選択します。

• 自動のバックアップの無効化

  Autonomous Data GuardでAutonomous Container Database (ACD)をプロビジョニングしている間、自動バックアップを無効にできません。

• スケジュール済メンテナンスの管理

  プライマリ・コンテナ・データベースとそのスタンバイのスケジュール済メンテナンスは、個別に管理できます。ただし、2つのメンテナンスはリンクされているため、スケジュール済メンテナンス時間を上書きするように選択した場合は、プライマリの前にスタンバイでスケジュール済メンテナンスを実行する必要があります。

• 別のコンパートメントへの移動

  プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは、標準のコンテナ・データベースと同じように、個別に移動できます。ただし、標準のコンテナ・データベースの場合と同様に、適切なクラウド・ユーザー・グループからのみコンテナ・データベースをアクセス可能な状態に保つために、コンテナ・データベースを移動する際には細心の注意を払う必要があります。

• 再開

  プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは、標準のコンテナ・データベースと同じように、個別に再起動できます。

• 暗号化キーのローテーション

  暗号化キーは、プライマリACDまたはプライマリ・データベースからローテーションできます。

• 終了

  プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは個別に終了できます。ただし、プライマリ・コンテナ・データベースの終了とスタンバイ・コンテナ・データベースの終了の結果は異なります:

  • プライマリ・コンテナ・データ・データベースを終了すると、プライマリ・コンテナ・データ・データベースとスタンバイ・コンテナ・データ・データベースの両方を終了します。Autonomous AIデータベースを含むプライマリ・コンテナ・データベースは終了できません。

  • スタンバイ・コンテナ・データベースを終了して、スタンバイ・コンテナ・データベースを終了し、Autonomous Data Guard構成から削除します。プライマリのみが残っている場合は、Autonomous Data Guard構成が削除され、プライマリがスタンドアロン・コンテナ・データベースになります。

ステップバイステップ・ガイド

Autonomous Container DatabaseでのAutonomous Data Guard構成の管理に関するステップバイステップ・ガイダンスは、次を参照してください:

• Autonomous Container DatabaseでのAutonomous Data Guard使用可能

• Autonomous Data Guard構成のステータスの表示

• Autonomous Data Guard構成でのロールの切替え

• Autonomous Data Guard構成でのスタンバイへのフェイルオーバー

• Autonomous Data Guard構成での無効なスタンバイの回復

• Autonomous Data Guard設定の更新

• フィジカル・スタンバイからスナップショット・スタンバイへ変換

• スナップショット・スタンバイをフィジカル・スタンバイに変換

• 2番目のスタンバイAutonomous Container Databaseの追加

APIを使用して、Autonomous Data Guard構成を表示および管理することもできます。詳細は、Autonomous Data Guard構成を管理するためのAPIに関する項を参照してください。

関連コンテンツ

Autonomous Data Guard構成の管理