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

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

注記

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

ソースエンジンごとに、この変更ストリームを指定されたユーザーアカウントに開示するための固有の設定要件があります。ほとんどのエンジンでは、キャプチャプロセスでデータ損失を発生させずに意味のある方法で変更データを使用するために、追加の設定が必要です。たとえば、Oracle ではサプリメンタルロギングの追加が必要であり、MySQL では行レベルのバイナリログ (bin ログ) が必要です。

ソースデータベースから進行中の変更を読み取るために、はエンジン固有の API アクションAWS DMSを使用してソースエンジンのトランザクションログから変更を読み込みます。AWS DMSその方法の例を以下に示します。

Oracle の場合、Oracle LogMiner API またはバイナリリーダー API (bfile API) AWS DMSを使用して、進行中の変更を読み取ります。は、システム変更番号 (SCN) に基づいて、オンラインまたはアーカイブの REDO ログから進行中の変更をAWS DMS読み取ります。
Microsoft SQL Server の場合、は MS-Replication または MS-CDC AWS DMSを使用して、SQL Server トランザクションログに情報を書き込みます。次に、SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用して、ログシーケンス番号 (LSN) に基づいてトランザクションログの変更を読み取ります。
MySQL の場合、は行ベースのバイナリログ (バイナリログ) から変更をAWS DMS読み取り、それらの変更をターゲットに移行します。
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 マネジメントコンソールまたはを使用してAWS CLI、レプリケーションを開始するタイムスタンプAWS DMSを指定できます。AWS DMSその後、はこのカスタム CDC 開始時刻から継続的なレプリケーションタスクを開始します。は、指定されたタイムスタンプ (UTC 単位) を SQL Server の LSN や Oracle の SCN などのネイティブ開始ポイントAWS DMSに変換します。は、エンジン固有の方法AWS DMSを使用して、ソースエンジンの変更ストリームに基づいて移行タスクを開始する場所を決定します。

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

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

注記

CDC (Change Data Capture) の開始点を指定しても、移行前評価は現在の環境の既存のメタデータとパラメータの完全な分析を実行します。これにより、指定された CDC 開始点に関係なく、現在のすべての設定と設定が評価されます。

重要: 特定のタスクに対して過去 7 日以内に評価が実行されていない場合、移行前評価は再開モードと再ロードモードの両方で自動的に実行され、データの完全性と一貫性が確保されます。

技術的な詳細:

メタデータ分析は引き続き包括的です。
パラメータ評価は、現在の状態を対象としています。
CDC 開始点は評価範囲を制限しません。
完全なシステム設定レビューは維持されます。
再開モードと再ロードモードの自動実行は、次の場合に行われます。

最終評価 > 7 日前。

以前の評価レコードが見つかりませんでした。

これにより、指定された 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 マネジメントコンソール

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

にサインインAWS マネジメントコンソールし、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
```
ここでは、このネイティブ CDC 開始ポイントを指定するために必要な 4AF/B00000D0 コンポーネントです。PostgreSQL ソースのこの開始ポイントでレプリケーションを開始する CDC タスクを作成するときに、DMS API CdcStartPosition パラメータをこの値に設定します。を使用してこの CDC タスクAWS CLIを作成する方法については、「」を参照してくださいで AWSマネージド PostgreSQL DB インスタンスを使用して CDC を有効にするAWS DMS。

Oracle

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

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


SELECT CURRENT_SCN FROM V$DATABASE

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

openTransactionWindow 設定を使用する場合、開いているトランザクションを処理するには、ウィンドウを分単位で指定する必要があります。はキャプチャ位置をAWS DMSシフトし、データキャプチャを開始する新しい位置を見つけます。は、必要な Oracle REDO またはアーカイブされた REDO ログから開いているトランザクションをスキャンするために新しい開始位置AWS DMSを使用します。

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 ネイティブの開始ポイントは、binlogs ファイルの名前と位置の組み合わせです (例: mysql-bin-changelog.000024:373)。この例では、 mysql-bin-changelog.000024はバイナリログファイル名で、 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] (データベース移行タスク) を選択し、[Database migration tasks](データベース移行タスク) ページに表示されるリストから親タスクを選択します。親タスクページが開き、概要の詳細が表示されます。[データキャプチャの変更 (CDC)]、[データキャプチャの変更 (CDC) の開始位置]、および [データキャプチャの変更 (CDC) リカバリチェックポイント] でチェックポイント値を見つけます。チェックポイントの値は、次のようになります：

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

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

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

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

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

注記

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

ターゲットの再ロードによるタスクの開始

再ロードオプション (DMS API では「reload-target」) を使用して、既存のデータをAWS DMS移行し、進行中の変更タスクをレプリケートできます。この場合、移行は最初から開始され、各テーブルデータを再ロードし、フルロードおよび CDC 対応タスク設定を使用してデータレプリケーションを続行します。

再ロードオプションでタスク開始を使用するには、次の条件を適用する必要があります。

タスクを停止する必要があります。
タスクの移行メソッドは、全ロードまたは CDC による全ロードであることが必要です。

DMS は、テーブルを再ロードする前に TargetTablePrepMode 設定を適用します。TargetTablePrepMode をに設定する場合はDO_NOTHING、まずテーブルを手動で切り捨てる必要があります。

注記

ターゲットの再ロードオプションを使用して DMS タスクを開始すると、移行前評価は現在の環境の既存のメタデータとパラメータの完全な分析を実行します。これにより、実際のタスクステータスに関係なく、現在のすべての設定と設定が評価されます。

重要

特定のタスクに対して過去 7 日以内に評価が実行されていない場合、データの完全性と一貫性を確保するために、移行前評価が自動的に実行されます。

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

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

たとえば、データベース A からデータベース B に EMPLOYEE テーブルをコピーし、テーブルの変更内容をデータベース 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 つだけです。

ループバックの防止

ループバックの防止を表示するには、タスク T1AWS 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 双方向レプリケーションには、競合の検出や解決は含まれていません。データの不整合を検出するには、両方のタスクでデータ検証を使用します。
SQL Server ソースエンドポイントで双方向レプリケーションを設定するには、setUpMsCdcForTables を true に設定する必要があります。

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

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

ドキュメントの表記規則

複数のタスクの作成

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