Autonomous Data Guardの構成

専用インフラストラクチャ上のOracle Autonomous Database on Dedicated Exadata Infrastructureでは、Autonomous Data GuardをAutonomous Container Database (ACD)レベルで構成および管理します。Autonomous Data Guardは、新しいACDとOracle Public CloudデプロイメントですでにプロビジョニングされているACDの両方に対して有効にできます。

Autonomous Container Databaseを作成する場合、「Autonomous Data Guardの有効化」オプションを選択し、スタンバイ・データベースの詳細(特に、その作成先のExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースと、使用する保護モード)を指定します。この2つの詳細に関する選択肢の詳細は、Autonomous Data Guard構成オプションを参照してください。

Autonomous Data Guardを有効にし、Oracle Cloud Infrastructure (OCI)コンソールの「詳細」ページから既存のACDにスタンバイACDを追加できます。ただし、次の2週間以内にアクティブなメンテナンス実行がスケジュールされているACDでAutonomous Data Guardを有効にすることはできません。スタンバイACDの追加操作が進行中の場合、そのACDのスケジュール済メンテナンスは、スタンバイの追加操作が完了するまで開始されません。手順については、Autonomous Container DatabaseでのAutonomous Data Guardの有効化を参照してください。

ロールの遷移および操作

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

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

フェイルオーバーは、プライマリ・データベースが使用できなくなった場合に行われます。フェイルオーバーが行われると、スタンバイ・データベースがプライマリ・ロールに遷移します。一般に、フェイルオーバー操作を手動で実行する必要はありません。ただし、まれに自動障害操作が失敗した場合は、Autonomous Data Guard構成のスタンバイへのフェイルオーバーの説明に従って、手動フェイルオーバーを実行できます。

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

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

障害が発生したプライマリ・データベースが再度使用可能になると、そのロールは「無効なスタンバイ」に設定されます。この時点で、回復操作を実行してそれを再度有効にします。回復操作を実行するには、Autonomous Data Guard構成の無効なスタンバイの回復を参照してください。

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

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

自動フェイルオーバーは、デフォルトでは有効になっていません。Autonomous Data Guardの構成中に「自動フェイルオーバーの有効化」オプションを選択して、自動フェイルオーバーを有効にできます。自動フェイルオーバーを有効または無効にするには、Autonomous Data Guard設定の更新を参照してください。

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

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

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

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

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

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

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

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

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

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

Autonomous Data Guardを使用するデータベースが実行されている間は、サイド・メニューの「リソース」で「Autonomous Data Guardアソシエーション」を選択して、データベース(またはコンテナ・データベース)の「詳細」ページからトランスポート・ラグおよび適用ラグの時間をモニターできます。

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

• 適用ラグの上昇傾向。適用ラグの継続的な上昇傾向は、スタンバイ・データベースにプライマリ・データベースからのREDOレコードに対応するための十分な容量がないことを示します。この状況を解決するには、専用Autonomous DatabaseへのCPUまたはストレージ・リソースの追加の説明に従って、データベースのOCPUをスケール・アップします。
• トランスポート・ラグの上昇傾向。トランスポート・ラグの継続的な上昇傾向は、ネットワーク・パフォーマンスの問題を示します。Oracle Cloudの運用スタッフがネットワーク・パフォーマンスを常にモニターしているため、ユーザーは何もアクションを実行しなくても状況は解決します。ただし、必要な場合は、My Oracle Supportでのサービス・リクエストの作成の説明に従って、サービス・リクエストを発行し、運用スタッフに状況の対処を依頼することができます。

保護モードについて

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の保護モードに関する項を参照してください。