#はじめに
RDS Custom for Oracleは、AWSが提供するマネージドなRDSの新しい形態であり、マネージドではありますがOSレイヤへのrootアクセスが可能になり、ユーザ自身がカスタマイズを行う事が可能となります。
さて、RDS Custom for Oracleですが、標準では通常のRDSのようにマルチAZ(Multi Availability Zone)構成を取ることができません。一方で、AWSマネージドの機能として通常のRDS for Oracleと同様にRead Replicaという形でレプリカDBを作る機能が提供されています。
RDS Custom for OracleにおけるDR構成としてのRead Replicaについて、試してみたことをまとめていきます。
- RDS Custom for Oracle におけるRead Replicaの概要
- RDS Custom for Oracle でRead Replicaを作ってみた
- 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 レプリカの使用にまとめられています。
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については、幾つか制限があるとユーザガイドに記載があります。
サポートされない機能は以下になります。
- リードモードでのリードレプリカ
- クロスリージョンリードレプリカ
- プライマリDBインスタンスの削除（先にレプリカ側を削除する必要がある）
- AWS CLI(API)によるpromote-read-replicaを利用したリードレプリカの昇格（マニュアルによる昇格は可能）
- data guard 用に構成される RDS_DATAGUARD ユーザの変更・削除
- CommunicationTimeout パラメータは15秒で設定されており、変更不可
- リードレプリカにおけるレプリカユーザのパスワード変更
- 外部のリードレプリカに対するインスタンスロールの変更やレプリケーションラグの検知
主要な差分としてはリードモードでのリードレプリカの作成ができない、クロスリージョンにできない、APIによる昇格(プロモート)ができない点が運用設計には影響してくると思われます。
###2. RDS Custom for OracleでRead Replicaを作ってみた
ユーザガイドには記載がありませんが、コンソールからRead Replicaを作成することが可能です。
- RDSコンソールからDBを選択し、「アクション」->「リードレプリカを作成」
- 作成するリードレプリカの設定を選択
- リードレプリカの確認
######1. RDSコンソールからDBを選択し、「アクション」->「リードレプリカを作成」
######2. 作成するリードレプリカの設定を選択
現時点ではレプリカモードは「マウント」しか選択できません、依って、「リードレプリカ」ですがリードできない状態となります。また、送信先リージョンも同一リージョンしか選択できません。（別のAZを選択することはできます）
######3. リードレプリカの確認
レプリカを作成すると、以下のようにダッシュボードで新しいRDSが作成されたことが確認できます。
その他のCustomインスタンスと同様、OS上からマウントモードのDBに接続することが可能です。
ちなみに、レプリカ側の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にはFail Over動作そのものの記載はありません。
ただ、基本的にはマニュアルで実行できる、となっているので、OracleのData Guardコマンドラインインタフェース（DGMGRL）
を利用してFail Overを実施してみます。
DGMGRLを利用した手動フェイルオーバの手順はOracleのマニュアルに記載があります (6.11 手動フェイルオーバー操作の実行)。
Fail Overなので、プライマリ側は停止している状態を前提として、以下のような手順になります。
- RDS Custom for Oracle オートメーションの一時停止(レプリカ側)
- スタンバイ（レプリカ）に手動Fail Overを実施する
- RDS Custom for Oracle オートメーションの再開（新プライマリ側）
######1. RDS Custom for Oracle オートメーションの一時停止(レプリカ側)
ダッシュボードからレプリカDBを選択し「変更」→「RDS カスタムデータベースの自動化」で「一時停止」を選択します。
変更内容のサマリが表示されるので、内容を確認して変更を適用します。
RDSの状態が「オートメーションjの一時停止」になります
######2. スタンバイ（レプリカ）に手動Fail Overを実施する
手動Fail Overの流れとしては、Oracleのマニュアルを参照すると以下のようになります。
- ターゲット・スタンバイ（レプリカ）の準備状況の確認
- フェイルオーバー・コマンドを発行
- SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認
- 新しいプライマリ・データベースを表示
- 元のプライマリ・データベースがブローカにより無効化されたことを確認
では、流れをコマンドラインで実行していきます。
1．ターゲット・スタンバイ（レプリカ）の準備状況の確認
ORCL_A（asahidedb2）というプライマリDBと、ORCL_B（asahidedb2-rep2）というレプリカDBの構成で、ORCL_Aに接続できない状態となります。
ターゲット・スタンバイ（レプリカ）側に接続して状況を確認します。
show configuration
$ 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>
2． フェイルオーバー・コマンドを発行
ターゲット・スタンバイ（レプリカ側）のORCL_Bに接続し、Fail Overコマンドを発行します。
Fail Over to ORCL_B
DGMGRL> failover to 'ORCL_B';
Performing failover NOW, please wait...
Failover succeeded, new primary is "ORCL_B"
3．SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認
SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認します。
ORCL_Bがプライマリに変更されていることが確認できます。（この状態でORCL_BのDBはOPENになってます）
show configuration
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>
4．新しいプライマリ・データベースを表示
SHOW Databaseコマンドを発行して新しいプライマリ・データベース（ORCL_B）を確認します。
show database ORCL_B
DGMGRL> show database ORCL_B;
Database - orcl_b
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
ORCL
Database Status:
SUCCESS
DGMGRL>
5．元のプライマリ・データベースがブローカにより無効化されたことを確認
SHOW Databaseコマンドを発行して元のプライマリ・データベース(ORCL_A)がブローカにより無効化されたことを確認を確認します。
show database ORCL_A
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>
######3. RDS Custom for Oracle オートメーションの再開（新プライマリ側）
新プライマリ側はダッシュボード上は レプリカ として表示されている状態です。
選択し、オートメーションモードを一時停止から「完全なオートメーション」へ変更します。
変更が完了すると、レプリカ側のステータスがプライマリに変更され、プライマリ側のステータスがレプリカに変更されます。
※ここでレプリカ（旧プライマリ）側も利用可能な状態にはなるのですが、Data Guardの同期の復旧はうまくいきませんでした。Flash Back Database をONにすれば reinstate が入ると思うので、今度確認してみようと思います。
#まとめ
如何でしょうか？
RDS for Oracleに比べると機能は制限されてしまいますが、RDS Customでも比較的簡単にDR構成を構築することが可能です。
データベースに対するDR機能は基本的には必須要件になることも多いと思いますので、DR環境の構築が簡単にできるのは大きなメリットになると思います。
現時点では実質的に UnRead Replica になってしまっていること、クロスリージョンの機能、API経由でのプライマリ昇格機能がないという点は制限ですが、データベースのデータを別のAZに確保しFail Overができる、というような要件は満たすことが可能です。
その他の機能もDRでのRPO/RTOや広域被災を考慮すると重要な点になってくるため、アップデートを待ちたいと思います。