3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Oracle Database@AzureでAutonomous Data Guardを構成して切り替えテストを実施する

Last updated at Posted at 2024-09-26

はじめに

前回までにOracle Database@Azureへの接続までを構築して実施しDB情報の確認までを行いました。今回は障害対策の可用性としてOracle Autonomous DatabaseのAutonomous Data Guard機能をAzure側で設定していきたいと思います。

Autonomous Databaseの災害対策構成について

Autonomous Database ではReal Application Clusters(RAC)やAutomatic Storage Management(ASM)などの高可用性技術が事前構成済みです。そのため、単一のDBサーバー障害やストレージ障害については、RTO/RPOがほぼ0(SLO: サービスレベル目標)で復旧させることが可能です。

それらに加え、有償オプションとして、大きく2種類の災害対策ソリューションが提供されています。

それがAutonomous Data Guardとバックアップベースのディザスタ・リカバリです。Autonomous Data Guard は、本番環境用インスタンス(プライマリ・インスタンス)のスタンバイ・データベースを構成する事ができます。これによって、Autonomous Database インスタンスにデータ保護およびディザスタ・リカバリを実現可能です。
Autonomous Data Guard が有効になっている場合、全ノード障害やリージョン障害などの大規模障害の際に、フェイルオーバーやスイッチオーバーが可能なスタンバイ・データベースを提供します。なおAutonomous Data Guard のスタンバイ・データベースへはデータ操作や接続ができません。
image.png

※現在2024年9月においてOracle Database@Azureでは全ノード障害への対応とスイッチオーバーはすでに実装されており、リージョン障害やフェイルオーバーについてはCloud Worldでの発表の通り今後実装される予定となっております。

[参照]Autonomous Database を災害対策構成にしてみよう
[参照]Autonomous Database Serverless 技術詳細

今回の構成

リージョン間でのAutonomous Data Guardはまだ実装されていないためUS-East側に2台目のAutonomous Databaseを構築して全ノード障害に対応できるAutonomous Data Guardを構成します。
そこから切り替えのスイッチオーバーを実行し切り替わったかの確認テストを実施します。
image.png

Oracle Autonomous Data Guard 構築手順

Autonomous Data Guardの設定

Azureのホーム画面で[Autonomoous Databaseのリソース名を入力]→[リソース]→[Autonomous Database]選択します。
image.png

[設定]→[ディザスタ・リカバリ]にて設定を確認します。現在のピア・ロールがバックアップコピー、スタンバイ、East US、バックアップベースとなっています。こちらをAutonomous Data Guardへ設定変更するために[編集]を選択します。
image.png
下記項目に入力して[送信]を選択します。
image.png
※データ損失制限(秒)のある自動フェイルオーバーに関してはこちらをご覧ください。
データ損失制限(秒)のある自動フェイルオーバーについて

設定を確認するとスタンバイ、スタンバイ、East US、Autonomous Data Guard、自動フェイルオーバー0秒に切り替わりました。
image.png

スタンバイデータベースに切り替えのテスト

実際に切り替わるかを確認するために切り替えを実施します。[スイッチオーバー]を選択します。
image.png

下記項目を入力して[送信]を選択します。
image.png

ARM要求が成功の通知が出たら切り替えの完了です。
image.png

ところで、前回の最後にDatabase Actionsの接続で確認したDBID、NAME、DB_UNIQUE_NAMEの固有情報はきろくしてありますか。こちらはその時のスクショを取ったものです。こちらの情報が同じSQLをたたいて変わっていればスタンバイDatabaseへの切り替えの成功が確認できます。
image.png

RDP接続で踏み台ServerにサインインしてURL接続からDatabase Actionsを開きます。
image.png

無事情報が変わっており,スタンバイとプライマリが切り替わったことを確認できました。これにて切り替えテスト終了です。
image.png

切り戻しについて

[設定]→[ディザスタ・リカバリ]→[スイッチオーバー]をもう一度実施すればプライマリとスタンバイが再び入れ替わるため元の構成に戻ります。
image.png
Autonomous Data Guardをバックアップベースに戻したい場合は[ディザスタ・リカバリ]→[編集]→[バックアップベース・ディザスタ・リカバリ]→[送信]を実行することで可能となります。今回の手順は以上となります。
image.png

前の手順

101:Oracle Database@AzureをPAYGで作成してみた
102:Oracle Database@Azureに接続してみた

次の手順

104:Oracle Database@Azureにデータをロードする

運用時の手順

201:Oracle Database@Azureのサブスクリプションとアカウントの仕組みについて
202:Oracle Database@Azureでポータル別設定項目をまとめてみた
203:Oracle Database@Azureでこまったときにサポートリクエストを上げて自己解決する方法

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?