}
```
次のサンプルは、条件式に使用されるセクションを主に示しています。
![\[の使用を開始する AWS DMS\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### オブジェクトマッピングで属性マッピングを使用する
属性マッピングでは、ターゲット上のデータを再編成するために、ソース列名を使用してテンプレート文字列を指定することができます。ユーザーがテンプレートで指定する場合を除き、書式設定は行われません。
次の例は、ソースデータベースの構造と、DynamoDB ターゲットの必要とされる構造を示します。最初に示すのは、ソースの構造で、この場合は Oracle データベースです。次に DynamoDB 内のデータの必要とされる構造を示します。この例では最後に、必要なターゲット構造を作成するのに使用される JSON を示します。
Oracle データの構造は次のとおりです。
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| プライマリキー | 該当なし | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
DynamoDB データの構造は次のとおりです。
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| パーティションキー | ソートキー | 該当なし |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
次の JSON は、DynamoDB 構造を達成するために使用されるオブジェクトマッピングと列マッピングを示します。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "{\"Name\":\"${FirstName}\",\"Home\":{\"Address\":\"${HomeAddress}\",\"Phone\":\"${HomePhone}\"}, \"Work\":{\"Address\":\"${WorkAddress}\",\"Phone\":\"${WorkPhone}\"}}"
}
]
}
}
]
}
```
列マッピングを使用するもう 1 つの方法は、ドキュメントタイプとして DynamoDB 形式を使用することです。次のコード例では、`attribute-sub-type` として *dynamodb map* を属性マッピングに使用します。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-map",
"value": {
"M": {
"Name": {
"S": "${FirstName}"
},
"Home": {
"M": {
"Address": {
"S": "${HomeAddress}"
},
"Phone": {
"S": "${HomePhone}"
}
}
},
"Work": {
"M": {
"Address": {
"S": "${WorkAddress}"
},
"Phone": {
"S": "${WorkPhone}"
}
}
}
}
}
}
]
}
}
]
}
```
次の例のように、`dynamodb-map` の代わりに `dynamodb-list` を属性マッピングの属性サブタイプとして使用することもできます。
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### 例1: オブジェクトマッピングで属性マッピングを使用する
次の例は、2 つの MySQL データベーステーブル *nfl\$1data* と *sport\$1team* のデータを、*NFLTeams* と *SportTeams* という 2 つの DynamoDB テーブルへ移行します。テーブルの構造、および MySQL データベーステーブルから DynamoDB テーブルへデータをマップするために使用される JSON は、次のとおりです。
MySQL データベース *nfl\$1data* の構造は次のとおりです。
```
mysql> desc nfl_data;
+---------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| Position | varchar(5) | YES | | NULL | |
| player_number | smallint(6) | YES | | NULL | |
| Name | varchar(40) | YES | | NULL | |
| status | varchar(10) | YES | | NULL | |
| stat1 | varchar(10) | YES | | NULL | |
| stat1_val | varchar(10) | YES | | NULL | |
| stat2 | varchar(10) | YES | | NULL | |
| stat2_val | varchar(10) | YES | | NULL | |
| stat3 | varchar(10) | YES | | NULL | |
| stat3_val | varchar(10) | YES | | NULL | |
| stat4 | varchar(10) | YES | | NULL | |
| stat4_val | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
+---------------+-------------+------+-----+---------+-------+
```
MySQL データベーステーブル*sport\$1team* の構造は次のとおりです。
```
mysql> desc sport_team;
+---------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| name | varchar(30) | NO | | NULL | |
| abbreviated_name | varchar(10) | YES | | NULL | |
| home_field_id | smallint(6) | YES | MUL | NULL | |
| sport_type_name | varchar(15) | NO | MUL | NULL | |
| sport_league_short_name | varchar(10) | NO | | NULL | |
| sport_division_short_name | varchar(10) | YES | | NULL | |
```
2 つのテーブルを 2 つの DynamoDB テーブルにマッピングするために使用されるテーブルマッピングルールは次のとおりです。
```
{
"rules":[
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "nfl_data"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "sport_team"
},
"rule-action": "include"
},
{
"rule-type":"object-mapping",
"rule-id":"3",
"rule-name":"MapNFLData",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"nfl_data"
},
"target-table-name":"NFLTeams",
"mapping-parameters":{
"partition-key-name":"Team",
"sort-key-name":"PlayerName",
"exclude-columns": [
"player_number", "team", "name"
],
"attribute-mappings":[
{
"target-attribute-name":"Team",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${team}"
},
{
"target-attribute-name":"PlayerName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"PlayerInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${
stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}"
}
]
}
},
{
"rule-type":"object-mapping",
"rule-id":"4",
"rule-name":"MapSportTeam",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"sport_team"
},
"target-table-name":"SportTeams",
"mapping-parameters":{
"partition-key-name":"TeamName",
"exclude-columns": [
"name", "id"
],
"attribute-mappings":[
{
"target-attribute-name":"TeamName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"TeamInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}"
}
]
}
}
]
}
```
*NFLTeams* DynamoDB テーブルの出力例は次のとおりです。
```
"PlayerInfo": "{\"Number\": \"6\",\"Position\": \"P\",\"Status\": \"ACT\",\"Stats\": {\"Stat1\": \"PUNTS:73\",\"Stat2\": \"AVG:46\",\"Stat3\": \"LNG:67\",\"Stat4\": \"IN 20:31\"}",
"PlayerName": "Allen, Ryan",
"Position": "P",
"stat1": "PUNTS",
"stat1_val": "73",
"stat2": "AVG",
"stat2_val": "46",
"stat3": "LNG",
"stat3_val": "67",
"stat4": "IN 20",
"stat4_val": "31",
"status": "ACT",
"Team": "NE"
}
```
SportsTeams *DynamoDB* テーブルの出力例は次のとおりです。
```
{
"abbreviated_name": "IND",
"home_field_id": 53,
"sport_division_short_name": "AFC South",
"sport_league_short_name": "NFL",
"sport_type_name": "football",
"TeamInfo": "{\"League\": \"NFL\",\"Division\": \"AFC South\"}",
"TeamName": "Indianapolis Colts"
}
```
## DynamoDB のターゲットデータ型
の DynamoDB エンドポイントは、ほとんどの DynamoDB データ型 AWS DMS をサポートしています。次の表は、 の使用時にサポートされる Amazon AWS DMS ターゲットデータ型 AWS DMS と AWS DMS 、データ型からのデフォルトのマッピングを示しています。
AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。
が異種データベースからデータを AWS DMS 移行する場合、ソースデータベースのデータ型をデータ型と呼ばれる中間 AWS DMS データ型にマッピングします。その後、中間データ型をターゲットデータ型にマッピングします。次の表は、DynamoDB の各 AWS DMS データ型とマッピングされるデータ型を示しています。
| AWS DMS データ型 | DynamoDB データ型 |
| --- | --- |
| String | String |
| WString | String |
| ブール値 | ブール値 |
| 日付 | String |
| DateTime | String |
| INT1 | Number |
| INT2 | Number |
| INT4 | Number |
| INT8 | Number |
| 数値 | Number |
| Real4 | Number |
| Real8 | Number |
| UINT1 | Number |
| UINT2 | Number |
| UINT4 | Number |
| UINT8 | Number |
| CLOB | String |
# のターゲットとしての Amazon Kinesis Data Streams の使用 AWS Database Migration Service
を使用して AWS DMS 、Amazon Kinesis データストリームにデータを移行できます。Amazon Kinesis Data Streams サービスは、Amazon Kinesis Data Streams サービスの一部です。データレコードの大量のストリームをリアルタイムで収集し、処理するには、Kinesis データストリームを使用します。
Kinesis データストリームはシャードで構成されています。*シャード*は、ストリーム内のデータレコードの一意に識別されたシーケンスです。Amazon Kinesis Data Streams におけるシャードの詳細については、*Amazon Kinesis Data Streams デベロッパーガイド*の「[シャード](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard)」をご参照ください。
AWS Database Migration Service は、JSON を使用してレコードを Kinesis データストリームに発行します。変換時に、 AWS DMS はソースデータベースから各レコードを JSON 形式または JSON\$1UNFORMATTED メッセージ形式の属性と値のペアにシリアル化します。JSON\$1UNFORMATTED メッセージ形式は、改行区切り文字を含む単一行の JSON 文字列です。これにより、Amazon Data Firehose は Amazon S3 の宛先に Kinesis データを配信し、Amazon Athena を含むさまざまなクエリ エンジンを使用してクエリを実行できます。
サポートされている任意のデータソースから、ターゲットストリームにデータを移行するために、オブジェクトのマッピングを使用します。オブジェクトマッピングを使用して、ストリームにデータレコードを構築する方法を決定します。データをそのシャードにグループ化するために Kinesis Data Streams で使用する、各テーブルのパーティション キーも定義します。
AWS DMS は、いくつかの Kinesis Data Streams パラメータ値も設定します。テーブル作成のコストは、データの量および移行するテーブルの数によって異なります。
**注記**
AWS DMS コンソールまたは API の **SSL モード**オプションは、一部のデータストリーミングや Kinesis や DynamoDB などの NoSQL サービスには適用されません。これらはデフォルトで安全であるため、SSL モードの設定が none (**SSL Mode=None**) と等しい AWS DMS ことを示しています。SSL を使用するために、エンドポイントに追加の設定は必要ありません。例えば、Kinesis をターゲット エンドポイントとして使用する場合、デフォルトでセキュリティで保護されます。Kinesis へのすべての API コールは SSL を使用するため、 AWS DMS エンドポイントに追加の SSL オプションは必要ありません。 AWS DMS が Kinesis Data Stream への接続時にデフォルトで使用する HTTPS プロトコルを使用して、SSL エンドポイント経由で安全にデータを保存して取得できます。
**Kinesis Data Streams エンドポイント設定**
Kinesis Data Streams ターゲットエンドポイントを使用する場合、 AWS DMS API の `KinesisSettings`オプションを使用してトランザクションとコントロールの詳細を取得できます。
接続は、次のいずれかの方法で設定できます。
+ AWS DMS コンソールで、エンドポイント設定を使用します。
+ CLI では、[CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html) コマンド の`kinesis-settings` オプションを使用します。
CLI で、次の `kinesis-settings` オプションのリクエストパラメータを使用します。
**注記**
AWS DMS バージョン 3.4.1 以降では、`IncludeNullAndEmpty` エンドポイント設定に対応しています。ただし、Kinesis Data Streams ターゲットのその他のエンドポイント設定は でサポートされています AWS DMS。
+ `MessageFormat` - エンドポイントで作成されたレコードの出力形式。メッセージ形式は `JSON` (デフォルト) または `JSON_UNFORMATTED` (タブなし 1 行) です。
+ `IncludeControlDetails` - Kinesis メッセージ出力に、テーブル定義、列定義、テーブル、列の変更の詳細な制御情報を表示します。デフォルトは `false` です。
+ `IncludeNullAndEmpty` — ターゲットに NULL 列と空の列を含めます。デフォルトは `false` です。
+ `IncludePartitionValue` – パーティションタイプが `schema-table-type` でない限り、Kinesis メッセージ出力内のパーティション値を表示します。デフォルトは `false` です。
+ `IncludeTableAlterOperations` – `rename-table`、`drop-table`、`add-column`、`drop-column`、`rename-column` など、制御データのテーブルを変更するデータ定義言語 (DDL) オペレーションが含まれます。デフォルトは `false` です。
+ `IncludeTransactionDetails` - ソースデータベースからの詳細のトランザクション情報を提供します。この情報には、コミットタイムスタンプ、ログの位置、`transaction_id`、`previous_transaction_id`、および `transaction_record_id ` (トランザクション内のレコードオフセット) の値が含まれます。デフォルトは `false` です。
+ `PartitionIncludeSchemaTable` パーティションタイプが `primary-key-type` の場合、スキーマとテーブル名をパーティション値にプレフィックスします。これにより、Kinesis シャード間のデータ分散が増加します。例えば、`SysBench` スキーマに数千のテーブルがあり、各テーブルのプライマリ キーの範囲が制限されているとします。この場合、同じプライマリキーが数千のテーブルから同じシャードに送信され、スロットリングが発生します。デフォルトは `false` です。
+ `UseLargeIntegerValue` - AWS DMS バージョン 3.5.4 で利用可能な倍精度のインスタンスをキャストする代わりに、最大 18 桁の整数を使用します。デフォルトは False です。
次の例で、 AWS CLIを使用して発行された例 `create-endpoint`コマンドを使用中の `kinesis-settings` オプションを示します。
```
aws dms \
create-endpoint \
--region \
--endpoint-identifier \
--endpoint-type target \
--engine-name kinesis \
--kinesis-settings ServiceAccessRoleArn=arn:aws:iam:::role/,StreamArn=arn:aws:kinesis:::stream/,MessageFormat=json-unformatted,
IncludeControlDetails=true,IncludeTransactionDetails=true,IncludePartitionValue=true,PartitionIncludeSchemaTable=true,
IncludeTableAlterOperations=true
```
**マルチスレッド全ロードタスク設定**
転送速度を上げるために、 は Kinesis Data Streams ターゲットインスタンスへのマルチスレッド全ロード AWS DMS をサポートします。DMS では、このマルチスレッドでのタスク設定を、以下でサポートします。
+ `MaxFullLoadSubTasks` - 並列ロードするソーステーブルの最大数を指定するにはこのオプションを使用します。DMS は、専用のサブタスクを使用して、対応する Kinesis ターゲットテーブルに各テーブルをロードします。デフォルトは 8、最大値は 49 です。
+ `ParallelLoadThreads` – このオプションを使用して、 AWS DMS が各テーブルを Kinesis ターゲットテーブルにロードするために使用するスレッドの数を指定します。Kinesis Data Streams ターゲットの最大値は 32 です。この上限を増やすよう依頼できます。
+ `ParallelLoadBufferSize` – Kinesis ターゲットにデータをロードするために並列ロードスレッドが使用する、バッファ内に保存するレコードの最大数を指定するには、このオプションを使用します。デフォルト値は 50 です。最大値は 1000 です。この設定は `ParallelLoadThreads` で使用します。`ParallelLoadBufferSize` は、複数のスレッドがある場合にのみ有効です。
+ `ParallelLoadQueuesPerThread` - このオプションを使用して、各同時スレッドがキューからデータレコードを取り出し、ターゲットのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルトは 1 です。ただし、さまざまなペイロードサイズの Kinesis ターゲットの場合、有効な範囲は 1 スレッドあたり 5 ～ 512 キューです。
**マルチスレッド CDC ロードタスクの設定**
タスク設定を使用して `PutRecords` API コールの動作を変更するなど、Kinesis などのリアルタイム データストリーミング ターゲット エンドポイントの変更データキャプチャ (CDC) のパフォーマンスを向上させることができます。これを行うには、`ParallelApply*` タスク設定を使用して、同時スレッドの数、スレッドあたりのキュー数、バッファに格納するレコード数を指定します。例えば、CDC ロードを実行し、128 本のスレッドを並列に適用するとします。また、スレッドあたり 64 個のキューにアクセスして、バッファあたり 50 個のレコードを保存する必要があります。
CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Kinesis ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 で、最大値は 32 です。
+ `ParallelApplyBufferSize` – CDC ロード中に同時スレッドが Kinesis ターゲット エンドポイントにプッシュする場合に、各バッファキューに保存するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` – 各スレッドがキューからデータレコードを取り出し、CDC 中に Kinesis エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルト値は 1、最大値は 512 です。
`ParallelApply*` タスク設定を使用する場合、`partition-key-type` のデフォルトは `schema-name.table-name` ではなくテーブルの `primary-key` です。
## 前イメージを使用した Kinesis データストリームの CDC 行の元の値のターゲットとしての表示
Kinesis のようなデータストリーミングターゲットに CDC 更新を書き込む場合、更新によって変更される前に、ソースデータベースの行の元の値を表示できます。これを可能にするために、 はソースデータベースエンジンによって提供されたデータに基づいて、更新イベントの*前のイメージ* AWS DMS を入力します。
ソースデータベースエンジンによって、前イメージに対してさまざまな量の情報が提供されます。
+ Oracle では、列が変更された場合にのみ列の更新が提供されます。
+ PostgreSQL は、プライマリキーの一部である列のデータ (変更されたかどうか) のみを提供します。すべての列に (変更の有無を問わず) データを提供するには、`REPLICA_IDENTITY` を `DEFAULT`でなく `FULL` に設定する必要があります。各テーブルを `REPLICA_IDENTITY` に設定する際は、慎重に行うべきであることに注意します。`REPLICA_IDENTITY` を `FULL` に設定すると、すべての列値がログ先行書き込み (WAL) に継続的に書き込まれます。これにより、頻繁に更新されるテーブルではパフォーマンスやリソースの問題が発生する可能性があります。
+ MySQL は通常、BLOB および CLOB データ型を除くすべての列のデータを (変更の有無を問わず) 提供します。
前イメージを有効にして、ソースデータベースから元の値を AWS DMS 出力に追加するには、`BeforeImageSettings` タスク設定または `add-before-image-columns` パラメータを使用します。このパラメータは、列変換ルールを適用します。
`BeforeImageSettings` は、次に示すように、ソースデータベースシステムから収集された値を使用して、すべての更新オペレーションに新しい JSON 属性を追加します。
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**注記**
全ロードと CDC `BeforeImageSettings` AWS DMS タスク (既存のデータを移行して進行中の変更をレプリケートする) などの CDC コンポーネントを含むタスク、または CDC のみのタスク (データ変更のみをレプリケートする) にのみ適用されます。全ロードのタスクには `BeforeImageSettings` を適用しないでください。
`BeforeImageSettings` オプションには、次の項目が適用されます。
+ `EnableBeforeImage` オプションを `true` に設定して、前イメージを有効にします。デフォルトは `false` です。
+ `FieldName` オプションを使用して、新しい JSON 属性に名前を割り当てます。`EnableBeforeImage` が `true` の場合、`FieldName` は必須であり、空にすることはできません。
+ `ColumnFilter` オプションは、前イメージを使用して追加する列を指定します。テーブルのプライマリキーの一部である列だけを追加するには、デフォルト値 `pk-only` を使用します。前イメージ値を持つ列を追加するには、`all` を使用します。変更前イメージには、CLOB や BLOB などの LOB データ型の列が含まれていないことに注意します。
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**注記**
Amazon S3 ターゲットは `BeforeImageSettings` をサポートしていません。S3 ターゲットの場合、CDC 中に前イメージを実行するには `add-before-image-columns` 変換ルールのみを使用します。
### 前イメージ変換ルールの使用
タスク設定の代わりに、列変換ルールを適用する `add-before-image-columns` パラメータを使用できます。このパラメータを使用すると、Kinesis のようなデータストリーミングターゲットで CDC 中に前イメージを有効にできます。
変換ルールで `add-before-image-columns` を使用すると、前イメージの結果のよりきめ細かい制御を適用することができます。変換ルールを使用すると、オブジェクトロケーターを使用し、ルールに選択したテーブルを制御できます。また、変換ルールを連結することもできます。これにより、テーブルごとに異なるルールを適用できます。その後、他のルールを使用して生成された列を操作できます。
**注記**
同じタスク内で、`add-before-image-columns` パラメータと同時に `BeforeImageSettings` タスク設定を使用しないでください。代わりに、1 つのタスクにこのパラメータとこの設定のいずれかを使用し、両方を使用しないでください。
列の `add-before-image-columns` パラメータを持つ `transformation` ルールタイプは、`before-image-def` セクションを提供する必要があります。例を以下に示します。
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
`column-prefix` の値は列名の前に付加され、`column-prefix` のデフォルト値は `BI_` です。`column-suffix` の値は列名に追加され、デフォルトは空です。`column-prefix` と `column-suffix` の両方を空の文字列に設定しないでください。
`column-filter` の値を 1 つ選択します。テーブルのプライマリキーの一部である列だけを追加するには、`pk-only` を選択します。LOB タイプではない列のみを追加するように `non-lob` を選択します。または、前イメージの値を持つ任意の列を追加するように `all` を選択します。
### 前イメージ変換前ルールの例
次の例の変換ルールは、ターゲットに `BI_emp_no` という新しい列を追加します。したがって、`UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` のようなステートメントは、`BI_emp_no` フィールドに 1 を設定します。CDC 更新を Amazon S3 ターゲットに書き込むと、更新された元の行は `BI_emp_no` 列からわかります。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
`add-before-image-columns` ルールアクションの使用方法については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」をご参照ください。
## のターゲットとして Kinesis データストリームを使用するための前提条件 AWS Database Migration Service
### のターゲットとして Kinesis データストリームを使用するための IAM ロール AWS Database Migration Service
Kinesis データストリームを のターゲットとして設定する前に AWS DMS、必ず IAM ロールを作成してください。このロールでは AWS DMS 、移行先の Kinesis データストリームへのアクセスを が引き受けて許可する必要があります。アクセス許可の最小設定は、次の IAM ポリシーで示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Kinesis データストリームに移行する際に使用するロールには、次のアクセス許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### のターゲットとしての Kinesis データストリームへのアクセス AWS Database Migration Service
AWS DMS バージョン 3.4.7 以降では、Kinesis エンドポイントに接続するには、次のいずれかを実行する必要があります。
+ VPC エンドポイントを使用するように DMS を設定します。VPC エンドポイントを使用するように DMS を設定する方法については、「[の VPC エンドポイントの設定 AWS DMS](CHAP_VPC_Endpoints.md)」を参照してください。
+ パブリックルートを使用するように DMS を設定します。つまり、レプリケーションインスタンスをパブリックにします。パブリックレプリケーションインスタンスの詳細については、「[パブリックおよびプライベートレプリケーション インスタンス](CHAP_ReplicationInstance.PublicPrivate.md)」を参照してください。
## のターゲットとして Kinesis Data Streams を使用する場合の制限 AWS Database Migration Service
ターゲットとして Kinesis Data Streams を使用する場合、以下の制限が適用されます。
+ AWS DMS は、トランザクションに関係なく、各更新を特定の Kinesis データストリーム内の 1 つのデータレコードとしてソースデータベース内の 1 つのレコードに発行します。ただし、`KinesisSettings` API の関連パラメータを使用して、各データレコードのトランザクションの詳細を含めることができます。
+ 完全 LOB モードはサポートされていません。
+ サポートされる最大 LOB サイズは 1 MB です。
+ Kinesis Data Streamsは、重複排除をサポートしていません。ストリームからデータを消費するアプリケーションは、重複したレコードを処理する必要があります。詳細については、*Amazon Kinesis Data Streams デベロッパーガイド*の「[重複レコードの処理](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)」をご参照ください。
+ AWS DMS では、パーティションキーに次の 4 つのフォームがサポートされています。
+ `SchemaName.TableName`: スキーマとテーブル名の組み合わせ。
+ `${AttributeName}`: JSON のいずれかのフィールドの値、またはソースデータベースのテーブルのプライマリキー。
+ `transaction-id`: CDC トランザクション ID。同じトランザクション内のすべてのレコードは、同じパーティションに移動します。
+ `constant`: テーブルやデータに関係なく、すべてのレコードの固定リテラル値。すべてのレコードは同じパーティションキー値「定数」に送信され、すべてのテーブルで厳密なグローバル順序が提供されます。
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "PartitionKeyTypeExample",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ Kinesis Data Streams 内の保管中のデータの暗号化の詳細については、*AWS Key Management Service デベロッパーガイド*の「[Kinesis Data Streams でのデータ保護](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html)」をご参照ください。
+ `IncludeTransactionDetails` エンドポイント設定は、ソースエンドポイントが Oracle、SQL Server、PostgreSQL、または MySQL の場合にのみサポートされます。他のソースエンドポイントタイプでは、トランザクションの詳細は含まれません。
+ `BatchApply`は Kinesis エンドポイントではサポートされていません。Kinesis ターゲットにバッチ 適用を使用 (例えば、`BatchApplyEnabled` ターゲットメタデータタスク設定) すると、タスク失敗やデータ損失が発生する可能性があります。Kinesisをターゲットエンドポイントとして使用する場合、`BatchApply` を有効にしないでください。
+ Kinesis ターゲットは、レプリケーションインスタンスと同じ AWS AWS リージョン アカウントの Kinesis データストリームでのみサポートされます。
+ MySQL ソースから移行する場合、BeforeImage データには CLOB データ型と BLOB データ型は含まれません。詳細については、「[前イメージを使用した Kinesis データストリームの CDC 行の元の値のターゲットとしての表示](#CHAP_Target.Kinesis.BeforeImage)」を参照してください。
+ AWS DMS は、16 桁を超える`BigInt`データ型の値の移行をサポートしていません。この制限を回避するには、次の変換ルールを使用して `BigInt` 列を文字列に変換できます。変換ルールの詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照してください。
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ 1 つのトランザクション内の複数の DML オペレーションが、ソースデータベースのラージオブジェクト (LOB) 列を変更すると、ターゲットデータベースは、対象トランザクションの最後のオペレーションにおける最終的な LOB 値のみを保持します。同じトランザクションの以前のオペレーションで設定された中間 LOB 値は上書きされるため、データの損失や不整合が発生する可能性があります。この動作は、レプリケーション中の LOB データの処理方法が原因で発生します。
+ AWS DMS Kinesis をターゲットエンドポイントとして使用する場合、 は埋め込み`'\0'`文字を含むソースデータをサポートしていません。埋め込み`'\0'`文字を含むデータは、最初の`'\0'`文字で切り捨てられます。
## Kinesis データストリームにデータを移行するためのオブジェクトマッピングの使用
AWS DMS はテーブルマッピングルールを使用して、ソースからターゲット Kinesis データストリームにデータをマッピングします。ターゲットストリームにデータをマッピングするために、オブジェクトマッピングと呼ばれるテーブルマッピングルールのタイプを使用します。オブジェクトマッピングを使用して、ソースのデータレコードがどのように Kinesis データストリームに発行されたデータレコードにマッピングされるかを定義します。
Kinesis データストリームには、パーティション キー以外にプリセット構造はありません。オブジェクトマッピングルールでは、データレコードの `partition-key-type` に指定できる値は、`schema-table`、`transaction-id`、`primary-key`、`constant`、`attribute-name` です。
オブジェクトマッピングルールを作成するには、`object-mapping` として `rule-type` を指定します。このルールが、使用したいオブジェクトマッピングのタイプを指定します。
ルールの構造は次のとおりです。
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS は現在、 `rule-action`パラメータの唯一の有効な値`map-record-to-document`として `map-record-to-record`と をサポートしています。これらの設定は、`exclude-columns` 属性リストの一部として除外されない値に影響します。`map-record-to-record` および `map-record-to-document`値は、デフォルトで がこれらのレコード AWS DMS を処理する方法を指定します。これらの値は、どのような方法でも属性マッピングに影響しません。
リレーショナルデータベースから Kinesis データストリームに移行する際に `map-record-to-record` を使用します。このルールタイプでは、Kinesis データストリームのパーティション キーとしてリレーショナルデータベースから `taskResourceId.schemaName.tableName` 値を使用し、ソースデータベース内の各列の属性を作成します。
`map-record-to-record` を使用する場合は、次の点に注意します。
+ この設定は、`exclude-columns` リストで除外されている列にのみ影響します。
+ このような列ごとに、 はターゲットトピックで対応する属性 AWS DMS を作成します。
+ AWS DMS は、ソース列が属性マッピングで使用されているかどうかに関係なく、この対応する属性を作成します。
`map-record-to-document` を使用して、属性名「\$1doc」を使用しソース列を適切なターゲットストリーム内の単一のフラットドキュメントに配置します。 AWS DMS 说「`_doc`」という名前のソースで 1 つのフラットマップにデータを配置します。この配置は、`exclude-columns` 属性リストに含まれていないソーステーブル内のすべての列に適用されます。
`map-record-to-record` を理解するための 1 つの方法は、実際の動作を確認することです。この例では、次の構造とデータを含むリレーショナルデータベースのテーブルの行から始めると想定してください。
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
この情報を `Test` という名前のスキーマから Kinesis データストリームに移行するには、データをターゲットストリームにマッピングするルールを作成します。以下のルールはマッピングを示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
次は、Kinesis データストリームの結果のレコード形式を示しています：
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaName.tableName
+ データ: //次の JSON メッセージ
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
ただし、同じルールを使用しますが、`rule-action` パラメータを `map-record-to-document` に変更して特定の列を除外します。以下のルールはマッピングを示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"exclude-columns": [
"homeaddress",
"homephone",
"workaddress",
"workphone"
]
}
}
]
}
```
この場合、`exclude-columns` パラメータ、`FirstName`、`LastName`、`StoreId`、`DateOfBirth` は `_doc` にマッピングされます。次は、この結果のレコード形式を示しています。
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### 属性マッピングを使用したデータの再構築
属性マップを使用してデータを Kinesis データストリームに移行している間にデータを再構築できます。例えば、ソース内の複数のフィールドを結合してターゲット内に 1 つのフィールドを構成することもできます。以下の属性マップはデータを再構築する方法を示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
の定数値を設定するには`partition-key`、 を指定します。これにより`"partition-key-type: "constant"`、パーティション値が に設定されます`constant`。たとえば、すべてのデータを 1 つのシャードに強制的に格納するためにこれを行うことができます。以下のマッピングはこの方法を示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"target-attribute-name": "DateOfBirth",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**注記**
特定のテーブル用のコントロールレコードの `partition-key` 値は、`TaskId.SchemaName.TableName` です。特定のタスク用のコントロールレコードの `partition-key` 値は、そのレコードの `TaskId` です。オブジェクトマッピングの `partition-key` 値を指定することは、コントロールレコードの `partition-key` には影響しません。
テーブルマッピングルール`attribute-name`で `partition-key-type`が に設定されている場合、 を指定する必要があります。これは`partition-key-name`、ソーステーブルの列またはマッピングで定義されたカスタム列を参照する必要があります。さらに、ソース列がターゲット Kinesis Stream にどのようにマッピングされるかを定義するには、 を指定`attribute-mappings`する必要があります。
### Kinesis Data Streams のメッセージ形式
JSON 出力は、単にキーと値のペアのリストです。JSON\$1UNFORMATTED メッセージ形式は、改行区切り文字を含む単一行の JSON 文字列です。
AWS DMS には、Kinesis Data Streams からのデータを簡単に消費できるように、次の予約済みフィールドが用意されています。
**RecordType**
レコードタイプはデータまたはコントロールのいずれかです。*データレコード*は、ソースの実際の行を表します。*コントロールレコード*は、タスクの再起動など、ストリーム内の重要なイベント用です。
**運用**
データレコードの場合、オペレーションは `load`、`insert`、`update`、または `delete` です。
コントロールレコードの場合、オペレーションは `create-table`、`rename-table`、`drop-table`、`change-columns`、`add-column`、`drop-column`、`rename-column`、`column-type-change` です。
**SchemaName**
レコードのソーススキーマ。コントロールレコードの場合、このフィールドは空です。
**TableName**
レコードのソーステーブル。コントロールレコードの場合、このフィールドは空です。
**タイムスタンプ**
JSON メッセージが構築された時刻のタイムスタンプ。このフィールドは ISO 8601 形式でフォーマットされます。
# のターゲットとしての Apache Kafka の使用 AWS Database Migration Service
を使用して AWS DMS 、Apache Kafka クラスターにデータを移行できます。Apache Kafka は分散ストリーミング プラットフォームです。Apache Kafka を使用すると、ストリーミング データをリアルタイムで取り込み、処理できます。
AWS は、 AWS DMS ターゲットとして使用する Amazon Managed Streaming for Apache Kafka (Amazon MSK) も提供します。Amazon MSK は、Apache Kafka インスタンスの実装と管理を簡素化する、フルマネージド型 Apache Kafka ストリーミング サービスです。オープンソースの Apache Kafka バージョンで動作し、Apache Kafka インスタンスとまったく同じ AWS DMS ターゲットとして Amazon MSK インスタンスにアクセスします。詳細については、*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*の「[Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html)」をご参照ください。
Kafka クラスターは、パーティションに分割されたトピックと呼ばれるカテゴリにレコードのストリームを保存します。*パーティション*は、トピック内のデータレコード (メッセージ) の一意に識別されたシーケンスです。パーティションは、トピックレコードの並列処理を可能にするために、クラスター内の複数のブローカーに分散することができます。トピックとパーティション、および Apache Kafka での分散の詳細については、「[トピックとログ](https://kafka.apache.org/documentation/#intro_topics)」と「[分散](https://kafka.apache.org/documentation/#intro_distribution)」をご参照ください。
Kafka クラスターは、Amazon MSK インスタンス、Amazon EC2 インスタンス上で実行されるクラスター、またはオンプレミスのクラスターのいずれかです。Amazon MSK インスタンスまたは Amazon EC2 インスタンス上のクラスターは、同じ VPC 内にも、別の VPC 内にも配置できます。クラスターがオンプレミスの場合は、レプリケーションインスタンスに独自のオンプレミスのネーム サーバーを使用して、クラスターのホスト名を解決できます。レプリケーションインスタンスのネームサーバーのセットアップについては、「[独自のオンプレミスネームサーバーの使用](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver)」を参照してください。ネットワークの設定の詳細については、「[レプリケーション インスタンスのためのネットワークのセットアップ](CHAP_ReplicationInstance.VPC.md)」を参照してください。
Amazon MSK クラスターを使用する場合、セキュリティグループがレプリケーションインスタンスからのアクセスを許可していることを確認します。Amazon MSK クラスターのセキュリティグループの変更については、「[Amazon MSK クラスターのセキュリティグループの変更](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html)」を参照してください。
AWS Database Migration Service は、JSON を使用して Kafka トピックにレコードを発行します。変換時、 AWS DMS はソースデータベースからの各レコードを JSON フォーマットの属性と値のペアにシリアル化します。
サポートされている任意のデータソースから、ターゲット Kafka クラスターにデータを移行するために、オブジェクトのマッピングを使用します。オブジェクトマッピングを使用して、ターゲットトピックにデータ レコードを構築する方法を決定します。データをそのパーティションにグループ化するために Apache Kafka で使用する、各テーブルのパーティションキーも定義します。
現在、 はタスクごとに 1 つのトピック AWS DMS をサポートしています。単一のタスクに複数のテーブルがある場合、すべてのメッセージが単一のトピックに送信されます。各メッセージには、ターゲットスキーマと table. AWS DMS versions 3.4.6 以降を識別するメタデータセクションが含まれており、オブジェクトマッピングを使用したマルチトピックレプリケーションをサポートしています。詳細については、「[オブジェクトマッピングを使用したマルチトピックレプリケーション](#CHAP_Target.Kafka.MultiTopic)」を参照してください。
**Apache Kafka のエンドポイント設定**
AWS DMS コンソールのエンドポイント設定、または CLI の `--kafka-settings`オプションを使用して、接続の詳細を指定できます。各設定の要件は次のとおりです。
+ `Broker` — Kafka クラスター内の 1 つ以上のブローカーの場所を、`broker-hostname:port` のカンマ区切りリストの形式で指定します。例: `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`。この設定では、クラスター内の任意またはすべてのブローカーのロケーションを指定できます。クラスターブローカーはすべて、トピックに移行されたデータレコードのパーティション化を処理するために通信します。
+ `Topic` - (オプション) 最大 255 文字および記号のトピック名を指定します。ピリオド (.)、アンダースコア (\$1)、マイナス (-) を使用できます。ピリオド (.) またはアンダースコア (\$1) があるトピック名は、内部データ構造内で衝突する可能性があります。トピック名には、どちらか一方を使用し、両方とも使用することは避けてください。トピック名を指定しない場合、 AWS DMS を移行トピック`"kafka-default-topic"`として使用します。
**注記**
で指定した移行トピックまたはデフォルトのトピック AWS DMS を作成するには、Kafka クラスター設定`auto.create.topics.enable = true`の一部として を設定します。詳細については、[のターゲットとして Apache Kafka を使用する場合の制限 AWS Database Migration Service](#CHAP_Target.Kafka.Limitations)を参照してください。
+ `MessageFormat` - エンドポイントで作成されたレコードの出力形式。メッセージ形式は `JSON` (デフォルト) または `JSON_UNFORMATTED` (タブなし 1 行) です。
+ `MessageMaxBytes` — エンドポイントで作成されたレコードの最大サイズ (バイト単位)。デフォルトは 1,000,000 です。
**注記**
CLI/SDK AWS のみを使用して、デフォルト以外の値`MessageMaxBytes`に変更できます。例えば、既存の Kafka エンドポイントを変更して `MessageMaxBytes` を変更するには、以下のコマンドを使用します。
```
aws dms modify-endpoint --endpoint-arn your-endpoint
--kafka-settings Broker="broker1-server:broker1-port,broker2-server:broker2-port,...",
Topic=topic-name,MessageMaxBytes=integer-of-max-message-size-in-bytes
```
+ `IncludeTransactionDetails` - ソースデータベースからの詳細のトランザクション情報を提供します。この情報には、コミットタイムスタンプ、ログの位置、`transaction_id`、`previous_transaction_id`、および `transaction_record_id` (トランザクション内のレコードオフセット) の値が含まれます。デフォルトは `false` です。
+ `IncludePartitionValue` パーティションタイプが でない限り、Kafka メッセージ出力内のパーティション値を表示します。`schema-table-type`デフォルトは `false` です。
+ `PartitionIncludeSchemaTable` パーティションタイプが `primary-key-type` の場合、スキーマとテーブル名をパーティション値にプレフィックスします。これにより、Kafka パーティション間のデータ分散が増加します。例えば、`SysBench` スキーマに数千のテーブルがあり、各テーブルのプライマリ キーの範囲が制限されているとします。この場合、同じプライマリキーが数千のテーブルから同じパーティションに送信され、スロットリングが発生します。デフォルトは `false` です。
+ `IncludeTableAlterOperations` – `rename-table`、`drop-table`、`add-column`、`drop-column`、`rename-column` など、制御データのテーブルを変更するデータ定義言語 (DDL) オペレーションが含まれます。デフォルトは `false` です。
+ `IncludeControlDetails` - Kafka メッセージ出力に、テーブル定義、列定義、テーブルおよび列の変更の詳細な制御情報を表示します。デフォルトは `false` です。
+ `IncludeNullAndEmpty` — ターゲットに NULL 列と空の列を含めます。デフォルトは `false` です。
+ `SecurityProtocol` — Transport Layer Security (TLS) を使用して Kafka ターゲット エンドポイントへの安全な接続を設定します。オプションには `ssl-authentication`、`ssl-encryption`、および `sasl-ssl` があります。`sasl-ssl` を使用して `SaslUsername` と `SaslPassword` を要求します。
+ `SslEndpointIdentificationAlgorithm` - 証明書のホスト名検証を設定します。この設定は、 AWS DMS バージョン 3.5.1 以降でサポートされています。オプションは以下のとおりです。
+ `NONE`: クライアント接続でブローカーのホスト名検証を無効にします。
+ `HTTPS`: クライアント接続でブローカーのホスト名検証を有効にします。
+ `useLargeIntegerValue` - AWS DMS バージョン 3.5.4 で利用可能な倍精度で入力をキャストする代わりに、最大 18 桁の整数を使用します。デフォルトは False です。
設定を使用すると、転送速度を上げることができます。これを行うために、 AWS DMS は Apache Kafka ターゲット クラスターへのマルチスレッド全ロードをサポートしています。 AWS DMS は、次のようなタスク設定を使用して、このマルチスレッドをサポートします：
+ `MaxFullLoadSubTasks` – このオプションを使用して、並列でロードするソーステーブルの最大数を指定します。 は、専用サブタスクを使用して、各テーブルを対応する Kafka ターゲットテーブルに AWS DMS ロードします。デフォルトは 8、最大値は 49 です。
+ `ParallelLoadThreads` – このオプションを使用して、 AWS DMS が各テーブルを Kafka ターゲットテーブルにロードするために使用するスレッドの数を指定します。Apache Kafka ターゲットの最大値は 32 です。この上限を増やすよう依頼できます。
+ `ParallelLoadBufferSize` - Kafka ターゲットにデータをロードするために並列ロードスレッドが使用する、バッファ内に保存するレコードの最大数を指定するには、このオプションを使用します。デフォルト値は 50 です。最大値は 1000 です。この設定は `ParallelLoadThreads` で使用します。`ParallelLoadBufferSize` は、複数のスレッドがある場合にのみ有効です。
+ `ParallelLoadQueuesPerThread` - このオプションを使用して、各同時スレッドがキューからデータレコードを取り出し、ターゲットのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルトは 1 です。最大数は 512。
Kafka エンドポイントの変更データキャプチャ (CDC) のパフォーマンスを向上するには、並列スレッドと一括オペレーションのタスク設定を調整します。これを行うには、`ParallelApply*` タスク設定を使用して、同時スレッドの数、スレッドあたりのキュー数、バッファに格納するレコード数を指定します。例えば、CDC ロードを実行し、128 本のスレッドを並列に適用するとします。また、スレッドあたり 64 個のキューにアクセスして、バッファあたり 50 個のレコードを保存する必要があります。
CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Kafka ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 で、最大値は 32 です。
+ `ParallelApplyBufferSize` - CDC ロード中に同時スレッドが Kafka ターゲット エンドポイントにプッシュする場合に、各バッファキューに保存するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` - 各スレッドがキューからデータレコードを取り出し、CDC 中に Kafka エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルトは 1 です。最大数は 512。
`ParallelApply*` タスク設定を使用する場合、`partition-key-type` のデフォルトは `schema-name.table-name` ではなくテーブルの `primary-key` です。
## Transport Layer Security (TLS) を使用した Kafka への接続
このクラスターは Transport Layer Security (TLS) を使用した安全な接続のみを受け入れます。DMS では、次の 3 つのセキュリティプロトコルオプションのいずれかを使用して、Kafka エンドポイント接続をセキュリティで保護できます。
**SSL 暗号化 (`server-encryption`)**
クライアントは、サーバーの証明書を使用してサーバー ID を検証します。次に、サーバーとクライアント間で暗号化された接続が確立されます。
**SSL 認証 (`mutual-authentication`)**
サーバーとクライアントは、独自の証明書を使用して ID を相互に検証します。次に、サーバーとクライアント間で暗号化された接続が確立されます。
**SASL-SSL (`mutual-authentication`)**
簡易認証およびセキュリティ レイヤー (SASL) メソッドは、クライアントの証明書をユーザー名とパスワードに置き換えて、クライアント ID を検証します。具体的には、サーバーがクライアントの ID を検証できるように、サーバーが登録したユーザー名とパスワードを指定します。次に、サーバーとクライアント間で暗号化された接続が確立されます。
**重要**
Apache Kafka と Amazon MSK は解決済みの証明書を受け入れます。これは、Kafka と Amazon MSK が対処すべき既知の制限です。詳細については、「[Apache Kafka の問題、KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700)」をご参照ください。
Amazon MSK を使用している場合は、この既知の制限の回避策としてアクセスコントロールリスト (ACL) を使用することを検討してください。ACL の使用の詳細については、*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*の [Apache Kafka ACL](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) セクションをご参照ください。
自己管理 Kafka クラスターを使用している場合クラスターの設定の詳細については、「[2018/10/21日付のコメント](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376)」をご参照ください。
### Amazon MSK または自己管理 Kafka クラスターでの SSL 暗号化の使用
SSL 暗号化を使用して、Amazon MSK または自己管理 Kafka クラスターへのエンドポイント接続をセキュリティで保護できます。SSL 暗号化認証方法を使用する場合、クライアントはサーバーの証明書を使用してサーバーの ID を検証します。次に、サーバーとクライアント間で暗号化された接続が確立されます。
**SSL 暗号化を使用して Amazon MSK に接続するには**
+ ターゲットの Kafka エンドポイントを作成するとき、`ssl-encryption` オプションを使うセキュリティ プロトコル エンドポイントの設定 (`SecurityProtocol`) を行います。
次の JSON 例では、セキュリティプロトコルを SSL 暗号化として設定しています。
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**自己管理 Kafka クラスターに SSL 暗号化を使用するには**
1. オンプレミス Kafka クラスターでPrivate Certificate Authority (CA) を使用している場合は、プライベート CA 証明書をアップロードして Amazon リソースネーム (ARN) を取得します。
1. ターゲットの Kafka エンドポイントを作成するとき、`ssl-encryption` オプションを使うセキュリティ プロトコル エンドポイントの設定 (`SecurityProtocol`) を行います。次の JSON の例では、セキュリティプロトコルを `ssl-encryption` として設定します。
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. プライベート CA を使用している場合は、上記の最初のステップで取得した ARN に `SslCaCertificateArn` を設定します。
### SSL 認証の使用
SSL 認証を使用して、Amazon MSK または自己管理 Kafka クラスターへのエンドポイント接続をセキュリティで保護できます。
SSL 認証を使用したクライアント認証と暗号化を有効にして Amazon MSK に接続するには、次の手順を実行します：
+ Kafka の秘密キーと公開証明書を準備します。
+ 証明書を DMS Certificate Manager にアップロードします。
+ Kafka エンドポイント設定で指定された、対応する証明書 ARN を使用して Kafka ターゲットエンドポイントを作成します。
**Amazon MSK の秘密キーと公開証明書を準備するには**
1. EC2 インスタンスを作成し、*Amazon Managed Streaming for Apache Kafka 開発者ガイド*の[クライアント認証](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html)セクションにあるステップ 1 ～ 9 の説明に従って、認証を使用するようにクライアントをセットアップします。
これらの手順を完了したら、Certificate-ARN（ACM に保存された公開証明書 ARN）と、 `kafka.client.keystore.jks` ファイル内のプライベートキーができます。
1. 公開証明書を取得し、次のコマンドを使用し証明書を `signed-certificate-from-acm.pem` ファイルにコピーします：
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
コマンドは以下のような情報を返します：
```
{"Certificate": "123", "CertificateChain": "456"}
```
次に、`"123"` に同等のものを `signed-certificate-from-acm.pem` ファイルにコピーします。
1. 次の例に示すように,`msk-rsa` キーを `kafka.client.keystore.jks to keystore.p12` からインポートしてプライベートキーを取得します:
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. 次のコマンドを使用して`keystore.p12` を `.pem` の形式にエクスポートします。
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
**[Enter PEM pass phrase]**(PEM パスフレーズを入力してください) メッセージが表示され、証明書の暗号化に適用されるキーを識別します。
1. バッグ属性とキー属性を `.pem` ファイルから削除し、最初の行が次の文字列でスタートしていることを確認します。
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**公開証明書とプライベートキーを DMS Certificate Managerにアップロードし、Amazon MSK への接続をテストするには**
1. 次のコマンドを使用して、DMS Certificate Managerにアップロードします。
```
aws dms import-certificate --certificate-identifier signed-cert --certificate-pem file://path to signed cert
aws dms import-certificate --certificate-identifier private-key —certificate-pem file://path to private key
```
1. Amazon MSK ターゲット エンドポイントを作成し、接続をテストして TLS 認証が機能することを確認します。
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:0000", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "arn:aws:dms:us-east-1:012346789012:cert:",
"SslClientKeyArn": "arn:aws:dms:us-east-1:0123456789012:cert:","SslClientKeyPassword":"test1234"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
**重要**
SSL 認証を使用して、自己管理 Kafka クラスターへの接続をセキュリティで保護できます。場合によっては、オンプレミス Kafka クラスターでPrivate Certificate Authority (CA) を使用することがあります。その場合は、CA チェーンおよび公開証明書、プライベートキーを DMS Certificate Managerにアップロードします。次に、オンプレミス Kafka ターゲットエンドポイントを作成するときに、エンドポイント設定で対応する Amazon リソースネーム (ARN) を使用します。
**自己管理 Kafka クラスターのプライベートキーと署名付き証明書を準備するには**
1. 以下に示すようにキーペアを生成します。
```
keytool -genkey -keystore kafka.server.keystore.jks -validity 300 -storepass your-keystore-password
-keypass your-key-passphrase -dname "CN=your-cn-name"
-alias alias-of-key-pair -storetype pkcs12 -keyalg RSA
```
1. 証明書署名リクエスト (CSR) を取得します。
```
keytool -keystore kafka.server.keystore.jks -certreq -file server-cert-sign-request-rsa -alias on-premise-rsa -storepass your-key-store-password
-keypass your-key-password
```
1. クラスター トラストストアの CA を使用して CSR に署名します。CA がない場合は、独自のプライベート CA を作成できます。
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. `ca-cert` をサーバーのトラストストアとキーストアにインポートします。トラストストアをお持ちでない場合は、次のコマンドを使用してトラストストアを作成してこれに `ca-cert ` をインポートします。
```
keytool -keystore kafka.server.truststore.jks -alias CARoot -import -file ca-cert
keytool -keystore kafka.server.keystore.jks -alias CARoot -import -file ca-cert
```
1. 証明書に署名します。
```
openssl x509 -req -CA ca-cert -CAkey ca-key -in server-cert-sign-request-rsa -out signed-server-certificate.pem
-days validate-days -CAcreateserial -passin pass:ca-password
```
1. 署名付き証明書をキーストアにインポートします。
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. 次のコマンドを使用して、`on-premise-rsa` キーを `kafka.server.keystore.jks` から `keystore.p12` にインポートします。
```
keytool -importkeystore \
-srckeystore kafka.server.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias on-premise-rsa \
-deststorepass your-truststore-password \
-destkeypass your-key-password
```
1. 次のコマンドを使用して `keystore.p12` を `.pem` の形式にエクスポートします。
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. `encrypted-private-server-key.pem` および `signed-certificate.pem`、`ca-cert`を DMS Certificate Managerにアップロードします。
1. 返された ARN を使用してエンドポイントを作成します。
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:9092", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "your-client-cert-arn","SslClientKeyArn": "your-client-key-arn","SslClientKeyPassword":"your-client-key-password",
"SslCaCertificateArn": "your-ca-certificate-arn"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
### SASL-SSL 認証を使用して Amazon MSK に接続する
簡易認証およびセキュリティレイヤー (SASL) 方式では、ユーザー名とパスワードを使用してクライアント ID を検証し、サーバーとクライアント間で暗号化された接続を作成します。
SASL を使用するには、Amazon MSK クラスターを設定するときに、まず安全なユーザー名とパスワードを作成します。Amazon MSK クラスターの安全なユーザー名とパスワードを設定する方法については、*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*の「[Amazon MSK クラスターの SALS/SCRAM 認証の設定](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial)」をご参照ください。
次に、Kafka ターゲット エンドポイントを作成するときに、`sasl-ssl` オプションを使ってセキュリティプロトコル エンドポイントの設定（`SecurityProtocol`) を行います。`SaslUsername` と `SaslPassword` オプションも設定します。次の JSON の例に示すように、Amazon MSK クラスターを初めてセットアップしたときに作成した安全なユーザー名とパスワードと一致していることを確認してください。
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**注記**
現在、 はパブリック CA ベースの SASL-SSL のみ AWS DMS をサポートしています。DMS は、プライベート CA を基盤とするセルフマネージド型 Kafka で使用する SASL-SSL はサポートしていません。
SASL-SSL 認証の場合、 はデフォルトで SCRAM-SHA-512 メカニズム AWS DMS をサポートします。 AWS DMS バージョン 3.5.0 以降は、プレーンメカニズムもサポートしています。Plain メカニズムを使用するには、`KafkaSettings` API データ型の `SaslMechanism` パラメータを `PLAIN` に設定します。データ型 `PLAIN` は Kafka でサポートされていますが、Amazon Kafka (MSK) ではサポートされていません。
## ターゲットとして Apache Kafka の CDC 行の元の値を表示するために前イメージを使用
Kafka のようなデータストリーミングターゲットに CDC 更新を書き込むときは、更新によって変更される前に、ソースデータベースの行の元の値を表示できます。これを可能にするために、 はソースデータベースエンジンによって提供されたデータに基づいて、更新イベントの*前のイメージ* AWS DMS を入力します。
ソースデータベースエンジンによって、前イメージに対してさまざまな量の情報が提供されます。
+ Oracle では、列が変更された場合にのみ列の更新が提供されます。
+ PostgreSQL は、プライマリキーの一部である列のデータ (変更されたかどうか) のみを提供します。論理レプリケーションを使用し、ソーステーブルに REPLICA IDENTITY FULL を設定した場合は、WAL に書き込まれた行の変更前と変更後の情報をすべて取得できます。このような情報はここで確認できます。
+ MySQL は通常、すべての列のデータ (変更されたかどうか) を提供します。
前イメージを有効にして、ソースデータベースから元の値を AWS DMS 出力に追加するには、`BeforeImageSettings` タスク設定または `add-before-image-columns` パラメータを使用します。このパラメータは、列変換ルールを適用します。
`BeforeImageSettings` は、次に示すように、ソースデータベースシステムから収集された値を使用して、すべての更新オペレーションに新しい JSON 属性を追加します。
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**注記**
全ロード \$1 CDCタスク (既存のデータを移行して進行中の変更をレプリケートする)、または CDC のみのタスク (データ変更のみをレプリケートする) に `BeforeImageSettings` を適用します。全ロードのタスクには `BeforeImageSettings` を適用しないでください。
`BeforeImageSettings` オプションには、次の項目が適用されます。
+ `EnableBeforeImage` オプションを `true` に設定して、前イメージを有効にします。デフォルトは `false` です。
+ `FieldName` オプションを使用して、新しい JSON 属性に名前を割り当てます。`EnableBeforeImage` が `true` の場合、`FieldName` は必須であり、空にすることはできません。
+ `ColumnFilter` オプションは、前イメージを使用して追加する列を指定します。テーブルのプライマリキーの一部である列だけを追加するには、デフォルト値 `pk-only` を使用します。LOB タイプではない列のみを追加するには、`non-lob` を使用します。前イメージ値を持つ列を追加するには、`all` を使用します。
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### 前イメージ変換ルールの使用
タスク設定の代わりに、列変換ルールを適用する `add-before-image-columns` パラメータを使用できます。このパラメータを使用すると、Kafka のようなデータストリーミングターゲットで CDC 中に前イメージを有効にできます。
変換ルールで `add-before-image-columns` を使用すると、前イメージの結果のよりきめ細かい制御を適用することができます。変換ルールを使用すると、オブジェクトロケーターを使用し、ルールに選択したテーブルを制御できます。また、変換ルールを連結することもできます。これにより、テーブルごとに異なるルールを適用できます。その後、他のルールを使用して生成された列を操作できます。
**注記**
同じタスク内で、`add-before-image-columns` パラメータと同時に `BeforeImageSettings` タスク設定を使用しないでください。代わりに、1 つのタスクにこのパラメータとこの設定のいずれかを使用し、両方を使用しないでください。
列の `add-before-image-columns` パラメータを持つ `transformation` ルールタイプは、`before-image-def` セクションを提供する必要があります。例を以下に示します。
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
`column-prefix` の値は列名の前に付加され、`column-prefix` のデフォルト値は `BI_` です。`column-suffix` の値は列名に追加され、デフォルトは空です。`column-prefix` と `column-suffix` の両方を空の文字列に設定しないでください。
`column-filter` の値を 1 つ選択します。テーブルのプライマリキーの一部である列だけを追加するには、`pk-only` を選択します。LOB タイプではない列のみを追加するように `non-lob` を選択します。または、前イメージの値を持つ任意の列を追加するように `all` を選択します。
### 前イメージ変換前ルールの例
次の例の変換ルールは、ターゲットに `BI_emp_no` という新しい列を追加します。したがって、`UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` のようなステートメントは、`BI_emp_no` フィールドに 1 を設定します。CDC 更新を Amazon S3 ターゲットに書き込むと、更新された元の行は `BI_emp_no` 列からわかります。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
`add-before-image-columns` ルールアクションの使用方法については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」をご参照ください。
## のターゲットとして Apache Kafka を使用する場合の制限 AWS Database Migration Service
ターゲットとして Apache Kafka を使用する場合、以下の制限が適用されます。
+ AWS DMS Kafka ターゲットエンドポイントは、Amazon Managed Streaming for Apache Kafka (Amazon MSK) の IAM アクセスコントロールをサポートしていません。
+ 完全 LOB モードはサポートされていません。
+ が新しいトピックを自動的に作成できるようにするプロパティを使用して AWS DMS 、クラスターの Kafka 設定ファイルを指定します。設定 `auto.create.topics.enable = true` を含めます。Amazon MSK を使用している場合は、Kafka クラスターを作成するときにデフォルト設定を指定し、`auto.create.topics.enable` 設定を `true` に変更できます。デフォルト設定の詳細については、*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*の「[Amazon MSK のデフォルト設定](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html)」をご参照ください。Amazon MSK を使用して作成された既存の Kafka クラスターを変更する必要がある場合は、次の例のように AWS CLI コマンドを実行して Kafka 設定`aws kafka create-configuration`を更新します。
```
14:38:41 $ aws kafka create-configuration --name "kafka-configuration" --kafka-versions "2.2.1" --server-properties file://~/kafka_configuration
{
"LatestRevision": {
"Revision": 1,
"CreationTime": "2019-09-06T14:39:37.708Z"
},
"CreationTime": "2019-09-06T14:39:37.708Z",
"Name": "kafka-configuration",
"Arn": "arn:aws:kafka:us-east-1:111122223333:configuration/kafka-configuration/7e008070-6a08-445f-9fe5-36ccf630ecfd-3"
}
```
ここでは、`//~/kafka_configuration` は必要なプロパティ設定を使用して作成した設定ファイルです。
Amazon EC2 にインストールされている独自の Kafka インスタンスを使用している場合は、 `auto.create.topics.enable = true`インスタンスに用意されているオプションを使用して、 AWS DMS が新しいトピックを自動的に作成できるように Kafka クラスター設定を変更します。
+ AWS DMS は、トランザクションに関係なく、特定の Kafka トピック内の 1 つのデータレコード (メッセージ) としてソースデータベース内の 1 つのレコードに各更新を発行します。
+ AWS DMS では、パーティションキーに次の 4 つのフォームがサポートされています。
+ `SchemaName.TableName`: スキーマとテーブル名の組み合わせ。
+ `${AttributeName}`: JSON のいずれかのフィールドの値、またはソースデータベースのテーブルのプライマリキー。
+ `transaction-id`: CDC トランザクション ID。同じトランザクション内のすべてのレコードは、同じパーティションに移動します。
+ `constant`: テーブルやデータに関係なく、すべてのレコードの固定リテラル値。すべてのレコードは同じパーティションキー値「定数」に送信され、すべてのテーブルで厳密なグローバル順序が提供されます。
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransactionIdPartitionKey",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ `IncludeTransactionDetails` エンドポイント設定は、ソースエンドポイントが Oracle、SQL Server、PostgreSQL、または MySQL の場合にのみサポートされます。他のソースエンドポイントタイプでは、トランザクションの詳細は含まれません。
+ `BatchApply` は Kafka エンドポイントではサポートされていません。Batch 適用 (例えば、`BatchApplyEnabled` のターゲットメタデータ タスク設定) を使用すると、Kafka ターゲットデータが失われる可能性があります。
+ AWS DMS は、16 桁を超える`BigInt`データ型の値の移行をサポートしていません。この制限を回避するには、次の変換ルールを使用して `BigInt` 列を文字列に変換できます。変換ルールの詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照してください。
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ AWS DMS Kafka ターゲットエンドポイントは Amazon MSK サーブレスをサポートしていません。
+ マッピングルールを定義する場合、オブジェクトマッピングルールと変換ルールの両方を保有するのはサポートされていません。設定の必要があるルールは 1 つのみです。
+ AWS DMS は、3.8 までの Apache Kafka バージョン用の SASL 認証をサポートしています。Kafka 4.0 以降を使用している場合は、SASL 認証なしでのみ接続できます。
+ AWS DMS は、Kafka をターゲットエンドポイントとして使用する場合、埋め込み`'\0'`文字を含むソースデータをサポートしていません。埋め込み`'\0'`文字を含むデータは、最初の`'\0'`文字で切り捨てられます。
## データを Kafka トピックに移行するためのオブジェクトマッピングの使用
AWS DMS はテーブルマッピングルールを使用して、ソースからターゲット Kafka トピックにデータをマッピングします。ターゲットトピックにデータをマッピングするために、オブジェクトマッピングと呼ばれるテーブルマッピングルールのタイプを使用します。オブジェクトマッピングを使用して、ソースのデータレコードがどのように Kafka トピックに発行されたデータレコードにマッピングされるかを定義します。
Kafka トピックには、パーティションキー以外にプリセット構造はありません。
**注記**
オブジェクトマッピングは必ずしも使用する必要はありません。通常のテーブルマッピングは、さまざまな変換に使用できます。ただし、パーティションキータイプは次のデフォルト動作に従います。
プライマリキーはフルロードのパーティションキーとして使用されます。
並行適用タスク設定を使用しない場合は、`schema.table` が CDC のパーティションキーとして使用されます。
並列適用タスク設定を使用する場合、プライマリキーは CDC のパーティションキーとして使用されます。
オブジェクトマッピングルールを作成するには、`object-mapping` として `rule-type` を指定します。このルールが、使用したいオブジェクトマッピングのタイプを指定します。
ルールの構造は次のとおりです。
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS は現在、 `rule-action`パラメータの唯一の有効な値`map-record-to-document`として `map-record-to-record`と をサポートしています。これらの設定は、`exclude-columns` 属性リストの一部として除外されない値に影響します。`map-record-to-record` および `map-record-to-document`値は、デフォルトで がこれらのレコード AWS DMS を処理する方法を指定します。これらの値は、どのような方法でも属性マッピングに影響しません。
リレーショナルデータベースから Kafka トピックに移行する際に `map-record-to-record` を使用します。このルールタイプでは、Kafka トピックのパーティションキーとしてリレーショナルデータベースから `taskResourceId.schemaName.tableName` 値を使用し、ソースデータベース内の各列の属性を作成します。
`map-record-to-record` を使用する場合は、次の点に注意します。
+ この設定は、`exclude-columns` リストで除外されている列にのみ影響します。
+ このような列ごとに、 はターゲットトピックで対応する属性 AWS DMS を作成します。
+ AWS DMS は、ソース列が属性マッピングで使用されているかどうかに関係なく、この対応する属性を作成します。
`map-record-to-record` を理解するための 1 つの方法は、実際の動作を確認することです。この例では、次の構造とデータを含むリレーショナルデータベースのテーブルの行から始めると想定してください。
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
この情報を `Test` という名前のスキーマから Kafka トピックに移行するには、データをターゲットストリームにマッピングするルールを作成します。以下のルールはマッピングを示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Kafka トピックとパーティション キー (この場合は `taskResourceId.schemaName.tableName`) を指定すると、以下の説明は Kafka ターゲットトピックのサンプルデータを使用した結果のレコード形式を示します。
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
**Topics**
+ [属性マッピングを使用したデータの再構築](#CHAP_Target.Kafka.AttributeMapping)
+ [オブジェクトマッピングを使用したマルチトピックレプリケーション](#CHAP_Target.Kafka.MultiTopic)
+ [Apache Kafka のメッセージ形式](#CHAP_Target.Kafka.Messageformat)
### 属性マッピングを使用したデータの再構築
属性マップを使用してデータを Kafka トピックに移行している間にデータを再構築できます。例えば、ソース内の複数のフィールドを結合してターゲット内に 1 つのフィールドを構成することもできます。以下の属性マップはデータを再構築する方法を示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
の定数値を設定するには`partition-key`、 を指定します。これにより`"partition-key-type: "constant"`、パーティション値が に設定されます`constant`。たとえば、すべてのデータを 1 つのパーティションに強制的に格納するためにこれを行うことができます。以下のマッピングはこの方法を示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"attribute-name": "CustomerName",
"value": "${FirstName},${LastName}"
},
{
"attribute-name": "ContactDetails",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"attribute-name": "DateOfBirth",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**注記**
特定のテーブル用のコントロールレコードの `partition-key` 値は、`TaskId.SchemaName.TableName` です。特定のタスク用のコントロールレコードの `partition-key` 値は、そのレコードの `TaskId` です。オブジェクトマッピングの `partition-key` 値を指定することは、コントロールレコードの `partition-key` には影響しません。
テーブルマッピングルール`attribute-name`で `partition-key-type`が に設定されている場合、 を指定する必要があります。これは`partition-key-name`、ソーステーブルの列またはマッピングで定義されたカスタム列を参照する必要があります。さらに、ソース列がターゲット Kafka トピックにどのようにマッピングされるかを定義するには、 を指定`attribute-mappings`する必要があります。
### オブジェクトマッピングを使用したマルチトピックレプリケーション
デフォルトでは、 AWS DMS タスクはすべてのソースデータを次のいずれかの Kafka トピックに移行します。
+ AWS DMS ターゲットエンドポイントの**トピック**フィールドで指定します。
+ ターゲットエンドポイントの **[トピック]** フィールドが入力されておらず、Kafka `auto.create.topics.enable` 設定が `true` に設定されている場合、`kafka-default-topic` の指定に従う。
AWS DMS エンジンバージョン 3.4.6 以降では、 `kafka-target-topic` 属性を使用して、移行された各ソーステーブルを個別のトピックにマッピングできます。例えば、次のオブジェクトマッピングルールは、ソーステーブルを `Customer` と`Address` をそれぞれ Kafka トピック `customer_topic` と `address_topic` に移行します。同時に、 `Test` はスキーマ内のテーブルを含む他のすべてのソース`Bills`テーブルを、ターゲットエンドポイントで指定されたトピック AWS DMS に移行します。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "MapToKafka1",
"rule-action": "map-record-to-record",
"kafka-target-topic": "customer_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "3",
"rule-name": "MapToKafka2",
"rule-action": "map-record-to-record",
"kafka-target-topic": "address_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Address"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "4",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Bills"
}
}
]
}
```
Kafka マルチトピックレプリケーションを使用すると、単一のレプリケーションタスクでソーステーブルをグループ化して個別の Kafka トピックに移行できます。
### Apache Kafka のメッセージ形式
JSON 出力は、単にキーと値のペアのリストです。
**RecordType**
レコードタイプはデータまたはコントロールのいずれかです。*データレコード*は、ソースの実際の行を表します。*コントロールレコード*は、タスクの再起動など、ストリーム内の重要なイベント用です。
**運用**
データレコードの場合、オペレーションは `load`、`insert`、`update`、または `delete` です。
コントロールレコードの場合、オペレーションは `create-table`、`rename-table`、`drop-table`、`change-columns`、`add-column`、`drop-column`、`rename-column`、`column-type-change` です。
**SchemaName**
レコードのソーススキーマ。コントロールレコードの場合、このフィールドは空です。
**TableName**
レコードのソーステーブル。コントロールレコードの場合、このフィールドは空です。
**タイムスタンプ**
JSON メッセージが構築された時刻のタイムスタンプ。このフィールドは ISO 8601 形式でフォーマットされます。
次の JSON メッセージの例は、追加メタデータをすべて含むデータ型メッセージを示しています。
```
{
"data":{
"id":100000161,
"fname":"val61s",
"lname":"val61s",
"REGION":"val61s"
},
"metadata":{
"timestamp":"2019-10-31T22:53:59.721201Z",
"record-type":"data",
"operation":"insert",
"partition-key-type":"primary-key",
"partition-key-value":"sbtest.sbtest_x.100000161",
"schema-name":"sbtest",
"table-name":"sbtest_x",
"transaction-id":9324410911751,
"transaction-record-id":1,
"prev-transaction-id":9324410910341,
"prev-transaction-record-id":10,
"commit-timestamp":"2019-10-31T22:53:55.000000Z",
"stream-position":"mysql-bin-changelog.002171:36912271:0:36912333:9324410911751:mysql-bin-changelog.002171:36912209"
}
}
```
次の JSON メッセージの例は、コントロールタイプのメッセージを示しています。
```
{
"control":{
"table-def":{
"columns":{
"id":{
"type":"WSTRING",
"length":512,
"nullable":false
},
"fname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"lname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"REGION":{
"type":"WSTRING",
"length":1000,
"nullable":true
}
},
"primary-key":[
"id"
],
"collation-name":"latin1_swedish_ci"
}
},
"metadata":{
"timestamp":"2019-11-21T19:14:22.223792Z",
"record-type":"control",
"operation":"create-table",
"partition-key-type":"task-id",
"schema-name":"sbtest",
"table-name":"sbtest_t1"
}
}
```
# のターゲットとしての Amazon OpenSearch Service クラスターの使用 AWS Database Migration Service
を使用して AWS DMS 、Amazon OpenSearch Service (OpenSearch Service) にデータを移行できます。OpenSearch Service は、OpenSearch Service クラスターのデプロイ、運用、スケーリングが簡単に実行できるマネージドサービスです。
OpenSearch Service では、インデックスとドキュメントを操作します。*インデックス*はドキュメントのコレクションであり、*ドキュメント*はスカラー値、配列、およびその他のオブジェクトを含む JSON オブジェクトです。 は JSON ベースのクエリ言語 OpenSearch を提供するため、インデックス内のデータをクエリして対応するドキュメントを取得できます。
AWS DMS が OpenSearch Service のターゲットエンドポイントのインデックスを作成すると、ソースエンドポイントからテーブルごとに 1 つのインデックスが作成されます。OpenSearch Service インデックスの作成コストは、いくつかの要因によって異なります。これらは、作成されたインデックスの数、これらのインデックス内のデータの合計量、および が各ドキュメントに OpenSearch 保存する少量のメタデータです。
移行の範囲に適したコンピューティングリソースとストレージリソースを使用して OpenSearch サービスクラスターを設定します。使用するレプリケーションタスクに応じて、次の要素を考慮することをお勧めします。
+ 全データロードの場合、移行するデータの合計量、さらに転送の速度を考慮します。
+ 継続的な変更のレプリケートの場合、更新頻度、エンドツーエンドのレイテンシーの要件を考慮します。
また、OpenSearch クラスターでインデックスを設定し、ドキュメントの数に細心の注意を払います。
**マルチスレッド全ロードタスク設定**
転送速度を向上させるために、 は OpenSearch Service ターゲットクラスターへのマルチスレッド全ロード AWS DMS をサポートします。 は、以下を含むタスク設定でこのマルチスレッド AWS DMS をサポートします。
+ `MaxFullLoadSubTasks` - このオプションを使用して、並列ロードするソーステーブルの最大数を指定します。DMS は、専用のサブタスクを使用して、対応する OpenSearch Service ターゲットインデックスに各テーブルをロードします。デフォルトは 8、最大値は 49 です。
+ `ParallelLoadThreads` – このオプションを使用して、 AWS DMS が各テーブルを OpenSearch Service ターゲットインデックスにロードするために使用するスレッドの数を指定します。OpenSearch Service ターゲットの最大値は 32 です。この上限を増やすよう依頼できます。
**注記**
`ParallelLoadThreads` をデフォルト値 (0) から変更しない場合、 AWS DMS は一度に 1 つのレコードを転送します。この方法の場合、OpenSearch Service クラスターに過度の負荷がかかります。このオプションを 1 以上に設定していることを確認します。
+ `ParallelLoadBufferSize` – 並列ロードスレッドが OpenSearch Service ターゲットにデータをロードするために使用するバッファに保存するレコードの最大数を指定するには、このオプションを使用します。デフォルト値は 50 です。最大値は 1000 です。この設定は `ParallelLoadThreads` で使用します。`ParallelLoadBufferSize` は、複数のスレッドがある場合にのみ有効です。
マルチスレッドを使用して DMS が OpenSearch Service クラスターをロードする方法の詳細については、 AWS ブログ記事[「移行のために AWS Database Migration Service Amazon OpenSearch Service をスケールする](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/)」を参照してください。
**マルチスレッド CDC ロードタスクの設定**
タスク設定を使用して `PutRecords` API コールの動作を変更するなど、OpenSearch Service ターゲットクラスターの変更データキャプチャ (CDC) のパフォーマンスを向上できます。これを行うには、`ParallelApply*` タスク設定を使用して、同時スレッドの数、スレッドあたりのキュー数、バッファに格納するレコード数を指定します。例えば、CDC ロードを実行し、32 本のスレッドを並列に適用するとします。また、スレッドあたり 64 個のキューにアクセスして、バッファあたり 50 個のレコードを保存する必要があります。
**注記**
CDC から Amazon OpenSearch Service ターゲットエンドポイントへの`ParallelApply*`タスク設定の使用のサポートは、 AWS DMS バージョン 3.4.0 以降で利用できます。
CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを OpenSearch Service ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 で、最大値は 32 です。
+ `ParallelApplyBufferSize` – CDC ロード中に OpenSearch Service ターゲットエンドポイントにプッシュする同時スレッドの各バッファキューに格納するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` – CDC 中に各スレッドがキューからデータレコードを取り出して OpenSearch Service エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定する。
`ParallelApply*` タスク設定を使用する場合、`partition-key-type` のデフォルトは `schema-name.table-name` ではなくテーブルの `primary-key` です。
## リレーショナルデータベースから OpenSearch Service インデックスへの移行
AWS DMS は、OpenSearch Service のスカラーデータ型へのデータの移行をサポートしています。Oracle や MySQL などのリレーショナルデータベースから OpenSearch Service に移行する場合は、データを格納する方法を再編成が必要となる場合があります。
AWS DMS は、次の OpenSearch Service スカラーデータ型をサポートしています。
+ ブール値
+ 日付
+ 浮動小数点数
+ Int
+ String
AWS DMS は、Date 型のデータを String 型に変換します。これらの日付を解釈するカスタムマッピングを指定できます。
AWS DMS は LOB データ型の移行をサポートしていません。
## Amazon OpenSearch Service を のターゲットとして使用するための前提条件 AWS Database Migration Service
のターゲットとして OpenSearch Service データベースを使用する前に AWS DMS、 AWS Identity and Access Management 必ず (IAM) ロールを作成してください。このロールは、 がターゲットエンドポイントの OpenSearch Service インデックス AWS DMS にアクセスできるようにします。アクセス許可の最小設定は、次の IAM ポリシーで示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
OpenSearch Service への移行に使用するロールには、次のアクセス権限が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
前の例では、 `region`を AWS リージョン識別子、 *`account-id`* を AWS アカウント ID、 を Amazon OpenSearch Service ドメインの名前`domain-name`に置き換えます。例: `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`。
## のターゲットとして OpenSearch Service を使用する場合のエンドポイント設定 AWS DMS
追加の接続属性の使用と同様、エンドポイントの設定を使用して、ターゲットの OpenSearch Service データベースを設定できます。 AWS DMS コンソールを使用するか、`--elasticsearch-settings '{"EndpointSetting": "value", ...}'`JSON 構文で の `create-endpoint` コマンドを使用して[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)、ターゲットエンドポイントを作成するときに設定を指定します。
次の表は、ターゲットとして OpenSearch Service を使用できるエンドポイント設定を説明しています。
| 属性名 | 有効値 | デフォルト値と説明 |
| --- | --- | --- |
| `FullLoadErrorPercentage` | 0 より大きく、100 より小さい正の整数。 | 10 – 全ロードタスクの場合、この属性によって、タスクが失敗するまでに許容されるエラーのしきい値が決まります。たとえば、ソースエンドポイントに 1,500 行あり、このパラメータが 10 に設定されているとします。ターゲットエンドポイントへの書き込み時に が 150 個を超えるエラー (行数の 10%) AWS DMS を検出した場合、タスクは失敗します。 |
| `ErrorRetryDuration` | 0 より大きい正の整数。 | 300 – ターゲットエンドポイントでエラーが発生した場合、 はこの数秒間 AWS DMS 再試行します。再試行しない場合、タスクは失敗します｡ |
| `UseNewMappingType` | true、または false | `false`、ただし opensearch v2.x を使用するには、`true` に設定する必要があります。 |
## のターゲットとして Amazon OpenSearch Service を使用する場合の制限 AWS Database Migration Service
Amazon OpenSearch Service をターゲットとして使用する場合、次の制限が適用されます。
+ OpenSearch Service は、動的マッピング (自動推測) を使用して、移行されたデータに使用するデータ型を決定します。
+ OpenSearch サービスは、各ドキュメントを一意の ID で保存します。以下は ID の例です。
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
各ドキュメント ID は 64 バイト長であるため、ストレージ要件と予想されます。たとえば、 AWS DMS ソースから 100,000 行を移行する場合、結果の OpenSearch Service インデックスにはさらに 6,400,000 バイトのストレージが必要です。
+ OpenSearch Service では、プライマリキー属性を更新できません。この制限は、ターゲットで不要なデータが発生する可能性があるため、変更データキャプチャ (CDC) で継続的なレプリケーションを使用する場合に重要です。CDC モードでは、プライマリキーは 32 バイト長の SHA256 値にマップされます。この値はユーザーが判読できる 64 バイト文字列に変換され、OpenSearch サービスのドキュメント ID として使用されます。
+ が移行できない項目 AWS DMS を検出した場合、Amazon CloudWatch Logs にエラーメッセージを書き込みます。この動作は、例外テーブルにエラーを書き込む他の AWS DMS ターゲットエンドポイントの動作とは異なります。
+ AWS DMS は、マスターユーザーとパスワードできめ細かなアクセスコントロールが有効になっている Amazon ES クラスターへの接続をサポートしていません。
+ AWS DMS は OpenSearch Service サーバーレスをサポートしていません。
+ OpenSearch サービスは、既存のインデックスへのデータの書き込みをサポートしていません。
+ レプリケーションタスクの `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` 設定は、OpenSearch ターゲットエンドポイントでの使用には対応していません。
+ を使用して Amazon Elasticsearch にデータを移行する場合 AWS DMS、ソースデータにはプライマリキーまたは一意の識別子列が必要です。ソースデータにプライマリキーまたは一意の識別子がない場合は、define-primary-key の変換ルールを使用して定義する必要があります。
## Amazon OpenSearch Service のターゲットデータ型
が異種データベースからデータを AWS DMS 移行すると、サービスはソースデータベースのデータ型をデータ型と呼ばれる中間 AWS DMS データ型にマッピングします。その後、サービスは中間データ型をターゲットデータ型にマッピングします。次の表は、OpenSearch Service で各 AWS DMS データ型とマッピングされるデータ型を示しています。
| AWS DMS データ型 | OpenSearch Service のデータ型 |
| --- | --- |
| ブール値 | boolean |
| 日付 | string |
| 時間 | date |
| タイムスタンプ | date |
| INT4 | integer |
| Real4 | float |
| UINT4 | integer |
AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。
# AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用
が AWS DMS サポートする Amazon DocumentDB (MongoDB 互換) のバージョンについては、「」を参照してください[のターゲット AWS DMS](CHAP_Introduction.Targets.md)。 AWS DMS を使用して、 AWS DMS がサポートするソースデータエンジンから Amazon DocumentDB にデータを移行できます。ソースエンジンは、Amazon RDS、Aurora、Amazon S3 などの AWS マネージドサービス上に配置できます。このエンジンは Amazon EC2 またはオンプレミスで実行されている MongoDB などの自己管理データベース上に存在していてもかまいません。
を使用して AWS DMS 、ソースデータを Amazon DocumentDB データベース、コレクション、またはドキュメントにレプリケートできます。
**注記**
ソース エンドポイントが MongoDB または Amazon DocumentDB の場合は、**[Document mode]** (ドキュメントモード) で移行します。
MongoDB はバイナリ JSON 形式 (BSON) でデータを保存します。 は、Amazon DocumentDB でサポートされているすべての BSON データ型 AWS DMS をサポートします。これらのデータ型のリストについては、*Amazon DocumentDB デベロッパーガイド* の「[サポートされている MongoDB API およびオペレーション、データ型](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html)」をご参照ください。
ソースエンドポイントがリレーショナルデータベースの場合、 は次のようにデータベースオブジェクトを Amazon DocumentDB に AWS DMS マッピングします。
+ リレーショナルデータベースあるいはデータベーススキーマは、Amazon DocumentDB の*データベース*にマップされます。
+ リレーショナルデータベース内のテーブルは、Amazon DocumentDB 内の*コレクションです*にマップされます。
+ リレーショナルテーブル内のレコードは、Amazon DocumentDB 内の*文書*にマップされます。ソースレコードのデータから各ドキュメントが構築されます。
ソース エンドポイントが Amazon S3 である場合は、Amazon S3 の AWS DMS マッピングルールに対応する Amazon DocumentDB オブジェクトが作成されます。たとえば次のような URI があったとします。
```
s3://amzn-s3-demo-bucket/hr/employee
```
この場合、 は のオブジェクトを次のように Amazon DocumentDB `amzn-s3-demo-bucket`に AWS DMS マッピングします。
+ URI の最上位パート (`hr`) は、 Amazon DocumentDB データベースにマップされます。
+ 次の URI パート (`employee`) は、Amazon DocumentDB のコレクションにマップされます。
+ `employee` の各オブジェクトは Amazon DocumentDB 内のドキュメントにマップされます。
Amazon S3 のマッピングルールの詳細については、「[のソースとしての Amazon S3 の使用 AWS DMS](CHAP_Source.S3.md)」をご参照ください。
**Amazon DocumentDB のエンドポイント設定**
AWS DMS バージョン 3.5.0 以降では、並列スレッドと一括オペレーションのタスク設定を調整することで、Amazon DocumentDB エンドポイントの変更データキャプチャ (CDC) のパフォーマンスを向上させることができます。これを行うには、`ParallelApply*` タスク設定を使用して、同時スレッドの数、スレッドあたりのキュー数、バッファに格納するレコード数を指定します。例えば、CDC ロードを実行し、128 本のスレッドを並列に適用するとします。また、スレッドあたり 64 個のキューにアクセスして、バッファあたり 50 個のレコードを保存する必要があります。
CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Amazon DocumentDB ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 で、最大値は 32 です。
+ `ParallelApplyBufferSize` – CDC ロード中に Amazon DocumentDB ターゲットエンドポイントにプッシュする同時スレッドの各バッファキューに格納するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` – CDC 中に各スレッドがキューからデータレコードを取り出して Amazon DocumentDB エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定する。デフォルトは 1 です。最大数は 512。
**注記**
Amazon DocumentDB ターゲットの場合、並列 CDC 適用によってキーエラーが重複したり、セカンダリ一意インデックスを使用するワークロードや変更の厳密な順序付けが必要なワークロードに CDC 適用が停止されたりする可能性があります。これらのワークロードには、デフォルトのシングルスレッド CDC 適用設定を使用します。
のターゲットとして Amazon DocumentDB を使用する方法の詳細については AWS DMS、以下のセクションを参照してください。
**Topics**
+ [ソースから Amazon DocumentDB ターゲットへのデータのマッピング](#CHAP_Target.DocumentDB.data-mapping)
+ [ターゲットとしての Amazon DocumentDB Elastic Cluster への接続](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Amazon DocumentDB をターゲットとする継続的なレプリケーション](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Amazon DocumentDB をターゲットとして使用する場合の制限事項](#CHAP_Target.DocumentDB.limitations)
+ [ターゲットとしての Amazon DocumentDB のエンドポイントの設定](#CHAP_Target.DocumentDB.ECAs)
+ [Amazon DocumentDB のターゲットデータ型](#CHAP_Target.DocumentDB.datatypes)
**注記**
移行プロセスのstep-by-stepのチュートリアルについては、 AWS Database Migration Service Step-by-Step移行ガイド[」のMongoDB から Amazon DocumentDB への移行](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html)」を参照してください。
## ソースから Amazon DocumentDB ターゲットへのデータのマッピング
AWS DMS はソースエンドポイントからレコードを読み取り、読み取りデータに基づいて JSON ドキュメントを作成します。JSON ドキュメントごとに、一意の識別子として機能する `_id`フィールドを決定 AWS DMS する必要があります。このターゲットは次に、その `_id` フィールドをプライマリ キーとして使用してJSON ドキュメントを、Amazon DocumentDB コレクションに書き込みます。
### 単一列のソースデータ
ソースデータが 1 つの列で構成されている場合、そのデータは文字列型である必要があります。(ソースエンジンに応じて、実際のデータ型は VARCHAR、NVARCHAR、TEXT、LOB、CLOB などです）。データは有効な JSON ドキュメントであると AWS DMS 想定し、そのまま Amazon DocumentDB にレプリケートします。
結果の JSON ドキュメントに `_id` という名前のフィールドが含まれている場合は、そのフィールドが Amazon DocumentDB で一意の `_id` として使用されます。
JSON に `_id` フィールドが含まれていない場合は、Amazon DocumentDB によって自動的に `_id` 値が生成されます。
### 複数列のソースデータ
ソースデータが複数の列で構成されている場合、 はこれらのすべての列から JSON ドキュメント AWS DMS を作成します。ドキュメントの `_id`フィールドを決定するために、 は次のように AWS DMS 処理します。
+ `_id` という名前の列がある場合は、その列のデータがターゲット `_id` として使用されます。
+ `_id` 列がないが、ソースデータにプライマリキーまたは一意のインデックスがある場合、 AWS DMS はそのキーまたはインデックス値を`_id`値として使用します。プライマリキーや一意のインデックスのデータは、JSON ドキュメント内の明示的なフィールドとしても表示されます。
+ `_id` 列も、プライマリ キーも、一意のインデックスもない場合は、Amazon DocumentDB によって自動的に `_id` 値が生成されます。
### ターゲットエンドポイントのデータ型の強制変換
AWS DMS は、Amazon DocumentDB ターゲットエンドポイントに書き込むときにデータ構造を変更できます。これらの変更をリクエストするには、ソースエンドポイントでテーブルや列の名前を変更するか、タスクの実行時に適用される変換ルールを指定します。
#### ネストされた JSON ドキュメント (json\$1 プレフィックス) の使用
ソース列の名前に `json_` というプレフィックスを付けることによってデータ型を強制変換することができます (`json_columnName`)。手動で行うことも、変換を使用して行うこともできます。この場合、その列は、文字列フィールドとしてではなく、ターゲットドキュメント内のネストされた JSON ドキュメントとして作成されます。
たとえば、MongoDB ソースエンドポイントから次のドキュメントを移行するとします。
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
これらのソースデータ型を強制変換しない場合、埋め込まれている `ContactDetails` ドキュメントは文字列として移行されます。
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
しかし、変換ルールを追加して、`ContactDetails` を JSON オブジェクトに強制変換することができます。たとえば、ソース列の元の名前が `ContactDetails` である場合に、データ型をネストされた JSON に強制変換するには、ソースに「\$1json\$1\$1」プレフィックスを手動で追加するか、変換ルールを使用して、ソースエンドポイントの列名前「JSON\$1ContactDetails」に変更する必要があります。例えば、次の変換ルールを使用できます。
```
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "1",
"rule-name": "1",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "ContactDetails"
},
"rule-action": "rename",
"value": "json_ContactDetails",
"old-value": null
}
]
}
```
AWS DMS は、次のように ContactDetails フィールドをネストされた JSON としてレプリケートします。
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### JSON 配列 (array\$1 プレフィックス) の使用
列の名前に `array_` というプレフィックスを付けることによってデータ型を強制変換することができます (`array_columnName`)。手動で行うことも、変換を使用して行うこともできます。この場合、 は列 AWS DMS を JSON 配列と見なし、ターゲットドキュメントにそのように作成します。
たとえば、MongoDB ソースエンドポイントから次のドキュメントを移行するとします。
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
これらのソースデータ型を強制変換しない場合、埋め込まれている `ContactDetails` ドキュメントは文字列として移行されます。
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
しかし、変換ルールを追加して、`ContactAddress` と `ContactPhoneNumbers` を JSON 配列に強制変換することができます。その例を次の表に示します。
****
| ソース列の元の名前 | ソース列の変更後の名前 |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS は`ContactPhoneNumbers`次のように `ContactAddress`と をレプリケートします。
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### TLS を使用して Amazon DocumentDB に接続する
デフォルトでは、新しく作成された Amazon DocumentDB クラスターは、Transport Layer Security (TLS) を使用したセキュアな接続のみを受け入れます。TLS が有効になっている場合、Amazon DocumentDB へのすべての接続で公開キーが必要になります。
Amazon DocumentDB のパブリックキーを取得するには、ホストされている Amazon Amazon S3バケット`rds-combined-ca-bundle.pem`から ファイル をダウンロードします。 AWS ファイルのダウンロードの詳細については、*Amazon DocumentDB デベロッパーガイド*の「[TLS を使用した接続の暗号化](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html)」をご参照ください。
この .pem ファイルをダウンロードしたら、以下 AWS DMS に示すように、そのファイルに含まれるパブリックキーを にインポートできます。
#### AWS マネジメントコンソール
**パブリックキー (.pem) ファイルをインポートするには**
1. [https://console.aws.amazon.com/dms](https://console.aws.amazon.com/dms) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで [**Certificates**] を選択します。
1. [**Import certificate (証明書のインポート)**] を選択し、次の操作を行います。
+ [**Certificate identifier (証明書の識別子)**] に、証明書の一意の名前を入力します (例: `docdb-cert`)。
+ [**Import file (ファイルのインポート)**] で、.pem ファイルを保存した場所を参照します。
すべての設定が正しいことを確認したら、[**Add new CA certificate (新しい CA 証明書の追加)**] を選択します。
#### AWS CLI
次の例に示すように `aws dms import-certificate` コマンドを使用します。
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
AWS DMS ターゲットエンドポイントを作成するときは、証明書識別子 ( など`docdb-cert`) を指定します。また、[SSL mode (SSL モード)] パラメータを [`verify-full`] に設定します。
## ターゲットとしての Amazon DocumentDB Elastic Cluster への接続
AWS DMS バージョン 3.4.7 以降では、Amazon DocumentDB ターゲットエンドポイントを Elastic クラスターとして作成できます。ターゲットエンドポイントを Elastic クラスターとして作成する場合、既存の SSL 証明書は機能しないため、Amazon DocumentDB Elastic クラスターエンドポイントに新しい SSL 証明書をアタッチする必要があります。
**新しい SSL 証明書を Amazon DocumentDB Elastic クラスターエンドポイントにアタッチするには**
1. ブラウザで [https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) を開いて、コンテンツを `.pem` に一意のファイル名を付けて保存します (`SFSRootCAG2.pem` など)。この証明書ファイルは、後半の手順でインポートする必要がありますす。
1. Elastic クラスターエンドポイントを作成して、次のオプションを設定します。
1. **[エンドポイント設定]** の下で、**[新しい CA 証明書の追加]** をクリックします。
1. **[証明書の識別子]** には、**SFSRootCAG2.pem** を入力します。
1. **[証明書ファイルのインポート]** では、**[ファイルを選択]** をクリックして、前のタスクでダウンロードした `SFSRootCAG2.pem` ファイルに移動します。
1. ファイルを選択して、ダウンロードした `SFSRootCAG2.pem` ファイルを選択します。
1. [**証明書のインポート**] を選択します。
1. **[証明書の選択]** ドロップダウンで、**[SFSRootCAG2.pem]** を選択します。
ダウンロードした `SFSRootCAG2.pem` ファイルからの新しい SSL 証明書が、Amazon DocumentDB Elastic クラスターエンドポイントにアタッチされます。
## Amazon DocumentDB をターゲットとする継続的なレプリケーション
Amazon DocumentDB をターゲットとした継続的なレプリケーション (変更データキャプチャ、CDC) が有効になっている場合、 AWS DMS バージョン 3.5.0 以降では以前のリリースと比べてパフォーマンスが 20 倍向上しています。が 1 秒あたり最大 250 レコード AWS DMS を処理する以前のリリースでは、 AWS DMS は現在、1 秒あたり 5000 レコード以上を効率的に処理します。 AWS DMS また、 は Amazon DocumentDB のドキュメントがソースと同期していることを確認します。ソースレコードを作成または更新するときは、まず以下を実行して、影響を受ける Amazon DocumentDB レコードを決定 AWS DMS する必要があります。
+ ソースレコードに `_id` という名前の列がある場合は、その列の値を使用して Amazon DocumentDB コレクションの対応する `_id` が特定されます。
+ `_id` 列がないが、ソースデータにプライマリキーまたは一意のインデックスがある場合、 AWS DMS はそのキーまたはインデックス値を Amazon DocumentDB コレクションの として使用`_id`します。
+ ソースレコードに `_id`列、プライマリキー、または一意のインデックスがない場合、 はすべてのソース列を Amazon DocumentDB コレクションの対応するフィールドに AWS DMS 一致させます。
新しいソースレコードが作成されると、 は対応するドキュメントを Amazon DocumentDB に AWS DMS 書き込みます。既存のソースレコードが更新されると、 は Amazon DocumentDB のターゲットドキュメントの対応するフィールド AWS DMS を更新します。ターゲットドキュメントには存在するがソースレコードには存在しないフィールドは、一切変更されません。
ソースレコードが削除されると、 は Amazon DocumentDB から対応するドキュメント AWS DMS を削除します。
### ソースの構造の変更 (DDL)
継続的レプリケーションでは、ソースのデータ構造 (テーブル、列など) の変更が Amazon DocumentDB の対応する要素に反映されます。リレーショナルデータベースでは、これらの変更はデータ定義言語 (DDL) ステートメントを使用して開始されます。がこれらの変更を Amazon DocumentDB AWS DMS に伝達する方法を次の表に示します。
****
| ソースの DDL | Amazon DocumentDB ターゲットでの効果 |
| --- | --- |
| CREATE TABLE | 空のコレクションが作成されます。 |
| テーブル名を変更するステートメント (RENAME TABLE、ALTER TABLE...RENAME など) | コレクションの名前が変更されます。 |
| TRUNCATE TABLE | コレクションからすべてのドキュメントが削除されます (HandleSourceTableTruncated が true の場合のみ)。詳細については、「[変更処理の DDL 処理のタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md)」をご参照ください。 |
| DROP TABLE | コレクションが削除されます (HandleSourceTableDropped が true の場合のみ)。詳細については、「[変更処理の DDL 処理のタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md)」をご参照ください。 |
| テーブルに列を追加するステートメント (ALTER TABLE...ADD など) | この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しいフィールドが追加されます。 |
| ALTER TABLE...RENAME COLUMN | この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しい名前のフィールドが追加されます。 |
| ALTER TABLE...DROP COLUMN | この DDL ステートメントは無視され、警告が表示されます。 |
| 列のデータ型を変更するステートメント (ALTER COLUMN...MODIFY など) | この DDL ステートメントは無視され、警告が表示されます。ソースでその新しいデータ型を使用した最初の INSERT が実行されたときに、その新しいデータ型のフィールドを使用してターゲットドキュメントが作成されます。 |
## Amazon DocumentDB をターゲットとして使用する場合の制限事項
Amazon DocumentDB をターゲットとして使用する場合は、次の制限が適用されます AWS DMS。
+ Amazon DocumentDB では、コレクション名にドル記号 (\$1) を含めることはできません。また、データベース名に Unicode 文字を含めることもできません。
+ AWS DMS では、複数のソーステーブルを 1 つの Amazon DocumentDB コレクションに統合することはできません。
+ AWS DMS がプライマリキーを持たないソーステーブルから変更を処理すると、そのテーブル内の LOB 列は無視されます。
+ **[変更テーブル]** オプションが有効で、 AWS DMS で「*\$1id*」という名前のソース列が検出されると、その列が変更テーブルに 「*\$1\$1id*」 (アンダースコア 2 つが前に付く) として表示されます。
+ ソースエンドポイントとして Oracle を選択する場合は、Oracle ソースで完全なサプリメンタルロギングが有効になっている必要があります。有効になっていないと、ソースに変更されていない列がある場合にデータが null 値として Amazon DocumentDB にロードされます。
+ レプリケーション タスクの設定、`TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` は、DocumentDB ターゲット エンドポイントでの使用には対応していません。
+ MongoDB の上限付きコレクションは、Amazon DocumentDB ではサポートされていません。ただし AWS DMS は、ターゲット DocumentDB の上限なしのコレクションなどのオブジェクトを自動的に移行します。
+ Amazon DocumentDB ターゲットに並列 CDC を適用すると、キーエラーが重複したり、セカンダリ一意インデックスを使用するワークロードや変更の厳密な順序付けが必要なワークロードに CDC 適用が停止されたりする可能性があります。このようなワークロードでは、デフォルトのシングルスレッド CDC 適用設定を使用します。
## ターゲットとしての Amazon DocumentDB のエンドポイントの設定
追加の接続属性の使用と同様、エンドポイントの設定を使用して、ターゲットの Amazon DocumentDB データベースを設定できます。 AWS DMS コンソールを使用するか、`--doc-db-settings '{"EndpointSetting": "value", ...}'`JSON 構文で の `create-endpoint` コマンドを使用して[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)、ターゲットエンドポイントを作成するときに設定を指定します。
次の表は、ターゲットとして Amazon DocumentDB を使用できるエンドポイント設定を説明しています。
| 属性名 | 有効値 | デフォルト値と説明 |
| --- | --- | --- |
| `replicateShardCollections` | boolean `true` `false` | `true` の場合、このエンドポイント設定には次のような影響がおよび、次のとおりの制限がある。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Amazon DocumentDB のターゲットデータ型
次の表に、DMS の使用時にサポートされる Amazon DocumentDB AWS ターゲットデータ型と、 AWS DMS データ型からのデフォルトのマッピングを示します。DMS データ型の詳細については、 AWS 「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。
| AWS DMS データ型 | Amazon DocumentDB データ型 |
| --- | --- |
| BOOLEAN | ブール値 |
| BYTES | バイナリデータ |
| DATE | 日付 |
| TIME | 文字列 (UTF8) |
| DATETIME | 日付 |
| INT1 | 32 ビット整数 |
| INT2 | 32 ビット整数 |
| INT4 | 32 ビット整数 |
| INT8 | 64 ビット整数 |
| NUMERIC | 文字列 (UTF8) |
| REAL4 | Double |
| REAL8 | Double |
| STRING | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 |
| UINT1 | 32 ビット整数 |
| UINT2 | 32 ビット整数 |
| UINT4 | 64 ビット整数 |
| UINT8 | 文字列 (UTF8) |
| WSTRING | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 |
| BLOB | バイナリ |
| CLOB | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 |
| NCLOB | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 |
# のターゲットとしての Amazon Neptune の使用 AWS Database Migration Service
Amazon Neptune は、高速で信頼性に優れたフルマネージド型のグラフデータベースサービスであり、高度に接続されたデータセットを使用するアプリケーションの構築と実行を容易にします。Neptune の中核は、専用のハイパフォーマンスなグラフデータベース エンジンです。このエンジンは、数十億の関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリできるよう最適化されています。Neptune は、人気の高いグラフクエリ言語 Apache TinkerPop Gremlin と W3C の SPARQL をサポートしています。Amazon Neptune の詳細については、*Amazon Neptune ユーザーガイド* の「[Amazon Neptune のクォータ](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html)」をご参照ください。
Neptune などのグラフデータベースがなければ、リレーショナルデータベースで高接続データをモデル化するとよいでしょう。データに動的接続がある可能性があるため、このようなデータソースを使用するアプリケーションは SQL で接続されたデータクエリをモデル化する必要があります。この方法では、グラフクエリを SQL に変換するために余分なレイヤーを記述する必要があります。また、リレーショナルデータベースにはスキーマの剛性があります。接続を変更するスキーマのすべての変更には、新しいスキーマをサポートするために、ダウンタイムおよびクエリ変換の追加メンテナンスが必要になります。アプリケーションの設計時に考慮すべき別の大きな制約は、クエリのパフォーマンスです。
グラフデータベースは、このような状況を大幅に簡素化することができます。スキーマから解放され、豊富なグラフクエリレイヤー (Gremlin または SPARQL) とグラフクエリ用に最適化されたインデックスにより、柔軟性とパフォーマンスが向上します。Amazon Neptune グラフデータベースには、保存時の暗号化、安全な認可レイヤー、デフォルトバックアップ、マルチ AZ サポート、リードレプリカ サポートなどのエンタープライズ機能もあります。
を使用すると AWS DMS、高度に接続されたグラフをモデル化するリレーショナルデータを、サポートされている SQL データベースの DMS ソースエンドポイントから Neptune ターゲットエンドポイントに移行できます。
詳細については、以下をご参照ください。
**Topics**
+ [ターゲットとしての Amazon Neptune への移行の概要](#CHAP_Target.Neptune.MigrationOverview)
+ [ターゲットとしての Amazon Neptune エンドポイント設定の指定](#CHAP_Target.Neptune.EndpointSettings)
+ [ターゲットとして Amazon Neptune にアクセスするための IAM サービスロールの作成](#CHAP_Target.Neptune.ServiceRole)
+ [ターゲットとしての Amazon Neptune 用の Gremlin および R2RML を使用したグラフ マッピングルールの指定](#CHAP_Target.Neptune.GraphMapping)
+ [ターゲットとしての Amazon Neptune への Gremlin および R2RML 移行のデータ型](#CHAP_Target.Neptune.DataTypes)
+ [ターゲットとしての Amazon Neptune の使用における制限](#CHAP_Target.Neptune.Limitations)
## ターゲットとしての Amazon Neptune への移行の概要
Neptune ターゲットへの移行を開始する前に、 AWS アカウントに次のリソースを作成します。
+ ターゲット エンドポイントの Neptune クラスター。
+ ソースエンドポイント AWS DMS の でサポートされている SQL リレーショナルデータベース。
+ ターゲット エンドポイントの Amazon S3 バケット。この S3 バケットを Neptune クラスターと同じ AWS リージョンに作成します。 AWS DMS は、この S3 バケットを Neptune データベースに一括ロードするターゲットデータの中間ファイルストレージとして使用します。Amazon S3 バケットの作成の詳細については、*Amazon Simple Storage Service ユーザーガイド*の[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)をご参照ください。
+ Neptune クラスターと同じ VPC 内の S3 の Virtual Private Cloud (VPC) エンドポイント。
+ IAM ポリシーを含む AWS Identity and Access Management (IAM) ロール。このポリシーでは、ターゲットエンドポイントの S3 バケットに対する、`GetObject`、`PutObject`、`DeleteObject` および `ListObject` アクセス許可を指定する必要があります。このロールは、ターゲット S3 バケット AWS DMS と Neptune データベースの両方への IAM アクセスを持つ と Neptune の両方によって引き受けられます。詳細については、「[ターゲットとして Amazon Neptune にアクセスするための IAM サービスロールの作成](#CHAP_Target.Neptune.ServiceRole)」を参照してください。
これらのリソースを取得したら、Neptune ターゲットへの移行の設定とスタートは、コンソールまたは DMS API を使用した全ロードの移行と同様です。ただし、Neptune ターゲットへの移行には固有のステップが必要です。
**AWS DMS リレーショナルデータベースを Neptune に移行するには**
1. [レプリケーション インスタンスの作成](CHAP_ReplicationInstance.Creating.md) の説明に従って、レプリケーションインスタンスを作成します。
1. ソースエンドポイントの でサポートされている SQL リレーショナルデータベースを作成してテスト AWS DMS します。
1. Neptune データベースのターゲット エンドポイントを作成してテストします。
ターゲット エンドポイントを Neptune データベースに接続するには、Neptune クラスター エンドポイントまたは Neptune ライター インスタンス エンドポイントのサーバー名を指定します。また、 の S3 バケットフォルダを指定 AWS DMS して、Neptune データベースへの一括ロード用に中間ファイルを保存します。
移行中、 は、指定した最大ファイルサイズまで、移行されたすべてのターゲットデータをこの S3 バケットフォルダに AWS DMS 保存します。このファイルストレージがこの最大サイズに達すると、 AWS DMS は保存された S3 データをターゲットデータベースにロードします。フォルダをクリアして、後でターゲットデータベースにロードするために、追加ターゲットデータの保存を有効にします。これらの設定の指定の詳細については、「[ターゲットとしての Amazon Neptune エンドポイント設定の指定](#CHAP_Target.Neptune.EndpointSettings)」をご参照ください。
1. 手順 1 ～ 3 で作成したリソースを使用して全ロードレプリケーション タスクを作成し、次の手順を実行します：
1. 通常のタスクテーブルマッピングを使用して、適切な選択ルールと変換ルールを使用して、リレーショナルデータベースから移行する特定のソーススキーマ、テーブルおよびビューを指定します。詳細については、「[テーブルマッピングを使用して、タスクの設定を指定する](CHAP_Tasks.CustomizingTasks.TableMapping.md)」をご参照ください。
1. 次のいずれかを選択して、ターゲットマッピングを指定し、ソーステーブルおよびビューから Neptune ターゲット データベースグラフへのマッピングルールを指定します。
+ Gremlin JSON — Gremlin JSON を使用して Neptune データベースをロードする方法については、*Amazon Neptune ユーザーガイド*の「[Gremlin ロードデータ形式](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html)」をご参照ください。
+ SPARQL RDB からリソース記述フレームワーク マッピング言語 (R2RML) への SPARQL R2RML の使用方法については、W3C 仕様の「[R2RML: RDB から RDF へのマッピング言語](https://www.w3.org/TR/r2rml/)」をご参照ください。
1. 次のいずれかを行います。
+ AWS DMS コンソールを使用して、**「データベース移行タスクの作成**」ページのグラフマッピング**ルールを使用してグラフマッピング**オプションを指定します。
+ AWS DMS API を使用して、`CreateReplicationTask`API コールの `TaskData` リクエストパラメータを使用してこれらのオプションを指定します。
Gremlin JSON および SPARQL R2RML を使用してグラフマッピングルールを指定する方法の詳細と例については、「[ターゲットとしての Amazon Neptune 用の Gremlin および R2RML を使用したグラフ マッピングルールの指定](#CHAP_Target.Neptune.GraphMapping)」をご参照ください。
1. 移行タスクのレプリケーションを開始します。
## ターゲットとしての Amazon Neptune エンドポイント設定の指定
ターゲットエンドポイントを作成または変更するには、コンソール、`CreateEndpoint` または `ModifyEndpoint` API オペレーションを使用します。
AWS DMS コンソールの Neptune ターゲットの場合、エンドポイント**の作成またはエンドポイント****コンソールの変更ページでエンドポイント****固有の設定**を指定します。`CreateEndpoint` と `ModifyEndpoint` に、`NeptuneSettings` オプションのリクエストパラメータを指定します。以下の例は CLI を使用してこれを行う方法を示しています。
```
dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com
--port 8192
--neptune-settings
'{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
"S3BucketName":"amzn-s3-demo-bucket",
"S3BucketFolder":"amzn-s3-demo-bucket-folder",
"ErrorRetryDuration":57,
"MaxFileSize":100,
"MaxRetryCount": 10,
"IAMAuthEnabled":false}‘
```
ここでは、CLI `--server-name` オプションで、Neptune クラスター ライター エンドポイントのサーバ名を指定します。または、Neptune ライターインスタンス エンドポイントのサーバー名を指定することもできます。
`--neptune-settings` オプションリクエストパラメータは次のとおりです。
+ `ServiceAccessRoleArn` – (必須) Neptune ターゲットエンドポイント用に作成したサービスロールの Amazon リソースネーム (ARN)。詳細については、「[ターゲットとして Amazon Neptune にアクセスするための IAM サービスロールの作成](#CHAP_Target.Neptune.ServiceRole)」をご参照ください。
+ `S3BucketName` – (必須) DMS が Neptune ターゲットデータベースへ一括ロードする前に、移行されたグラフデータを .csv ファイルに一時的に保存する S3 バケットの名前。DMS は、これらの .csv ファイルに格納する前に、SQL ソースデータをグラフデータにマッピングします。
+ `S3BucketFolder` – (必須) DMS が `S3BucketName` で指定された S3 バケットに移行されたグラフデータを保存するフォルダのパス
+ `ErrorRetryDuration` – (オプション) エラーを発生させる前に、DMS が Neptune ターゲットデータベースに移行されたグラフデータの一括ロードを再試行するまで待機する時間 (ミリ秒)。デフォルトは 250 です。
+ `MaxFileSize` – (オプション) DMS が Neptune ターゲットデータベースにデータを一括ロードする前に、.csv ファイルに保存される移行済みグラフデータの最大サイズ (KB 単位)。デフォルトは 1,048,576 KB (1 GB) です。成功すると、DMS はバケットをクリアし、移行されたグラフデータの次のバッチを保存する準備が整います。
+ `MaxRetryCount` – (オプション) エラーを発生させる前に、DMS が移行されたグラフデータの Neptune ターゲットデータベースへの一括ロード リトライ回数。デフォルトは 5 です。
+ `IAMAuthEnabled` – (オプション) このエンドポイントで IAM 認可を有効にする場合は、このパラメータを `true` に設定し、`ServiceAccessRoleArn` によって指定されたサービスロールに適切な IAM ポリシードキュメントをアタッチします。デフォルトは `false` です。
## ターゲットとして Amazon Neptune にアクセスするための IAM サービスロールの作成
ターゲットとして Neptune にアクセスするには、IAM を使用してサービスロールを作成します。Neptune エンドポイントの設定に応じて、以下で説明する IAM ポリシーと信頼ドキュメントの一部またはすべてをこのロールにアタッチします。Neptune エンドポイントを作成するときに、このサービスロールの ARN を指定します。これにより、 AWS DMS と Amazon Neptune は Neptune とそれに関連付けられた Amazon S3 バケットの両方にアクセスするためのアクセス許可を引き受けることができます。
Neptune エンドポイント設定で、`NeptuneSettings` の `IAMAuthEnabled` パラメータを `true` に設定した場合は、サービスロールに次のようなような IAM ポリシーをアタッチします。`IAMAuthEnabled` を `false` に設定すると、このポリシーを無視できます。
```
// Policy to access Neptune
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "neptune-db:*",
"Resource": "arn:aws:neptune-db:us-east-1:123456789012:cluster-CLG7H7FHK54AZGHEH6MNS55JKM/*"
}
]
}
```
前述の IAM ポリシーは、`Resource` で指定された Neptune ターゲットクラスターへのフルアクセスを許可します。
サービスロールに次のような IAM ポリシーをアタッチします。このポリシーにより、DMS は、移行したグラフデータを Neptune ターゲットデータベースに一括ロードするために作成した S3 バケットに一時的に保存できます。
```
//Policy to access S3 bucket
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ListObjectsInBucket0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": ["s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
},
{
"Sid": "ListObjectsInBucket1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
}
]
}
```
前述の IAM ポリシーでは、Neptune ターゲット用に作成された S3 バケット (`arn:aws:s3:::amzn-s3-demo-bucket`) の内容をアカウントからクエリできます。また、アカウントはすべてのバケットファイルとフォルダ (`arn:aws:s3:::amzn-s3-demo-bucket/`) の内容を完全に操作できます。
信頼関係を編集し、次の IAM ロールをサービスロールにアタッチして、 AWS DMS と Amazon Neptune データベースサービスの両方がロールを引き受けることを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "neptune",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Neptune ターゲット エンドポイントにこのサービスロールを指定する方法については、「[ターゲットとしての Amazon Neptune エンドポイント設定の指定](#CHAP_Target.Neptune.EndpointSettings)」をご参照ください。
## ターゲットとしての Amazon Neptune 用の Gremlin および R2RML を使用したグラフ マッピングルールの指定
作成するグラフ マッピングルールは、SQL リレーショナル データベースソースから抽出されたデータを Neptune データベース クラスター ターゲットにロードする方法を指定します。これらのマッピングルールの形式は、ルールが Apache TinkerPop Gremlin を使用してプロパティグラフデータをロードするか、R2RML を使用してリソース記述フレームワーク (RDF) データをロードするかによって異なります。以下で、これらの形式に関する情報と詳細を確認できます。
これらのマッピングルールは、コンソールまたは DMS API を使用して移行タスクを作成するときに指定できます。
コンソールを使用して、**[Create database migration task]** (データベース移行タスクの作成) ページで**[Graph mapping rules]** (グラフマッピングのルール) を使用してこれらのマッピングルールを指定します。[**グラフマッピングルール**] では、付属のエディタを使用して直接マッピングルールを入力および編集できます。または、適切なグラフマッピング形式のマッピングルールを含むファイルを参照することもできます。
API を使用して、`TaskData` API コールの `CreateReplicationTask` リクエストパラメータを使用してこれらのオプションを指定します。`TaskData` に、適切なグラフマッピング形式のマッピングルールを含むファイルのパスを設定します。
### Gremlin を用いたプロパティグラフデータ生成のためのグラフマッピングルール
Gremlin を使用してプロパティグラフデータを生成し、ソースデータから生成される各グラフエンティティのマッピングルールを使用する JSON オブジェクトを指定します。この JSON の形式は、Amazon Neptune の一括ロード用に定義されています。次のテンプレートは、このオブジェクトの各ルールがどのようになるかを示しています。
```
{
"rules": [
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"vertex_definitions": [
{
"vertex_id_template": "{col1}",
"vertex_label": "(the vertex to create)",
"vertex_definition_id": "(an identifier for this vertex)",
"vertex_properties": [
{
"property_name": "(name of the property)",
"property_value_template": "{col2} or text",
"property_value_type": "(data type of the property)"
}
]
}
]
},
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{col1}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"to_vertex": {
"vertex_id_template": "{col3}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"edge_id_template": {
"label": "(the edge label to add)",
"template": "{col1}_{col3}"
},
"edge_properties":[
{
"property_name": "(the property to add)",
"property_value_template": "{col4} or text",
"property_value_type": "(data type like String, int, double)"
}
]
}
]
}
]
}
```
頂点ラベルが存在することは、頂点がここに作成されていることを意味します。頂点ラベルがない場合は、頂点が別のソースによって作成され、この定義では頂点プロパティだけが追加されることを意味します。必要な数の頂点定義とエッジ定義を指定して、リレーショナルデータベースソース全体のマッピングを指定します。
次に、`employee` テーブルのルール例を示します。
```
{
"rules": [
{
"rule_id": "1",
"rule_name": "vertex_mapping_rule_from_nodes",
"table_name": "nodes",
"vertex_definitions": [
{
"vertex_id_template": "{emp_id}",
"vertex_label": "employee",
"vertex_definition_id": "1",
"vertex_properties": [
{
"property_name": "name",
"property_value_template": "{emp_name}",
"property_value_type": "String"
}
]
}
]
},
{
"rule_id": "2",
"rule_name": "edge_mapping_rule_from_emp",
"table_name": "nodes",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{emp_id}",
"vertex_definition_id": "1"
},
"to_vertex": {
"vertex_id_template": "{mgr_id}",
"vertex_definition_id": "1"
},
"edge_id_template": {
"label": "reportsTo",
"template": "{emp_id}_{mgr_id}"
},
"edge_properties":[
{
"property_name": "team",
"property_value_template": "{team}",
"property_value_type": "String"
}
]
}
]
}
]
}
```
ここでは、頂点とエッジの定義は、従業員 ID (`EmpID`) を持つ `employee` ノードとマネージャ ID (`managerId`) を持つ `employee` ノードからのレポート関係をマッピングします。
Gremlin JSON を使用したグラフ マッピングルールの作成の詳細については、*Amazon Neptune ユーザーガイド*の「[Gremlin ロードデータ形式](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html)」をご参照ください。
### RDF/SPARQL データ生成のためのグラフマッピングルール
SPARQL を使用してクエリする RDF データをロードする場合は、R2RML にグラフマッピングルールを記述します。R2RML は、リレーショナルデータを RDF にマッピングするための標準の W3C 言語です。R2RML ファイルで、*トリプルマップ* (以下の `<#TriplesMap1>` など) は、論理テーブルの各行を 0 個以上の RDF トリプルに変換するルールを指定します。*サブジェクトマップ* (以下の `rr:subjectMap` のいずれか) は、トリプルマップによって生成された RDF トリプルのサブジェクトを生成するためのルールを指定します。*述語オブジェクトマップ* (以下の `rr:predicateObjectMap` のいずれか) は、論理テーブルの論理テーブル行ごとに 1 つ以上の述語オブジェクトのペアを作成する関数です。
`nodes` テーブルの簡単な例を次に示します。
```
@prefix rr: .
@prefix ex: .
<#TriplesMap1>
rr:logicalTable [ rr:tableName "nodes" ];
rr:subjectMap [
rr:template "http://data.example.com/employee/{id}";
rr:class ex:Employee;
];
rr:predicateObjectMap [
rr:predicate ex:name;
rr:objectMap [ rr:column "label" ];
]
```
前の例では、マッピングは、従業員のテーブルからマッピングされたグラフノードを定義します。
`Student` テーブルの別の簡単な例を次に示します。
```
@prefix rr: .
@prefix ex: .
@prefix foaf: .
@prefix xsd: .
<#TriplesMap2>
rr:logicalTable [ rr:tableName "Student" ];
rr:subjectMap [ rr:template "http://example.com/{ID}{Name}";
rr:class foaf:Person ];
rr:predicateObjectMap [
rr:predicate ex:id ;
rr:objectMap [ rr:column "ID";
rr:datatype xsd:integer ]
];
rr:predicateObjectMap [
rr:predicate foaf:name ;
rr:objectMap [ rr:column "Name" ]
].
```
前の例では、マッピングは、`Student` テーブル内の人物間の友だち関係をマッピングするグラフノードを定義します。
SPARQL R2RML を使用したグラフマッピングルールの作成の詳細については、W3C 仕様の「[R2RML: RDB から RDF へのマッピング言語](https://www.w3.org/TR/r2rml/)」をご参照ください。
## ターゲットとしての Amazon Neptune への Gremlin および R2RML 移行のデータ型
AWS DMS は、SQL ソースエンドポイントから Neptune ターゲットへのデータ型マッピングを 2 つの方法のいずれかで実行します。どちらの方法を使用するかは、Neptune データベースのロードに使用しているグラフマッピング形式によって異なります。
+ 移行データの JSON 形式を使用する、Apache TinkerPop Gremlin。
+ 移行データの R2RML 形式を使用する W3C の SPARQL。
これら 2 つのグラフマッピング形式の詳細については、「[ターゲットとしての Amazon Neptune 用の Gremlin および R2RML を使用したグラフ マッピングルールの指定](#CHAP_Target.Neptune.GraphMapping)」をご参照ください。
次に、各形式のデータ型マッピングの説明を示します。
### SQL ソースから Gremlin ターゲットへのデータ型マッピング
次の表に、SQL ソースから Gremlin 形式のターゲットへのデータ型マッピングを示します。
AWS DMS は、リストにない SQL ソースデータ型を Gremlin にマッピングします`String`。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Neptune.html)
Neptune を読み込むための Gremlin データ型の詳細については、*Neptune ユーザーガイド*の「[Gremlin データ型](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes)」をご参照ください。
### SQL ソースから R2RML (RDF) ターゲットへのデータ型マッピング
次の表に、SQL ソースから R2RML 形式のターゲットへのデータ型マッピングを示します。
RDF literal. AWS DMS maps any unlisted SQL source data type to an RDF literal を除き、リストされているすべての RDF データ型では大文字と小文字が区別されます。
*RDF リテラル*は、さまざまなリテラル辞書形式およびデータ型の 1 つです。詳細については、W3C 仕様*リソース記述フレームワーク (RDF): 概念と抽象構文*の「[RDF リテラル](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal)」をご参照ください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Neptune.html)
Neptune をロードするための RDF データ型と SQL ソースデータ型へのマッピングの詳細については、W3C 仕様*R2RML: RDB から RDF マッピング言語*の「[データ型の変換](https://www.w3.org/TR/r2rml/#datatype-conversions)」をご参照ください。
## ターゲットとしての Amazon Neptune の使用における制限
ターゲットとして Neptuneを使用する場合、以下の制限が適用されます。
+ AWS DMS は現在、Neptune ターゲットへの移行にのみ全ロードタスクをサポートしています。Neptune ターゲットへの変更データ キャプチャ (CDC) の移行はサポートされていません。
+ 移行タスクをスタートする前に、次の例のように、ターゲット Neptune データベースで、すべてのデータが手動でクリアされていることを確認してください。
グラフ内のすべてのデータ (頂点とエッジ) をドロップするには、次の Gremlin コマンドを実行します。
```
gremlin> g.V().drop().iterate()
```
`'customer'` ラベルのある頂点をドロップするには、次の Gremlin コマンドを実行します。
```
gremlin> g.V().hasLabel('customer').drop()
```
**注記**
大きなデータセットをドロップするには時間がかかる場合があります。`limit(1000)` などの制限を使用して、`drop()` を反復処理することができます。
`'rated'` ラベルのあるエッジをドロップするには、以下の Gremlin コマンドを実行します。
```
gremlin> g.E().hasLabel('rated').drop()
```
**注記**
大きなデータセットをドロップするには時間がかかる場合があります。`limit(1000)` などの制限を使用して、`drop()` を反復処理することができます。
+ DMS API オペレーション `DescribeTableStatistics` は、Neptune グラフデータ構造の性質上、特定のテーブルについて不正確な結果を返すことがあります。
移行中、 は各ソーステーブル AWS DMS をスキャンし、グラフマッピングを使用してソースデータを Neptune グラフに変換します。変換されたデータは、まずターゲットエンドポイントに指定された S3 バケットフォルダに保存されます。ソースがスキャンされ、この中間の S3 データが正常に生成された場合、`DescribeTableStatistics` はデータが Neptune ターゲットデータベースに正常にロードされたと見なします。しかし、これは常に正しいとは限りません。特定のテーブルのデータが正しくロードされたことを確認するには、そのテーブルの移行の両端の `count()` の戻り値を比較します。
次の例では、 はソースデータベースから`customer`テーブルを AWS DMS ロードし、ターゲット Neptune データベースグラフ`'customer'`に ラベルが割り当てられます。このラベルがターゲットデータベースに書き込まれることを確認できます。これを行うには、ソースデータベースから使用可能な `customer` 行の数と、タスクの完了後に Neptune ターゲットデータベースにロードされた `'customer'` ラベル付きの行の数を比較します。
SQL を使用してソースデータベースから使用可能な customer 行の数を取得するには、次のコマンドを実行します。
```
select count(*) from customer;
```
Gremlin を使用してターゲットデータベースグラフにロードされた `'customer'` ラベル付きの行の数を取得するには、次のコマンドを実行します。
```
gremlin> g.V().hasLabel('customer').count()
```
+ 現在、1 つのテーブルの読み込みに失敗すると、タスク全体が失敗します。リレーショナル データベースターゲットとは異なり、Neptune のデータは高度に接続されているため、多くの場合、タスクを再開することは不可能です。このタイプのデータロードの失敗のためにタスクが正常に再開できない場合は、ロードに失敗したテーブルをロードする新しいタスクを作成します。この新しいタスクを実行する前に、部分的にロードされたテーブルを Neptune ターゲットから手動でクリアします。
**注記**
障害が回復可能な場合 (ネットワーク転送エラーなど)、Neptune ターゲットへの移行に失敗したタスクを再開できます。
+ AWS DMS は R2RML のほとんどの標準をサポートしています。ただし、逆式、結合、ビューなど、特定の R2RML 標準 AWS DMS はサポートされていません。R2RML ビューの回避策は、ソースデータベースに対応するカスタム SQL ビューを作成することです。移行タスクで、テーブルマッピングを使用してビューを入力として選択します。次に、ビューをテーブルにマップすると、R2RML によって消費され、グラフデータが生成されます。
+ サポートされていない SQL データ型を使用してソースデータを移行すると、結果のターゲットデータの精度が低下する可能性があります。詳細については、「[ターゲットとしての Amazon Neptune への Gremlin および R2RML 移行のデータ型](#CHAP_Target.Neptune.DataTypes)」を参照してください。
+ AWS DMS は、Neptune ターゲットへの LOB データの移行をサポートしていません。
# のターゲットとしての Redis OSS の使用 AWS Database Migration Service
Redis OSS は、オープンソースのインメモリ データ構造ストアで、データベース、キャッシュ、メッセージブローカーとして使用されます。データ インメモリを管理すると、読み取りまたは書き込みオペレーションにかかる時間が 1 msec 未満になり、毎秒数億のオペレーションが実行される可能性があります。インメモリデータストアとして、Redis OSS は、ミリ秒未満の応答時間を必要とする最も要求の厳しいアプリケーションの電源となります。
を使用すると AWS DMS、最小限のダウンタイムで、サポートされているソースデータベースからターゲット Redis OSS データストアにデータを移行できます。Redis OSS の詳細については、「[Redis OSS ドキュメント](https://redis.io/documentation)」をご参照ください。
オンプレミス Redis OSS に加えて、 は以下 AWS Database Migration Service をサポートしています。
+ ターゲットデータストアとしての [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/)。ElastiCache (Redis OSS) は Redis OSS クライアントと連携し、オープンな Redis OSS データ形式を使用してデータを格納します。
+ ターゲットデータストアとしての [Amazon MemoryDB](https://aws.amazon.com/memorydb/)。MemoryDB は Redis OSS と互換であり、今日使用されているすべての Redis OSS データ構造および API、コマンドを使用してアプリケーションを構築できます。
のターゲットとして Redis OSS を使用する方法の詳細については AWS DMS、以下のセクションを参照してください。
**Topics**
+ [のターゲットとして Redis OSS クラスターを使用するための前提条件 AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [のターゲットとして Redis を使用する場合の制限 AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [リレーショナルデータベースまたは非リレーショナルデータベースから Redis OSS ターゲットへのデータ移行](#CHAP_Target.Redis.Migrating)
+ [ターゲットとしての Redis OSS エンドポイント設定の指定](#CHAP_Target.Redis.EndpointSettings)
## のターゲットとして Redis OSS クラスターを使用するための前提条件 AWS DMS
DMS は、スタンドアロン構成で、またはデータが複数のノードにわたって自動的に*シャード*される Redis OSS クラスターとしてオンプレミス Redis OSS ターゲットに対応します。シャーディングとは、複数のサーバーまたはノードに分散されるシャードと呼ばれる小さなチャンクにデータを分離するプロセスです。実際、シャードは総データ セットのサブセットを含むデータ パーティションであり、全体的なワークロードのスライスを提供します。
Redis OSS はキー値 NoSQL データ ストアであるため、ソースがリレーショナルデータベースである場合に使用する Redis OSS キーの命名規則は、**schema-name.table-name.primary-key** です。Redis OSS では、キーと値に特殊文字 % を含めることはできません。それ以外の場合、DMS はレコードをスキップします。
**注記**
ElastiCache (Redis OSS) をターゲットとして使用している場合、DMS は*クラスターモードの有効化*構成のみに対応します。ElastiCache (Redis OSS) バージョン 6.x 以降を使用してクラスターモードが有効になっているターゲットデータストアを作成する方法の詳細については、「*Amazon ElastiCache (Redis OSS) ユーザーガイド*」の「[Getting started](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html)」を参照してください。
データベースの移行を開始する前に、次の条件を使用して Redis OSS クラスターを起動します。
+ クラスターに 1 つ以上のシャードがあります。
+ ElastiCache (Redis OSS) ターゲットを使用している場合は、クラスターが IAM ロールベースのアクセス制御を使用していないことを確認してください。代わりに、Redis OSS Auth を使用してユーザーを認証します。
+ マルチ AZ (アベイラビリティーゾーン) を有効にします。
+ データベースから移行されるデータに適合するのに十分なメモリがクラスターにあることを確認します。
+ 最初の移行タスクをスタートする前に、ターゲット Redis OSS クラスターがすべてのデータからクリアされていることを確認してください。
クラスター構成を作成する前に、データ移行のセキュリティ要件を決定する必要があります。DMS は、暗号化構成に関係なく、ターゲット レプリケーション グループへの移行をサポートします。ただし、暗号化を有効または無効にできるのは、クラスター構成を作成するときに限られます。
## のターゲットとして Redis を使用する場合の制限 AWS Database Migration Service
ターゲットとして Redis OSS を使用する場合、以下の制限が適用されます。
+ Redis OSS はキー値 no-sql データストアであるため、ソースがリレーショナルデータベースである場合に使用する Redis OSS キー命名規則は `schema-name.table-name.primary-key` になります。
+ Redis OSS では、キー値に特殊文字 `%` を含めることはできません。それ以外の場合、DMS はレコードをスキップします。
+ DMS では、`%` 文字を含む行は移行されません。
+ DMS では、フィールド名に `%` 文字が含まれているフィールドは移行されません。
+ 完全 LOB モードはサポートされていません。
+ ElastiCache (Redis OSS) をターゲットとして使用する場合、Private Certificate Authority (CA) はサポートされません。
+ AWS DMS ターゲットエンドポイントとして Redis を使用する場合、 は埋め込み`'\0'`文字を含むソースデータをサポートしていません。埋め込み`'\0'`文字を含むデータは、最初の`'\0'`文字で切り捨てられます。
## リレーショナルデータベースまたは非リレーショナルデータベースから Redis OSS ターゲットへのデータ移行
任意のソース SQL または NoSQL データストアから Redis OSS ターゲットに直接データを移行できます。Redis OSS ターゲットへの移行の設定とスタートは、DMS コンソールまたは API を使用した全ロードと変更データ キャプチャの移行と同様です。Redis OSS ターゲットへのデータベース移行を実行するには、次の操作を行います。
+ 移行のすべてのプロセスを実行するレプリケーション インスタンスを作成します。詳細については、「[レプリケーション インスタンスの作成](CHAP_ReplicationInstance.Creating.md)」をご参照ください。
+ ソースエンドポイントを指定します。詳細については、「[ソースおよびターゲットエンドポイントの作成](CHAP_Endpoints.Creating.md)」をご参照ください。
+ クラスターの DNS 名とポート番号を見つけます。
+ SSL 接続を確認するために使用できる証明書バンドルをダウンロードします。
+ 次の説明に従って、ターゲット エンドポイントを指定します。
+ 使用するテーブルとレプリケーション プロセスを定義するタスクまたはタスクセットを作成します。詳細については、「[[Creating a task] (タスクの作成)](CHAP_Tasks.Creating.md)」をご参照ください。
+ ソースデータベースからターゲット クラスターにデータを移行します。
データベースの移行は、次の 2 つのいずれかの方法で開始します：
1. AWS DMS コンソールを選択し、そこで各ステップを実行できます。
1. AWS Command Line Interface () を使用できますAWS CLI。で CLI を使用する方法の詳細については AWS DMS、「」の[AWS CLIAWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)「」を参照してください。
**クラスターの DNS 名とポート番号を見つけるには**
+ 次の AWS CLI コマンドを使用して、 `replication-group-id`にレプリケーショングループの名前を指定します。
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
ここで、出力は `Address` 属性では DNS 名、クラスター内のプライマリノードの`Port` 属性にポート番号を表示します。
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
MemoryDB をターゲットとして使用する場合は、以下の AWS CLI コマンドを使用して Redis OSS クラスターにエンドポイントアドレスを提供します。
```
aws memorydb describe-clusters --clusterid clusterid
```
**SSL 接続を確認するために使用できる証明書バンドルをダウンロードします。**
+ コマンドラインで、以下の `wget` コマンドを入力します。Wget は、インターネットからファイルをダウンロードするために使用される無料の GNU コマンドライン ユーティリティツールです。
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
ここで、 は、指定した S3 バケットと、それが提供する rds-combined-ca-bundle.pem ファイルにアクセスするために必要なリージョンの Amazon S3 ドメイン`aws-api-domain`を完了します。 AWS rds-combined-ca-bundle
**AWS DMS コンソールを使用してターゲットエンドポイントを作成するには**
このエンドポイントは、既に実行中の Redis OSS ターゲット用です。
+ コンソールで、ナビゲーションペインから **[Endpoints]** (エンドポイント) を選択し、次に **[Create Endpoint]** (エンドポイントの作成) を選択します。次の表で設定について説明します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Redis.html)
エンドポイントのすべての情報を入力したら、 AWS DMS は、データベース移行中に使用する Redis OSS ターゲットエンドポイントを作成します。
移行タスクの作成とデータベース移行のスタートについては、「[[Creating a task] (タスクの作成)](CHAP_Tasks.Creating.md)」をご参照ください。
## ターゲットとしての Redis OSS エンドポイント設定の指定
ターゲットエンドポイントを作成または変更するには、コンソール、`CreateEndpoint` または `ModifyEndpoint` API オペレーションを使用します。
AWS DMS コンソールの Redis OSS ターゲットの場合は、エンドポイント**の作成またはエンドポイント****コンソールの変更ページでエンドポイント****固有の設定**を指定します。
`CreateEndpoint` と `ModifyEndpoint`API オペレーションを使用する際、`RedisSettings` オプションのリクエストパラメータを指定する。次の例では、 AWS CLIを使用してこの操作を行う方法を示しています。
```
aws dms create-endpoint --endpoint-identifier my-redis-target
--endpoint-type target --engine-name redis --redis-settings
'{"ServerName":"sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com","Port":6379,"AuthType":"auth-token",
"SslSecurityProtocol":"ssl-encryption", "AuthPassword":"notanactualpassword"}'
{
"Endpoint": {
"EndpointIdentifier": "my-redis-target",
"EndpointType": "TARGET",
"EngineName": "redis",
"EngineDisplayName": "Redis",
"TransferFiles": false,
"ReceiveTransferredFiles": false,
"Status": "active",
"KmsKeyId": "arn:aws:kms:us-east-1:999999999999:key/x-b188188x",
"EndpointArn": "arn:aws:dms:us-east-1:555555555555:endpoint:ABCDEFGHIJKLMONOPQRSTUVWXYZ",
"SslMode": "none",
"RedisSettings": {
"ServerName": "sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com",
"Port": 6379,
"SslSecurityProtocol": "ssl-encryption",
"AuthType": "auth-token"
}
}
}
```
`--redis-settings`パラメータは次のとおりです:
+ `ServerName` — (必須) タイプ `string` で、データの移行先となる Redis OSS クラスターを指定し、同じ VPC に存在します。
+ `Port`— (必須) タイプ `number` で、エンドポイントへのアクセスに使用されるポート値。
+ `SslSecurityProtocol`— (オプション) 有効な値は `plaintext` と `ssl-encryption` です。デフォルトは `ssl-encryption` です。
`plaintext` オプションは、エンドポイントとデータベース間のトラフィックに Transport Layer Security (TLS) 暗号化を提供しません。
`ssl-encryption` を使用して、暗号化された接続を作成します。`ssl-encryption` はサーバーの証明書を検証するために SSL 認定権限 (CA) ARN を必要としませんが、オプションで `SslCaCertificateArn` 設定を使用して特定可能です。認定権限 ARN が指定されていない場合、DMS は Amazon ルート CA を使用します。
オンプレミスの Redis OSS ターゲットを使用する場合、`SslCaCertificateArn` を使用して公開またはPrivate Certificate Authority (CA) を DMS にインポートし、サーバー認証用にその ARN を指定します。ElastiCache (Redis OSS) をターゲットとして使用する場合、プライベート CA はサポートされません。
+ `AuthType` — (必須) Redis OSS に接続するときに実行する認証のタイプを示します。有効な値は、`none`、`auth-token`、および `auth-role` です。
`auth-token` オプションには「*[AuthPassword]* (認証パスワード)」の入力が必要ですが、一方、`auth-role` オプションには必要「*[AuthUserName]* (認証ユーザー名)」と「*[AuthPassword]* (認証パスワード)」を入力します。
# のターゲットとしての Babelfish の使用 AWS Database Migration Service
を使用して、Microsoft SQL Server ソースデータベースから Babelfish ターゲットにデータを移行できます AWS Database Migration Service。
Aurora 用の Babelfish PostgreSQL は、Microsoft SQL Server クライアントからデータベース接続を受け入れる機能を使用して Amazon Aurora PostgreSQL 互換エディションデータベースを拡張します。これにより、SQL Server 向けに構築されたアプリケーションは、従来の移行と比較してほとんどコードを変更することなく、データベースドライバーを変更せずに、Aurora PostgreSQL と直接連携できるようになります。
がターゲットとして AWS DMS サポートする Babelfish のバージョンについては、「」を参照してください[のターゲット AWS DMS](CHAP_Introduction.Targets.md)。Aurora PostgreSQL 上の Babelfish の以前のバージョンの場合は、 Babelfish エンドポイントを使用する前にアップグレードする必要があります。
**注記**
データを Babelfish に移行するには、Aurora PostgreSQL ターゲットエンドポイントの使用をお勧めします。詳細については、「[ターゲットとしての Babelfish for Aurora PostgreSQL の使用](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish)」を参照してください。
Babelfish をデータベースエンドポイントとして使用する方法の詳細については、「*Amazon Aurora のユーザーガイド*」の「[Babelfish for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)」を参照してください。
## のターゲットとして Babelfish を使用するための前提条件 AWS DMS
が適切なデータ型とテーブルメタデータ AWS DMS を使用していることを確認するには、データを移行する前にテーブルを作成する必要があります。移行を実行する前にターゲットにテーブルを作成しない場合は、誤ったデータ型とアクセス許可を持つテーブルを作成する AWS DMS 可能性があります。たとえば、 は代わりにタイムスタンプ列を binary(8) として AWS DMS 作成し、予想されるタイムスタンプ/ローバージョン機能を提供しません。
**移行前にテーブルを準備して作成するには**
1. 一意の制約、プライマリキー、またはデフォルト制約を含む create table DDL ステートメントを実行します。
外部キー制約、ビュー、ストアドプロシージャ、関数、トリガーなどのオブジェクトの DDL ステートメントは含めないでください。上記はソースデータベースを移行した後に適用できます。
1. テーブルのアイデンティティ列、計算列、または rowversion や timestamp などのデータ型を含む列を特定します。次に、移行タスクを実行する際の既知の問題に対処するために必要な変換ルールを作成します。詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照してください。
1. Babelfish がサポートしていないデータ型の列を特定します。次に、サポートされているデータ型を使用するようにターゲットテーブル内の影響を受ける列を変更するか、移行タスク中にこのような列を削除する変換ルールを作成します。詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照してください。
次の表は、Babelfish でサポートされていないソースデータ型と、それに対して使用することが推奨されるターゲットでのデータ型を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Babelfish.html)
**ソースの Aurora PostgreSQL Serverless V2 データベースの Aurora キャパシティユニット (ACU) レベルを設定するには**
最小 ACU 値を設定することで、 AWS DMS 移行タスクを実行する前にパフォーマンスを向上させることができます。
+ **[Severless v2 キャパシティ設定]** ウィンドウで、**[最小 ACU]** を **2**、または Aurora DB クラスターに適切なレベルに設定します。
詳細については、「**Amazon Aurora ユーザーガイド」の「[Aurora クラスターの Aurora Serverless v2 での容量範囲の選択](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html)」を参照してください。
AWS DMS 移行タスクを実行した後、ACUs の最小値を Aurora PostgreSQL Serverless V2 ソースデータベースの妥当なレベルにリセットできます。
## のターゲットとして Babelfish を使用する場合のセキュリティ要件 AWS Database Migration Service
以下では、Babelfish ターゲット AWS DMS で を使用するためのセキュリティ要件について説明します。
+ データベースの作成に使用される管理者ユーザー名 (Admin ユーザー)
+ PSQL ログインと、十分な SELECT、INSERT、UPDATE、DELETE、および REFERENCES アクセス権限を持つユーザー
## のターゲットとして Babelfish を使用するためのユーザーアクセス許可 AWS DMS
**重要**
セキュリティ上の理由から、データ移行に使用するユーザーアカウントは、ターゲットとして使用する Babelfish データベースに登録されているユーザーである必要があります。
Babelfish ターゲットエンドポイントでは、 AWS DMS 移行を実行するための最低限のユーザーのアクセス権限が必要です。
**ログインと低特権の Transact-SQL (T-SQL) ユーザーを作成するには**
1. サーバーに接続する際に使用するログイン名とパスワードを作成します。
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Babelfish クラスターの仮想データベースを作成します。
```
CREATE DATABASE my_database;
GO
```
1. ターゲットデータベースの T-SQL ユーザーを作成します。
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Babelfish データベース内の各テーブルごとにテーブルに対するアクセス権限を付与します。
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## のターゲットとしての Babelfish の使用に関する制限 AWS Database Migration Service
Babelfish データベースを AWS DMSのターゲットとして使用する場合、次の制限が適用されます。
+ テーブル作成モードについては、**[何もしない]** のみがサポートされています。
+ ROWVERSION データ型には、移行タスク中にテーブルから列名を削除するテーブルマッピングルールが必要です。
+ sql\$1variant データ型はサポートされていません。
+ 完全 LOB モードはサポートされています。SQL Server をソースエンドポイントとして使用する場合、LOB をターゲットエンドポイントに移行するために SQL Server エンドポイント接続属性設定 `ForceFullLob=True` を設定する必要があります。
+ レプリケーションタスクの設定には次の制限があります。
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Babelfish の TIME (7)、DATETIME2 (7)、DATETIMEOFFSET (7) のデータ型では、時刻の秒部分の精度値が 6 桁に制限されます。上記のデータ型を使用する際は、ターゲットテーブルの精度値を 6 に設定することを検討します。Babelfish バージョン 2.2.0 以降では、TIME (7) と DATETIME2 (7) を使用すると、精度の 7 桁目は常にゼロになります。
+ DO\$1NOTHING モードでは、DMS はテーブルが既に存在するかどうかを確認します。テーブルがターゲットスキーマに存在しない場合、DMS はソースのテーブル定義に基づいてテーブルを作成し、ユーザー定義のデータ型を基本データ型にマップします。
+ Babelfish ターゲットへの移行 AWS DMS タスクは、ROWVERSION または TIMESTAMP データ型を使用する列を持つテーブルをサポートしていません。転送プロセス中にテーブルから列名を削除するテーブルマッピングルールを使用できます。次の変換ルールの例では、ソースの `Actor` という名前のテーブルを変換して、ターゲットの `Actor` テーブル内の先頭文字が `col` であるすべての列を削除します。
```
{
"rules": [{
"rule-type": "selection",is
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "remove-column",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "Actor",
"column-name": "col%"
}
}]
}
```
+ アイデンティティ列または計算列を含むテーブルの場合、ターゲットテーブルで Categories などの大文字と小文字が混合した名前が使用されている場合、DMS タスクのためにテーブル名を小文字に変換する変換ルールアクションを作成する必要があります。次の例は、変換ルールアクションを作成する方法を示しています。 AWS DMS コンソールを使用して**小文字**にします。詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照してください。
![\[Babelfish の変換ルール\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Babelfish バージョン 2.2.0 以前のバージョンの場合、DMS では Babelfish ターゲットエンドポイントにレプリケートできる列の数が 20 列に制限されていました。Babelfish 2.2.0 では、この制限は 100 列に引き上げられています。ただし、Babelfish バージョン 2.4.0 以降では、レプリケートできる列の数がさらに増大しています。SQL Server データベースに対して次のコードサンプルを実行すると、長すぎるテーブルを特定できます。
```
USE myDB;
GO
DECLARE @Babelfish_version_string_limit INT = 8000; -- Use 380 for Babelfish versions before 2.2.0
WITH bfendpoint
AS (
SELECT
[TABLE_SCHEMA]
,[TABLE_NAME]
, COUNT( [COLUMN_NAME] ) AS NumberColumns
, ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) AS InsertIntoCommandLength -- values string
, CASE WHEN ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) -- values string
>= @Babelfish_version_string_limit
THEN 1
ELSE 0
END AS IsTooLong
FROM [INFORMATION_SCHEMA].[COLUMNS]
GROUP BY [TABLE_SCHEMA], [TABLE_NAME]
)
SELECT *
FROM bfendpoint
WHERE IsTooLong = 1
ORDER BY TABLE_SCHEMA, InsertIntoCommandLength DESC, TABLE_NAME
;
```
## ターゲットの Babelfish のデータ型
次の表は、 の使用時にサポートされる Babelfish ターゲットデータ型 AWS DMS と AWS DMS 、データ型からのデフォルトのマッピングを示しています。
AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。
| AWS DMS データ型 | Babelfish のデータ型 |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY(長さ) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC(p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | 列が日付または時刻列の場合、次の操作を行います。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Babelfish.html) 列が日付または時刻列ではない場合、VARCHAR (長さ) を使用します。 |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(長さ) |
| BLOB | VARBINARY(最大) DMS でこのデータ型を使用するには、特定のタスク用に BLOB の使用を有効にする必要がある。DMS は、プライマリキーがあるテーブルでのみ BLOB データ型をサポートする。 |
| CLOB | VARCHAR(max) DMS でこのデータ型を使用するには、特定のタスクで CLOB の使用を有効にする必要がある。 |
| NCLOB | NVARCHAR(最大) DMS でこのデータ型を使用するには、特定のタスクで NCLOB の使用を有効にする必要がある。CDC 中に、DMS はプライマリキーがあるテーブルでのみ NCLOB データ型をサポートする。 |
# のターゲットとしての Amazon Timestream の使用 AWS Database Migration Service
を使用して AWS Database Migration Service 、フルロードと CDC データ移行をサポートしながら、ソースデータベースから Amazon Timestream ターゲットエンドポイントにデータを移行できます。
Amazon Timestream は、大量のデータインジェスト用に構築された、高速でスケーラブルなサーバーレスの時系列データベースサービスです。時系列データは、一定の間隔で収集された一連のデータポイントで、時間の経過とともに変化するイベントの測定に使用します。IoT アプリケーション、DevOps アプリケーション、分析アプリケーションのメトリクスの収集、保存、分析に役立ちます。Timestream にデータを保存すると、データの傾向やパターンをほぼリアルタイムで視覚化して特定できます。Amazon Timestream の詳細については、「Amazon Timestream デベロッパーガイド」の「[Amazon Timestream とは](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html)」を参照してください。**
**Topics**
+ [のターゲットとして Amazon Timestream を使用するための前提条件 AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [マルチスレッド全ロードタスク設定](#CHAP_Target.Timestream.FLTaskSettings)
+ [マルチスレッド CDC ロードタスクの設定](#CHAP_Target.Timestream.CDCTaskSettings)
+ [のターゲットとして Timestream を使用する場合のエンドポイント設定 AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Amazon Timestream ターゲットエンドポイントの作成と変更](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [データを Timestream トピックに移行するためのオブジェクトマッピングの使用](#CHAP_Target.Timestream.ObjectMapping)
+ [のターゲットとして Amazon Timestream を使用する場合の制限 AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## のターゲットとして Amazon Timestream を使用するための前提条件 AWS Database Migration Service
Amazon Timestream を のターゲットとして設定する前に AWS DMS、必ず IAM ロールを作成してください。このロールは AWS DMS 、 が Amazon Timestream に移行するデータにアクセスできるようにする必要があります。Timestream への移行に使用するロールの最低限のアクセス許可は、次の IAM ポリシーに示されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDescribeEndpoints",
"Effect": "Allow",
"Action": [
"timestream:DescribeEndpoints"
],
"Resource": "*"
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"timestream:ListTables",
"timestream:DescribeDatabase"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"timestream:DeleteTable",
"timestream:WriteRecords",
"timestream:UpdateTable",
"timestream:CreateTable"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME/table/TABLE_NAME"
}
]
}
```
------
すべてのテーブルを移行する場合は、上の例の *TABLE\$1NAME* として `*` を使用します。
Timestream をターゲットとして使用する場合は、次の点に注意してください。
+ タイムスタンプが 1 年を超える履歴データを取り込む場合は、 AWS DMS を使用してデータをカンマ区切り値 (csv) 形式で Amazon S3 に書き込むことをお勧めします。次に、Timestream のバッチロードを使用してデータを Timestream に取り込みます。詳細については、「Amazon Timestream デベロッパーガイド」の「[Timestream でのバッチロードの使用](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html)」を参照してください。[https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html)
+ 1 年未満のデータをフルロードで移行する場合は、Timestream テーブルのメモリストア保持期間を最も古いタイムスタンプ以上に設定することをお勧めします。次に、移行が完了したら、テーブルのメモリストア保持期間を編集して希望の値に変更します。例えば、データの最も古いタイムスタンプが 2 か月前である場合、このデータを移行するには、次の操作を行います。
+ Timestream ターゲットテーブルのメモリストア保持期間を 2 か月に設定します。
+ を使用してデータ移行を開始します AWS DMS。
+ データ移行が完了したら、ターゲット Timestream テーブルの保持期間を希望の値に変更します。
以下のページの情報を使用して、移行前にメモリストアのコストを見積もることをお勧めします。
+ [Amazon Timestream の料金](https://aws.amazon.com/timestream/pricing)
+ [AWS 料金計算ツール](https://calculator.aws/#/addService)
+ CDC データ移行では、取り込まれたデータがメモリストア保持期間の範囲内に収まるように、ターゲットテーブルのメモリストア保持期間を設定することをお勧めします。詳細については、「Amazon Timestream デベロッパーガイド」の「[書き込みのベストプラクティス](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html)」を参照してください。[https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html)
## マルチスレッド全ロードタスク設定
データ転送速度を向上させるために、 は、以下のタスク設定で Timestream ターゲットエンドポイントへのマルチスレッド全ロード移行タスク AWS DMS をサポートします。
+ `MaxFullLoadSubTasks` - このオプションを使用して、並列ロードするソーステーブルの最大数を指定します。DMS は、専用のサブタスクを使用して、対応する Amazon Timestream ターゲットテーブルに各テーブルをロードします。デフォルトは 8、最大値は 49 です。
+ `ParallelLoadThreads` – このオプションを使用して、 AWS DMS が各テーブルを Amazon Timestream ターゲットテーブルにロードするために使用するスレッドの数を指定します。Timestream ターゲットの最大値は 32 です。この上限を増やすよう依頼できます。
+ `ParallelLoadBufferSize` – このオプションを使用して、Amazon Timestream ターゲットにデータをロードするために並列ロードスレッドで使用する、バッファ内に保存するレコードの最大数を指定します。デフォルト値は 50 です。最大値は 1000 です。この設定は `ParallelLoadThreads` で使用します。`ParallelLoadBufferSize` は、複数のスレッドがある場合にのみ有効です。
+ `ParallelLoadQueuesPerThread` - このオプションを使用して、各同時スレッドがキューからデータレコードを取り出し、ターゲットのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルトは 1 です。ただし、さまざまなペイロードサイズの Amazon Timestream ターゲットの場合、有効な範囲は 1 スレッドあたり 5～512 キューです。
## マルチスレッド CDC ロードタスクの設定
CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Timestream ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0、最大値は 32 です。
+ `ParallelApplyBufferSize` – 同時スレッドが CDC ロード中に Timestream ターゲットエンドポイントにプッシュするために、各バッファキューに保存するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` – 各スレッドがキューからデータレコードを取り出し、CDC 中に Timestream エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルト値は 1、最大値は 512 です。
## のターゲットとして Timestream を使用する場合のエンドポイント設定 AWS DMS
エンドポイント設定を使用して、追加の接続属性を使用する場合と同じように、Timestream ターゲットデータベースを設定できます。 AWS DMS コンソールを使用するか、`--timestream-settings '{"EndpointSetting": "value", ...}'`JSON 構文で の `create-endpoint` コマンドを使用して[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)、ターゲットエンドポイントを作成するときに設定を指定します。
次の表は、ターゲットとしての Timestream で使用できるエンドポイント設定を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Timestream.html)
## Amazon Timestream ターゲットエンドポイントの作成と変更
IAM ロールを作成し、アクセス許可の最小セットを確立したら、 AWS DMS コンソールを使用するか、JSON 構文で の `create-endpoint` コマンドを使用して [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)Amazon Timestream `--timestream-settings '{"EndpointSetting": "value", ...}'` ターゲットエンドポイントを作成できます。
以下の例は、 AWS CLIを使用して Timestream ターゲットエンドポイントを作成および変更する方法を示しています。
**Timestream ターゲットエンドポイントの作成コマンド**
```
aws dms create-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"DatabaseName":"db_name",
"MagneticDuration": 3,
"CdcInsertsAndUpdates": true,
"EnableMagneticStoreWrites": true,
}
```
**Timestream ターゲットエンドポイントの変更コマンド**
```
aws dms modify-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"MagneticDuration": 3,
}
```
## データを Timestream トピックに移行するためのオブジェクトマッピングの使用
AWS DMS はテーブルマッピングルールを使用して、ソースからターゲットの Timestream トピックにデータをマッピングします。ターゲットトピックにデータをマッピングするために、オブジェクトマッピングと呼ばれるテーブルマッピングルールのタイプを使用します。オブジェクトマッピングを使用して、ソースのデータレコードをどのように Timestream トピックに発行されたデータレコードにマッピングするかを定義します。
Timestream トピックには、パーティションキー以外にプリセット構造はありません。
**注記**
オブジェクトマッピングは必ずしも使用する必要はありません。通常のテーブルマッピングは、さまざまな変換に使用できます。ただし、パーティションキータイプは次のデフォルト動作に従います。
プライマリキーはフルロードのパーティションキーとして使用されます。
並行適用タスク設定を使用しない場合は、`schema.table` が CDC のパーティションキーとして使用されます。
並列適用タスク設定を使用する場合、プライマリキーは CDC のパーティションキーとして使用されます。
オブジェクトマッピングルールを作成するには、`object-mapping` として `rule-type` を指定します。このルールが、使用したいオブジェクトマッピングのタイプを指定します。ルールの構造は次のとおりです。
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "timestream-map",
"rule-action": "map-record-to-record",
"target-table-name": "tablename",
"object-locator": {
"schema-name": "",
"table-name": ""
},
"mapping-parameters": {
"timestream-dimensions": [
"column_name1",
"column_name2"
],
"timestream-timestamp-name": "time_column_name",
"timestream-multi-measure-name": "column_name1or2",
"timestream-hash-measure-name": true or false,
"timestream-memory-duration": x,
"timestream-magnetic-duration": y
}
}
]
}
```
AWS DMS は現在、 `rule-action`パラメータの唯一の有効な値`map-record-to-document`として `map-record-to-record`と をサポートしています。`map-record-to-record` と の`map-record-to-document`値は、`exclude-columns`属性リストの一部として除外されていないレコードに対してデフォルトで AWS DMS 何を行うかを指定します。これらの値は、どのような方法でも属性マッピングに影響しません。
リレーショナルデータベースから Timestream トピックに移行する場合は `map-record-to-record` を使用します。このルールタイプでは、Timestream トピックのパーティションキーとしてリレーショナルデータベースの `taskResourceId.schemaName.tableName` 値を使用し、ソースデータベース内の各列の属性を作成します。を使用する場合`map-record-to-record`、`exclude-columns`属性リストにリストされていないソーステーブルの任意の列に対して、 はターゲットトピックに対応する属性 AWS DMS を作成します。この対応する属性は、そのソース列が属性マッピングで使用されているかどうかにかかわらず作成されます。
`map-record-to-record` を理解するための 1 つの方法は、実際の動作を確認することです。この例では、次の構造とデータを含むリレーショナルデータベースのテーブルの行から始めると想定してください。
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
この情報を `Test` という名前のスキーマから Timestream トピックに移行するには、データをターゲットトピックにマッピングするルールを作成します。以下のルールはマッピングを示しています。
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToTimestream",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Timestream トピックとパーティションキー (この例では `taskResourceId.schemaName.tableName`) を指定した場合、Timestream ターゲットトピックのサンプルデータを使用した結果のレコード形式は次のとおりです。
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## のターゲットとして Amazon Timestream を使用する場合の制限 AWS Database Migration Service
Amazon Timestream をターゲットとして使用する場合は、以下の制限が適用されます。
+ **ディメンションとタイムスタンプ:** Timestream はソースデータ内のディメンションとタイムスタンプを複合プライマリキーのように使用します。また、これらの値を更新することを許可しません。つまり、ソースデータベース内のレコードのタイムスタンプまたはディメンションを変更すると、Timestream データベースは新しいレコードを作成しようとします。したがって、レコードのディメンションまたはタイムスタンプを別の既存のレコードのディメンションまたはタイムスタンプと一致するように変更すると、 は新しいレコードを作成したり、以前の対応するレコードを更新したりする代わりに、他のレコードの値 AWS DMS を更新します。
+ **DDL コマンド:** の現在のリリースでは、 `CREATE TABLE`および `DROP TABLE` DDL コマンド AWS DMS のみがサポートされています。
+ **レコードの制限:** Timestream には、レコードサイズやメジャーサイズなど、レコードに関する制限があります。詳細については、「Amazon Timestream デベロッパーガイド」の「[クォータ](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html)」を参照してください。[https://docs.aws.amazon.com/](https://docs.aws.amazon.com/)
+ **レコードと NULL 値の削除:** Timestream はレコードの削除をサポートしていません。ソースから削除されたレコードの移行をサポートするために、 は Timestream ターゲットデータベースのレコード内の対応するフィールド AWS DMS をクリアします。 は、対応するターゲットレコードのフィールドの値を、数値フィールドの場合は **0**、テキストフィールドの場合は **null**、ブール型フィールドの場合は **false** AWS DMS に変更します。
+ ターゲットとしての Timestream は、リレーショナルデータベース (RDBMS) 以外のソースをサポートしていません。
+ AWS DMS は、次のリージョンのターゲットとして Timestream のみをサポートします。
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (オレゴン)
+ 欧州 (アイルランド)
+ 欧州 (フランクフルト)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ ターゲットとしての Timestream は、`TargetTablePrepMode` を `TRUNCATE_BEFORE_LOAD` に設定することをサポートしていません。この設定で `DROP_AND_CREATE` を使用しないことをお勧めします。
# のターゲットとしての Amazon RDS for Db2 と IBM Db2 LUW の使用 AWS DMS
AWS Database Migration Service () を使用して、Db2 LUW データベースから Amazon RDS for Db2 またはオンプレミス Db2 データベースにデータを移行できますAWS DMS。
がターゲットとして AWS DMS サポートする Db2 LUW のバージョンについては、「」を参照してください[のターゲット AWS DMS](CHAP_Introduction.Targets.md)。
Secure Sockets Layer (SSL) を使用して、Db2 LUW エンドポイントとレプリケーションインスタンスとの接続を暗号化できます。Db2 LUW エンドポイントで SSL を使用する方法の詳細については、「[での SSL の使用 AWS Database Migration Service](CHAP_Security.SSL.md)」を参照してください。
## のターゲットとして Db2 LUW を使用する場合の制限 AWS DMS
Db2 LUW データベースをターゲットとして使用する場合は、次の制限が適用されます AWS DMS。Db2 LUW をソースとして使用する場合の制限については、「[のソースとして Db2 LUW を使用する場合の制限 AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations)」を参照してください。
+ AWS DMS は、ソースが Db2 LUW または Db2 for z/OS の場合にのみ、ターゲットとして Db2 LUW をサポートします。
+ Db2 LUW をターゲットとして使用する場合、フル LOB モードのレプリケーションはサポートされません。
+ Db2 LUW をターゲットとして使用する場合、フルロードフェーズでは XML データ型がサポートされません。これは IBM dbload ユーティリティの制限です。詳細については、*IBM Informix Servers* ドキュメントの「[dbload ユーティリティ](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility)」を参照してください。
+ AWS DMS は、二重引用符 (") に対応する値を持つ BLOB フィールドを切り捨てます。これは IBM dbload ユーティリティの制限です。
+ AWS DMS DMS バージョン 3.5.3 で Db2 LUW ターゲットに移行する場合、 は並列全ロードオプションをサポートしていません。このオプションは、DMS バージョン 3.5.4 以降でのみ使用可能です。
## のターゲットとして Db2 LUW を使用する場合のエンドポイント設定 AWS DMS
エンドポイント設定を使用して、追加の接続属性を使用する場合と同じように、Db2 LUW データベースを設定できます。 AWS DMS コンソールを使用するか、`--ibm-db2-settings '{"EndpointSetting": "value", ...}'`JSON 構文で の `create-endpoint` コマンドを使用して[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)、ターゲットエンドポイントを作成するときに設定を指定します。
次の表は、ターゲットとしての Db2 LUW で使用できるエンドポイント設定を示しています。
| 名前 | 説明 |
| --- | --- |
| `KeepCsvFiles` | true の場合、データのレプリケートに使用された .csv ファイルを Db2 LUW ターゲットに AWS DMS 保存します。DMS は、これらのファイルを分析とトラブルシューティングに使用します。 |
| `LoadTimeout` | DMS が Db2 ターゲットに対して実行するオペレーションを AWS DMS タイムアウトするまでの時間 (ミリ秒単位）。デフォルト値は 1200 (20 分) です。 |
| `MaxFileSize` | Db2 LUW へのデータ転送に使用する .csv ファイルの最大サイズ (KB 単位) を指定します。 |
| `WriteBufferSize` | DMS レプリケーションインスタンスで .csv ファイルをローカルディスクに生成するときに使用するメモリ内ファイル書き込みバッファのサイズ (KB 単位)。デフォルト値は 1024 (1 MB) です。 |