Autonomous Data Guard構成でのプライマリ・データベースおよびスタンバイ・データベースの管理
Autonomous Data Guard構成でプライマリ・データベースとスタンバイ・データベースを管理する方法について学習します。
Autonomous Data Guardが有効になっているAutonomous Container DatabaseでAutonomous Databaseを作成すると、データベースの完全に別個の2つのコピーが作成されます: 1つはプライマリ・コンテナ・データベース内に、もう1つ(同期コピー)はスタンバイ・コンテナ・データベース内に作成されます。その後、プライマリ・コンテナ・データベースが使用できない場合、Autonomous Data Guardは自動的にスタンバイ・コンテナ・データベースをプライマリ・コンテナ・データベースに変換し、Autonomous Databaseへのアプリケーション接続の処理を開始します。
Autonomous Data Guardを使用すると2つのAutonomous Databaseが作成されるため、OCPUおよびストレージ・リソースの数の2倍が(半分はプライマリ・データベースに、半分はスタンバイ・データベースに)使用されます。
これらの2つのデータベースは、互いのピア・データベースと呼ばれることが多く、Autonomous Databaseのリストおよびデータベースの「詳細」ページでは「プライマリ」および「スタンバイ」というラベルで識別されます。
フリート管理者がAutonomous Data Guardが有効になったAutonomous Container Databaseを作成および管理する方法の詳細は、Autonomous Data Guardの管理を参照してください。
プライマリ・データベースおよびスタンバイ・データベースでの管理操作
2つのデータベースはリンクされて同期されるため、Autonomous DatabaseでAutonomous Data Guard構成のプライマリ・データベースおよびスタンバイ・データベース実行する標準管理操作は、標準データベースと比較して、その仕組みが異なる場合があります。次のリストでは、これらの違いについて説明します。
- スケール・アップ、スケール・ダウンおよび自動スケーリング
2つのピア・データベースのOCPU数、ストレージ・サイズおよび自動スケーリング設定は同じである必要があります。したがって、スケール・アップ、スケール・ダウンおよび自動スケーリング設定の変更は、プライマリ・データベースの「詳細」ページからのみ行えます。行った変更は、プライマリ・データベースとスタンバイ・データベースの両方に影響します。
- 停止、起動および再起動
2つのピア・データベースのライフサイクル・ステータスは常に同期されています。したがって、データベースの停止、起動および再起動は、プライマリ・データベースの「詳細」ページからのみ行えます。実行した操作は、プライマリ・データベースとスタンバイ・データベースの両方に影響します。
- 手動でのバックアップ
プライマリ・データベースとスタンバイ・データベースは、標準のデータベースと同じように、個別に手動でバックアップできます。
- リストア
データベースのリストアおよびリカバリは、プライマリ・データベースの「詳細」ページからのみ行えます。
- クローン
データベースのクローニングは、プライマリ・データベースの「詳細」ページからのみ行えます。
- 暗号化キーのローテーション
プライマリ・データベースとスタンバイ・データベースの暗号化キーは、標準のデータベースと同じように、個別にローテーションできます。
- 別のコンパートメントへの移動
プライマリ・データベースとスタンバイ・データベースは、標準のデータベースと同じように、個別に別のコンパートメントに移動できます。
- 終了
データベースの終了は、プライマリ・データベースの「詳細」ページからのみ行えます。
クライアント・アプリケーションからのスタンバイ・データベースへのアクセス
Autonomous Data Guardを使用する場合、クライアント・アプリケーションは通常、プライマリ・データベースに接続して操作を実行します。
この通常の接続に加えて、Autonomous Data Guardには、読取り専用操作のみを実行するクライアント・アプリケーションをスタンバイ・データベースに接続するオプションもあります。このオプションを利用するために、クライアント・アプリケーションは、("読取り専用"を表す) "_RO"を含むデータベース・サービス名を使用してデータベースに接続します(Autonomous Databaseの事前定義済データベース・サービス名を参照)。
タイム・ラグのモニタリング
Autonomous Data Guardを使用するデータベースが実行されている間は、サイド・メニューの「リソース」で「Autonomous Data Guardアソシエーション」を選択して、プライマリ・データベースまたはスタンバイ・データベースの「詳細」ページからトランスポート・ラグおよび適用ラグの時間をモニターできます。
時間の経過とともに、データベースのワークロードの増減に伴って小さな変動はあるはずです。ただし、ラグの時間の継続的な上昇傾向に気付いた場合は、次のアクションを実行して状況を解決できます:
- 適用ラグの上昇傾向。適用ラグの継続的な上昇傾向は、スタンバイ・データベースにプライマリ・データベースからのREDOレコードに対応するための十分な容量がないことを示します。この状況を解決するには、専用Autonomous DatabaseへのCPUまたはストレージ・リソースの追加の説明に従って、データベースのOCPUをスケール・アップします。
- トランスポート・ラグの上昇傾向。トランスポート・ラグの継続的な上昇傾向は、ネットワーク・パフォーマンスの問題を示します。Oracle Cloudの運用スタッフがネットワーク・パフォーマンスを常にモニターしているため、ユーザーは何もアクションを実行しなくても状況は解決します。ただし、必要な場合は、サービス・リクエストを発行して、運用スタッフに状況の対処を依頼することができます。
親トピック: 専用Autonomous Databaseの作成と管理