AWS DMS を使用した継続的なレプリケーションのタスクの作成

ソースデータストアから継続的な変更をキャプチャする AWS DMS タスクを作成できます。このキャプチャはデータの移行中に実行できます。サポートされているターゲットデータストアへの初めての (フルロード) 移行が完了した後に、継続的な変更をキャプチャするタスクを作成することもできます。このプロセスは継続的なレプリケーションまたは変更データキャプチャ (CDC) と呼ばれます。AWS DMS では、このプロセスを使用してソースデータストアの継続的な変更をレプリケートします。データベースエンジンのネイティブ API を使用してデータベースログへの変更を収集することが、このプロセスの仕組みです。

注記

ビューを移行できるのは、フルロードタスクのみを使用する場合です。CDC のみのタスク、または完了後に CDC を開始するフルロードタスクの場合、移行の範囲はソースのテーブルのみとなります。フルロードのみのタスクを使用すると、ビューまたはテーブルとビューの組み合わせを移行できます。詳細については、「 JSON を使用するテーブル選択および変換を指定する」を参照してください。

各ソースエンジンには、この変更ストリームを特定のユーザーアカウントにパブリッシュするための固有の設定要件があります。ほとんどのエンジンでは、キャプチャプロセスがデータを損失することなく意味のある方法で変更データを使用できるようにするために、追加の設定が必要になります。例えば、Oracle ではサプリメンタルロギングの追加が必要であり、MySQL では行レベルのバイナリログ (bin ログ) が必要です。

ソースデータベースから継続的な変更を読み取るために、AWS DMS はエンジン固有の API アクションを使用してソースエンジンのトランザクションログから変更を読み取ります。AWS DMS での実際の例は次のとおりです。

Oracle の場合、AWS DMS は、Oracle LogMiner API または Binary Reader API (bfile API) を使用して継続的な変更を読み取ります。AWS DMS は、システム変更番号 (SCN) に基づいてオンラインまたはアーカイブ REDO ログから継続的な変更を読み取ります。
Microsoft SQL Server の場合、AWS DMS は MS-Replication または MS-CDC を使用して SQL Server のトランザクションログに情報を書き込みます。次に、SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用して、ログシーケンス番号 (LSN) に基づいてトランザクションログの変更を読み取ります。
MySQL の場合、AWS DMS は、行ベースのバイナリログ (binlog) から変更を読み取り、この変更をターゲットに移行します。
PostgreSQL の場合、AWS DMS は論理レプリケーションスロットを設定して、test_decoding プラグインを使用し、ソースから変更を読み取り、この変更をターゲットに移行します。
Amazon RDS をソースとして使用する場合は、CDC をセットアップするためにバックアップが有効になっていることを確認することをお勧めします。また、変更ログを十分な時間 (通常は 24 時間で十分) 保持するようにソースデータベースが設定されていることを確認することをお勧めします。各エンドポイントの特定の設定については、次を参照してください。
- Amazon RDS for Oracle: AWS管理対象の Oracle ソースを次のように設定します。 AWS DMS
- Amazon RDS for MySQL and Aurora MySQL: AWSマネージド型の MySQL 互換データベースをソースとして使用する AWS DMS
- Amazon RDS for SQL Server: Cloud SQL Server DB インスタンスでの継続的なレプリケーションのセットアップ
- Amazon RDS for PostgreSQL と Aurora PostgreSQL: PostgreSQL は必要な WAL を自動的に保持します

継続的なレプリケーションタスクには 2 つのタイプがあります。

フルロード + CDC: このタスクは既存のデータを移行して、ソースデータベースへの変更に基づいてターゲットデータベースを更新します。
CDC のみ: このタスクは、ターゲットデータベースにデータが移行した後、継続的な変更を移行します。

CDC 開始点を起点とするレプリケーションの実行

AWS DMS の継続的なレプリケーションタスク (変更データキャプチャのみ) は、複数の開始点から開始できます。これには次が含まれます。

カスタム CDC 開始時刻から – AWS Management Console または AWS CLI を使用して、レプリケーションを開始するタイムスタンプを AWS DMS に指示できます。AWS DMS は、このカスタム CDC 開始時刻から継続的なレプリケーションタスクを開始します。AWS DMS は、指定されたタイムスタンプ (UTC) を、SQL Server の LSN や Oracle の SCN などのネイティブ開始点に変換します。AWS DMS は、エンジン固有のメソッドを使用して、ソースエンジンの変更ストリームに基づいて移行タスクを開始する場所を決定します。

注記
ソースが Db2 の場合、StartFromContext 接続属性を必要なタイムスタンプに設定した場合にのみ CDC 開始時刻をカスタマイズできます。
PostgreSQL がソースの場合、カスタム CDC 開始時刻はサポートされません。これは、Oracle や SQL Server とは異なり、PostgreSQL データベースエンジンにはタイムスタンプを LSN や SCN にマップする方法がないためです。
CDC ネイティブ開始点から – ソースエンジンのトランザクションログのネイティブ開始点から開始することもできます。タイムスタンプはトランザクションログ内の複数のネイティブ開始点を示す可能性もあるため、場合によっては、この方法のほうが適していることがあります。AWS DMS は、この機能を次のソースエンドポイントでサポートしています。
- SQL Server
- PostgreSQL
- Oracle
- MySQL
- MariaDB

タスクが作成されると、AWS DMS は CDC の開始点にマークが付けられます。これを変更することはできません。別のCDC開始点を使用するには、新しいタスクを作成します。

CDC ネイティブ開始点の決定

CDC ネイティブ開始点は、CDC を開始できる時間を定義するデータベースエンジンのログ内の開始点です。一括データダンプが既にターゲットに適用されている場合を例にとって説明します。この場合、継続的なレプリケーションのみのタスクのネイティブ開始点を検索できます。データの不整合を回避するには、レプリケーションのみのタスクの開始点は慎重に選択します。DMS は、選択された CDC 開始点の後に開始されたトランザクションをキャプチャします。

サポートされているソースエンジンから CDC ネイティブ開始点を検索する方法の例は次のとおりです。

SQL Server

SQL Server のログシーケンス番号 (LSN) は次の 3 つの部分で構成されています。

仮想ログファイル (VLF) シーケンス番号
ログブロックの開始オフセット
スロット番号

LSN の例: 00000014:00000061:0001

トランザクションログのバックアップ設定に基づいて SQL Server 移行タスクの開始点を取得するには、SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用します。

SQL Server で CDC ネイティブ開始点を使用するには、継続的なレプリケーションの対象の任意のテーブルにパブリケーションを作成します。CDC ネイティブ開始点を使用せずに CDC を使用すると、AWS DMS はパブリケーションを自動的に作成します。

PostgreSQL

PostgreSQL データベースがソースの場合は、CDC 復旧チェックポイントを使用できます。このチェックポイントの値は、ソースデータベース (親タスク) に対して継続的なレプリケーションタスクが実行される際、さまざまな時点で生成されます。チェックポイントの一般的な詳細については、「CDC 開始点としてのチェックポイントの使用」を参照してください。

ネイティブ開始点として使用するチェックポイントを特定するには、データベースの pg_replication_slots ビューを使用するか、AWS Management Console から親タスク概要の詳細を使用します。

コンソールで親タスクの概要の詳細を検索するには

AWS Management Console にサインインして、https://console.aws.amazon.com/dms/v2/ で AWS DMS コンソールを開きます。

IAM ユーザーとしてサインインしている場合は、AWS DMS にアクセスするための適切なアクセス許可があることを確認します。必要なアクセス許可の詳細については、「AWS DMS の使用に必要な IAM アクセス許可」を参照してください。
ナビゲーションペインで、[データベース移行タスク] を選択します。
[データベース移行タスク] ページのリストから親タスクを選択すると、親タスクのページが開き、概要の詳細が表示されます。
[変更データキャプチャ (CDC)]、[変更データキャプチャ (CDC) の開始位置]、[変更データキャプチャ (CDC) の復旧チェックポイント] の下にあるチェックポイントの値を調べます。

値は、次のように表示されます。
```
checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0
```
ここで、4AF/B00000D0 コンポーネントは、このネイティブ CDC 開始点に関して指定が必須です。CDC タスクを作成して、PostgreSQL ソースのこの開始点でレプリケーションを開始するために、DMS API の CdcStartPosition パラメータをこの値に設定します。AWS CLI を使用してこのような CDC タスクを作成する方法の詳細については、「AWS DMS を使用して AWS が管理する PostgreSQL DB インスタンスでの CDC の有効化」を参照してください。

Oracle

システム変更番号 (SCN) は、Oracle データベースで使用される論理的な内部タイムスタンプです。SCN は、データベース内で発生するイベントを順序付けします。これは、トランザクションの ACID プロパティを満たすために必要です。Oracle データベースは SCN を使用して、すべての変更がディスクに書き込まれた場所をマークし、復旧アクションによってこの場所に既に書き込まれた変更が適用されないようにします。Oracle はまた、復旧を停止できるように、SCN を使用してデータセットに対して REDO が存在しないポイントをマークします。

Oracle データベース内の現在の SCN を取得するには、次のコマンドを実行します。


SELECT CURRENT_SCN FROM V$DATABASE

SCN またはタイムスタンプを使用して CDC タスクを開始すると、オープントランザクションの結果が失われ、このような結果の移行に失敗します。オープントランザクションとは、タスクの開始位置より前に開始され、タスクの開始位置の後にコミットされたトランザクションを指します。SCN とタイムスタンプを特定して、すべてのオープントランザクションを含む時点から CDC タスクを開始できます。詳細については、Oracle オンラインドキュメントの「トランザクション」を参照してください。バージョン 3.5.1 以降では、タスクを開始するために SCN またはタイムスタンプを使用する場合、AWS DMS は openTransactionWindow エンドポイント設定を使用して CDC のみのタスクのオープントランザクションをサポートしています。

この openTransactionWindow 設定を使用する場合、オープントランザクションを処理する期間を分単位で指定する必要があります。AWS DMS はキャプチャ位置を移動して、データキャプチャを開始する新しい位置を検索します。AWS DMS は、必要となる Oracle REDO ログまたはアーカイブ REDO ログからオープントランザクションをスキャンするために新しい開始位置を使用します。

MySQL

MySQL バージョン 5.6.3 のリリース前までは、MySQL のログシーケンス番号 (LSN) は 4 バイトの符号なし整数でした。MySQL バージョン 5.6.3 では、REDO ログファイルのサイズ上限が 4 GB から 512 GB に引き上げられ、LSN は 8 バイトの符号なし整数になりました。この増加は、サイズ情報の保存に追加のバイトが必要になったことを受けてのことです。MySQL 5.6.3 以降で構築された LSN 値を使用するアプリケーションでは、LSN 値を保存して比較するために 32 ビット変数ではなく 64 ビット変数を使用する必要があります。MySQL の LSN の詳細については、「MySQL のドキュメント」を参照してください。

MySQL データベース内の現在の LSN を取得するには、次のコマンドを実行します。


mysql> show master status;

このクエリは、binlog ファイル名、位置、その他いくつかの値を返します。CDC ネイティブ開始点は、binlog ファイル名と位置の組み合わせになります (mysql-bin-changelog.000024:373 など)。この例では、mysql-bin-changelog.000024 は binlog ファイル名、373 は AWS DMS で変更のキャプチャを開始すべき位置です。

CDC 開始点としてのチェックポイントの使用

継続的なレプリケーションタスクが変更を移行し、AWS DMS では AWS DMS 固有のチェックポイント情報を随時キャッシュします。AWS DMS が作成するチェックポイントには、レプリケーションエンジンが変更ストリームの復旧点を認識できる情報が含まれています。チェックポイントを使用すると、変更のタイムラインに戻り、失敗した移行タスクを回復できます。また、チェックポイントを使用して、任意の時点で別のターゲットに対して別の継続的なレプリケーションタスクを開始することもできます。

チェックポイント情報の取得には、次の 3 つのいずれかの方法を使用します。

API オペレーション DescribeReplicationTasks を実行して結果を表示します。タスクごとに情報にフィルターを適用してチェックポイントを検索できます。タスクが停止または失敗した最新のチェックポイントを取得できます。タスクを削除すると、この情報は失われます。
ターゲットインスタンスで awsdms_txn_state というメタデータテーブルを表示します。テーブルでクエリを実行すると、チェックポイント情報を取得できます。メタデータテーブルを作成するには、タスクの作成時に TaskRecoveryTableEnabled パラメータを Yes に設定します。この設定があると、AWS DMS はチェックポイント情報を継続的にターゲットメタデータテーブルに書き込みます。タスクを削除すると、この情報は失われます。

メタデータテーブル checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121 のチェックポイントの例は次のとおりです。
ナビゲーションペインで、[データベース移行タスク] を選択して、[Database migration tasks] ページに表示されるリストから親タスクを選択します。親タスクページが開き、概要の詳細が表示されます。[変更データキャプチャ (CDC)]、[変更データキャプチャ (CDC) の開始位置]、[変更データキャプチャ (CDC) の復旧チェックポイント] の下にあるチェックポイントの値を調べます。チェックポイント値は、次のように表示されます。

checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

コミット時点またはサーバー時間のポイントでのタスクの停止

CDC ネイティブ開始点の導入により、AWS DMS は次の時点でタスクを停止することもできます。

ソースでのコミット時刻
レプリケーションインスタンスのサーバー時間

必要に応じてタスクを変更して、停止する時刻を UTC で設定できます。タスクは、設定したコミット時間またはサーバー時間に基づいて自動的に停止します。または、タスクの作成時に移行タスクを停止する時間が明らかである場合は、タスクの作成時に停止時刻を設定できます。

注記

新しい AWS DMS サーバーレスレプリケーションを初めて開始する場合、すべてのリソースを初期化するのに最大 40 分かかることがあります。server_time オプションは、リソースの初期化が完了した後にのみ適用されることに注意します。

双方向レプリケーションの実行

AWS DMS タスクを使用して、2 つのシステム間で双方向レプリケーションを実行できます。双方向レプリケーションの場合、2 つのシステム間で同じテーブル (またはテーブルセット) のデータを両方向にレプリケートできます。

例えば、EMPLOYEE テーブルをデータベース A からデータベース B にコピーして、このテーブルに対する変更をデータベース A からデータベース B にレプリケートできます。また、EMPLOYEE テーブルに対する変更をデータベース B から A にレプリケートすることもできます。つまり、双方向にレプリケートすることになります。

注記

AWS DMS 双方向レプリケーションは、プライマリノード、競合解決などの完全なマルチマスターソリューションを意図して設計されているわけではありません。

双方向レプリケーションは、異なるノード上のデータが運用上分離されている状況で使用します。つまり、ノード A で動作しているアプリケーションが変更したデータ要素があり、そのノード A がノード B との双方向レプリケーションを実行するとします。ノード A のそのデータ要素は、ノード B で動作するアプリケーションによって変更されることはありません。

AWS DMS は、次のデータベースエンジンで双方向レプリケーションをサポートしています。

Oracle
SQL Server
MySQL
PostgreSQL
Amazon Aurora MySQL 互換エディション
Aurora PostgreSQL 互換エディション

双方向レプリケーションタスクの作成

AWS DMS 双方向レプリケーションを有効にするには、両方のデータベース(A と B) のソースエンドポイントとターゲットエンドポイントを設定します。例えば、データベース A のソースエンドポイント、データベース B のソースエンドポイント、データベース A のターゲットエンドポイント、データベース B のターゲットエンドポイントを設定します。

次に、ソース A がデータをターゲット B に移動するタスクと、ソース B がデータをターゲット A に移動するタスクの 2 つのタスクを作成します。さらに、各タスクでループバック防止機能が設定されていることを確認します。これにより、両方のタスクのターゲットに同一の変更が適用されることが避けられ、少なくとも一方のタスクのデータが破損するのを防ぐことができます。詳細については、「ループバックの防止」を参照してください。

最も簡単な方法としては、まずデータベース A とデータベース B の両方に同一のデータセットを作成します。次に CDC のみのタスクを 2 つ作成します。1 つは A から B にデータをレプリケートするタスクで、もう 1 つは B から A にデータをレプリケートするタスクです。

AWS DMS を使用してノード A からノード B の新しいデータセット (データベース) をインスタンス化するには、次を実行します。

データベース A から B にデータを移動するにはフルロードおよび CDC タスクを使用します。この間、アプリケーションがデータベース B のデータを変更しないことを確認します。
フルロードが完了した後、アプリケーションがデータベース B のデータを変更できるようになる前に、データベース B の時刻または CDC 開始位置をメモします。手順については、「CDC 開始点を起点とするレプリケーションの実行」を参照してください。
この開始時刻または CDC 開始位置を使用して、データベース B から A にデータを移動する CDC 専用タスクを作成します。

注記

フルロードと CDC に使用できる双方向ペアのタスクは 1 つのみです。

ループバックの防止

タスク T1 で AWS DMS がソースデータベース A から変更ログを読み取り、ターゲットデータベース B に変更内容を適用するケースを例に、ループバックの防止について説明します。

次に、2 番目のタスクである T2 がソースデータベース B から変更ログを読み取り、ターゲットデータベース A に適用します。T2 がこれを行う前に、DMS では、ソースデータベース A からターゲットデータベース B に対して行われたのと同じ変更がソースデータベース B に対して行われていないことを確認する必要があります。つまり、DMS は、このような変更がターゲットデータベース A にエコー (ループ) されないことを確認する必要があります。これを行わないと、データベース A のデータが破損する可能性があります。

変更のループバックを回避するには、各双方向レプリケーションタスクに次のタスク設定を追加します。これにより、どちらの方向でもループバックデータの破損が発生しないようにします。


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

LoopbackPreventionSettings タスク設定により、トランザクションが新規であるか、反対方向のレプリケーションタスクからのエコーであるかが定まります。AWS DMS がトランザクションをターゲットデータベースに適用すると、変更を示す DMS テーブル (awsdms_loopback_prevention) が更新されます。各トランザクションをターゲットに適用する前に、DMS はこの awsdms_loopback_prevention テーブルへの参照を含むトランザクションをすべて無視します。したがって、変更は適用されません。

双方向ペアの各レプリケーションタスクにこのようなタスク設定を含めます。このような設定により、ループバック防止機能が有効になります。さらに、この設定は、各エンドポイントの awsdms_loopback_prevention テーブルを含むタスク内の各ソースデータベースとターゲットデータベースのスキーマも指定します。

各タスクがこのようなエコーを識別して破棄できるようにするには、EnableLoopbackPrevention を true に設定します。awsdms_loopback_prevention を含むソースでスキーマを指定するには、SourceSchema をソースデータベース内の該当するスキーマ名に設定します。同じテーブルを含むターゲットでスキーマを指定するには、TargetSchema をターゲットデータベース内の該当するスキーマ名に設定します。

次の例では、レプリケーションタスク T1 とその反対方向のレプリケーションタスク T2 の SourceSchema 設定と TargetSchema 設定が、反対方向の設定で指定されています。

タスク T1 の設定は、次のとおりです。


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

反対方向のタスク T2 の設定は、次のとおりです。


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}

注記

AWS CLI を使用する場合、create-replication-task コマンドまたは modify-replication-task コマンドのみを使用して、双方向レプリケーションタスクで LoopbackPreventionSettings を設定します。

双方向レプリケーションの制限

AWS DMS の双方向レプリケーションには、次の制限があります。

ループバック防止は、データ操作言語 (DML) ステートメントのみを追跡します。AWS DMS は、データ定義言語 (DDL) ループバックの防止をサポートしていません。これを行うには、双方向ペアのいずれかのタスクを、DDL ステートメントを除外するように設定します。
ループバック防止を使用するタスクは、バッチでの変更のコミットはサポートしていません。ループバック防止を使用してタスクを設定するには、BatchApplyEnabled を false に設定します。
DMS 双方向レプリケーションには、競合の検出や解決は含まれません。データの不整合を検出するには、両方のタスクでデータ検証を使用します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

複数のタスクの作成

[Modifying a task] (タスクの変更)