翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# を使用した継続的なレプリケーション用のタスクの作成 AWS DMS
<a name="CHAP_Task.CDC"></a>

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

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

ソースエンジンごとに、この変更ストリームを指定されたユーザーアカウントに開示するための固有の設定要件があります。ほとんどのエンジンでは、キャプチャプロセスでデータ損失を発生させずに意味のある方法で変更データを使用するために、追加の設定が必要です。たとえば、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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Amazon-Managed.Configuration)
  + **Amazon RDS for MySQL and Aurora MySQL:** [のソースとしての AWSマネージド MySQL 互換データベースの使用 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.AmazonManaged)
  + **Amazon RDS for SQL Server:** [Cloud SQL Server DB インスタンスでの継続的なレプリケーションのセットアップ](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration)
  + **Amazon RDS for PostgreSQL と Aurora PostgreSQL:** PostgreSQL は必要な WAL を自動的に保持します 

継続的なレプリケーションタスクには 2 つのタイプがあります。
+ 全ロード \+ CDC: タスクでは、まず既存のデータを移行し、次にソースデータベースへの変更に応じてターゲットデータベースを更新します。
+ CDC のみ: タスクでは、ターゲットデータベースにデータが取り込まれた後の継続的変更を移行します。

## CDC 開始ポイントからのレプリケーションの実行
<a name="CHAP_Task.CDC.StartPoint"></a>

複数のポイントから AWS DMS 継続的なレプリケーションタスク (変更データキャプチャのみ) を開始できます。これには以下が含まれます。
+  **カスタム CDC 開始時刻から** – AWS マネジメントコンソール または を使用して AWS CLI 、レプリケーションを開始する AWS DMS タイムスタンプを指定できます。 AWS DMS はこのカスタム CDC 開始時刻から継続的なレプリケーションタスクを開始します。 は、指定されたタイムスタンプ (UTC 単位) を SQL Server の LSN や Oracle の SCN などのネイティブ開始ポイント AWS DMS に変換します。 は、エンジン固有の方法 AWS DMS を使用して、ソースエンジンの変更ストリームに基づいて移行タスクを開始する場所を決定します。
**注記**  
`StartFromContext` 追加の接続属性を必要なタイムスタンプに設定することによってのみ、ソースとして Db2 はカスタマイズされた 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 ネイティブ開始ポイント機能をサポートしていません。  
 Amazon Aurora MySQL 
 Amazon Aurora PostgreSQL 
Amazon DocumentDB (MongoDB 互換性)
Amazon S3
IBM Db2 for z/OS
IBM Db2 LUW
Microsoft Azure SQL データベース
Microsoft Azure SQL マネージドインスタンス
MongoDB
SAP Sybase ASE

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

**注記**  
 CDC (Change Data Capture) の開始点を指定しても、移行前評価は現在の環境の既存のメタデータとパラメータの完全な分析を実行します。これにより、指定された CDC 開始点に関係なく、現在のすべての設定と設定が評価されます。  
 重要: 特定のタスクに対して過去 7 日以内に評価が実行されていない場合、移行前評価は再開モードと再ロードモードの両方で自動的に実行され、データの完全性と一貫性が確保されます。  
 メタデータ分析は引き続き包括的です。
 パラメータ評価は、現在の状態を対象としています。
 CDC 開始点は評価範囲を制限しません。
 システム設定の完全なレビューは維持されます。
 以下の場合、再開モードと再ロードモードでの自動実行:   
 最終評価 > 7 日前。  
 以前の評価レコードが見つかりませんでした。
 これにより、指定された CDC ポイントと現在のシステム状態間のデータ整合性を維持しながら、正確な移行計画を立てることができます。

### CDC ネイティブのスタートポイントの決定
<a name="CHAP_Task.CDC.StartPoint.Native"></a>

*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 のスタートポイントとして使用する](#CHAP_Task.CDC.StartPoint.Checkpoint)」をご参照ください。  
ネイティブの開始点として使用するチェックポイントを特定するには、データベース`pg_replication_slots`ビューまたは親タスクの概要の詳細を AWS マネジメントコンソール  

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

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。

   IAM ユーザーとしてサインインしている場合は、 AWS DMSにアクセスするための適切なアクセス許可があることを確認します。必要なアクセス権限の詳細については、「[を使用するために必要な IAM アクセス許可 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)」をご参照ください。

1. ナビゲーションペインで、[**データベース移行タスク**] を選択します。

1. [**データベース移行タスク**] ページのリストから親タスクを選択します。これにより、親タスクページが開き、概要の詳細が表示されます。

1. [**データキャプチャの変更 (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](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC)。

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

```
SELECT CURRENT_SCN FROM V$DATABASE
```
SCN またはタイムスタンプを使用して CDC タスクを開始すると、オープントランザクションの結果が失われ、このような結果の移行に失敗します。**オープントランザクションとは、タスクの開始位置より前に開始され、タスクの開始位置の後にコミットされたトランザクションを指します。SCN とタイムスタンプを特定して、すべての未決トランザクションを含むポイントで CDC タスクをスタートできます。詳細については、Oracle ドキュメントの「[トランザクション](https://docs.oracle.com/database/121/CNCPT/transact.htm#CNCPT016)」をご参照ください。バージョン 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 のドキュメント](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_lsn)」をご参照ください。  
 MySQL データベース内の現在の LSN を取得するには、以下のコマンドを実行します。  

```
mysql> show master status;
```
 このクエリから、binlog ファイルの名前、位置、およびその他いくつかの値が返されます。CDC ネイティブの開始ポイントは、binlogs ファイルの名前と位置の組み合わせです (例: `mysql-bin-changelog.000024:373`)。この例では、 `mysql-bin-changelog.000024`はバイナリログファイル名で、 `373`は が変更のキャプチャを開始 AWS DMS する必要がある位置です。

### チェックポイントを CDC のスタートポイントとして使用する
<a name="CHAP_Task.CDC.StartPoint.Checkpoint"></a>

 継続的なレプリケーションタスクは変更を移行し、 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`

### コミット時間ポイントまたはサーバー時間ポイントでのタスクの停止
<a name="CHAP_Task.CDC.StopPoint"></a>

 CDC ネイティブ開始ポイントの導入により、 AWS DMS は次の時点でタスクを停止することもできます。
+ ソースのコミット時間
+ レプリケーションインスタンスのサーバー時間

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

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

### ターゲットの再ロードによるタスクの開始
<a name="CHAP_Task.CDC.Start.Task"></a>

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

 再ロードオプションでタスク開始を使用するには、次の条件を適用する必要があります。
+  タスクを停止する必要があります。
+  タスクの移行メソッドは、全ロードまたは CDC による全ロードであることが必要です。

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

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

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

## 双方向レプリケーションの実行
<a name="CHAP_Task.CDC.Bidirectional"></a>

 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 互換エディション

### 双方向レプリケーションタスクの作成
<a name="CHAP_Task.CDC.Bidirectional.Tasks"></a>

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

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

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

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

1. データベース A から B にデータを移動するには全ロードおよび CDC タスクを使用します。この間、アプリケーションによりデータベース B のデータが変更されないようにしてください。

1. 全ロードが完了した後、アプリケーションがデータベース B のデータを変更できるようになる前に、データベー ス B の時刻または CDC 開始位置をメモします。手順については、「[CDC 開始ポイントからのレプリケーションの実行](#CHAP_Task.CDC.StartPoint)」をご参照ください。

1. この開始時刻または CDC 開始位置を使用して、データベース B から A にデータを移動する CDC 専用タスクを作成します。

**注記**  
全ロードと CDC にできる双方向ペアのタスクは 1 つだけです。

### ループバックの防止
<a name="CHAP_Task.CDC.Bidirectional.Loopback"></a>

ループバックの防止を表示するには、タスク 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`で を設定します。

### 双方向レプリケーションの制限
<a name="CHAP_Task.CDC.Bidirectional.Limitations"></a>

の双方向レプリケーション AWS DMS には、次の制限があります。
+ ループバック防止は、データ操作言語 (DML) ステートメントのみを追跡します。 AWS DMS は、データ定義言語 (DDL) ループバックの防止をサポートしていません。これを行うには、双方向ペアのいずれかのタスクを、DDL ステートメントが除外されるように設定します。
+ ループバック防止を使用するタスクは、一括変更のコミットをサポートしていません。ループバック防止を使用してタスクを設定するには、`BatchApplyEnabled` を `false` に設定します。
+ DMS 双方向レプリケーションには、競合の検出や解決は含まれていません。データの不整合を検出するには、両方のタスクでデータ検証を使用します。
+ SQL Server ソースエンドポイントで双方向レプリケーションを設定するには、`setUpMsCdcForTables` を `true` に設定する必要があります。