Oracle Data ata Guard のスイッチオーバー操作の実行
Oracle Data Guard 環境では、プライマリデータベースは 1 つ以上のスタンバイデータベースをサポートします。プライマリデータベースからスタンバイデータベースへ、マネージド型のスイッチオーバーベースのロール移行を実行できます。
トピック
Oracle Data Guard のスイッチオーバー機能の概要
スイッチオーバーでは、プライマリデータベースとスタンバイデータベースとの間でロールが入れ替わります。スイッチオーバー中、元のプライマリデータベースはスタンバイロールに移行し、元のスタンバイデータベースはプライマリロールに移行します。

Amazon RDS は、Oracle データベースレプリカの完全マネージド型のスイッチオーバーベースのロール移行をサポートしています。レプリカは、個別の AWS リージョン、または単一のリージョンの異なるアベイラビリティーゾーン (AZ) に配置できます。マウントされているか、読み取り専用で開いているスタンバイデータベースへのスイッチオーバーのみを開始できます。
トピック
Oracle Data ata Guard スイッチオーバーの利点
RDS for Oracle のリードレプリカと同様に、マネージド型スイッチオーバーは Oracle Data Guard に依存しています。このオペレーションは、データ損失がゼロになるように設計されています。Amazon RDS は、スイッチオーバーの次の要素を自動化します。
-
新しいスタンバイデータベースを元のスタンバイデータベースと同じ状態 (マウントされているか、読み取り専用)、プライマリデータベースと指定されたスタンバイデータベースのロールを逆にする
-
データの整合性を確保する
-
移行後もレプリケーション構成を維持する
-
新しいスタンバイデータベースのロールが元のプライマリロールに戻ることができることで、逆転の繰り返しをサポートする
サポートされている Oracle Database のバージョン
Oracle Data Guard のスイッチオーバーは、次のリリースでサポートされています。
-
Oracle Database 19c
-
Oracle Database 12c Release 2 (12.2)
-
PSU 12.1.0.2.v10 以降を使用する、Oracle Database 12c リリース 1 (12.1)
AWS リージョンのサポート
Oracle Data Guard のスイッチオーバーは、次の AWS リージョンで使用できます。
-
アジアパシフィック (ムンバイ)
-
アジアパシフィック (大阪)
-
アジアパシフィック (ソウル)
-
アジアパシフィック (シンガポール)
-
アジアパシフィック (シドニー)
-
アジアパシフィック (東京)
-
カナダ (中部)
-
欧州 (フランクフルト)
-
ヨーロッパ (アイルランド)
-
欧州 (ロンドン)
-
欧州 (パリ)
-
欧州 (ストックホルム)
-
南米 (サンパウロ)
-
米国東部 (バージニア北部)
-
米国東部 (オハイオ)
-
米国西部 (北カリフォルニア)
-
米国西部 (オレゴン)
-
AWS GovCloud (米国東部)
-
AWS GovCloud (米国西部)
Oracle Data Guard のスイッチオーバーの費用
Oracle Data Guard のスイッチオーバー機能には追加コストはかかりません。Oracle Database Enterprise Edition には、マウントモードのスタンバイデータベースのサポートが含まれています。スタンバイデータベースを読み出し専用モードで開くには、Oracle Active Data Guard オプションが必要です。
Oracle Data Guard のスイッチオーバーの仕組み
Oracle Data Guard のスイッチオーバーはフルマネージド型操作です。スタンバイデータベースのスイッチオーバーを開始するには、CLI コマンド switchover-read-replica
を実行します。すると、Amazon RDS はレプリケーション構成のプライマリロールとスタンバイロールを変更します。
オリジナルのスタンバイとオリジナルのプライマリがスイッチオーバー前のロールです。新しいスタンバイと新しいプライマリがスイッチオーバー後のロールです。バイスタンダーのレプリカは、Oracle Data Guard 環境ではスタンバイデータベースとして機能しますが、ロールの切り替えは行わないレプリカデータベースです。
Oracle Data Guard のスイッチオーバーのステージ
スイッチオーバーを実行するには、Amazon RDS が次のステップを実行する必要があります。
-
元のプライマリデータベースの新しいトランザクションをブロックします。スイッチオーバー中、Amazon RDS は Oracle Data Guard 設定のすべてのデータベースのレプリケーションを中断します。スイッチオーバー中、元のプライマリデータベースは書き込み要求を処理できません。
-
未適用のトランザクションを元のスタンバイデータベースに送り、適用します。
-
新しいスタンバイデータベースを読み取り専用モードまたはマウントモードで再起動します。モードは、スイッチオーバー前の元のスタンバイデータベースのオープン状態によって異なります。
-
新しいプライマリデータベースを読み取り/書き込みモードで開きます。
Oracle Data Guard のスイッチオーバー操作後
Amazon RDS は、プライマリデータベースとスタンバイデータベースのロールを切り替えます。アプリケーションを再接続し、その他の必要な構成を実行するのはユーザーです。
成功基準
Oracle Data Guard のスイッチオーバーは、元のスタンバイデータベースが次の処理を実行したときに成功したと判断できます。
-
新しいプライマリデータベースとしてのロールに移行する
-
再構成を完了する
ダウンタイムを抑えるため、新しいプライマリデータベースはできるだけ早くアクティブになります。Amazon RDS はバイスタンダーのレプリカを非同期で設定するため、これらのレプリカは元のプライマリデータベースの後でアクティブになる可能性があります。
新しいプライマリデータベースへの接続
Amazon RDS は、スイッチオーバー後、現在のデータベース接続を新しいプライマリデータベースに伝達しません。Oracle Data Guard のスイッチオーバーが完了したら、アプリケーションを新しいプライマリデータベースに再接続します。
新しいプライマリデータベースの構成
新しいプライマリデータベースへのスイッチオーバーを実行するために、Amazon RDS は元のスタンバイデータベースのモードをオープンに変更します。ロールの変更がデータベースの唯一の変更です。Amazon RDS によって Multi-AZ レプリケーションなどの機能は設定されません。
オプションが異なるクロスリージョンレプリカへのスイッチオーバーを実行しても、新しいプライマリデータベースでは独自のオプションが保持されます。Amazon RDS は元のプライマリデータベースのオプションを移行しません。元のプライマリデータベースで SSL、NNE、OEM、OEM_AGENT などのオプションが指定されている場合も、Amazon RDS はそれらを新しいプライマリデータベースに伝達しません。
Oracle Data Guard のスイッチオーバーの準備
Oracle Data Guard のスイッチオーバーを開始する前に、レプリケーション環境が次の要件を満たしていることを確認します。
-
元のスタンバイデータベースがマウントされているか、読み取り専用で開かれている。
-
元のスタンバイデータベースで自動バックアップが有効になっている。
-
元のプライマリデータベースと元のスタンバイデータベースが使用可能な状態である。
-
元のプライマリデータベースと元のスタンバイデータベースに、保留中のメンテナンスアクションがない。
-
元のスタンバイデータベースがレプリケーション状態である。
-
プライマリデータベースまたはスタンバイデータベースのいずれかがスイッチオーバーライフサイクルで、現在スイッチオーバーを開始しようとしていない。スイッチオーバー後にレプリカデータベースの再構成中、Amazon RDS は別のスイッチオーバーを開始できないようにします。
注記
バイスタンダーのレプリカとは、スイッチオーバーの対象ではない Oracle Data Guard 構成のレプリカです。バイスタンダーのレプリカは、スイッチオーバー時、どのような状態でもかまいません。
-
元のスタンバイデータベースが、元のプライマリデータベースの構成と希望に近い構成になっている。元のプライマリデータベースと元のスタンバイデータベースでオプションが異なるシナリオを想定します。スイッチオーバーが完了しても、Amazon RDS では、新しいプライマリデータベースを元のプライマリデータベースと同じオプションで自動的には再設定しません。
-
切り替えを開始する前に、目的のマルチ AZ 配置を設定します。Amazon RDS では、切り替えの一環としてマルチ AZ を管理しません。マルチ AZ 配置はそのままになります。
db_maz がマルチ AZ 配置のプライマリデータベースで、db_saz がシングル AZ レプリカであると仮定します。db_maz から db_saz への切り替えを開始します。その後、db_maz はマルチ AZ レプリカデータベースになり、db_saz はシングル AZ プライマリデータベースになります。これで、新しいプライマリデータベースは マルチ AZ 配置によって保護されなくなりました。
-
クロスリージョンの切り替えに備え、プライマリデータベースはレプリケーション設定以外の DB インスタンスと同じオプショングループを使用しません。クロスリージョンの切り替えを正常に行うには、現在のプライマリデータベースとそのリードレプリカが、現在のプライマリデータベースのオプショングループを使用する DB インスタンスのみである必要があります。そうではない場合、Amazon RDS が切り替えを妨げます。
Oracle Data Guard のスイッチオーバーの開始
RDS for Oracle リードレプリカをプライマリロールに切り替え、以前のプライマリ DB インスタンスをレプリカロールに切り替えることができます。
Oracle リードレプリカをプライマリ DB ロールに切り替えるには
-
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
Amazon RDS コンソールで、[Databases (データベース)] を選択します。
[Databases (データベース)] ペインが表示されます。各リードレプリカには、[Role (ロール)] 列に [Replica (レプリカ)] があります。
-
プライマリロールに切り替えるリードレプリカを選択します。
-
[Actions] (アクション) で、[Switch over replica] (レプリカを切り替える) を選択します。
-
[I acknowledge] (承認します) を選択します。次に、[Switch over replica] (レプリカを切り替える) を選択します。
-
[Databases] (データベース) ページで、スイッチオーバーの進行状況をモニタリングします。
スイッチオーバーが完了すると、ターゲットのロールがレプリカからソースに変わります。
Oracle レプリカをプライマリ DB ロールに切り替えるには、AWS CLI switchover-read-replica
コマンドを使用します。次の例では、replica-to-be-made-primary
という名前の Oracle レプリカを新しいプライマリデータベースに切り替えます。
例
Linux、macOS、Unix の場合:
aws rds switchover-read-replica \ --db-instance-identifier
replica-to-be-made-primary
Windows の場合:
aws rds switchover-read-replica ^ --db-instance-identifier
replica-to-be-made-primary
Oracle レプリカをプライマリ DB ロールに切り替えるには、必須パラメータ DBInstanceIdentifier
を使用して、Amazon RDS API SwitchoverReadReplica
操作を呼び出します。このパラメータは、プライマリ DB ロールを継承する Oracle レプリカの名前を指定します。
Oracle Data Guard のスイッチオーバーのモニタリング
インスタンスの状態を確認するには、AWS CLI コマンド describe-db-instances
を使用します。次のコマンドでは、DB インスタンス orcl2
のステータスをモニタリングします。このデータベースは、スイッチオーバー前はスタンバイデータベースでしたが、スイッチオーバー後は新しいプライマリデータベースになります。
aws rds describe-db-instances \ --db-instance-identifier
orcl2
スイッチオーバーが正常に完了したことを確認するには、V$DATABASE.OPEN_MODE
のクエリを実行します。新しいプライマリデータベースの値が READ WRITE
であることを確認します。
SELECT OPEN_MODE FROM V$DATABASE;
スイッチオーバー関連のイベントを検索するには、AWS CLI コマンド describe-events
を使用します。次の例では、orcl2
インスタンスのイベントを検索します。
aws rds describe-events \ --source-identifier
orcl2
\ --source-type db-instance