Amazon RDS Custom for OracleのDR構成を試してみた

#はじめに

RDS Custom for Oracleは、AWSが提供するマネージドなRDSの新しい形態であり、マネージドではありますがOSレイヤへのrootアクセスが可能になり、ユーザ自身がカスタマイズを行う事が可能となります。
さて、RDS Custom for Oracleですが、標準では通常のRDSのようにマルチAZ(Multi Availability Zone)構成を取ることができません。一方で、AWSマネージドの機能として通常のRDS for Oracleと同様に[Read Replicaという形でレプリカDBを作る機能](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html)が提供されています。

RDS Custom for OracleにおけるDR構成としてのRead Replicaについて、試してみたことをまとめていきます。

1. RDS Custom for Oracle におけるRead Replicaの概要
1. RDS Custom for Oracle でRead Replicaを作ってみた
1. RDS Custom for Oracle でRead ReplicaにFail Overしてみた

**(注) RDS Custom for Oracleで利用するライセンスは基本的にBYOLとなりますので、本機能だけではありませんが、利用には適切なライセンスを準備ください**

###1. RDS Custom for OracleにおけるRead Replicaの概要
######RDS for OracleにおけるRead Replica
AWSにおける、Oracleのレプリカデータベースについての記載は[Amazon RDS での Oracle レプリカの使用](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-read-replicas.html)にまとめられています。

Oracleレプリカとしては、以下の二つのモードがあり、それぞれモード変更が可能です。

- 読み取り専用モード
    - Oracle Enetrprise Editionの機能、Active Data Guardを利用してソースデータベースから変更をリードレプリカデータベースに送信し、適用する
    - 1つのソースデータベースから最大5つのリードレプリカが作成可能
- マウントモード
    - Oracle Enterprise Editioの機能、Oracle Data Guardを利用してソースデータベースから変更をレプリカデータベースに送信し、適用する
    - レプリカデータベースはマウントモードのため、ユーザ接続を受け付けない

同じソースデータベースに対して、読み取り専用モード、マウントモードを組み合わせて作成可能であり、読み取り専用モードとマウントモードは相互にモード変更が可能、となってます。

######RDS *Custom* for OracleにおけるRead Replica
Amazon RDS Custom for OracleにおけるRead Replicaについては、幾つか[制限がある](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html#custom-rr.limitations)とユーザガイドに記載があります。
サポートされない機能は以下になります。

- **リードモードでのリードレプリカ**
- クロスリージョンリードレプリカ
- プライマリDBインスタンスの削除（先にレプリカ側を削除する必要がある）
- AWS CLI(API)によるpromote-read-replicaを利用したリードレプリカの昇格（マニュアルによる昇格は可能）
- data guard 用に構成される RDS_DATAGUARD ユーザの変更・削除
- CommunicationTimeout パラメータは15秒で設定されており、変更不可
- リードレプリカにおけるレプリカユーザのパスワード変更
- 外部のリードレプリカに対するインスタンスロールの変更やレプリケーションラグの検知

主要な差分としてはリードモードでのリードレプリカの作成ができない、クロスリージョンにできない、APIによる昇格(プロモート)ができない点が運用設計には影響してくると思われます。

###2. RDS Custom for OracleでRead Replicaを作ってみた

ユーザガイドには記載がありませんが、コンソールからRead Replicaを作成することが可能です。

1. RDSコンソールからDBを選択し、「アクション」->「リードレプリカを作成」
1. 作成するリードレプリカの設定を選択
1. リードレプリカの確認


######1. RDSコンソールからDBを選択し、「アクション」->「リードレプリカを作成」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/e53a9108-ec55-6be7-ff12-dc5c51e77623.png)


######2. 作成するリードレプリカの設定を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/b02090de-b10f-2280-d6ba-a9df392a9d67.png)


現時点ではレプリカモードは「マウント」しか選択できません、依って、**「リードレプリカ」ですがリードできない状態**となります。また、送信先リージョンも同一リージョンしか選択できません。（別のAZを選択することはできます）


######3. リードレプリカの確認
レプリカを作成すると、以下のようにダッシュボードで新しいRDSが作成されたことが確認できます。
その他のCustomインスタンスと同様、OS上からマウントモードのDBに接続することが可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/dc8ff1a6-bd1a-7eb8-fd74-1b5acb022ee8.png)



ちなみに、レプリカ側のOSはプライマリ側のOS設定がそのままコピーされますが、listener.ora等の設定ファイルはデフォルトで作成されるため、sqlnet.ora等に個別の設定を入れ込んでいる場合には別途追加で設定が必要になります。

###3. RDS Custom for Oracle を Read ReplicaにFail Overしてみた

AWSが提供しているTechnical Guide [Enabling High Availability with Data Guard on Amazon RDS Custom for Oracle](https://d1.awsstatic.com/whitepapers/enabling-high-availability-with-data-guard-on-amazon-rds-custom-for-oracle.pdf)にはFail Over動作そのものの記載はありません。
ただ、基本的にはマニュアルで実行できる、となっているので、OracleのData Guardコマンドラインインタフェース（DGMGRL）
を利用してFail Overを実施してみます。

DGMGRLを利用した手動フェイルオーバの手順はOracleのマニュアルに記載があります ([6.11 手動フェイルオーバー操作の実行](https://docs.oracle.com/cd/F19136_01/dgbkr/examples-using-data-guard-broker-DGMGRL-utility.html#GUID-630F5987-328C-410C-AE3B-A9D66EB233D4))。

Fail Overなので、プライマリ側は停止している状態を前提として、以下のような手順になります。

1. RDS Custom for Oracle オートメーションの一時停止(レプリカ側)
1. スタンバイ（レプリカ）に手動Fail Overを実施する
1. RDS Custom for Oracle オートメーションの再開（新プライマリ側）


######1. RDS Custom for Oracle オートメーションの一時停止(レプリカ側)

ダッシュボードからレプリカDBを選択し「変更」→「RDS カスタムデータベースの自動化」で「一時停止」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/86a6b91c-a5e0-6b26-7267-5b243f9dfbd8.png)

変更内容のサマリが表示されるので、内容を確認して変更を適用します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/36d6b677-5894-b376-b3e3-0b3c1fd28922.png)

RDSの状態が「オートメーションjの一時停止」になります

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/c726cfc4-d190-cf33-0a01-6041687f3118.png)

######2. スタンバイ（レプリカ）に手動Fail Overを実施する

手動Fail Overの流れとしては、[Oracleのマニュアル](https://docs.oracle.com/cd/F19136_01/dgbkr/examples-using-data-guard-broker-DGMGRL-utility.html#GUID-D46A9644-136B-4149-8C74-BF4E845B3DE3)を参照すると以下のようになります。

1. ターゲット・スタンバイ（レプリカ）の準備状況の確認
1. フェイルオーバー・コマンドを発行
1. SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認
1. 新しいプライマリ・データベースを表示
1. 元のプライマリ・データベースがブローカにより無効化されたことを確認

では、流れをコマンドラインで実行していきます。

1．ターゲット・スタンバイ（レプリカ）の準備状況の確認

ORCL_A（asahidedb2）というプライマリDBと、ORCL_B（asahidedb2-rep2）というレプリカDBの構成で、ORCL_Aに接続できない状態となります。
ターゲット・スタンバイ（レプリカ）側に接続して状況を確認します。

<details><summary>show configuration</summary><div>

```
$ dgmgrl /
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Dec 20 16:52:02 2021 Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "ORCL_B"
Connected as SYSDG.
DGMGRL> show configuration;

Configuration - rds_dg

  Protection Mode: MaxPerformance
  Members:
  orcl_a - Primary database
    Error: ORA-16662: network timeout when contacting a member

    orcl_b - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

DGMGRL> 

```

</div></details>


2． フェイルオーバー・コマンドを発行

ターゲット・スタンバイ（レプリカ側）のORCL_Bに接続し、Fail Overコマンドを発行します。

<details><summary>Fail Over to ORCL_B</summary><div>

```
DGMGRL> failover to 'ORCL_B';
Performing failover NOW, please wait...
Failover succeeded, new primary is "ORCL_B"
```

</div></details>


3．SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認

SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認します。
ORCL_Bがプライマリに変更されていることが確認できます。（この状態でORCL_BのDBはOPENになってます）

<details><summary>show configuration</summary><div>

```
DGMGRL> show configuration;

Configuration - rds_dg

  Protection Mode: MaxPerformance
  Members:
  orcl_b - Primary database
    Warning: ORA-16809: multiple warnings detected for the member

    orcl_a - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 91 seconds ago)

DGMGRL>
```

</div></details>




4．新しいプライマリ・データベースを表示

SHOW Databaseコマンドを発行して新しいプライマリ・データベース（ORCL_B）を確認します。

<details><summary>show database ORCL_B</summary><div>

```
DGMGRL> show database ORCL_B;

Database - orcl_b

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    ORCL

Database Status:
SUCCESS

DGMGRL>
```

</div></details>

5．元のプライマリ・データベースがブローカにより無効化されたことを確認

SHOW Databaseコマンドを発行して元のプライマリ・データベース(ORCL_A)がブローカにより無効化されたことを確認を確認します。

<details><summary>show database ORCL_A</summary><div>

```
DGMGRL> show database 'ORCL_A';

Database - orcl_a

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      (unknown)
  Apply Lag:          (unknown)
  Average Apply Rate: (unknown)
  Real Time Query:    OFF
  Instance(s):
    ORCL

Database Status:
DISABLED - ORA-16661: the standby database needs to be reinstated

DGMGRL>
```

</div></details>

######3. RDS Custom for Oracle オートメーションの再開（新プライマリ側）

新プライマリ側はダッシュボード上は レプリカ として表示されている状態です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/7d39b0b4-97f9-e46e-d9ec-424934692b14.png)

選択し、オートメーションモードを一時停止から「完全なオートメーション」へ変更します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/46e28059-73ae-d2c3-4239-524f94abe6ee.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/d43ceca9-1064-e4ee-bdf0-69d1dbf10070.png)

変更が完了すると、レプリカ側のステータスがプライマリに変更され、プライマリ側のステータスがレプリカに変更されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/256ee1d2-77b3-b460-6074-340275386318.png)

※ここでレプリカ（旧プライマリ）側も利用可能な状態にはなるのですが、Data Guardの同期の復旧はうまくいきませんでした。Flash Back Database をONにすれば reinstate が入ると思うので、今度確認してみようと思います。

#まとめ
如何でしょうか？
RDS for Oracleに比べると機能は制限されてしまいますが、RDS Customでも比較的簡単にDR構成を構築することが可能です。
データベースに対するDR機能は基本的には必須要件になることも多いと思いますので、DR環境の構築が簡単にできるのは大きなメリットになると思います。

現時点では実質的に *UnRead* Replica になってしまっていること、クロスリージョンの機能、API経由でのプライマリ昇格機能がないという点は制限ですが、データベースのデータを別のAZに確保しFail Overができる、というような要件は満たすことが可能です。
その他の機能もDRでのRPO/RTOや広域被災を考慮すると重要な点になってくるため、アップデートを待ちたいと思います。