Amazon Web Services ブログ

AWS DMS を使用した Amazon RDS for Oracle での災害復旧

AWS Database Migration Service (AWS DMS) は、オンプレミスのデータベースから Amazon Relational Database Service (RDS) にデータを移行するのに役立ちます。また、とりわけ、異種または同種のデータベースエンジン間でデータを移行するために使用できます。あらゆる規模の企業が、2 つ目の物理サイトをセットアップすることなく、AWS を使用して重要な IT システムの災害復旧 (DR) を高速化しています。DR ソリューションは RTO/RPO に依存します。ベストプラクティスの詳細については、「新しいホワイトペーパー: 災害復旧に AWS を使用する」を参照してください。

この記事では、AWS DMS を使用して、RDS プラットフォームで実行されている Oracle データベースの DR ソリューションをセットアップする方法について説明します。

災害復旧に AWS DMS を使用する理由

プライマリデータベースインスタンスが AWS で実行されている DR ソリューションには、クロスリージョンレプリケーションメカニズムが必要です。AWS DMS は、RDS から任意の場所 (別のリージョンを含む) へのデータのライブ移行をサポートしています。この機能を利用して、別のリージョンに個別の RDS インスタンスを設定して、DR データベースとして機能するようにできます。Oracle Golden Gate など、RDS 上の Oracle 用の DR サイトをセットアップするオプションは他にもありますが、AWS DMS は低コストでシンプルなすべてネイティブのアプローチを提供しています。さらに、エンタープライズエディションまたはスタンダードエディションの使用に関する依存関係はありません。AWS DMS は全ロード移行と変更データキャプチャ (CDC) をサポートしているため、継続的なデータレプリケーションが可能です。AWS DMS を使用する場合、データベースインスタンスレベルで動作する物理レプリケーションとは異なり、AWS DMS は論理レプリケーションソリューションであるため、スキーマやテーブルセットなどのデータベースのサブセットを移行できます。Oracle を使用するインスタンスでは、AWS DMS は Oracle LogMiner API またはバイナリリーダー API を使用してトランザクションログを読み取ることにより、データの変更を決定して追跡します。AWS DMS は、システム変更番号 (SCN) に基づいて、オンラインまたはアーカイブ REDO ログから進行中の変更を読み取ります。詳細については、「 Amazon が管理する Oracle データベースを AWS DMS のソースとして使用する」を参照してください。

データベースレベルの補足ロギングを有効にして、レプリケーションの変更をキャプチャします。同様に、移行する各テーブルの補足ロギングを有効にする必要があります。プライマリキーを持つテーブルの補足ロギングプライマリキーを有効にして、プライマリキーまたはユニークキーのないテーブルのすべてのカラムを補足します。LogMiner に情報を提供するには、ARCHIVELOG MODE をオンにする必要があります。DMS はデフォルトで LogMiner を使用して、アーカイブログから情報を読み取り、変更をキャプチャします。また、DMS では、LogMiner または Binary Reader を使って REDO ログを読み取ることができます。どちらのアプローチにもメリットとデメリットがあるため、選択はレプリケーション要件に大きく左右されます。詳細については、「変更データキャプチャ (CDC) に Oracle LogMiner または Oracle Binary Reader を使用する」を参照してください。

AWS DMS では、全ロード移行、CDC、または CDC による全ロード移行を実行できます。ただし、DR RDS インスタンスをセットアップする際、RDS スナップショットを使用してターゲットインスタンスをプリロードする方が効率的な場合があります。特にデータベースのサイズが大きい場合、全ロードを実行するためにレプリケーションインスタンスが必要ないため、コストを節約できます。リージョン間で RDS データベーススナップショットをコピーできます。この記事では、DR RDS インスタンスをセットアップし、サンプル RDS for Oracle インスタンスを使用してほぼゼロの RTO/RPO を実現する連続レプリケーションを実行するために必要な手順の概要を示します。

DMS を DR ソリューションとして使用する前に覚えておくべきこと

AWS DMS は、ソースデータストアに対する継続的な変更をキャプチャし、それらをターゲットデータストアに適用します。この機能は DR のユースケースを満たすために活用できますが、注意すべき点がいくつかあります。

パフォーマンス: AWS DMS を使用した DR ソリューションのパフォーマンスは、移行のパフォーマンスに影響する要因が数多くあるため、データベースごとに異なることがあります。この要因には、ソースでのリソースの可用性、利用可能なネットワークスループット、レプリケーションサーバーのリソース容量、変更を取り込むターゲットの能力、ソースデータのタイプと配信、移行するオブジェクトの数などが含まれます。途中で 1 つ以上のボトルネックが発生すると、移行のパフォーマンスが制限されます。パフォーマンスに関する考慮事項の詳細については、「AWS Database Migration Service のベストプラクティス」を参照してください。

また、AWS DMS は論理レプリケーションソリューションであるため、パフォーマンスはソースのデータとトランザクションの性質に応じて異なるという事実にも注意してください。AWS DMS では、デフォルトで変更データキャプチャ (CDC) に Oracle LogMiner を使用します。あるいは、Oracle Binary Reader を使用できます。これにより、特定の考慮事項について LogMiner と比較した場合、パフォーマンスが大幅に向上し、Oracle サーバーの負荷が軽減されます。

ソース/ターゲットの制限: AWS DMS は、ADD、DROP、EXCHANGE や TRUNCATE などの DDL 操作、およびパーティションまたはサブパーティション操作によるデータの変更をレプリケートしません。ALTER TABLE コマンドの使用にも制限があります。制限の完全なリストについては、「Oracle を AWS DMS のソースとして使用することに関する制限」を参照してください。

同様に、AWS DMS は ターゲット RDS for Oracle データベースにスキーマを作成しません。したがって、DR シナリオでは、RDS スナップショットを復元してターゲットデータベースインスタンスを作成することをお勧めします。これにより、1 回限りのデータロードも処理されます。または、Oracle Data Pump を使用できます。このブログでは、前者のアプローチを使用します。制限の完全なリストについては、「AWS DMS のターゲットとしての Oracle の制限」を参照してください。

レイテンシー: AWS DMS は、Oracle LogMiner API またはバイナリリーダー API を使用して、進行中の変更を読み取ります。 多数の REDO ログを生成するビジーなソースデータベースは、大幅なレイテンシーを引き起こす可能性があります。バイナリリーダーは LogMiner をバイパスし、ログを直接読み取ります。したがって、LogMiner とバイナリリーダーの間で比較検討することが重要です。さらに、長時間実行されるトランザクションはソースレイテンシーにつながる可能性があります。AWS DMS はトランザクションログから着信変更を読み取るだけですが、AWS DMS はレプリケーションが進行している間にターゲットにコミットされた変更のみを転送するためです。その他の考慮事項には LOB データがあります。AWS DMS は、2 つのフェーズで進行中のレプリケーションのために LOB データを移行します。最初に、AWS DMS は、LOB を含む列を除くすべての列を含むターゲットテーブルに新しい行を作成します。次に、AWS DMS は LOB を含む行を更新します。LOB 列を含むテーブルを頻繁に更新するソースデータベースがある場合、ソースレイテンシーが発生する可能性があります。

ターゲットデータベースの特性のためレイテンシーが発生することもあります。その原因は、ターゲットにプライマリキーまたはインデックスがないことにある可能性があります。AWS DMS は論理レプリケーションを使用しているため、必要なインデックスが適切に配置されていない場合、UPDATE や DELETE などの変更により、テーブル全体がスキャンされる可能性もあります。テーブル全体のスキャンは、ターゲットでパフォーマンスの問題を引き起こし、ターゲットレイテンシーを引き起こすこともあります。

考慮事項には他にも、ソースおよびターゲットデータベースインスタンス、およびレプリケーションインスタンスのリソースボトルネックがあります。

RTO/RPO 要件の周りに定義された SLA がある状況では、レイテンシーが重要な考慮事項です。お客様は、このソリューションをテストして、独自のベンチマークに到達することをお勧めします。Oracle Golden Gate、Cross-region Read Replicas などのプライマリインスタンスから DR インスタンスにデータをレプリケートするためのさまざまなオプションを比較検討し、最適なオプションを見極める必要があります。CDCLatencySource と CDCLatencyTarget の CloudWatch サービスメトリクスを使用して、AWS DMS タスクのレプリケーションレイテンシーをモニタリングできます。

モニタリング: Amazon CloudWatch とメトリクスを使用して、DMS タスクの進行状況、使用されているリソース、使用されているネットワークアクティビティをモニタリングできます。 Amazon CloudWatch のログ記録を有効にすることで、レプリケーションホストのメトリクス、レプリケーションタスクのメトリクス、テーブルのメトリクスをモニタリングできます。タスクのステータス、完了率、経過時間、テーブル統計など、各タスクの基本的な CloudWatch 統計情報は、AWS DMS コンソールから取得できます。レプリケーションインスタンスのパフォーマンスメトリクスには、CPUUtilization、FreeStorageSpace、FreeableMemory などがあります。受信やコミットされた変更、レプリケーションホスト、ソースやターゲットデータベース間のレイテンシーなどのレプリケーションタスク関連のメトリクスが含まれます。テーブルのメトリクスには、移行中のデータや、挿入、更新、削除された数などが含まれます。

Amazon CloudWatch のアラームとイベントを設定して、移行をより詳細に追跡できます。移行のデバッグに関する詳細なガイダンスは、AWS DMS 移行のデバッグから入手できます。

アーキテクチャの概要

このアーキテクチャには、独自の VPC とサブネット内のリージョン 1 で実行される RDS for Oracle プライマリインスタンスが含まれます。DR リージョンへのレプリケーションをセットアップするために使用する AWS Database Migration Service は、同じ VPC 内の別の EC2 インスタンスで実行されています。AWS DMS は、データをレプリケートするデータベース移行ジョブを実行します。

ターゲット RDS for Oracle インスタンスは、独自の VPC とパブリックサブネット内のリージョン 2 で実行されています。このインスタンスは、プライマリ RDS インスタンスのスナップショットから作成され、CDC を使用してプライマリでリアルタイムにレプリケートされます。次の図は、このソリューションのアーキテクチャを示しています。これは、AWS DMS を使用して RDS for Oracle にマルチリージョン DR をセットアップするものです。

ソリューションの概要

このソリューションには、次の手順が含まれます。

  1. 選択したリージョンに RDS for Oracle のプライマリインスタンスを設定します。この手順はオプションです。実際のシナリオでは、プライマリデータベースはすでにセットアップされています。
  2. AWS DMS のユーザーを設定して、ソースデータベースで適切な権限で使用できるようにします。さらに、オブジェクトの補足ロギングを有効にします。
  3. 更新がないように、データベースが休止していることを確認してください。これを行うには、スケジュールされたメンテナンスウィンドウにこれを実行する方法があります。あるいは、RDS スナップショットの代わりに、Oracle エクスポートとインポート機能の使用を検討してください。この記事では、RDS スナップショットアプローチを使用します。このアプローチでは、メンテナンスウィンドウ中に手順を実行することを想定しています。
  4. 手動スナップショットを作成する前に、データベースの SCN 番号を取得します。インスタンスのスナップショットを使用して、データベースの初期移行を行います。手動スナップショットを DR のリージョンにコピーできます。詳細については、「スナップショットのコピー」を参照してください。
  5. スナップショットがコピーされた後、このスナップショットを使用して、新しい RDS インスタンスが DR リージョンにプロビジョニングされます。
  6. AWS DMS レプリケーションをセットアップして、以前に出発点としてキャプチャした SCN 番号で CDC を使用します。

この記事では、RDS と AWS DMS 両方のシングル AZ デプロイを使用しています。本番稼働環境では、両方にマルチ AZ 設定を選択することをお勧めします。また、レプリケーションインスタンスはパブリックサブネットに配置され、ターゲット RDS インスタンスにアクセスします。本番稼働シナリオではこれを避け、ピアリングなどの他のオプションを検討してください。

ステップ 1: サンプル RDS for Oracle プライマリインスタンスのセットアップ

開始するには、次の CloudFormation テンプレートを実行します。このテンプレートは、AWS DMS により RDS for Oracle で DR をセットアップする方法の一例です。

このスクリプトは、スクリプトを実行するリージョンで、RDS for Oracle インスタンスとともに新しい VPC とサブネットをプロビジョニングします。このスクリプトは、インストールした SQL Developer で Windows インスタンスもプロビジョニングして、Oracle データベースで使用できるようにします。次のテーブルは、スクリプトの実行に必要なパラメータをまとめたものです。

パラメータラベル (名前) デフォルト 説明
スタック名 入力必須 任意の名前
RDSInstanceType 入力必須 必要に応じてドロップダウンボックスから選択します
EC2ServerInstanceType 入力必須 必要に応じてドロップダウンボックスから選択します
KeyName 入力必須 インスタンスへのアクセスを有効にする既存のキーペアの名前。ドロップダウンボックスから選択します。
VpcCIDR 10.0.0.0/16 VPC の CIDR ブロック
Subnet1CIDR
(PrivateSubnet1CIDR)		 10.0.0.0/19 プライベートサブネット 1 の CIDR ブロック
プライベートサブネット 2 CIDR
(PrivateSubnet2CIDR)		 10.0.32.0/19 プライベートサブネット 2 の CIDR ブロック

次のスクリーンショットは、パラメータ入力画面を示しています。

この記事では、設定のテストに使用できるサンプルデータベースを示します。また、任意のテーブルに行を挿入して、データベースを変更することもできます。

これで、DR インスタンスを作成し、リアルタイムレプリケーションメカニズムを設定して、両方のデータベースを密接に同期させる準備ができました。

作成した RDS インスタンスに移動します。インスタンスのエンドポイント名を取得するには、CloudFormation 出力セクションの SourceOracleEndpoint キーを確認します。同様に、SourceEC2PublicDNS からこのインスタンスの DNS エンドポイントを取得します。

リモートデスクトップソフトウェアを使用して、上記で実行した CloudFormation スクリプトでプロビジョニングされた Windows インスタンスに接続します。このインスタンスには、すでに SQL Developer がインストールされています。次に、SQL Developer を使用して新しいデータベース接続を設定し、上記で作成した RDS for Oracle インスタンスに接続します。以下に詳細を示します。

  • 名前。NewOracleSource
  • データベースのタイプ。Oracle
  • ユーザー名。dbmaster
  • パスワード。dbmaster123
  • 接続タイプ。Basic
  • ホスト名。<<上記の DNS エンドポイント>>
  • ポート。1521
  • SID。OracleDB

[Test] をクリックします。画面の下部に AWS Customer Succcess Stories と表示されるはずです。次のスクリーンショットは、接続の詳細を示しています。

ステップ 2: AWS DMS が使用するユーザーの設定

接続したら、以下のコードを入力して、AWS DMS ユーザーにソース Oracle エンドポイントへアクセスするための次の権限を付与します。

GRANT SELECT ANY TABLE to DMS_USER;
GRANT SELECT on ALL_VIEWS to DMS_USER;
GRANT SELECT ANY TRANSACTION to DMS_USER;
GRANT SELECT on DBA_TABLESPACES to DMS_USER;
GRANT SELECT on ALL_TAB_PARTITIONS to DMS_USER;
GRANT SELECT on ALL_INDEXES to DMS_USER;
GRANT SELECT on ALL_OBJECTS to DMS_USER;
GRANT SELECT on ALL_TABLES to DMS_USER;
GRANT SELECT on ALL_USERS to DMS_USER;
GRANT SELECT on ALL_CATALOG to DMS_USER;
GRANT SELECT on ALL_CONSTRAINTS to DMS_USER;
GRANT SELECT on ALL_CONS_COLUMNS to DMS_USER;
GRANT SELECT on ALL_TAB_COLS to DMS_USER;
GRANT SELECT on ALL_IND_COLUMNS to DMS_USER;
GRANT SELECT on ALL_LOG_GROUPS to DMS_USER;
GRANT LOGMINING TO DMS_USER;

次のスクリーンショットは、SQL Developer コンソールのこのコードを示しています。

さらに、次のコードを入力します。

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','DMS_USER','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR','DMS_USER','EXECUTE');

ソース Oracle データベースインスタンスのアーカイブ REDO ログを 24 時間保持するには、次のクエリを入力します。

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

データベースレベルの補足ロギングを有効にするには、次のクエリを入力します。

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

プライマリキーを持つテーブルの PRIMARY KEY ロギングを有効にするには、次のクエリを入力します。

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

プライマリキーを持たないテーブルの補足ロギングを追加するには、次のクエリを入力します。

alter table dms_sample.nfl_stadium_data add supplemental log data (ALL) columns;
alter table dms_sample.mlb_data add supplemental log data (ALL) columns;
alter table dms_sample.nfl_data add supplemental log data (ALL) columns;

ステップ 3: ソース RDS インスタンスの手動スナップショットの作成

データベースが休止、つまりデータベースの更新ができないことを確認してください。データベースの SCN 番号を取得するには、次のクエリを入力します。

select CURRENT_SCN from v$database;

上記のクエリの出力をメモします。出力は、3829791 などの数値の形式です。この手順は、AWS DMS レプリケーションタスクの設定中に CDC の開始点を設定するために必要です。詳細については、「AWS DMS を使用した継続的なレプリケーションのタスクの作成」を参照してください。

これで、DR インスタンスをセットアップし、初期データをロードできます。そのためには、RDS スナップショット機能を使用します。次の手順を実行します。

  1. AWS マネジメントコンソールで、作成したソース RDS データベースに移動します。
  2. [Snapshots] を選択します。
  3. Actions ドロップダウンから、[Copy Snapshot] を選択します。
  4. Destination Region の Source DB Snapshot で、ユーザーの DR を選択します。
    この記事では、アジアパシフィック (シドニー) を選択しています。
  5. フィールド New DB Snapshot Identifier に名前を付けます。この記事では、source-snapshot です。
  6. 他のすべてのフィールドはデフォルトのままにします。
  7. [Copy Snapshot] を選択します。
    RDS は、宛先リージョンにスナップショットを自動的に表示します。
  8. スナップショットの ARN をメモします。

ステップ 4: DR リージョンでの RDS インスタンスの作成

次の CloudFormation テンプレートを実行します。これにより、作成したスナップショットを使用して、別のリージョンに DR のための RDS インスタンスがセットアップされます。

次のテーブルは、テンプレートに必要なパラメータをまとめたものです。

パラメータラベル (名前) デフォルト 説明
スタック名 入力必須 任意の名前
ClientIP 入力必須 RDS for Oracle データベースへの接続に使用されるクライアントマシンの IP アドレス
DBSnapshotId 入力必須 前の手順で作成した、リージョン内で利用可能な RDS スナップショット

次のスクリーンショットは、パラメータ入力画面を示しています。

AWS マネジメントコンソールの CloudFormation 画面の Outputs セクションから、ターゲット RDS インスタンスのエンドポイントの詳細を取得できます。

DR リージョンの RDS インスタンスをプロビジョニングした後、ステップ 1 でプロビジョニングしたのと同じ Windows クライアントインスタンスから新しいインスタンスへの接続を確認します。SID は TargetDB で、ユーザー名とパスワードはソースインスタンスと同じままです。また、いくつかのテスト SQL を実行して、両方のデータベースが同期していることを確認します。

次のステップは、AWS DMS を使用してソースからターゲットへの変更をキャプチャしてレプリケートすることです。次の CloudFormation template は、ソースとターゲット RDS インスタンスの詳細をパラメータとして取得し、CDC の実行に必要な AWS DMS レプリケーションリソースを作成します。

プライマリデータベースインスタンスが実行されているリージョンまたは DR リージョンで、レプリケーションインスタンスをセットアップできます。フィルターまたは変換を使用してデータのサブセットのみを移行またはレプリケートする場合、ネットワーク経由で DR リージョンに転送されるデータの量が少ないため、レプリケーションインスタンスをソース側に保持する必要があります。この記事、およびデータベース全体の移行と進行中のレプリケーションの他のケースでは、どちらの側でも AWS DMS レプリケーションインスタンスを保持できます。

次のテーブルは、テンプレートに必要なパラメータをまとめたものです。

パラメータラベル (名前) デフォルト 説明
スタック名 入力必須 任意の名前
ExistsDMSCloudwatchRole N dms-cloudwatch-logs-role がアカウントにすでに存在する場合は、Y を入力します。それ以外の場合はデフォルトのままにします
ExistsDMSVPCRole N アカウントに dms-vpc-role が存在する場合、Y を入力します。それ以外の場合はデフォルトのままにします
OracleRDSSourceEndpoint 入力必須 ソース RDS for Oracle データベースのエンドポイント
OracleRDSSourcePort 1521 ソース RDS for Oracle データベースのポート
OracleRDSSourceUser 入力必須 ターゲット RDS for Oracle データベースのユーザー
OracleRDSSourcePassword 入力必須 前のユーザーのパスワード
OracleRDSTargetEndpoint 入力必須 ターゲット RDS for Oracle データベースのエンドポイント
OracleRDSTargetPort 1521 ソース RDS for Oracle データベースのポート
OracleRDSTargetUser 入力必須 ターゲット RDS for Oracle データベースのユーザー
OracleRDSTargetPassword 入力必須 前のユーザーのパスワード
SCNNumber 入力必須 Oracle のシステム変更番号。これを取得するには、ドキュメントの指示に従ってください
SourceDatabase 入力必須 ソース RDS for Oracle のデータベース名
TargetDatabase 入力必須 ターゲット RDS for Oracle のデータベース名
VPC 入力必須 前の手順で設定した既存の仮想プライベートクラウドの VPC ID
サブネット 入力必須 ドロップダウンから DMS インスタンスのサブネットを選択します

次のスクリーンショットは、パラメータ入力画面を示しています。

スクリプトを正常に実行したら、CDC を実行する必要があるすべての AWS DMS リソースが作成され、レプリケーションタスクが実行されているはずです。これらのリソースは、コンソール内の AWS DMS 画面に移動して見つけることができます。レプリケーションタスクのステータスが Ready から Replication Ongoing に変わるまで数分かかります。自動的に変更されない場合は、次の手順を実行します。

  1. DMS コンソールで、タスクを選択します。
  2. Actions ドロップダウンから、[Restart/Resume] を選択します。

ステップ 5: CDC のテスト

これで、レプリケーションが機能しているかどうかをテストできます。ソースにダミー行を挿入し、それらがターゲットに即座に複製されることを確認するには、次の SQL を実行します。

INSERT ALL
INTO dms_sample.sport_type (name,description) VALUES ('hockey', 'A sport in which two
teams play against each other by trying to more a puck into the opponents goal using a
hockey stick')
INTO dms_sample.sport_type (name,description) VALUES ('basketball', 'A sport in which
two teams of five players each that oppose one another shoot a basketball through the
defenders hoop')
INTO dms_sample.sport_type (name,description) VALUES ('soccer','A sport played with a
spherical ball between two teams of eleven players')
INTO dms_sample.sport_type (name,description) VALUES ('volleyball','two teams of six
players are separated by a net and each team tries to score by grounding a ball on the
others court')
INTO dms_sample.sport_type (name,description) VALUES ('cricket','A bat-and-ball game
between two teams of eleven players on a field with a wicket at each end')
SELECT * FROM dual;
COMMIT;
SELECT * FROM dms_sample.sport_type;

AWS DMS タスクは、ターゲット Oracle データベースをソースデータベースの変更に合わせて最新の状態に保ちます。

ターゲットがソースに追いついたときのレイテンシーはゼロに近くなります。

DR のトリガー

上記のセットアップを適切に行うと、災害が発生した場合、通常、次の変更を行います。これにより、アプリケーションがセカンダリデータベース (新しいプライマリ) に到達し、リクエストを効率的に処理できるようになります。

  1. DNS 設定を変更するか、Amazon Route 53 のアクティブ/パッシブフェイルオーバー機能を使用します。フェイルオーバーが発生すると、DR リージョンのセカンダリデータベースインスタンスが新しいプライマリデータベースインスタンスになります。
  2. 新しい RDS プライマリインスタンスをアプリケーションに必要な容量にスケールアップします (BYOL モデルを使用している場合、Oracle データベースに適用されるライセンス制限を考慮してください)。
  3. 新しいプライマリデータベースインスタンスのマルチ AZ オプションをオンにします。
  4. 前述の手法を使用して、RDS スナップショットを別のリージョンにコピーし、SCN 番号をメモします。
  5. CloudFormation テンプレートを起動して、ターゲットリージョンに新しいセカンダリデータベースを作成します。
  6. CloudFormation テンプレートを起動して、AWS DMS レプリケーションインスタンスをセットアップし、新しいプライマリデータベースインスタンスから指定した SCN 番号で AWS DMS タスクを作成して実行します。

レプリケーションラグを減らし、AZ 障害の場合に DMS レプリケーションの可用性を高める詳細については、「AWS Database Migration Service のベストプラクティス」を参照してください。

概要

この記事では、DMS をコスト効率よく使用して RDS for Oracle データベースの DR ソリューションをセットアップする方法について説明しました。AWS DMS は、ソースデータストアに対する継続的な変更をキャプチャし、それらをターゲットデータストアに適用します。ただし、RPO 要件に関して定義された SLA がある状況では、ソリューションをテストして、このための独自のベンチマークに到達することをお勧めします。Oracle Golden Gate や Cross-region Read Replicas などのプライマリインスタンスから DR インスタンスにデータをレプリケートするためのさまざまなオプションを比較検討し、最適なオプションを見極める必要があります。AWS Database Migration Service の詳細については、「AWS Database Migration Service の使用開始」を参照してください。このアプローチがお客様ご自身や顧客にどのように機能したかについてご意見があれば、コメント欄にご記入ください。

 

著者について

Madhuri Susarla は、AWS のパートナーチームのソリューションアーキテクトです。彼女は大手のグローバルシステムインテグレーターと協力して、クラウドコンピューティングの時代に価値を創造することに情熱を傾けています。彼女は複数のクラウドプラットフォームを手がけました。コンテンツを作成して人前で話すことによって再利用性が高まると考えています。彼女は 3 人の息子たちと遊ぶことを楽しんでいますが、子どものサッカー、勉強、料理の選択に追われています。

 

 

Ejaz Sayyed はアマゾン ウェブ サービスのグローバルシステムインテグレーター (GSI) チームのパートナーソリューションアーキテクトです。Ejaz が主に取り組んでいる分野には、AWS のデータベースサービス、および AWS でのデータベースとデータウェアハウスの移行などがあります。最近は、お客様のために、GSI が AWS 上でのデータレイクを構築するためのサポートをしています。