Autonomous DatabaseのSLAを99.995%にしてみた！

この記事は、JPOUG Advent Calendar 2022とOracle Cloud Infrastructure Advent Calendar 2022の17日目の記事になります。
JPOUG Advent Calendar 2022の16日目の記事はけんぼーさんの「Oracleの監査の検証（従来型監査編） - 忘れかけのIT備忘録」、Oracle Cloud Infrastructure Advent Calendar 2022の16日目の記事はssfujitaさんの「Oracle Autonomous Database上でTransparent Application Continuityの特徴を実機検証してみた – Slowly But Surely」でした。

はじめに

Autonomous Databaseでは99.95%のSLAを保証していますが、Autonomous DatabaseのAutonomous Data Guardを有効にすることにより、99.995%のSLAを保証するとのリリースが今年の8月にありました。

Autonomous Database: 99.995%の可用性SLAをAutonomous Data Guard構成で提供開始

Autonomous Data Guardは以前から提供されていましたが、99.995%のSLAが保証されたことにより、今後、エンタープライズでの導入が進んでいくと思いますので、改めて機能を検証してみました。

Oracle Database Technology Night #61 Oracle CloudWorld 2022 フィードバックより引用

やったこと

OCI上に構築したAutonomous Data Guardの検証環境は以下の通り。

Autonomous Data Guard検証環境

Autonomous Databaseを作成する（東京リージョン）

まずは、東京リージョン（ap-tokyo-1）にAutonomous Databaseを作成します。

東京リージョンのAutonomous Databaseの構成

• データベース名:ATP01
• ワークロード・タイプ:トランザクション処理
• OCPU数:2
• ストレージ:1TB
• ライセンス・タイプ:Enterprise Edition
• データベースのバージョン:19c

ATP01(ap-tokyo-1)のコンソール画面

この段階では、ATP01のAutonomous Data Guardは以下のように無効になっています。

ATP01のAutonomous Data Guardの情報（ステータス:無効）

Autonomous Data Guardを有効化する（大阪リージョン）

つぎに、ATP01のAutonomous Data Guardを以下の「有効化」のリンクをクリックしてます。

ATP01(ap-tokyo-1)のAutonomous Data Guardの情報（有効化）

クリックすると以下の「Autonomous Databaseの有効化」の設定画面が出てきますので、
リージョンに「日本中央部（大阪）」を選択して、画面下にある「Autonomous Databaseの有効化」ボタンをクリックします。

ATP01(ap-tokyo-1)の「Autonomous Data Guardの有効化」設定画面

この操作により、大阪リージョン（ap-osaka-1）にATP01のスタンバイデータベースの作成が開始されます。

ATP01(ap-tokyo-1)のAutonomous Data Guardの状態（ATP01_Remote プロビジョニング中）

大阪リージョン（ap-osaka-1）側でもATP01のスタンバイデータベース（ATP01_Remote）が見えるようになります。

ATP01_Remote(ap-osaka-1)のコンソール画面（プロビジョニング中）

しばらくして、大阪リージョン（ap-osaka-1）のスタンバイデータベース（ATP01_Remote）の作成が完了するとそれぞれの画面の状態が以下のようになります。

ATP01(ap-tokyo-1)のコンソール画面（プライマリ）

ATP01(ap-tokyo-1)のAutonomous Data Guardの状態（ATP01_Remote スタンバイ）

ATP01_Remote(ap-osaka-1)のコンソール画面（スタンバイ）

ここまでの手順でAutonomous Data Guardの検証環境の構築は完了です。

高可用性（SLA 99.995%）を検証する

Autonomous Data Guardの検証環境の準備が終わりましたので、ここからはAutonomous Data Guardの高可用性の検証を進めていきます。

プライマリとスタンバイのロール切替は、主に以下のケースで発生すると思います。

• 【ケース1】計画的なデータベースのメンテナンス、定期的なディザスタリカバリ訓練
• 【ケース2】東京リージョン障害（プライマリデータベース障害）

ケース1では手動によるスイッチオーバーでのロール切替、手動によるスイッチバックでのロール切戻しになりますが、ケース2では障害発生時の自動フェイルオーバーでのロール切替、手動によるスイッチオーバーでのロール切戻しになります。

検証の事前確認

検証を始める前に、現在のプライマリデータベースの情報を取得しておきます。
ATP01のコンソール画面からデータベース・アクションを起動して、メニューから「開発」カテゴリーにある「SQL」を選択します。
コードエディタ―に以下のSQL文を入力後、実行して現在のプライマリデータベースの情報を取得します。

SELECT 
DBID, NAME, DB_UNIQUE_NAME
FROM 
V$DATABASE;

取得した結果は以下の通りです。

DBID	NAME	DB_UNIQUE_NAME
1031809666	ED51POD	ed51pod

ケース1の検証

スイッチオーバー

クロスリージョンでのスイッチオーバーの操作はスタンバイデータベース側で実施する必要があります。

プライマリデータベースからスタンバイデータベースへのスイッチオーバーの操作は、大阪リージョン（ap-osaka-1）のスタンバイデータベース（ATP01_Remote）の画面から実施します。
画面からスイッチオーバーの操作は2か所から実施できますが、今回は「他のアクション」ボタンをクリックしてメニューから「スイッチオーバー」を選択することで実施しました。

ATP01_Remote(ap-osaka-1)のコンソール画面で「他のアクション」から「スイッチオーバー」を選択

メニューから「スイッチオーバー」を選択すると「スタンバイへのスイッチオーバーの確認」画面が表示されますので、スタンバイデータベースの選択とスタンバイデータベース名の入力後、「スタンバイへのスイッチオーバーの確認」ボタンをクリックすれば、スイッチオーバーが開始されます。

ATP01_Remote(ap-osaka-1)の「スタンバイへのスイッチオーバーの確認」画面

スタンバイデータベースへのスイッチオーバーが開始されるとATP01_Remote(ap-osaka-1)のロール変更が始まります。

ATP01_Remote(ap-osaka-1)のコンソール画面（ロール変更中）

ロール変更は、ATP01(ap-tokyo-1)でも確認できます。

ATP01(ap-tokyo-1)のコンソール画面（更新中）

スイッチオーバーの進行状況は、ATP01やATP01_Remoteの各コンソール画面のリソースにあるAutonomous Data Guardの項目や作業リクエストの項目で確認することができます。

Autonomous Databaseのコンソール画面（リソース）

ATP01_Remote(ap-osaka-1)がプライマリ、ATP01(ap-tokyo-1)がスタンバイに変更されていればスイッチオーバーは完了です。

ATP01_Remote(ap-osaka-1)のコンソール画面（プライマリ）

ATP01_Remote(ap-osaka-1)のAutonomous Data Guardの状態（プライマリ）

ATP01(ap-tokyo-1)のコンソール画面（セカンダリ）

ATP01(ap-tokyo-1)のAutonomous Data Guardの状態（セカンダリ）

ここで、再度スイッチオーバー完了後のプライマリデータベースの情報を取得してみます。

取得した結果は以下の通りです。スイッチオーバー前とは別のデータベースに接続されていることが確認できます。

DBID	NAME	DB_UNIQUE_NAME
850358680	EIM1POD	eim1pod

以上の手順でプライマリデータベースからスタンバイデータベースへのスイッチオーバーが問題なく完了したことが確認できました。

スイッチバック

ATP01_Remote(ap-osaka-1)からATP01(ap-tokyo-1)へのスイッチバックの手順はスイッチオーバーと同じ手順になりますので、詳細な説明は割愛します。

スイッチバック完了後のプライマリデータベースの情報を取得した結果は以下の通りです。

DBID	NAME	DB_UNIQUE_NAME
130217136	ENB1POD	enb1pod

スイッチオーバーしたときに、ATP01(ap-tokyo-1)はスタンバイデータベースとして再作成されているため、スイッチバック後は事前確認した最初のプライマリデータベースとは別のデータベースとなっています。

参考）OCI CLIでのスイッチオーバー操作

今回の検証ではプライマリからスタンバイへのスイッチオーバーの操作はOCIコンソールで実施しましたが、同様の操作はOCI CLIでも実施できますので、参考までにOCI CLIで実施する場合のコマンドを記載しておきます。

oci db autonomous-database switchover --autonomous-database-id <standby-adb-ocid> --peer-db-id <primary-adb-ocid>

ケース2の検証

フェイルオーバー

プライマリデータベースからスタンバイデータベースへのフェイルオーバーですが、プライマリデータベースの障害を発生させることが難しいため、今回は擬似的にOCI CLIでフェイルオーバーを実施しました。

クラウドシェルを起動後、以下のコマンドを入力してスタンバイデータベースへのフェイルオーバーを開始します。

oci db autonomous-database fail-over --autonomous-database-id <standby-adb-ocid> --peer-db-id <primary-adb-ocid> --region <standby-adb-region>

スタンバイデータベースへのフェイルオーバーが開始されるとATP01_Remote(ap-osaka-1)のロール変更が始まります。

ATP01_Remote(ap-osaka-1)コンソール画面（ロール変更中）

ATP01_Remote(ap-osaka-1)のコンソール画面の作業リクエストでもフェイルオーバーの操作が確認できます。

ATP01_Remote(ap-osaka-1)作業リクエスト（フェイルオーバー）

フェイルオーバーは、ATP01(ap-tokyo-1)でも確認できます。

ATP01(ap-tokyo-1)コンソール画面（ロール変更中）

ATP01_Remote(ap-osaka-1)がプライマリ、ATP01(ap-tokyo-1)がスタンバイに変更されていればフェイルオーバーは完了です。

ATP01_Remote(ap-osaka-1)コンソール画面（プライマリ）

ATP01(ap-tokyo-1)コンソール画面（スタンバイ）

フェイルオーバー完了後のプライマリデータベースの情報を取得した結果は以下の通りです。
フェイルオーバー前のスタンバイデータベースに接続されていることが確認できます。

DBID	NAME	DB_UNIQUE_NAME
850358680	EIM1POD	eim1pod

以上の手順でプライマリデータベースからスタンバイデータベースへのフェイルオーバーが問題なく完了したことが確認できました。

フェイルバック

ATP01_Remote(ap-osaka-1)からATP01(ap-tokyo-1)へのフェイルバックの手順はスイッチオーバーと同じ手順になりますので、詳細な説明は割愛します。

フェイルバック完了後のプライマリデータベースの情報を取得した結果は以下の通りです。

DBID	NAME	DB_UNIQUE_NAME
130217136	ENB1POD	enb1pod

フェイルオーバー前のプライマリデータベースと同じデータベースに接続されていることが確認できます。

まとめ

• クロスリージョンでのAutonomous Data Guard環境による高可用性の検証をスイッチオーバー、フェイルオーバーを実施して確認しました。
• Autonomous Data Guard環境でのスイッチオーバー、スイッチバックのオペレーションはOCIコンソールで簡単に実施できます。
• フェイルオーバーを発生させるためのオペレーションはOCIコンソールでは実施できないため、OCI CLIで実施しました。

参考資料

• スタンバイ・データベースについて
• 212: Autonomous Data Guardを構成してみよう | Oracle Cloud Infrastructure チュートリアル
• autonomous-database — OCI CLI Command Reference 3.22.0 documentation