機械翻訳について

Autonomous Data Guardを使用して、障害や障害から重要なデータベースを保護

Autonomous Data Guard機能を使用すると、障害、災害、人為的エラーまたはデータ破損にもかかわらず、クリティカルな本番データベースをミッション・クリティカルなアプリケーションで使用できるようにしておくことができます。 このような機能は、多くの場合、「障害リカバリ」と呼ばれます。

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

関連トピック

Autonomous Data Guardについて

Autonomous Data Guardは、データベースの2つの完全に独立したコピーを作成および維持: アプリケーションが接続して使用する「プライマリ」データベースと、プライマリ・データベースの同期コピーであるstandbyデータベース。 その後、なんらかの理由でプライマリ・データベースが使用できなくなった場合、Autonomous Data Guardはスタンバイ・データベースをプライマリ・データベースに自動的に変換し、そのためにアプリケーションのサービスを開始します。

プライマリ・データベースとスタンバイ・データベースは、多くの場合、相互にpeerデータベースと呼ばれます。

ノート:

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

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


autonomous-data-guard.epsの説明が続きます
「図autonomous-data-guard.epsの説明」

プライマリ・データベースに加えられた変更は、プライマリ・データベースREDOログに記録されます。 Autonomous Data Guardは、これらのREDOレコードをネットワーク上のストリームとしてスタンバイ・データベースのREDOログに転送します。 その後、スタンバイ・データベースはこれらのレコードをスタンバイ・データベースに適用します。 このようにして、スタンバイ・データベースはプライマリ・データベースとの同期が維持されます。

同期はほぼ瞬時ですが、前述のプロセスが示すように、時間を消費する2つの操作があります: REDOレコードをスタンバイ・データベースに転送し、REDOレコードをスタンバイ・データベースに適用します。 これらの最初は「トランスポート・ラグ」と呼ばれ、もう一方は「適用ラグ」と呼ばれます。 サイド・メニューのリソースで「Autonomous Data Guard関連付け」を選択すると、データベースの詳細ページからAutonomous Databaseの現在のラグ値を表示できます。 コンテナ・データベースの詳細ページから、コンテナ・データベース内のすべてのAutonomous Databaseの現在のラグ値を同じ方法で表示できます。

Autonomous Data Guardの構成

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

Autonomous Container Databaseを作成する場合、「Autonomous Data Guardの有効化」オプションを選択し、スタンバイ・データベースの詳細(特に、Exadata Infrastructureおよびそれを作成するAutonomous Exadata VM Clusterリソースおよび使用する保護モード)を指定します。 これら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はほぼゼロです。

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

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

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

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

ノート:

Exadata Cloud@Customerデプロイメントでクロス・リージョンAutonomous Data Guardが設定されているデータベースに対して自動フェイルオーバーを有効にすることはできません。
最大のパフォーマンス保護モードと最大可用性保護モードの両方が自動フェイルオーバーをサポートします:
  • 「最大可用性」モードでは、自動フェイルオーバーによってデータ損失ゼロが保証されます。
  • 「最大のパフォーマンス」モードでは、自動フェイルオーバーによって、スタンバイ・データベースが「ファスト・スタート・フェイルオーバー・ラグの制限」に指定された値を超えてプライマリ・データベースの後ろにないことが保証されます。 デフォルトでは、「ファスト・スタート・フェイルオーバー・ラグの制限」は30秒に設定され、最大パフォーマンス・モードにのみ適用されます。 この場合、自動フェイルオーバーは、構成されたデータ損失保証をアップヘルドにできる場合にのみ可能です。 ファスト・スタート・フェイルオーバー・ラグの制限は、5から3600の間の任意の値に変更できます。 手順については、「Autonomous Data Guard設定の更新」を参照してください。

    ノート:

    19.17および古いバージョンのACDでサポートされている最小高速開始ラグ制限値は30秒です。
ハードウェア障害、可用性ドメインの停止およびリージョンの停止の他に、次に示すように、ファスト・スタート・フェイルオーバーをトリガーできるデータベース・ヘルス条件がさらにいくつかあります:
データベース・ヘルス条件 説明
破損した制御ファイル ディスク障害のために制御ファイルが永続的に破損しました。
破損したディクショナリ 重要なデータベースのディクショナリが破損しました。 現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。
データファイル書込みエラー 一時ファイル、システム・データ・ファイル、UNDOファイルなど、すべてのデータ・ファイルで書込みエラーが発生しました。

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

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

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

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

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

スナップショット・スタンバイ機能では様々なユースケースがサポートされますが、主なユースケースは次のとおりです
  • プライマリおよびスタンバイのアプリケーション・インスタンスを読取り/書込みモードでプライマリ・データベースおよびスタンバイ・データベースに接続して、初期構成を実行します。
  • まず、スナップショット・スタンバイ・データベースにパッチを適用し、スタンバイ・アプリケーション・インスタンスでテストして、パッチの安定性を確認します。

ノート:

自動フェイルオーバーが有効になっているフィジカル・スタンバイAutonomous Container Databaseをスナップショット・スタンバイに変換することはできません。
スナップショット・スタンバイへの変換中に、スナップショット・モードでのみアクティブになっている新しいデータベース・サービスをアクティブ化するか、プライマリ・データベースで使用される同じサービス・セットを使用できます。 ただし、スナップショット・スタンバイ・データベースでプライマリ・データベース・サービスをアクティブ化すると、スナップショット・スタンバイ接続リクエストがプライマリ・データベースに転送される場合があります。その逆も、不正なデータベース接続文字列を使用する場合です。 したがって、プライマリおよびスナップショット・スタンバイ・データベースへの接続中に、適切な接続文字列を使用するように注意してください。

ノート:

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

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

スタンバイACDがスナップショット・スタンバイ・モードの場合、プライマリACDでは次の操作を実行できません:
  • Autonomous Databasesの作成または終了
  • スケール・アップまたはスケール・ダウンAutonomous Databases
  • Autonomous Databasesのリストア

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

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

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

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

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

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

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

Autonomous Data Guardでは、クライアント・アプリケーション「読取り/書込み操作を実行」をスナップショット・スタンバイ・データベースに接続することもできます。 スナップショット・スタンバイ・データベースに接続するには、「Autonomous Databasesの事前定義済データベース・サービス名」で説明されているように、クライアント・アプリケーションは「_SS」(スナップショット・スタンバイの場合)を含むデータベース・サービス名を使用できます。

ノート:

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

ラグ時間のモニタリング

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

データベースebbおよびフローのワークロードとして、時間の経過とともにわずかな変動が見られることが予想されます。 ただし、ラグ時間の上昇傾向が続くことに気付いた場合は、次のアクションを実行して状況を解決できます:

  • 適用ラグの上方トレンド。 適用ラグの継続的な上昇傾向は、スタンバイ・データベースにプライマリ・データベースからのREDOレコードを保持するための十分な容量がないことを示します。 この状況を解決するには、「専用Autonomous DatabaseへのCPUまたはストレージ・リソースの追加」の説明に従って、データベースのOCPUをスケール・アップします。
  • トランスポート・ラグの上昇トレンド。 トランスポート・ラグの継続的な上昇傾向は、ネットワーク・パフォーマンスの問題を示します。 Oracle Cloudの運用スタッフはネットワーク・パフォーマンスを常に監視するため、アクションを実行せずに状況が解決されることを確認してください。 ただし、必要に応じて、「My Oracle Supportでのサービス・リクエストの作成」で説明されているように、サービス・リクエストを発行することで、業務スタッフに状況をもたらすことができます。

Autonomous Data Guard構成オプション

Autonomous Data Guardを有効にしてAutonomous Container Databaseを作成する場合、スタンバイ・データベースを作成するExadata InfrastructureおよびAutonomous Exadata VMクラスタ・リソースを指定し、使用するデータ保護モードを指定します。

スタンバイに使用するExadata InfrastructureおよびAutonomous Exadata VMクラスタ・リソースを指定する際には、次の3つの選択肢があります:

  • プライマリ・データベースExadata InfrastructureおよびAutonomous Exadata VMクラスタの「別のリージョン内」:

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

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

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

  • プライマリ・データベースExadata InfrastructureおよびAutonomous Exadata VMクラスタの「別の可用性ドメイン(AD)内」:

    この選択により、外部ネットワーク接続やリージョン内の可用性ドメインへの電力の致命的な損失など、障害に対する高レベルの保護が提供されます。

    これを選択すると、データ保護とアプリケーション層での構成の簡略化のバランスがとれます。

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

  • プライマリ・データベースExadata InfrastructureおよびAutonomous Exadata VMクラスタとしての「同じ可用性ドメイン(AD)内」:

    これを選択すると、障害から最小限のレベルの保護が提供され、Oracleでは選択しないことをお薦めします。

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

    スタンバイ・データベースを同じ可用性ドメインに配置することを選択した場合は、「最大可用性」保護モードを使用することをお薦めします

保護モードについて

Autonomous Data Guardでは、次のデータ保護モードが提供されます:

  • 最大可用性。 この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。

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

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

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

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

    この保護モードは、最大可用性モードに比べてデータ保護が若干弱く、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。

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

Oracle Data Guard (Autonomous Data Guard機能の基礎となる)の保護モードの詳細は、「Oracle Data Guardコンセプトと管理」の「Oracle Data Guardの保護モード」を参照してください。

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

場合によっては、Autonomous Container Databasesで実行する標準管理操作は、Autonomous Data Guard構成のプライマリ・データベースとスタンバイ・コンテナ・データベースで、標準コンテナ・データベースとは異なる動作をします。 次のリストでは、これらの違いについて説明します。

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

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

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

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

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

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

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

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

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

    プライマリおよびスタンバイ・コンテナ・データベースは、標準のコンテナ・データベースと同様に、別々のコンパートメントに個別に移動できます。 ただし、標準コンテナ・データベースと同様に、コンテナ・データベースを移動する場合は、適切なクラウド・ユーザーのグループがコンテナ・データベースにアクセスできるように十分に注意する必要があります。

  • 再起動

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

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

    プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースの暗号化キーは、標準のコンテナ・データベースと同様に個別にローテーションできます。

  • 終了

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

    • 「プライマリ・コンテナ・データベース」を終了すると、プライマリ・データベースとスタンバイ・コンテナ・データベースの両方が終了します。 自律型データベースを含むプライマリ・コンテナ・データベースは終了できません。
    • スタンバイ・コンテナ・データベースを終了すると、スタンバイ・コンテナ・データベースが終了し、プライマリ・コンテナ・データベースからAutonomous Data Guard構成が削除されて、それが標準のコンテナ・データベースになります。

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

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