}
```
L'exemple suivant illustre les sections utilisées pour l'expression de condition.
![\[Commencez avec AWS DMS\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Utilisation du mappage d'attribut avec le mappage d'objet
La mappage d'attribut vous permet de spécifier une chaîne modèle, en utilisant les noms de la colonne source pour restructurer les données sur la cible. Aucun formatage n'est effectué, autre que ce qui est spécifié par l'utilisateur dans le modèle.
L'exemple suivant illustre la structure de la base de données source et la structure de cible DynamoDB souhaitée. La structure de la source est illustrée en premier, dans ce cas, une base de données Oracle, puis la structure souhaitée des données dans DynamoDB. L'exemple se termine avec le JSON utilisé pour créer la structure cible souhaitée.
La structure des données Oracle est la suivante :
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Clé primaire | N/A | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
La structure des données DynamoDB est la suivante :
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Clé de partition | Clé de tri | N/A |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
Le JSON suivant illustre le mappage d'objet et le mappage de colonne utilisés pour parvenir à la structure 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}\"}}"
}
]
}
}
]
}
```
Une autre façon d'utiliser le mappage de colonne consiste à utiliser le format DynamoDB comme type de document. L'exemple de code suivant utilise *dynamodb-map* comme `attribute-sub-type` pour la mappage d'attribut.
```
{
"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}"
}
}
}
}
}
}
]
}
}
]
}
```
Au lieu de cela`dynamodb-map`, vous pouvez utiliser le mappage d'attributs `dynamodb-list` as attribute-sub-type for, comme indiqué dans l'exemple suivant.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Exemple 1 : utilisation du mappage d'attribut avec le mappage d'objet
L'exemple suivant fait migrer les données de deux tables de base de données MySQL, *nfl\$1data et *sport\$1team**, vers deux tables DynamoDB appelées et. *NFLTeams*SportTeams** La structure des tables et le JSON utilisés pour mapper les données depuis les tables de base de données MySQL vers les tables DynamoDB sont les suivants :
La structure de la table de base de données MySQL *nfl\$1data* est indiquée ci-dessous :
```
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 | |
+---------------+-------------+------+-----+---------+-------+
```
La structure de la table de base de données MySQL *sport\$1team* est indiquée ci-dessous :
```
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 | |
```
Les règles de mappage de table utilisées pour mapper les deux tables vers les deux tables DynamoDB sont indiquées ci-dessous :
```
{
"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}\"}"
}
]
}
}
]
}
```
L'exemple de sortie pour la table *NFLTeams*DynamoDB est illustré ci-dessous :
```
"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"
}
```
L'exemple de sortie pour la table SportsTeams *DynamoDB* est illustré ci-dessous :
```
{
"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"
}
```
## Types de données cibles pour DynamoDB
Le point de terminaison DynamoDB pour AWS DMS prend en charge la plupart des types de données DynamoDB. Le tableau suivant indique les types de données AWS DMS cibles Amazon pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.
Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Lors de AWS DMS la migration de données à partir de bases de données hétérogènes, nous mappons les types de données de la base de données source à des types de données intermédiaires appelés types de AWS DMS données. Nous mappons ensuite les types de données intermédiaires vers les types de données cibles. Le tableau suivant indique chaque type de AWS DMS données et le type de données auquel il est mappé dans DynamoDB :
| AWS DMS type de données | Type de données DynamoDB |
| --- | --- |
| String | Chaîne |
| WString | String |
| Booléen | Booléen |
| Date | String |
| DateTime | String |
| INT1 | Number |
| INT2 | Number |
| INT4 | Number |
| INT8 | Number |
| Numérique | Number |
| Real4 | Number |
| Real8 | Number |
| UINT1 | Number |
| UINT2 | Number |
| UINT4 | Number |
| UINT8 | Number |
| CLOB | String |
# Utilisation d'Amazon Kinesis Data Streams comme cible pour AWS Database Migration Service
Vous pouvez l'utiliser AWS DMS pour migrer des données vers un flux de données Amazon Kinesis. Les flux de données Amazon Kinesis font partie du service Amazon Kinesis Data Streams. Vous pouvez utiliser des flux de données Kinesis pour collecter et traiter des flux volumineux d’enregistrements de données en temps réel.
Un flux de données Kinesis se compose de partitions. Les *partitions* sont des séquences d'enregistrements de données identifiées de manière unique dans un flux. Pour plus d’informations sur les partitions dans Amazon Kinesis Data Streams, consultez [Partition](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) dans le *Guide du développeur Amazon Kinesis Data Streams*.
AWS Database Migration Service publie des enregistrements dans un flux de données Kinesis à l'aide de JSON. Au cours de la conversion, AWS DMS sérialise chaque enregistrement de la base de données source dans une paire attribut-valeur au format JSON ou un format de message JSON\$1UNFORMATED. Un format de message JSON\$1UNFORMATED est une chaîne JSON à une seule ligne avec un délimiteur de nouvelle ligne. Il permet à Amazon Data Firehose de fournir des données Kinesis à une destination Amazon S3, puis de les interroger à l'aide de différents moteurs de requête, dont Amazon Athena.
Utilisez le mappage d'objet pour migrer vos données de n'importe quelle source de données prise en charge vers un flux cible. Avec le mappage d'objet, vous déterminez la façon de structurer les enregistrements de données dans le flux. Vous définissez également une clé de partition pour chaque table, que Kinesis Data Streams utilise pour regrouper les données dans ses partitions.
AWS DMS définit également plusieurs valeurs de paramètres Kinesis Data Streams. Le coût de création de la table dépend de la quantité de données et du nombre de tables à migrer.
**Note**
L'option **Mode SSL** de la AWS DMS console ou de l'API ne s'applique pas à certains services de streaming de données et NoSQL tels que Kinesis et DynamoDB. Ils sont sécurisés par défaut, ce qui AWS DMS montre que le paramètre du mode SSL est égal à aucun (**mode SSL = aucun**). Vous n’avez pas besoin de fournir de configuration supplémentaire pour que votre point de terminaison utilise le protocole SSL. Par exemple, lorsque Kinesis est utilisé comme point de terminaison cible, il est sécurisé par défaut. Tous les appels d'API adressés à Kinesis utilisent le protocole SSL, il n'est donc pas nécessaire d'ajouter une option SSL supplémentaire sur le AWS DMS terminal. Vous pouvez placer et récupérer des données en toute sécurité via des points de terminaison SSL à l’aide du protocole HTTPS, utilisé par AWS DMS par défaut lors de la connexion à un flux de données Kinesis.
**Paramètres de point de terminaison Kinesis Data Streams**
Lorsque vous utilisez les points de terminaison cibles de Kinesis Data Streams, vous pouvez obtenir les détails des transactions et des contrôles à l'aide de l'option `KinesisSettings` de l'API. AWS DMS
Vous pouvez définir les paramètres de connexion de l’une des manières suivantes :
+ Dans la AWS DMS console, à l'aide des paramètres du point de terminaison.
+ Dans la CLI, en utilisant l'`kinesis-settings`option de la [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)commande.
Dans l’interface CLI, utilisez les paramètres de demande de l’option `kinesis-settings` suivants :
**Note**
La prise en charge des paramètres de point de terminaison `IncludeNullAndEmpty` est disponible dans AWS DMS versions 3.4.1 et ultérieures. Mais la prise en charge des autres paramètres de point de terminaison suivants pour les cibles Kinesis Data Streams est disponible dans AWS DMS.
+ `MessageFormat` : format de sortie pour les enregistrements créés sur le point de terminaison. Le format du message est `JSON` (par défaut) ou `JSON_UNFORMATTED` (une seule ligne sans onglet).
+ `IncludeControlDetails` : affiche des informations de contrôle détaillées pour la définition de table, la définition de colonne et les modifications de table et de colonne dans la sortie du message Kinesis. La valeur par défaut est `false`.
+ `IncludeNullAndEmpty` : inclut les colonnes NULL et vides dans la cible. La valeur par défaut est `false`.
+ `IncludePartitionValue` : affiche la valeur de partition dans la sortie du message Kinesis, sauf si le type de partition est `schema-table-type`. La valeur par défaut est `false`.
+ `IncludeTableAlterOperations` : inclut toutes les opérations DDL (Data Definition Language) qui modifient la table dans les données de contrôle, telles que `rename-table`, `drop-table`, `add-column`, `drop-column` et `rename-column`. La valeur par défaut est `false`.
+ `IncludeTransactionDetails` : fournit des informations détaillées sur les transactions à partir de la base de données source. Ces informations comprennent un horodatage de validation, une position de journal et des valeurs pour `transaction_id`, `previous_transaction_id` et `transaction_record_id `(le décalage d'enregistrement dans une transaction). La valeur par défaut est `false`.
+ `PartitionIncludeSchemaTable` : préfixe les noms de schéma et de table aux valeurs de partition, lorsque le type de partition est `primary-key-type`. Cela augmente la distribution des données entre les fragments Kinesis. Par exemple, supposons qu'un schéma `SysBench` comporte des milliers de tables et que chaque table n'ait qu'une plage limitée pour une clé primaire. Dans ce cas, la même clé primaire est envoyée à partir de milliers de tables vers le même fragment, ce qui provoque une limitation. La valeur par défaut est `false`.
+ `UseLargeIntegerValue`— Utilisez jusqu'à 18 chiffres au lieu de convertir les entiers en doubles, disponible à partir de AWS DMS la version 3.5.4. La valeur par défaut est false.
L’exemple suivant illustre l’option `kinesis-settings` utilisée avec un exemple de commande `create-endpoint` émise à l’aide d’ AWS CLI.
```
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
```
**Paramètres de tâche de chargement complet multithread**
Pour accélérer le transfert, AWS DMS prend en charge le chargement complet multithread vers une instance cible Kinesis Data Streams. DMS prend en charge ce traitement multithread avec des paramètres de tâche, notamment les suivants :
+ `MaxFullLoadSubTasks` : utilisez cette option pour indiquer le nombre maximal de tables sources à charger en parallèle. DMS charge chaque table dans sa table cible Kinesis correspondante à l’aide d’une sous-tâche dédiée. La valeur par défaut est 8 ; la valeur maximale 49.
+ `ParallelLoadThreads`— Utilisez cette option pour spécifier le nombre de threads AWS DMS utilisés pour charger chaque table dans sa table cible Kinesis. La valeur maximale pour une cible Kinesis Data Streams est de 32. Vous pouvez demander une augmentation de cette limite maximale.
+ `ParallelLoadBufferSize` : utilisez cette option pour spécifier le nombre maximal d’enregistrements à stocker dans la mémoire tampon utilisée par les threads de chargement parallèles pour charger les données dans la cible Kinesis. La valeur par défaut est 50. La valeur maximale est 1 000. Utilisez ce paramètre avec `ParallelLoadThreads`. `ParallelLoadBufferSize` est valide uniquement dans le cas de plusieurs threads.
+ `ParallelLoadQueuesPerThread` : utilisez cette option pour spécifier le nombre de files d’attente auxquelles chaque thread simultané accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour la cible. La valeur par défaut est 1. Toutefois, pour les cibles Kinesis de différentes tailles de charge utile, la plage valide est comprise entre 5 et 512 files d’attente par thread.
**Paramètres de tâche de chargement CDC multithread**
Vous pouvez utiliser les paramètres de tâche afin d’améliorer les performances de la capture des données de modification (CDC) pour les points de terminaison cibles de streaming des données en temps réel, comme Kinesis et modifier le comportement de l’appel d’API `PutRecords`. Pour ce faire, vous pouvez spécifier le nombre de threads simultanés, les files d'attente par thread et le nombre d'enregistrements à stocker dans un tampon à l'aide de la tâche `ParallelApply*`. Par exemple, supposons que vous souhaitiez effectuer un chargement CDC et appliquer 128 threads en parallèle. Vous souhaitez également accéder à 64 files d'attente par thread, avec 50 enregistrements stockés par tampon.
Pour améliorer les performances du CDC, AWS DMS prend en charge les paramètres de tâche suivants :
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement CDC pour transférer des enregistrements de données vers un point de terminaison cible Kinesis. La valeur par défaut est zéro (0) et la valeur maximale est 32.
+ `ParallelApplyBufferSize` : spécifie le nombre maximal d’enregistrements à stocker dans chaque file d’attente de mémoire tampon pour que les threads simultanés soient transférés vers un point de terminaison cible Kinesis lors d’un chargement CDC. La valeur par défaut est 100 et la valeur maximale est 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads.
+ `ParallelApplyQueuesPerThread` : spécifie le nombre de files d’attente auxquelles chaque thread accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour un point de terminaison Kinesis pendant la CDC. La valeur par défaut est 1 et la valeur maximale est 512.
Lorsque vous utilisez les paramètres de tâche `ParallelApply*`, la valeur par défaut `partition-key-type` est la valeur `primary-key` de la table, pas `schema-name.table-name`.
## Utilisation d’une image antérieure pour afficher les valeurs d’origine des lignes CDC pour un flux de données Kinesis en tant que cible
Lorsque vous écrivez des mises à jour de CDC sur une cible de diffusion de données comme Kinesis, vous pouvez afficher les valeurs d’origine d’une ligne de base de données source avant de les modifier par une mise à jour. Pour ce faire, AWS DMS remplit une *image antérieure* des événements de mise à jour en fonction des données fournies par le moteur de base de données source.
Différents moteurs de base de données source fournissent différentes quantités d'informations pour une image antérieure :
+ Oracle met uniquement à jour des colonnes si elles changent.
+ PostgreSQL fournit uniquement des données pour les colonnes qui font partie de la clé primaire (modifiée ou non). Pour fournir des données pour toutes les colonnes (modifiées ou non), vous devez définir `REPLICA_IDENTITY` sur `FULL` au lieu de `DEFAULT`. Notez que vous devez choisir la valeur de `REPLICA_IDENTITY` avec soin pour chaque table. Si vous définissez `REPLICA_IDENTITY` sur `FULL`, toutes les valeurs de colonne sont écrites en continu dans la journalisation WAL. Cela peut entraîner des problèmes de performances ou de ressources avec les tables qui sont fréquemment mises à jour.
+ MySQL fournit généralement des données pour toutes les colonnes, à l’exception des types de données BLOB et CLOB (modifiés ou non).
Pour activer avant l'imagerie pour ajouter des valeurs d'origine de la base de données source à la sortie AWS DMS , utilisez le paramètre de tâche `BeforeImageSettings` ou le paramètre `add-before-image-columns`. Ce paramètre applique une règle de transformation de colonne.
`BeforeImageSettings` ajoute un nouvel attribut JSON à chaque opération de mise à jour avec des valeurs collectées à partir du système de base de données source, comme indiqué ci-dessous.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Note**
S'applique uniquement `BeforeImageSettings` aux AWS DMS tâches contenant un composant CDC, telles que les tâches à chargement complet plus CDC (qui migrent les données existantes et répliquent les modifications en cours), ou aux tâches CDC uniquement (qui répliquent uniquement les modifications de données). N’appliquez pas les `BeforeImageSettings` aux tâches à pleine charge uniquement.
Pour les options `BeforeImageSettings`, les conditions suivantes s'appliquent :
+ Définissez l'option `EnableBeforeImage` sur `true` pour activer la génération d’image antérieure. La valeur par défaut est `false`.
+ Utilisez l'option `FieldName` pour attribuer un nom au nouvel attribut JSON. Quand `EnableBeforeImage` est `true`, `FieldName` est obligatoire et ne peut pas être vide.
+ L'option `ColumnFilter` spécifie une colonne à ajouter en utilisant la génération d’image antérieure. Pour ajouter uniquement des colonnes faisant partie des clés primaires de la table, utilisez la valeur par défaut, `pk-only`. Pour ajouter une colonne ayant une valeur d'image antérieure, utilisez `all`. Notez que l’image antérieure ne contient pas de colonnes avec des types de données LOB, tels que CLOB ou BLOB.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**Note**
Les cibles Amazon S3 ne prennent pas en charge `BeforeImageSettings`. Pour les cibles S3, utilisez uniquement la règle de transformation `add-before-image-columns` à effectuer avant la génération d’images pendant la CDC.
### Utilisation d'une règle de transformation d'image antérieure
Au lieu des paramètres de tâche, vous pouvez utiliser le paramètre `add-before-image-columns`, qui applique une règle de transformation de colonne. Avec ce paramètre, vous pouvez activer la génération d’image antérieure pendant la CDC sur des cibles de streaming de données comme Kinesis.
En utilisant `add-before-image-columns` dans une règle de transformation, vous pouvez exercer un contrôle plus précis sur les résultats de l'image antérieure. Les règles de transformation vous permettent d'utiliser un localisateur d'objets qui vous fournit un contrôle sur les tables sélectionnées pour la règle. En outre, vous pouvez enchaîner les règles de transformation, ce qui permet d'appliquer différentes règles à différentes tables. Vous pouvez ensuite manipuler les colonnes produites à l'aide d'autres règles.
**Note**
N'utilisez pas le paramètre `add-before-image-columns` avec le paramètre de tâche `BeforeImageSettings` dans la même tâche. N’utilisez pas les deux, pour une seule tâche.
Un type de règle `transformation` avec le paramètre `add-before-image-columns` d'une colonne doit fournir une section `before-image-def`. Vous en trouverez un exemple ci-dessous.
```
{
"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,
}
}
```
La valeur de `column-prefix` est ajoutée à un nom de colonne et la valeur par défaut de `column-prefix` est `BI_`. La valeur de `column-suffix` est ajoutée au nom de la colonne et la valeur par défaut est vide. Ne définissez pas les deux `column-prefix` et `column-suffix` sur des chaînes vides.
Choisissez une valeur pour `column-filter`. Pour ajouter uniquement les colonnes qui font partie des clés primaires de la table, choisissez `pk-only` . Choisissez `non-lob` d'ajouter uniquement des colonnes qui ne sont pas de type LOB. Ou choisissez `all` d'ajouter une colonne qui a une valeur d’image antérieure.
### Exemple de règle de transformation d'image antérieure
La règle de transformation de l'exemple suivant ajoute une nouvelle colonne appelée `BI_emp_no` dans la cible. Ainsi, une instruction comme `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` remplit le champ `BI_emp_no` avec 1. Lorsque vous écrivez des mises à jour de CDC sur des cibles Amazon S3, la colonne `BI_emp_no` permet de savoir quelle ligne d’origine a été mise à jour.
```
{
"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"
}
}
]
}
```
Pour plus d'informations sur l'utilisation de l'action de règle `add-before-image-columns`, consultez [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Conditions préalables à l'utilisation d'un flux de données Kinesis comme cible pour AWS Database Migration Service
### Rôle IAM pour l'utilisation d'un flux de données Kinesis comme cible pour AWS Database Migration Service
Avant de configurer un flux de données Kinesis comme cible AWS DMS, assurez-vous de créer un rôle IAM. Ce rôle doit permettre AWS DMS d'assumer et d'accorder l'accès aux flux de données Kinesis vers lesquels la migration est effectuée. L'ensemble d'autorisations d'accès minimum est indiqué dans la stratégie IAM suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le rôle que vous utilisez pour la migration vers un flux de données Kinesis doit bénéficier des autorisations suivantes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Accès à un flux de données Kinesis en tant que cible pour AWS Database Migration Service
Dans les AWS DMS versions 3.4.7 et supérieures, pour vous connecter à un point de terminaison Kinesis, vous devez effectuer l'une des opérations suivantes :
+ Configurez DMS pour qu’il utilise les points de terminaison d’un VPC. Pour plus d’informations sur la configuration de DMS pour qu’il utilise les points de terminaison d’un VPC, consultez [Configuration des points de terminaison VPC pour AWS DMS](CHAP_VPC_Endpoints.md).
+ Configurez DMS pour qu’il utilise des routes publiques, c’est-à-dire qu’il rende votre instance de réplication publique. Pour plus d’informations sur les instances de réplication publiques, consultez [Instances de réplication publiques et privées](CHAP_ReplicationInstance.PublicPrivate.md).
## Limitations liées à l'utilisation de Kinesis Data Streams comme cible pour AWS Database Migration Service
Les limitations suivantes s’appliquent lorsque vous utilisez Kinesis Data Streams en tant que cible :
+ AWS DMS publie chaque mise à jour d'un seul enregistrement de la base de données source sous la forme d'un enregistrement de données dans un flux de données Kinesis donné, quelles que soient les transactions. Toutefois, vous pouvez inclure des détails de transaction pour chaque enregistrement de données à l'aide des paramètres pertinents de l'API `KinesisSettings`.
+ Le Mode LOB complet n'est pas pris en charge.
+ La taille LOB maximale prise en charge est de 1 Mo.
+ Kinesis Data Streams ne prend pas en charge la déduplication. Les applications qui consomment des données d'un flux doivent gérer les enregistrements en double. Pour plus d’informations, consultez [Gestion des enregistrements en double](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) dans le *Guide du développeur Amazon Kinesis Data Streams*.
+ AWS DMS prend en charge les quatre formes suivantes pour les clés de partition :
+ `SchemaName.TableName` : une combinaison du nom du schéma et du nom de la table.
+ `${AttributeName}` : la valeur d'un des champs du fichier JSON, ou la clé primaire de la table dans la base de données source.
+ `transaction-id`: ID de transaction CDC. Tous les enregistrements d'une même transaction sont placés sur la même partition.
+ `constant`: valeur littérale fixe pour chaque enregistrement, indépendamment de la table ou des données. Tous les enregistrements sont envoyés à la même valeur de clé de partition « constante », ce qui permet un ordre global strict dans toutes les tables.
```
{
"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"
}
}
```
+ Pour en savoir plus sur le chiffrement de vos données au repos dans Kinesis Data Streams, consultez [Protection des données dans Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html) dans le *Guide du développeur AWS Key Management Service *.
+ Le paramètre du point de `IncludeTransactionDetails` terminaison n'est pris en charge que lorsque le point de terminaison source est Oracle, SQL Server, PostgreSQL ou MySQL. Pour les autres types de point de terminaison source, les détails des transactions ne seront pas inclus.
+ `BatchApply` n’est pas pris en charge pour un point de terminaison Kinesis. L'utilisation de Batch Apply (par exemple, le paramètre de tâche de métadonnées `BatchApplyEnabled` cible) pour une cible Kinesis entraîne l'échec de la tâche et la perte de données. Ne l'activez pas `BatchApply` lorsque vous utilisez Kinesis comme point de terminaison cible.
+ Les cibles Kinesis ne sont prises en charge que pour un flux de données Kinesis dans le même AWS compte et le même Région AWS que l'instance de réplication.
+ Lors de la migration depuis une source MySQL, les BeforeImage données n'incluent pas les types de données CLOB et BLOB. Pour de plus amples informations, veuillez consulter [Utilisation d’une image antérieure pour afficher les valeurs d’origine des lignes CDC pour un flux de données Kinesis en tant que cible](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS ne prend pas en charge la migration de valeurs de type de `BigInt` données comportant plus de 16 chiffres. Pour contourner cette limitation, vous pouvez utiliser la règle de transformation suivante pour convertir la colonne `BigInt` en chaîne. Pour plus d’informations sur les règles de transformation, consultez [Règles et actions de transformation](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
}
}
```
+ Lorsque plusieurs opérations DML au sein d'une même transaction modifient une colonne LOB (Large Object) de la base de données source, la base de données cible ne conserve que la valeur LOB finale de la dernière opération de cette transaction. Les valeurs LOB intermédiaires définies par les opérations précédentes de la même transaction sont remplacées, ce qui peut entraîner des pertes de données ou des incohérences. Ce comportement est dû à la manière dont les données LOB sont traitées lors de la réplication.
+ AWS DMS ne prend pas en charge les données source contenant des `'\0'` caractères incorporés lors de l'utilisation de Kinesis comme point de terminaison cible. Les données contenant des `'\0'` caractères incorporés seront tronquées au premier `'\0'` caractère.
## Utilisation du mappage d’objet pour migrer les données vers un flux de données Kinesis
AWS DMS utilise des règles de mappage de tables pour mapper les données de la source au flux de données Kinesis cible. Pour mapper des données vers un flux cible, vous utilisez un type de règles de mappage de tables qu'on appelle le mappage d'objet. Utilisez le mappage d’objet pour définir la façon dont les enregistrements de données de la source sont mappés aux enregistrements de données publiés dans le flux de données Kinesis.
Les flux de données Kinesis ne disposent pas d’une structure prédéfinie autre que le fait d’avoir une clé de partition. Dans une règle de mappage d'objets, les valeurs possibles de `partition-key-type` pour un enregistrement de données sont `schema-table`, `transaction-id`, `primary-key`, `constant` et `attribute-name`.
Pour créer une règle de mappage d'objet, spécifiez `rule-type` comme `object-mapping`. Cette règle spécifie le type de mappage d'objet que vous souhaitez utiliser.
La structure de la règle est la suivante.
```
{
"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 prend actuellement en charge `map-record-to-record` et `map-record-to-document` en tant que seules valeurs valides pour le `rule-action` paramètre. Ces paramètres affectent les valeurs qui ne sont pas exclues de la liste d’attributs `exclude-columns`. Les `map-record-to-document` valeurs `map-record-to-record` et indiquent comment ces AWS DMS enregistrements sont gérés par défaut. Ces valeurs n'affectent en aucune façon les mappages d'attributs.
Utilisez `map-record-to-record` lors d’une migration d’une base de données relationnelle vers un flux de données Kinesis. Ce type de règle utilise la valeur `taskResourceId.schemaName.tableName` de la base de données relationnelle comme clé de partition dans le flux de données Kinesis et crée un attribut pour chaque colonne de la base de données source.
Lorsque vous utilisez `map-record-to-record`, notez ce qui suit :
+ Ce paramètre n’affecte que les colonnes exclues par la liste `exclude-columns`.
+ Pour chacune de ces colonnes, AWS DMS crée un attribut correspondant dans le sujet cible.
+ AWS DMS crée cet attribut correspondant, que la colonne source soit utilisée ou non dans un mappage d'attributs.
Utilisez `map-record-to-document` pour placer des colonnes sources dans un document unique à plat du flux cible approprié en utilisant le nom d’attribut « \$1doc ». AWS DMS place les données dans un mappage unique à plat sur la source appelée « `_doc` ». Ce placement s'applique à toute colonne de la table source non listée dans la liste d'attributs `exclude-columns`.
Une manière de comprendre `map-record-to-record` est de le voir en action. Dans cet exemple, imaginons que vous commencez avec une ligne de table d'une base de données relationnelle, présentant la structure et les données suivantes :
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Pour migrer ces informations d’un schéma nommé `Test` vers un flux de données Kinesis, vous créez des règles pour mapper les données au flux cible. La règle suivante illustre ce mappage.
```
{
"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"
}
}
]
}
```
L’exemple qui suit illustre le format d’enregistrement résultant dans le flux de données Kinesis :
+ StreamName: XXX
+ PartitionKey: Test.Customers //SchmaName.TableName
+ Data : //The following JSON message
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
Supposons toutefois que vous utilisiez les mêmes règles, mais que vous redéfinissiez le paramètre `rule-action` sur `map-record-to-document` et que vous excluiez certaines colonnes. La règle suivante illustre ce mappage.
```
{
"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"
]
}
}
]
}
```
Dans ce cas, les colonnes non répertoriées dans le paramètre `exclude-columns`, `FirstName`, `LastName`, `StoreId` et `DateOfBirth`, sont mappées à `_doc`. L’exemple qui suit illustre le format d’enregistrement résultant.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Restructuration de données avec le mappage d'attribut
Vous pouvez restructurer les données lors de leur migration vers un flux de données Kinesis à l’aide d’un mappage d’attribut. Par exemple, vous pourriez vouloir regrouper plusieurs champs de la source en un seul champ dans la cible. Le mappage d'attribut suivant illustre comment restructurer les données.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Pour définir une valeur constante pour`partition-key`, spécifiez`"partition-key-type: "constant"`, cela définit la valeur de partition sur`constant`. Par exemple, vous pouvez le faire pour forcer le stockage de toutes les données dans une seule partition. Le mappage suivant illustre cette approche.
```
{
"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}"
}
]
}
}
]
}
```
**Note**
La valeur `partition-key` d'un enregistrement de contrôle correspondant à une table spécifique est `TaskId.SchemaName.TableName`. La valeur `partition-key` d'un enregistrement de contrôle correspondant à une tâche spécifique est le `TaskId` de cet enregistrement. La spécification d'une valeur `partition-key` dans le mappage d'objet n'a aucun impact sur la `partition-key` d'un enregistrement de contrôle.
Lorsqu'il `partition-key-type` est défini sur `attribute-name` dans une règle de mappage de table, vous devez spécifier`partition-key-name`, qui doit faire référence soit à une colonne de la table source, soit à une colonne personnalisée définie dans le mappage. En outre, `attribute-mappings` il doit être fourni pour définir la manière dont les colonnes source sont mappées au Kinesis Stream cible.
### Format de message pour Kinesis Data Streams
La sortie JSON est simplement une liste de paires clé-valeur. Un format de message JSON\$1UNFORMATED est une chaîne JSON à une seule ligne avec un délimiteur de nouvelle ligne.
AWS DMS fournit les champs réservés suivants pour faciliter la consommation des données issues des Kinesis Data Streams :
**RecordType**
Les enregistrements peuvent être de type Données ou Contrôle. *Les enregistrements de données* représentent les lignes réelles de la source. *Les enregistrements de contrôle* sont destinés à des événements importants dans le flux, par exemple un redémarrage de la tâche.
**Opération**
Pour les enregistrements de données, l'opération peut être `load`,`insert`, `update` ou `delete`.
Pour les enregistrements de contrôle, l’opération peut être `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` ou `column-type-change`.
**SchemaName**
Schéma source de l'enregistrement. Ce champ peut être vide pour un enregistrement de contrôle.
**TableName**
Table source de l'enregistrement. Ce champ peut être vide pour un enregistrement de contrôle.
**Horodatage**
Horodatage de la construction du message JSON. Le champ est formaté selon le format ISO 8601.
# Utiliser Apache Kafka comme cible pour AWS Database Migration Service
Vous pouvez l'utiliser AWS DMS pour migrer des données vers un cluster Apache Kafka. Apache Kafka est une plateforme de streaming distribuée. Apache Kafka vous permet d’ingérer et de traiter des données de streaming en temps réel.
AWS propose également Amazon Managed Streaming pour Apache Kafka (Amazon MSK) à utiliser comme cible. AWS DMS Amazon MSK est un service de streaming Apache Kafka entièrement géré qui simplifie l’implémentation et la gestion des instances Apache Kafka. Il fonctionne avec les versions open source d'Apache Kafka, et vous accédez aux instances Amazon MSK en tant que AWS DMS cibles, exactement comme n'importe quelle instance Apache Kafka. Pour plus d’informations, consultez [Qu’est-ce qu’Amazon MSK ?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*.
Un cluster Kafka stocke les flux d’enregistrements dans des catégories appelées « rubriques », divisées en partitions. Les *partitions* sont des séquences identifiées de manière unique d’enregistrements de données (messages) dans une rubrique. Les partitions peuvent être réparties entre plusieurs agents dans un cluster pour permettre le traitement parallèle des enregistrements d’une rubrique. Pour de plus amples informations sur les rubriques et les partitions et leur distribution dans Apache Kafka, veuillez consulter [Rubriques et journaux](https://kafka.apache.org/documentation/#intro_topics) et [distribution](https://kafka.apache.org/documentation/#intro_distribution).
Votre cluster Kafka peut être une instance Amazon MSK, un cluster exécuté sur une instance Amazon EC2 ou un cluster sur site. Une instance Amazon MSK ou un cluster sur une instance Amazon EC2 peut se trouver dans le même VPC ou dans un autre VPC. Dans le cas d’un cluster sur site, vous pouvez utiliser votre propre serveur de noms sur site pour votre instance de réplication afin de résoudre le nom d’hôte du cluster. Pour en savoir plus sur la configuration d’un serveur de noms pour votre instance de réplication, consultez [Utilisation de votre propre serveur de noms sur site](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Pour plus d’informations sur la configuration d’un réseau, consultez [Configuration d'un réseau pour une instance de réplication](CHAP_ReplicationInstance.VPC.md).
Lorsque vous utilisez un cluster Amazon MSK, assurez-vous que son groupe de sécurité autorise l’accès à partir de votre instance de réplication. Pour en savoir plus sur la modification du groupe de sécurité d’un cluster Amazon MSK, consultez [Modification du groupe de sécurité d’un cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service publie des enregistrements dans un sujet Kafka à l'aide de JSON. Au cours de la conversion, AWS DMS sérialise chaque enregistrement de la base de données source dans une paire attribut-valeur au format JSON.
Utilisez le mappage d’objet pour migrer vos données de n’importe quelle source de données prise en charge vers un cluster Kafka cible. Avec le mappage d’objet, vous déterminez la façon de structurer les enregistrements de données dans la rubrique cible. Vous définissez également une clé de partition pour chaque table, qu'Apache Kafka utilise pour regrouper les données dans ses partitions.
Actuellement, ne AWS DMS prend en charge qu'un seul sujet par tâche. Pour une seule tâche comportant plusieurs tables, tous les messages sont placés dans une seule rubrique. Chaque message inclut une section de métadonnées qui identifie le schéma et la table cibles. AWS DMS les versions 3.4.6 et supérieures prennent en charge la réplication multisujet à l'aide du mappage d'objets. Pour de plus amples informations, veuillez consulter [Réplication à plusieurs rubriques à l’aide du mappage d’objet](#CHAP_Target.Kafka.MultiTopic).
**Paramètres du point de terminaison Apache Kafka**
Vous pouvez spécifier les détails de connexion via les paramètres du point de terminaison dans la AWS DMS console ou via l'`--kafka-settings`option de la CLI. Les conditions requises pour chaque paramètre sont les suivantes :
+ `Broker` : spécifiez les emplacements d’un ou de plusieurs agents dans votre cluster Kafka sous la forme d’une liste séparée par des virgules de tous les éléments `broker-hostname:port`. Par exemple : `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Ce paramètre peut spécifier les emplacements d’un ou de tous les agents du cluster. Les agents de cluster communiquent tous pour gérer le partitionnement des enregistrements de données migrés vers la rubrique.
+ `Topic` : (facultatif) spécifiez le nom de rubrique avec une longueur maximale de 255 lettres et symboles. Vous pouvez utiliser le point (.), le trait de soulignement (\$1) et le moins (-). Les noms de rubrique avec un point (.) ou un trait de soulignement (\$1) peuvent entrer en collision dans des structures de données internes. Utilisez l'un ou l'autre de ces symboles, mais pas les deux dans le nom de la rubrique. Si vous ne spécifiez pas de nom de rubrique, AWS DMS `"kafka-default-topic"` utilisez-le comme rubrique de migration.
**Note**
Pour AWS DMS créer soit un sujet de migration que vous spécifiez, soit le sujet par défaut, défini dans le `auto.create.topics.enable = true` cadre de la configuration de votre cluster Kafka. Pour de plus amples informations, consultez [Limitations liées à l'utilisation d'Apache Kafka comme cible pour AWS Database Migration Service](#CHAP_Target.Kafka.Limitations).
+ `MessageFormat` : format de sortie pour les enregistrements créés sur le point de terminaison. Le format du message est `JSON` (par défaut) ou `JSON_UNFORMATTED` (une seule ligne sans onglet).
+ `MessageMaxBytes` : taille maximale en octets des enregistrements créés sur le point de terminaison. La valeur par défaut est 1 000 000.
**Note**
Vous ne pouvez utiliser la AWS CLI/SDK que pour passer à une valeur autre que celle par `MessageMaxBytes` défaut. Par exemple, pour modifier votre point de terminaison Kafka existant et redéfinir la valeur de `MessageMaxBytes`, utilisez la commande suivante.
```
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` : fournit des informations détaillées sur les transactions à partir de la base de données source. Ces informations comprennent un horodatage de validation, une position de journal et des valeurs pour `transaction_id`, `previous_transaction_id` et `transaction_record_id`(le décalage d'enregistrement dans une transaction). La valeur par défaut est `false`.
+ `IncludePartitionValue` : affiche la valeur de partition dans la sortie du message Kafka, sauf si le type de partition est `schema-table-type`. La valeur par défaut est `false`.
+ `PartitionIncludeSchemaTable` : préfixe les noms de schéma et de table aux valeurs de partition, lorsque le type de partition est `primary-key-type`. Cela augmente la distribution des données entre les partitions Kafka. Par exemple, supposons qu'un schéma `SysBench` comporte des milliers de tables et que chaque table n'ait qu'une plage limitée pour une clé primaire. Dans ce cas, la même clé primaire est envoyée à partir de milliers de tables vers la même partition, ce qui provoque une limitation. La valeur par défaut est `false`.
+ `IncludeTableAlterOperations` : inclut toutes les opérations DDL (Data Definition Language) qui modifient la table dans les données de contrôle, telles que `rename-table`, `drop-table`, `add-column`, `drop-column` et `rename-column`. La valeur par défaut est `false`.
+ `IncludeControlDetails` : affiche les informations de contrôle détaillées pour la définition de table, la définition de colonne et les modifications de table et de colonne dans la sortie du message Kafka. La valeur par défaut est `false`.
+ `IncludeNullAndEmpty` : inclut les colonnes NULL et vides dans la cible. La valeur par défaut est `false`.
+ `SecurityProtocol` : définit une connexion sécurisée à un point de terminaison cible Kafka à l’aide du protocole TLS (Transport Layer Security). Les options sont `ssl-authentication`, `ssl-encryption` et `sasl-ssl`. L’utilisation de `sasl-ssl` requiert `SaslUsername` et `SaslPassword`.
+ `SslEndpointIdentificationAlgorithm`— Définit la vérification du nom d'hôte pour le certificat. Ce paramètre est pris en charge dans les AWS DMS versions 3.5.1 et ultérieures. Les options disponibles sont les suivantes :
+ `NONE`: désactive la vérification du nom d'hôte du broker dans la connexion client.
+ `HTTPS`: Activez la vérification du nom d'hôte du broker dans la connexion client.
+ `useLargeIntegerValue`— Utilisez jusqu'à 18 chiffres au lieu de convertir les entiers en doubles, disponible à partir de AWS DMS la version 3.5.4. La valeur par défaut est false.
Vous pouvez augmenter la vitesse du transfert dans les paramètres. Pour ce faire, AWS DMS prend en charge un chargement complet multithread sur un cluster cible Apache Kafka. AWS DMS prend en charge ce multithreading avec des paramètres de tâche qui incluent les éléments suivants :
+ `MaxFullLoadSubTasks`— Utilisez cette option pour indiquer le nombre maximum de tables sources à charger en parallèle. AWS DMS charge chaque table dans la table cible Kafka correspondante à l'aide d'une sous-tâche dédiée. La valeur par défaut est 8 ; la valeur maximale 49.
+ `ParallelLoadThreads`— Utilisez cette option pour spécifier le nombre de threads AWS DMS utilisés pour charger chaque table dans sa table cible Kafka. La valeur maximale pour une cible Apache Kafka est 32. Vous pouvez demander une augmentation de cette limite maximale.
+ `ParallelLoadBufferSize` : utilisez cette option pour spécifier le nombre maximal d’enregistrements à stocker dans la mémoire tampon utilisée par les threads de chargement parallèles pour charger les données dans la cible Kafka. La valeur par défaut est 50. La valeur maximale est 1 000. Utilisez ce paramètre avec `ParallelLoadThreads`. `ParallelLoadBufferSize` est valide uniquement dans le cas de plusieurs threads.
+ `ParallelLoadQueuesPerThread` : utilisez cette option pour spécifier le nombre de files d’attente auxquelles chaque thread simultané accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour la cible. La valeur par défaut est 1. La valeur maximale est 512.
Vous pouvez améliorer les performances de capture des données de modification (CDC) pour les points de terminaison Kafka en ajustant les paramètres de tâche des threads parallèles et des opérations en bloc. Pour ce faire, vous pouvez spécifier le nombre de threads simultanés, les files d'attente par thread et le nombre d'enregistrements à stocker dans un tampon à l'aide de la tâche `ParallelApply*`. Par exemple, supposons que vous souhaitiez effectuer un chargement CDC et appliquer 128 threads en parallèle. Vous souhaitez également accéder à 64 files d'attente par thread, avec 50 enregistrements stockés par tampon.
Pour améliorer les performances du CDC, AWS DMS prend en charge les paramètres de tâche suivants :
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement CDC pour transférer des enregistrements de données vers un point de terminaison cible Kafka. La valeur par défaut est zéro (0) et la valeur maximale est 32.
+ `ParallelApplyBufferSize` : spécifie le nombre maximal d’enregistrements à stocker dans chaque file d’attente de mémoire tampon pour que les threads simultanés soient transférés vers un point de terminaison cible Kafka lors d’un chargement CDC. La valeur par défaut est 100 et la valeur maximale est 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads.
+ `ParallelApplyQueuesPerThread` : spécifie le nombre de files d’attente auxquelles chaque thread accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour un point de terminaison Kafka pendant la CDC. La valeur par défaut est 1. La valeur maximale est 512.
Lorsque vous utilisez les paramètres de tâche `ParallelApply*`, la valeur par défaut `partition-key-type` est la valeur `primary-key` de la table, pas `schema-name.table-name`.
## Connexion à Kafka à l’aide du protocole TLS (Transport Layer Security)
Un cluster Kafka accepte les connexions sécurisées à l’aide du protocole TLS (Transport Layer Security). Avec DMS, vous pouvez utiliser l’une des trois options de protocole de sécurité suivantes pour sécuriser la connexion d’un point de terminaison Kafka.
**Chiffrement SSL (`server-encryption`)**
Les clients valident l’identité du serveur par le biais du certificat du serveur. Une connexion chiffrée est alors établie entre le serveur et le client.
**Authentification SSL (`mutual-authentication`)**
Le serveur et le client valident mutuellement leur identité respective via leurs propres certificats. Une connexion chiffrée est alors établie entre le serveur et le client.
**SASL-SSL (`mutual-authentication`)**
La méthode SASL (Simple Authentication and Security Layer) remplace le certificat du client par un nom d’utilisateur et un mot de passe pour valider l’identité du client. Plus précisément, vous fournissez un nom d’utilisateur et un mot de passe enregistrés par le serveur afin que ce dernier puisse valider l’identité d’un client. Une connexion chiffrée est alors établie entre le serveur et le client.
**Important**
Apache Kafka et Amazon MSK acceptent les certificats résolus. Il s’agit d’une limitation connue de Kafka et d’Amazon MSK qui doit être corrigée. Pour plus d’informations, consultez [Apache Kafka issues, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Si vous utilisez Amazon MSK, pensez à utiliser des listes de contrôle d'accès (ACLs) pour contourner cette limitation connue. Pour plus d'informations sur son utilisation ACLs, consultez la ACLs section [Apache Kafka](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) du guide du développeur *Amazon Managed Streaming for Apache Kafka*.
Si vous utilisez un cluster Kafka autogéré, consultez [Comment dated 21/Oct/18](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376) pour en savoir plus sur la configuration de votre cluster.
### Utilisation du chiffrement SSL avec Amazon MSK ou un cluster Kafka autogéré
Vous pouvez utiliser le chiffrement SSL pour sécuriser la connexion d’un point de terminaison à Amazon MSK ou à un cluster Kafka autogéré. Lorsque vous utilisez la méthode d’authentification par chiffrement SSL, les clients valident l’identité d’un serveur par le biais du certificat du serveur. Une connexion chiffrée est alors établie entre le serveur et le client.
**Pour utiliser le chiffrement SSL pour vous connecter à Amazon MSK**
+ Définissez le paramètre de point de terminaison du protocole de sécurité (`SecurityProtocol`) à l’aide de l’option `ssl-encryption` lorsque vous créez votre point de terminaison Kafka cible.
L’exemple de code JSON suivant définit le protocole de sécurité sur le chiffrement SSL.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**Pour utiliser le chiffrement SSL pour un cluster Kafka autogéré**
1. Si vous utilisez une autorité de certification (CA) privée dans votre cluster Kafka sur site, chargez votre certificat de CA privée et obtenez un Amazon Resource Name (ARN).
1. Définissez le paramètre de point de terminaison du protocole de sécurité (`SecurityProtocol`) à l’aide de l’option `ssl-encryption` lorsque vous créez votre point de terminaison Kafka cible. L’exemple de code JSON suivant définit le protocole de sécurité sur `ssl-encryption`.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Si vous utilisez une CA privée, définissez `SslCaCertificateArn` dans l’ARN obtenu à la première étape ci-dessus.
### Utilisation de l’authentification SSL
Vous pouvez utiliser l’authentification SSL pour sécuriser la connexion d’un point de terminaison à Amazon MSK ou à un cluster Kafka autogéré.
Pour activer l’authentification client et le chiffrement à l’aide de l’authentification SSL pour se connecter à Amazon MSK, procédez comme suit :
+ Préparez une clé privée et un certificat public pour Kafka.
+ Chargez les certificats dans le gestionnaire de certificats DMS.
+ Créez un point de terminaison cible Kafka avec le certificat correspondant ARNs spécifié dans les paramètres du point de terminaison Kafka.
**Pour préparer une clé privée et un certificat public pour Amazon MSK**
1. Créez une instance EC2 et configurez un client de sorte qu’il utilise l’authentification, comme décrit dans les étapes 1 à 9 de la section [Authentification TLS mutuelle](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) du *Guide du développeur Amazon Managed Streaming for Apache Kafka*.
Après avoir effectué ces étapes, vous disposez d’un Certificate-ARN (l’ARN de certificat public enregistré dans ACM) et d’une clé privée contenus dans un fichier `kafka.client.keystore.jks`.
1. Obtenez le certificat public et copiez-le dans le fichier `signed-certificate-from-acm.pem` à l’aide de la commande suivante :
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
Cette commande renvoie des informations semblables à celles de l’exemple suivant :
```
{"Certificate": "123", "CertificateChain": "456"}
```
Vous copiez ensuite votre équivalent de `"123"` dans le fichier `signed-certificate-from-acm.pem`.
1. Pour obtenir la clé privée, importez la clé `msk-rsa` à partir de `kafka.client.keystore.jks to keystore.p12`, comme illustré dans l’exemple suivant.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Utilisez la commande suivante pour exporter `keystore.p12` au format `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
Le message **Entrer une phrase passe PEM** apparaît et identifie la clé appliquée pour chiffrer le certificat.
1. Supprimez les attributs de conteneur et les attributs de clé du fichier `.pem` pour vous assurer que la première ligne commence par la chaîne suivante.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**Pour charger un certificat public et une clé privée dans le gestionnaire de certificats DMS et tester la connexion à Amazon MSK**
1. Chargez dans le gestionnaire de certificats DMS à l’aide de la commande suivante.
```
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. Créez un point de terminaison cible Amazon MSK et testez la connexion pour vous assurer que l’authentification TLS fonctionne.
```
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
```
**Important**
Vous pouvez utiliser l’authentification SSL pour sécuriser une connexion à un cluster Kafka autogéré. Dans certains cas, vous devrez peut-être utiliser une autorité de certification (CA) privée dans votre cluster Kafka sur site. Si tel est le cas, chargez votre chaîne de CA, votre certificat public et votre clé privée dans le gestionnaire de certificats DMS. Utilisez ensuite l’Amazon Resource Name (ARN) correspondant dans vos paramètres de point de terminaison lorsque vous créez votre point de terminaison cible Kafka sur site.
**Pour préparer une clé privée et un certificat signé pour un cluster Kafka autogéré**
1. Générez une paire de clés comme indiqué dans l’exemple suivant.
```
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. Générez une demande de signature de certificat (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. Utilisez la CA du magasin de clés de confiance de votre cluster pour signer la CSR. Si vous n’avez pas de CA, vous pouvez créer votre propre CA privée.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Importez `ca-cert` dans le magasin de clés de confiance et le magasin de clés du serveur. Si vous n’avez pas de magasin de clés de confiance, utilisez la commande suivante pour le créer et y importer `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. Signez le certificat.
```
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. Importez le certificat signé dans le magasin de clés.
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. Utilisez la commande suivante pour importer la clé `on-premise-rsa` de `kafka.server.keystore.jks` dans `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. Utilisez la commande suivante pour exporter `keystore.p12` au format `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Chargez `encrypted-private-server-key.pem`, `signed-certificate.pem` et `ca-cert` dans le gestionnaire de certificats DMS.
1. Créez un point de terminaison en utilisant le renvoyé ARNs.
```
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
```
### Utilisation de l’authentification SASL-SSL pour se connecter à Amazon MSK
La méthode SASL (Simple Authentication and Security Layer) utilise un nom d’utilisateur et un mot de passe pour valider l’identité d’un client et établit une connexion chiffrée entre le serveur et le client.
Pour utiliser SASL, vous devez commencer par créer un nom d’utilisateur et un mot de passe sécurisés lorsque vous configurez votre cluster Amazon MSK. Pour savoir comment configurer un nom d'utilisateur et un mot de passe sécurisés pour un cluster Amazon MSK, consultez la section [Configuration de l' SASL/SCRAM authentification pour un cluster Amazon MSK dans le guide du développeur](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) *Amazon Managed Streaming for Apache Kafka*.
Ensuite, lorsque vous créez votre point de terminaison cible Kafka, définissez le paramètre de point de terminaison du protocole de sécurité (`SecurityProtocol`) à l’aide de l’option `sasl-ssl`. Vous définissez également les options `SaslUsername` et `SaslPassword`. Assurez-vous qu’elles sont cohérentes avec le nom d’utilisateur et le mot de passe sécurisés que vous avez créés lorsque vous avez configuré votre cluster Amazon MSK pour la première fois, comme illustré dans l’exemple JSON suivant.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**Note**
Actuellement, ne AWS DMS prend en charge que le protocole SASL-SSL public soutenu par une autorité de certification. DMS ne prend pas en charge le protocole SASL-SSL pour une utilisation avec Kafka autogéré soutenu par une autorité de certification privée.
Pour l'authentification SASL-SSL, AWS DMS prend en charge le mécanisme SCRAM-SHA-512 par défaut. AWS DMS les versions 3.5.0 et supérieures prennent également en charge le mécanisme Plain. Pour prendre en charge le mécanisme Plain, définissez le paramètre `SaslMechanism` du type de données d’API `KafkaSettings` sur `PLAIN`. Le type de données `PLAIN` est pris en charge par Kafka, mais pas par Amazon Kafka (MSK).
## Utilisation d'une image antérieure pour afficher les valeurs originales des lignes de la CDC pour Apache Kafka comme cible
Lorsque vous écrivez des mises à jour de CDC sur une cible de diffusion de données comme Kafka, vous pouvez afficher les valeurs d'origine d'une ligne de base de données source avant de les modifier par une mise à jour. Pour ce faire, AWS DMS remplit une *image antérieure* des événements de mise à jour en fonction des données fournies par le moteur de base de données source.
Différents moteurs de base de données source fournissent différentes quantités d'informations pour une image antérieure :
+ Oracle met uniquement à jour des colonnes si elles changent.
+ PostgreSQL fournit uniquement des données pour les colonnes qui font partie de la clé primaire (modifiée ou non). Si la réplication logique est utilisée et que REPLICA IDENTITY FULL est défini pour la table source, vous pouvez obtenir des informations complètes avant et après sur la ligne écrite dans le WALs et disponibles ici.
+ MySQL fournit généralement des données pour toutes les colonnes (modifiées ou non).
Pour activer avant l'imagerie pour ajouter des valeurs d'origine de la base de données source à la sortie AWS DMS , utilisez le paramètre de tâche `BeforeImageSettings` ou le paramètre `add-before-image-columns`. Ce paramètre applique une règle de transformation de colonne.
`BeforeImageSettings` ajoute un nouvel attribut JSON à chaque opération de mise à jour avec des valeurs collectées à partir du système de base de données source, comme indiqué ci-dessous.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Note**
Appliquez les `BeforeImageSettings` à la charge complète et aux tâches CDC (qui migrent les données existantes et répliquent les modifications en cours), ou aux tâches CDC uniquement (qui répliquent les modifications de données uniquement). N’appliquez pas les `BeforeImageSettings` aux tâches à pleine charge uniquement.
Pour les options `BeforeImageSettings`, les conditions suivantes s'appliquent :
+ Définissez l'option `EnableBeforeImage` sur `true` pour activer la génération d’image antérieure. La valeur par défaut est `false`.
+ Utilisez l'option `FieldName` pour attribuer un nom au nouvel attribut JSON. Quand `EnableBeforeImage` est `true`, `FieldName` est obligatoire et ne peut pas être vide.
+ L'option `ColumnFilter` spécifie une colonne à ajouter en utilisant la génération d’image antérieure. Pour ajouter uniquement des colonnes faisant partie des clés primaires de la table, utilisez la valeur par défaut, `pk-only`. Pour ajouter uniquement des colonnes qui ne sont pas de type LOB, utilisez `non-lob`. Pour ajouter une colonne ayant une valeur d'image antérieure, utilisez `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Utilisation d'une règle de transformation d'image antérieure
Au lieu des paramètres de tâche, vous pouvez utiliser le paramètre `add-before-image-columns`, qui applique une règle de transformation de colonne. Avec ce paramètre, vous pouvez activer la génération d’image antérieure pendant la CDC sur des cibles de diffusion de données telles que Kafka.
En utilisant `add-before-image-columns` dans une règle de transformation, vous pouvez exercer un contrôle plus précis sur les résultats de l'image antérieure. Les règles de transformation vous permettent d'utiliser un localisateur d'objets qui vous fournit un contrôle sur les tables sélectionnées pour la règle. En outre, vous pouvez enchaîner les règles de transformation, ce qui permet d'appliquer différentes règles à différentes tables. Vous pouvez ensuite manipuler les colonnes produites à l'aide d'autres règles.
**Note**
N'utilisez pas le paramètre `add-before-image-columns` avec le paramètre de tâche `BeforeImageSettings` dans la même tâche. N’utilisez pas les deux, pour une seule tâche.
Un type de règle `transformation` avec le paramètre `add-before-image-columns` d'une colonne doit fournir une section `before-image-def`. Vous en trouverez un exemple ci-dessous.
```
{
"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,
}
}
```
La valeur de `column-prefix` est ajoutée à un nom de colonne et la valeur par défaut de `column-prefix` est `BI_`. La valeur de `column-suffix` est ajoutée au nom de la colonne et la valeur par défaut est vide. Ne définissez pas les deux `column-prefix` et `column-suffix` sur des chaînes vides.
Choisissez une valeur pour `column-filter`. Pour ajouter uniquement les colonnes qui font partie des clés primaires de la table, choisissez `pk-only` . Choisissez `non-lob` d'ajouter uniquement des colonnes qui ne sont pas de type LOB. Ou choisissez `all` d'ajouter une colonne qui a une valeur d’image antérieure.
### Exemple de règle de transformation d'image antérieure
La règle de transformation de l'exemple suivant ajoute une nouvelle colonne appelée `BI_emp_no` dans la cible. Ainsi, une instruction comme `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` remplit le champ `BI_emp_no` avec 1. Lorsque vous écrivez des mises à jour de CDC sur des cibles Amazon S3, la colonne `BI_emp_no` permet de savoir quelle ligne d’origine a été mise à jour.
```
{
"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"
}
}
]
}
```
Pour plus d'informations sur l'utilisation de l'action de règle `add-before-image-columns`, consultez [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Limitations liées à l'utilisation d'Apache Kafka comme cible pour AWS Database Migration Service
Les limitations suivantes s'appliquent lorsque vous utilisez apache Kafka comme cible :
+ AWS DMS Les points de terminaison cibles de Kafka ne prennent pas en charge le contrôle d'accès IAM pour Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ Le Mode LOB complet n'est pas pris en charge.
+ Spécifiez un fichier de configuration Kafka pour votre cluster avec des propriétés permettant AWS DMS de créer automatiquement de nouveaux sujets. Incluez le paramètre, `auto.create.topics.enable = true`. Si vous utilisez Amazon MSK, vous pouvez spécifier la configuration par défaut lorsque vous créez votre cluster Kafka, puis redéfinir le paramètre `auto.create.topics.enable` sur `true`. Pour plus d’informations sur les paramètres de configuration par défaut, consultez [Configuration Amazon MSK par défaut](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*. Si vous devez modifier un cluster Kafka existant créé à l'aide d'Amazon MSK, exécutez la AWS CLI commande `aws kafka create-configuration` pour mettre à jour votre configuration Kafka, comme dans l'exemple suivant :
```
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"
}
```
Ici, `//~/kafka_configuration` est le fichier de configuration que vous avez créé avec les paramètres de propriété requis.
Si vous utilisez votre propre instance Kafka installée sur Amazon EC2, modifiez la configuration du cluster Kafka avec `auto.create.topics.enable = true` le paramètre AWS DMS permettant de créer automatiquement de nouveaux sujets, en utilisant les options fournies avec votre instance.
+ AWS DMS publie chaque mise à jour d'un seul enregistrement de la base de données source sous la forme d'un enregistrement de données (message) dans un sujet Kafka donné, quelles que soient les transactions.
+ AWS DMS prend en charge les quatre formes suivantes pour les clés de partition :
+ `SchemaName.TableName` : une combinaison du nom du schéma et du nom de la table.
+ `${AttributeName}` : la valeur d'un des champs du fichier JSON, ou la clé primaire de la table dans la base de données source.
+ `transaction-id`: ID de transaction CDC. Tous les enregistrements d'une même transaction sont placés sur la même partition.
+ `constant`: valeur littérale fixe pour chaque enregistrement, indépendamment de la table ou des données. Tous les enregistrements sont envoyés à la même valeur de clé de partition « constante », ce qui permet un ordre global strict dans toutes les tables.
```
{
"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"
}
}
```
+ Le paramètre du point de `IncludeTransactionDetails` terminaison n'est pris en charge que lorsque le point de terminaison source est Oracle, SQL Server, PostgreSQL ou MySQL. Pour les autres types de point de terminaison source, les détails des transactions ne seront pas inclus.
+ `BatchApply` n’est pas pris en charge pour un point de terminaison Kafka. L’utilisation de l’application par lots (par exemple, le paramètre de tâche de métadonnées cible `BatchApplyEnabled`) pour une cible Kafka peut entraîner une perte de données.
+ AWS DMS ne prend pas en charge la migration de valeurs de type de `BigInt` données comportant plus de 16 chiffres. Pour contourner cette limitation, vous pouvez utiliser la règle de transformation suivante pour convertir la colonne `BigInt` en chaîne. Pour plus d’informations sur les règles de transformation, consultez [Règles et actions de transformation](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 Les points de terminaison cibles de Kafka ne sont pas compatibles avec Amazon MSK servless.
+ Lors de la définition des règles de mappage, il n'est pas possible de disposer à la fois d'une règle de mappage d'objets et d'une règle de transformation. Vous ne devez définir qu'une seule règle.
+ AWS DMS prend en charge l'authentification SASL pour les versions d'Apache Kafka jusqu'à 3.8. Si vous utilisez Kafka 4.0 ou une version ultérieure, vous ne pouvez vous connecter que sans authentification SASL.
+ AWS DMS ne prend pas en charge les données source contenant des `'\0'` caractères incorporés lors de l'utilisation de Kafka comme point de terminaison cible. Les données contenant des `'\0'` caractères incorporés seront tronquées au premier `'\0'` caractère.
## Utilisation du mappage d’objet pour migrer les données vers une rubrique Kafka
AWS DMS utilise des règles de mappage de tables pour mapper les données de la source au sujet Kafka cible. Pour mapper des données à une rubrique cible, vous utilisez un type de règle de mappage de table appelé « mappage d’objet ». Vous utilisez le mappage d'objet pour définir la façon dont les enregistrements de données de la source sont mappés sur les enregistrements de données publiés dans une rubrique Kafka.
Les rubriques Kafka ne disposent pas d'une structure prédéfinie autre que le fait d'avoir une clé de partition.
**Note**
Vous n’avez pas besoin d’utiliser le mappage d’objet. Vous pouvez utiliser un mappage de table standard pour différentes transformations. Cependant, le type de clé de partition suivra les comportements par défaut suivants :
La clé primaire est utilisée comme clé de partition pour le chargement complet.
Si aucun paramètre de tâche parallel-apply n’est utilisé, `schema.table` est utilisé comme clé de partition pour la CDC.
Si des paramètres de tâche parallel-apply sont utilisés, la clé primaire est utilisée comme clé de partition pour la CDC.
Pour créer une règle de mappage d'objet, spécifiez `rule-type` comme `object-mapping`. Cette règle spécifie le type de mappage d'objet que vous souhaitez utiliser.
La structure de la règle est la suivante.
```
{
"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 prend actuellement en charge `map-record-to-record` et `map-record-to-document` en tant que seules valeurs valides pour le `rule-action` paramètre. Ces paramètres affectent les valeurs qui ne sont pas exclues de la liste d’attributs `exclude-columns`. Les `map-record-to-document` valeurs `map-record-to-record` et indiquent comment ces AWS DMS enregistrements sont gérés par défaut. Ces valeurs n'affectent en aucune façon les mappages d'attributs.
Utilisez `map-record-to-record` lors d'une migration d'une base de données relationnelle vers une rubrique Kafka. Ce type de règle utilise la valeur `taskResourceId.schemaName.tableName` de la base de données relationnelle comme clé de partition dans la rubrique Kafka, et crée un attribut pour chaque colonne dans la base de données source.
Lorsque vous utilisez `map-record-to-record`, notez ce qui suit :
+ Ce paramètre n’affecte que les colonnes exclues par la liste `exclude-columns`.
+ Pour chacune de ces colonnes, AWS DMS crée un attribut correspondant dans le sujet cible.
+ AWS DMS crée cet attribut correspondant, que la colonne source soit utilisée ou non dans un mappage d'attributs.
Une manière de comprendre `map-record-to-record` est de le voir en action. Dans cet exemple, imaginons que vous commencez avec une ligne de table d'une base de données relationnelle, présentant la structure et les données suivantes :
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Pour migrer ces informations à partir d'un schéma nommé `Test` vers une rubrique Kafka, vous créez des règles pour mapper les données sur la rubrique cible. La règle suivante illustre ce mappage.
```
{
"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"
}
}
]
}
```
Compte tenu d’une rubrique Kafka et d’une clé de partition (dans ce cas, `taskResourceId.schemaName.tableName`), l’exemple ci-dessous illustre le format d’enregistrement résultant à l’aide de nos exemples de données dans la rubrique cible 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**
+ [Restructuration de données avec le mappage d'attribut](#CHAP_Target.Kafka.AttributeMapping)
+ [Réplication à plusieurs rubriques à l’aide du mappage d’objet](#CHAP_Target.Kafka.MultiTopic)
+ [Format de message pour Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Restructuration de données avec le mappage d'attribut
Vous pouvez restructurer les données lors de leur migration vers une rubrique Kafka à l'aide d'un mappage d'attribut. Par exemple, vous pourriez vouloir regrouper plusieurs champs de la source en un seul champ dans la cible. Le mappage d'attribut suivant illustre comment restructurer les données.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Pour définir une valeur constante pour`partition-key`, spécifiez`"partition-key-type: "constant"`, cela définit la valeur de partition sur`constant`. Par exemple, vous pouvez le faire pour forcer le stockage de toutes les données dans une seule partition. Le mappage suivant illustre cette approche.
```
{
"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}"
}
]
}
}
]
}
```
**Note**
La valeur `partition-key` d'un enregistrement de contrôle correspondant à une table spécifique est `TaskId.SchemaName.TableName`. La valeur `partition-key` d'un enregistrement de contrôle correspondant à une tâche spécifique est le `TaskId` de cet enregistrement. La spécification d'une valeur `partition-key` dans le mappage d'objet n'a aucun impact sur la `partition-key` d'un enregistrement de contrôle.
Lorsqu'il `partition-key-type` est défini sur `attribute-name` dans une règle de mappage de table, vous devez spécifier`partition-key-name`, qui doit faire référence soit à une colonne de la table source, soit à une colonne personnalisée définie dans le mappage. En outre, `attribute-mappings` il doit être fourni pour définir la manière dont les colonnes source sont mappées au sujet Kafka cible.
### Réplication à plusieurs rubriques à l’aide du mappage d’objet
Par défaut, les AWS DMS tâches migrent toutes les données sources vers l'une des rubriques Kafka suivantes :
+ Comme indiqué dans le champ **Rubrique** du point de terminaison AWS DMS cible.
+ Comme indiqué par `kafka-default-topic` si le champ **Rubrique** du point de terminaison cible n’est pas renseigné et que le paramètre `auto.create.topics.enable` Kafka est défini sur `true`.
Avec les versions 3.4.6 et supérieures AWS DMS du moteur, vous pouvez utiliser l'`kafka-target-topic`attribut pour associer chaque table source migrée à une rubrique distincte. Par exemple, les règles de mappage d’objet suivantes migrent les tables sources `Customer` et `Address` vers les rubriques Kafka `customer_topic` et `address_topic`, respectivement. Dans le même temps, AWS DMS migre toutes les autres tables sources, y compris la `Bills` table du `Test` schéma, vers le sujet spécifié dans le point de terminaison cible.
```
{
"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"
}
}
]
}
```
En utilisant la réplication à plusieurs rubriques Kafka, vous pouvez regrouper et migrer les tables sources afin de séparer les rubriques Kafka à l’aide d’une seule tâche de réplication.
### Format de message pour Apache Kafka
La sortie JSON est simplement une liste de paires clé-valeur.
**RecordType**
Les enregistrements peuvent être de type Données ou Contrôle. *Les enregistrements de données* représentent les lignes réelles de la source. *Les enregistrements de contrôle* sont destinés à des événements importants dans le flux, par exemple un redémarrage de la tâche.
**Opération**
Pour les enregistrements de données, l'opération peut être `load`,`insert`, `update` ou `delete`.
Pour les enregistrements de contrôle, l’opération peut être `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` ou `column-type-change`.
**SchemaName**
Schéma source de l'enregistrement. Ce champ peut être vide pour un enregistrement de contrôle.
**TableName**
Table source de l'enregistrement. Ce champ peut être vide pour un enregistrement de contrôle.
**Horodatage**
Horodatage de la construction du message JSON. Le champ est formaté selon le format ISO 8601.
L’exemple de message JSON suivant illustre un message de type de données avec toutes les métadonnées supplémentaires.
```
{
"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"
}
}
```
L’exemple de message JSON suivant illustre un message de type contrôle.
```
{
"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"
}
}
```
# Utilisation d'un cluster Amazon OpenSearch Service comme cible pour AWS Database Migration Service
Vous pouvez l'utiliser AWS DMS pour migrer des données vers Amazon OpenSearch Service (OpenSearch Service). OpenSearch Le service est un service géré qui facilite le déploiement, l'exploitation et le dimensionnement d'un cluster OpenSearch de services.
Dans OpenSearch Service, vous travaillez avec des index et des documents. Un *index* est un ensemble de documents, et un *document* est un objet JSON contenant des valeurs scalaires, des tableaux et d'autres objets. OpenSearch fournit un langage de requête basé sur JSON, afin que vous puissiez interroger des données dans un index et récupérer les documents correspondants.
Lorsqu'il AWS DMS crée des index pour un point de terminaison cible pour OpenSearch Service, il crée un index pour chaque table à partir du point de terminaison source. Le coût de création d'un indice de OpenSearch service dépend de plusieurs facteurs. Il s'agit du nombre d'index créés, de la quantité totale de données contenues dans ces index et de la petite quantité de métadonnées OpenSearch stockées pour chaque document.
Configurez votre cluster de OpenSearch services avec des ressources de calcul et de stockage adaptées à l'étendue de votre migration. Nous vous recommandons de prendre en compte les facteurs suivants, selon la tâche de réplication que vous souhaitez utiliser :
+ Pour un chargement de données complet, tenez compte du volume total de données à migrer ainsi que de la vitesse du transfert.
+ Pour reproduire les modifications en cours, tenez compte de la fréquence des mises à jour et de vos exigences de end-to-end latence.
Configurez également les paramètres d'index sur votre OpenSearch cluster en portant une attention particulière au nombre de documents.
**Paramètres de tâche de chargement complet multithread**
Pour accélérer le transfert, AWS DMS prend en charge le chargement complet multithread vers un cluster cible de OpenSearch services. AWS DMS prend en charge ce multithreading avec des paramètres de tâche tels que les suivants :
+ `MaxFullLoadSubTasks` : utilisez cette option pour indiquer le nombre maximal de tables sources à charger en parallèle. DMS charge chaque table dans son index cible de OpenSearch service correspondant à l'aide d'une sous-tâche dédiée. La valeur par défaut est 8 ; la valeur maximale 49.
+ `ParallelLoadThreads`— Utilisez cette option pour spécifier le nombre de threads AWS DMS utilisés pour charger chaque table dans son index cible de OpenSearch service. La valeur maximale d'un objectif OpenSearch de service est de 32. Vous pouvez demander une augmentation de cette limite maximale.
**Note**
Si vous ne modifiez pas la valeur par défaut de `ParallelLoadThreads` (0), AWS DMS transfère un seul enregistrement à la fois. Cette approche impose une charge excessive à votre cluster OpenSearch de services. Veillez à définir cette option sur 1 ou plus.
+ `ParallelLoadBufferSize`— Utilisez cette option pour spécifier le nombre maximum d'enregistrements à stocker dans la mémoire tampon que les threads de chargement parallèle utilisent pour charger les données vers la cible du OpenSearch service. La valeur par défaut est 50. La valeur maximale est 1 000. Utilisez ce paramètre avec `ParallelLoadThreads`. `ParallelLoadBufferSize` est valide uniquement dans le cas de plusieurs threads.
Pour plus d'informations sur la manière dont DMS charge un cluster de OpenSearch services à l'aide du multithreading, consultez le AWS billet de blog Scale [Amazon OpenSearch Service](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) for migrations. AWS Database Migration Service
**Paramètres de tâche de chargement CDC multithread**
Vous pouvez améliorer les performances de capture des données de modification (CDC) pour un cluster cible de OpenSearch service en utilisant les paramètres des tâches pour modifier le comportement de l'appel d'`PutRecords`API. Pour ce faire, vous pouvez spécifier le nombre de threads simultanés, les files d'attente par thread et le nombre d'enregistrements à stocker dans un tampon à l'aide de la tâche `ParallelApply*`. Par exemple, supposons que vous souhaitiez effectuer un chargement CDC et appliquer 32 threads en parallèle. Vous souhaitez également accéder à 64 files d'attente par thread, avec 50 enregistrements stockés par tampon.
**Note**
Support pour l'utilisation des paramètres des `ParallelApply*` tâches pendant les points de terminaison cibles du CDC vers Amazon OpenSearch Service est disponible dans AWS DMS les versions 3.4.0 et supérieures.
Pour améliorer les performances du CDC, AWS DMS prend en charge les paramètres de tâche suivants :
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement CDC pour transférer des enregistrements de données vers un point de terminaison cible du OpenSearch service. La valeur par défaut est zéro (0) et la valeur maximale est 32.
+ `ParallelApplyBufferSize`— Spécifie le nombre maximum d'enregistrements à stocker dans chaque file d'attente tampon pour les threads simultanés à envoyer vers un point de terminaison cible du OpenSearch service lors d'un chargement CDC. La valeur par défaut est 100 et la valeur maximale est 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads.
+ `ParallelApplyQueuesPerThread`— Spécifie le nombre de files d'attente auxquelles chaque thread accède pour extraire des enregistrements de données des files d'attente et générer un chargement par lots pour un point de terminaison de OpenSearch service pendant le CDC.
Lorsque vous utilisez les paramètres de tâche `ParallelApply*`, la valeur par défaut `partition-key-type` est la valeur `primary-key` de la table, pas `schema-name.table-name`.
## Migration d'une table de base de données relationnelle vers un index de service OpenSearch
AWS DMS prend en charge la migration des données vers les OpenSearch types de données scalaires du Service. Lorsque vous migrez d'une base de données relationnelle telle qu'Oracle ou MySQL vers OpenSearch Service, vous souhaiterez peut-être restructurer la façon dont vous stockez ces données.
AWS DMS prend en charge les types de données scalaires de OpenSearch service suivants :
+ Booléen
+ Date
+ Float
+ Int
+ String
AWS DMS convertit les données de type Date en type String. Vous pouvez spécifier des mappages personnalisés pour interpréter ces dates.
AWS DMS ne prend pas en charge la migration des types de données LOB.
## Conditions préalables à l'utilisation d'Amazon OpenSearch Service comme cible pour AWS Database Migration Service
Avant de commencer à utiliser une base de données de OpenSearch service comme cible AWS DMS, assurez-vous de créer un rôle Gestion des identités et des accès AWS (IAM). Ce rôle doit permettre AWS DMS d'accéder aux index de OpenSearch service sur le point de terminaison cible. L'ensemble d'autorisations d'accès minimum est indiqué dans la stratégie IAM suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le rôle que vous utilisez pour la migration vers le OpenSearch service doit disposer des autorisations suivantes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
Dans l'exemple précédent, remplacez-le `region` par l'identifiant de AWS région, *`account-id`* par l'identifiant de votre AWS compte et `domain-name` par le nom de votre domaine Amazon OpenSearch Service. Voici un exemple : `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`.
## Paramètres du point de terminaison lors OpenSearch de l'utilisation du service comme cible pour AWS DMS
Vous pouvez utiliser les paramètres du point de terminaison pour configurer la base de données cible de votre OpenSearch service de la même manière que vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--elasticsearch-settings '{"EndpointSetting": "value", ...}'` JSON.
Le tableau suivant indique les paramètres de point de terminaison que vous pouvez utiliser avec OpenSearch Service en tant que cible.
| Nom d’attribut | Valeurs valides | Valeur par défaut et description |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Un nombre entier positif supérieur à 0, mais ne dépassant pas 100. | 10 - Pour une tâche de chargement complet, cet attribut détermine le seuil d'erreurs autorisées avant que la tâche échoue. Par exemple, supposons qu'il y a 1 500 lignes au point de terminaison source et que ce paramètre est défini sur 10. La tâche échoue alors si elle AWS DMS rencontre plus de 150 erreurs (10 % du nombre de lignes) lors de l'écriture sur le point de terminaison cible. |
| `ErrorRetryDuration` | Un nombre entier positif supérieur à 0. | 300 — Si une erreur se produit sur le point de terminaison cible, AWS DMS réessayez pendant autant de secondes. Sinon, la tâche échoue. |
| `UseNewMappingType` | true ou false | `false`, mais pour fonctionner avec opensearch v2.x, il doit être défini sur. `true` |
## Limitations liées à l'utilisation d'Amazon OpenSearch Service comme cible pour AWS Database Migration Service
Les limites suivantes s'appliquent lors de l'utilisation d'Amazon OpenSearch Service comme cible :
+ OpenSearch Le service utilise le mappage dynamique (estimation automatique) pour déterminer les types de données à utiliser pour les données migrées.
+ OpenSearch Le service enregistre chaque document avec un identifiant unique. Voici un exemple d'ID.
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Chaque ID de document compte 64 octets. Tenez-en compte dans les exigences de stockage. Par exemple, si vous migrez 100 000 lignes depuis une AWS DMS source, l'index de OpenSearch service obtenu nécessite un stockage de 6 400 000 octets supplémentaires.
+ Avec OpenSearch Service, vous ne pouvez pas mettre à jour les attributs de la clé primaire. Cette restriction est importante lors de l'utilisation de la réplication continue avec la capture des données modifiées (CDC), car elle peut entraîner des données non souhaitées dans la cible. En mode CDC, les clés primaires sont mappées à SHA256 des valeurs de 32 octets. Elles sont converties en chaînes de 64 octets lisibles par l'homme et sont utilisées comme document de OpenSearch service. IDs
+ Si AWS DMS des éléments ne peuvent pas être migrés, il écrit des messages d'erreur dans Amazon CloudWatch Logs. Ce comportement est différent de celui des autres points de terminaison AWS DMS cibles, qui écrivent des erreurs dans une table d'exceptions.
+ AWS DMS ne prend pas en charge la connexion à un cluster Amazon ES sur lequel le contrôle d'accès détaillé est activé avec un utilisateur principal et un mot de passe.
+ AWS DMS ne prend pas en charge OpenSearch le service sans serveur.
+ OpenSearch Le service ne prend pas en charge l'écriture de données dans des index préexistants.
+ Le paramètre de tâche de réplication n'`TargetTablePrepMode:TRUNCATE_BEFORE_LOAD`est pas pris en charge pour une utilisation avec un point de terminaison OpenSearch cible.
+ Lorsque vous migrez des données vers Amazon Elasticsearch à l'aide de AWS DMS, les données source doivent comporter une clé primaire ou une colonne d'identifiant unique. Si les données source ne possèdent pas de clé primaire ou d'identifiant unique, vous devez en définir un à l'aide de la règle de define-primary-key transformation.
## Types de données cibles pour Amazon OpenSearch Service
Lors de AWS DMS la migration de données à partir de bases de données hétérogènes, le service fait correspondre les types de données de la base de données source à des types de données intermédiaires appelés types de AWS DMS données. Le service mappe ensuite les types de données intermédiaires vers les types de données cibles. Le tableau suivant indique chaque type de AWS DMS données et le type de données auquel il correspond dans OpenSearch Service.
| AWS DMS type de données | OpenSearch Type de données de service |
| --- | --- |
| Booléen | boolean |
| Date | chaîne |
| Heure | date |
| Horodatage | date |
| INT4 | entier |
| Real4 | float |
| UINT4 | entier |
Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Utilisation d'Amazon DocumentDB comme cible pour le service de migration de AWS base de données
Pour plus d'informations sur les versions d'Amazon DocumentDB (compatibles avec MongoDB) prises en charge, consultez. AWS DMS [Objectifs pour AWS DMS](CHAP_Introduction.Targets.md) Vous pouvez utiliser AWS DMS pour migrer des données vers Amazon DocumentDB (compatible avec MongoDB) à partir de tout moteur de données source pris en charge par AWS DMS . Le moteur source peut se trouver sur un service AWS géré tel qu'Amazon RDS, Aurora ou Amazon S3. Le moteur peut également se trouver sur une base de données autogérée, telle que MongoDB, qui s’exécute sur Amazon EC2 ou sur site.
Vous pouvez l'utiliser AWS DMS pour répliquer les données sources vers des bases de données, des collections ou des documents Amazon DocumentDB.
**Note**
Si votre point de terminaison source est MongoDB ou Amazon DocumentDB, exécutez la migration en **mode document**.
MongoDB stocke les données au format binaire JSON (BSON). AWS DMS prend en charge tous les types de données BSON pris en charge par Amazon DocumentDB. Pour obtenir la liste de ces types de données, consultez la section [MongoDB APIs, opérations et types de données pris en charge](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) dans *le manuel Amazon DocumentDB Developer Guide*.
Si le point de terminaison source est une base de données relationnelle, AWS DMS mappe les objets de base de données vers Amazon DocumentDB comme suit :
+ Une base de données relationnelle, ou schéma de base de données, est mappée à une *base de données* Amazon DocumentDB.
+ Les tables situées dans une base de données relationnelle sont mappées à des *collections* dans Amazon DocumentDB.
+ Les enregistrements situés dans une table relationnelle sont mappés à des *documents* dans Amazon DocumentDB. Chaque document est construit à partir de données de l'enregistrement source.
Si le point de terminaison source est Amazon S3, les objets Amazon DocumentDB résultants correspondent aux règles de mappage AWS DMS pour Amazon S3. Prenons l'exemple de l'URI suivant :
```
s3://amzn-s3-demo-bucket/hr/employee
```
Dans ce cas, AWS DMS mappe les objets dans `amzn-s3-demo-bucket` Amazon DocumentDB comme suit :
+ La partie supérieure de l’URI (`hr`) est mappée à une base de données Amazon DocumentDB.
+ La partie suivante de l’URI (`employee`) est mappée à une collection Amazon DocumentDB.
+ Chaque objet de `employee` est mappé à un document dans Amazon DocumentDB.
Pour plus d’informations sur les règles de mappage pour Amazon S3, consultez [Utilisation d'Amazon S3 comme source pour AWS DMS](CHAP_Source.S3.md).
**Paramètres de point de terminaison Amazon DocumentDB**
Dans AWS DMS les versions 3.5.0 et supérieures, vous pouvez améliorer les performances de capture des données de modification (CDC) pour les points de terminaison Amazon DocumentDB en ajustant les paramètres des tâches pour les threads parallèles et les opérations en masse. Pour ce faire, vous pouvez spécifier le nombre de threads simultanés, les files d'attente par thread et le nombre d'enregistrements à stocker dans un tampon à l'aide de la tâche `ParallelApply*`. Par exemple, supposons que vous souhaitiez effectuer un chargement CDC et appliquer 128 threads en parallèle. Vous souhaitez également accéder à 64 files d'attente par thread, avec 50 enregistrements stockés par tampon.
Pour améliorer les performances du CDC, AWS DMS prend en charge les paramètres de tâche suivants :
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement CDC pour transférer des enregistrements de données vers un point de terminaison cible Amazon DocumentDB. La valeur par défaut est zéro (0) et la valeur maximale est 32.
+ `ParallelApplyBufferSize` : spécifie le nombre maximal d’enregistrements à stocker dans chaque file d’attente de mémoire tampon pour que les threads simultanés soient transférés vers un point de terminaison cible Amazon DocumentDB lors d’un chargement CDC. La valeur par défaut est 100 et la valeur maximale est 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads.
+ `ParallelApplyQueuesPerThread` : spécifie le nombre de files d’attente auxquelles chaque thread accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour un point de terminaison Amazon DocumentDB pendant la CDC. La valeur par défaut est 1. La valeur maximale est 512.
**Note**
Pour les cibles Amazon DocumentDB, l'application CDC parallèle peut provoquer des erreurs clés dupliquées ou bloquer l'application CDC pour les charges de travail qui utilisent des index uniques secondaires ou nécessitent un ordre strict des modifications. Utilisez la configuration d'application CDC à thread unique par défaut pour ces charges de travail.
Pour plus d'informations sur l'utilisation d'Amazon DocumentDB comme cible pour AWS DMS, consultez les sections suivantes :
**Topics**
+ [Mappage de données d’une source vers une cible Amazon DocumentDB](#CHAP_Target.DocumentDB.data-mapping)
+ [Connexion aux clusters Elastic Amazon DocumentDB en tant que cible](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Réplication continue avec Amazon DocumentDB en tant que cible](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Limitations de l’utilisation d’Amazon DocumentDB en tant que cible](#CHAP_Target.DocumentDB.limitations)
+ [Utilisation des paramètres de point de terminaison avec Amazon DocumentDB en tant que cible](#CHAP_Target.DocumentDB.ECAs)
+ [Types de données cibles pour Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**Note**
Pour une step-by-step présentation détaillée du processus de migration, consultez la section [Migration de MongoDB vers Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html) dans le guide de migration. AWS Database Migration Service Step-by-Step
## Mappage de données d’une source vers une cible Amazon DocumentDB
AWS DMS lit les enregistrements depuis le point de terminaison source et construit des documents JSON en fonction des données qu'il lit. Pour chaque document JSON, vous AWS DMS devez déterminer un `_id` champ qui servira d'identifiant unique. Il écrit ensuite le document JSON dans une collection Amazon DocumentDB en utilisant le champ `_id` comme clé primaire.
### Données source se composant d'une colonne unique
Si les données source se composent d'une seule colonne, elles doivent être de type string (chaîne). (Selon le moteur source, le type de données réel peut être VARCHAR, NVARCHAR, TEXT, LOB, CLOB ou similaire.) AWS DMS suppose que les données sont un document JSON valide et les réplique telles quelles vers Amazon DocumentDB.
Si le document JSON résultant contient un champ nommé `_id`, ce dernier est utilisé comme `_id` unique dans Amazon DocumentDB.
Si le document JSON ne contient pas de champ `_id`, Amazon DocumentDB génère une valeur `_id` automatiquement.
### Données source se composant de plusieurs colonnes
Si les données source se composent de plusieurs colonnes, crée AWS DMS un document JSON à partir de toutes ces colonnes. Pour déterminer le `_id` champ du document, AWS DMS procédez comme suit :
+ Si l'une des colonnes est nommée `_id`, les données de cette colonne sont utilisées comme `_id` cible.
+ S'il n'y a pas de `_id` colonne, mais que les données source possèdent une clé primaire ou un index unique, AWS DMS utilise cette clé ou cette valeur d'index comme `_id` valeur. Les données de la clé primaire ou de l'index unique apparaissent également sous forme de champs explicites dans le document JSON.
+ S’il n’y a pas de colonne `_id` et aucune clé primaire ni aucun index unique, Amazon DocumentDB génère une valeur `_id` automatiquement.
### Imposition d'un type de données au niveau du point de terminaison cible
AWS DMS peut modifier les structures de données lorsqu'il écrit sur un point de terminaison cible Amazon DocumentDB. Vous pouvez demander ces modifications en renommant des colonnes et des tables au niveau du point de terminaison source ou en fournissant des règles de transformation qui sont appliquées lorsqu'une tâche est en cours d'exécution.
#### Utilisation d'un document JSON imbriqué (préfixe json\$1)
Pour imposer un type de données, vous pouvez préfixer le nom de colonne source avec `json_` (c'est-à-dire, `json_columnName`), manuellement ou à l'aide d'une transformation. Dans ce cas, la colonne est créée sous la forme d'un document JSON imbriqué dans le document cible, plutôt que sous la forme d'un champ de chaîne.
Par exemple, supposons que vous souhaitiez migrer le document suivant à partir d'un point de terminaison source MongoDB.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Si vous n'imposez aucun des types de données source, le document `ContactDetails` imbriqué est migré sous la forme d'une chaîne.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
Toutefois, vous pouvez ajouter une règle de transformation pour contraindre l'insertion de `ContactDetails` dans un objet JSON. Par exemple, supposons que le nom de la colonne source d'origine est `ContactDetails`. Pour forcer le type de données en tant que JSON imbriqué, la colonne du point de terminaison de la source doit être renommée « json\$1 ContactDetails » soit en ajoutant le préfixe « \$1json\$1\$1 » sur la source manuellement, soit par le biais de règles de transformation. Par exemple, vous pouvez utiliser la règle de transformation ci-dessous :
```
{
"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 réplique le ContactDetails champ en tant que JSON imbriqué, comme suit.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Utilisation d'un tableau JSON (préfixe array\$1)
Pour imposer un type de données, vous pouvez préfixer un nom de colonne avec `array_` (c'est-à-dire, `array_columnName`), manuellement ou à l'aide d'une transformation. Dans ce cas, AWS DMS considère la colonne comme un tableau JSON et la crée comme telle dans le document cible.
Supposons que vous souhaitiez migrer le document suivant à partir d'un point de terminaison source MongoDB.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Si vous n'imposez aucun des types de données source, le document `ContactDetails` imbriqué est migré sous la forme d'une chaîne.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
Toutefois, vous pouvez ajouter des règles de transformation pour forcer l'insertion de `ContactAddress` et de `ContactPhoneNumbers` dans des tableaux JSON, comme illustré dans le tableau suivant.
****
| Nom de la colonne source d'origine | Colonne source renommée |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS se reproduit `ContactAddress` et `ContactPhoneNumbers` comme suit.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Connexion à Amazon DocumentDB à l’aide du protocole TLS
Par défaut, un cluster Amazon DocumentDB récemment créé n’accepte que les connexions sécurisées qui utilisent le protocole TLS (Transport Layer Security). Lorsque le protocole TLS est activé, chaque connexion à Amazon DocumentDB nécessite une clé publique.
Vous pouvez récupérer la clé publique d'Amazon DocumentDB en téléchargeant le fichier depuis un compartiment Amazon S3 AWS hébergé. `rds-combined-ca-bundle.pem` Pour plus d’informations sur le téléchargement de ce fichier, consultez [Chiffrement des connexions à l’aide de TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) dans le *Guide du développeur Amazon DocumentDB*.
Après avoir téléchargé ce fichier .pem, vous pouvez importer la clé publique qu'il contient AWS DMS comme décrit ci-dessous.
#### AWS Management Console
**Pour importer le fichier de clé publique (.pem)**
1. Ouvrez la AWS DMS console à l'adresse [https://console.aws.amazon.com/dms](https://console.aws.amazon.com/dms).
1. Dans le volet de navigation, choisissez **Certificates**.
1. Choisissez l'onglet **Import certificate (Importer le certificat)** et effectuez les opérations suivantes :
+ Pour **Certificate identifier (Identifiant de certificat)**, entrez un nom unique pour le certificat, par exemple, `docdb-cert`.
+ Pour **Import file (Importer un fichier)**, accédez à l'emplacement où vous avez enregistré le fichier .pem.
Lorsque les paramètres vous conviennent, choisissez **Add new CA certificate (Ajouter un nouveau certificat CA)**.
#### AWS CLI
Utilisez la commande `aws dms import-certificate`, comme illustré dans l’exemple suivant.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Lorsque vous créez un point de terminaison AWS DMS cible, fournissez l'identifiant du certificat (par exemple,`docdb-cert`). Définissez aussi le paramètre de mode SSL sur `verify-full`.
## Connexion aux clusters Elastic Amazon DocumentDB en tant que cible
Dans AWS DMS les versions 3.4.7 et supérieures, vous pouvez créer un point de terminaison cible Amazon DocumentDB en tant que cluster élastique. Si vous créez votre point de terminaison cible en tant que cluster Elastic, vous devez attacher un nouveau certificat SSL au point de terminaison de votre cluster Elastic Amazon DocumentDB, car votre certificat SSL existant ne fonctionnera pas.
**Pour attacher un nouveau certificat SSL au point de terminaison de votre cluster Elastic Amazon DocumentDB**
1. Dans un navigateur, ouvrez [ https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) et enregistrez le contenu dans un `.pem` fichier portant un nom de fichier unique, par exemple. `SFSRootCAG2.pem` Il s’agit du fichier de certificat que vous devrez importer lors des étapes suivantes.
1. Créez le point de terminaison de cluster Elastic et définissez les options suivantes :
1. Sous **Configuration du point de terminaison**, choisissez **Ajouter un certificat CA**.
1. Pour **Identifiant de certificat**, entrez **SFSRootCAG2.pem**.
1. Pour **Importer un fichier de certificat**, choisissez **Choisir un fichier** et accédez au fichier `SFSRootCAG2.pem` que vous avez téléchargé précédemment.
1. Sélectionnez et ouvrez le fichier `SFSRootCAG2.pem` téléchargé.
1. Sélectionnez **Importer un certificat**.
1. Dans le menu déroulant **Choisir un certificat**, sélectionnez **SFSRootCAG2.pem.**
Le nouveau certificat SSL issu du fichier `SFSRootCAG2.pem` téléchargé est désormais attaché au point de terminaison de votre cluster Elastic Amazon DocumentDB.
## Réplication continue avec Amazon DocumentDB en tant que cible
Si la réplication continue (capture des données de modification, CDC) est activée pour Amazon DocumentDB en tant que cible, AWS DMS versions 3.5.0 et ultérieures fournit une amélioration des performances vingt fois supérieure à celle des versions précédentes. Dans les versions précédentes, AWS DMS qui géraient jusqu'à 250 enregistrements par seconde, AWS DMS traitaient désormais efficacement plus de 5 000 enregistrements par seconde. AWS DMS garantit également que les documents d'Amazon DocumentDB restent synchronisés avec la source. Lorsqu'un enregistrement source est créé ou mis à jour, vous AWS DMS devez d'abord déterminer quel enregistrement Amazon DocumentDB est concerné en procédant comme suit :
+ Si l’enregistrement source comporte une colonne nommée `_id`, la valeur de cette colonne détermine la valeur `_id` correspondante dans la collection Amazon DocumentDB.
+ S'il n'y a pas de `_id` colonne, mais que les données source possèdent une clé primaire ou un index unique, elles AWS DMS utilisent cette clé ou cette valeur d'index `_id` pour la collection Amazon DocumentDB.
+ Si l'enregistrement source ne contient pas de `_id` colonne, de clé primaire ou d'index unique, toutes les colonnes source AWS DMS correspondent aux champs correspondants de la collection Amazon DocumentDB.
Lorsqu'un nouvel enregistrement source est créé, AWS DMS écrit un document correspondant dans Amazon DocumentDB. Si un enregistrement source existant est mis à jour, AWS DMS met à jour les champs correspondants dans le document cible dans Amazon DocumentDB. Tous les champs qui existent dans le document cible, mais pas dans l'enregistrement source, restent intacts.
Lorsqu'un enregistrement source est supprimé, le document correspondant AWS DMS est supprimé d'Amazon DocumentDB.
### Modifications structurelles (DDL) à la source
Avec la réplication continue, les modifications des structures de données source (telles que les tables, colonnes, etc.) sont propagées à leurs homologues dans Amazon DocumentDB. Dans les bases de données relationnelles, ces modifications sont lancées à l'aide d'instructions DDL (Data Definition Language). Vous pouvez voir comment ces modifications sont AWS DMS répercutées sur Amazon DocumentDB dans le tableau suivant.
****
| DDL à la source | Effet sur la cible Amazon DocumentDB |
| --- | --- |
| CREATE TABLE | Crée une collection vide. |
| Déclaration qui renomme une table (RENAME TABLE, ALTER TABLE...RENAME, etc.) | Renomme la collection. |
| TRUNCATE TABLE | Supprime tous les documents de la collection, mais uniquement si HandleSourceTableTruncated a pour valeur true. Pour de plus amples informations, veuillez consulter [Paramètres de tâche pour la gestion du DDL de traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Supprime la collection, mais uniquement si HandleSourceTableDropped a pour valeur true. Pour de plus amples informations, veuillez consulter [Paramètres de tâche pour la gestion du DDL de traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Instruction qui ajoute une colonne à une table (ALTER TABLE...ADD, etc.) | L'instruction DDL est ignorée et un avertissement est émis. Lorsque la première instruction INSERT est exécutée à la source, le nouveau champ est ajouté au document cible. |
| ALTER TABLE...RENAME COLUMN | L'instruction DDL est ignorée et un avertissement est émis. Lorsque la première instruction INSERT est exécutée à la source, le nouveau champ est ajouté au document cible. |
| ALTER TABLE...DROP COLUMN | L'instruction DDL est ignorée et un avertissement est émis. |
| Déclaration qui modifie le type de données de la colonne (ALTER COLUMN...MODIFY, etc.) | L'instruction DDL est ignorée et un avertissement est émis. Lorsque la première instruction INSERT est exécutée à la source avec le nouveau type de données, le document cible est créé avec un champ ayant ce nouveau type de données. |
## Limitations de l’utilisation d’Amazon DocumentDB en tant que cible
Les limites suivantes s'appliquent lors de l'utilisation d'Amazon DocumentDB comme cible pour : AWS DMS
+ Dans Amazon DocumentDB, les noms de collection ne peuvent pas contenir le symbole du dollar (\$1). En outre, les noms de base de données ne peuvent pas contenir de caractères Unicode.
+ AWS DMS ne prend pas en charge la fusion de plusieurs tables sources dans une seule collection Amazon DocumentDB.
+ Lorsque AWS DMS des processus sont modifiés à partir d'une table source dépourvue de clé primaire, toutes les colonnes LOB de cette table sont ignorées.
+ Si l'option **Change table (Modifier la table)** est activée et que AWS DMS rencontre une colonne source nommée « *\$1id* », cette colonne apparaît sous la forme « *\$1\$1id* » (deux traits de soulignement) dans la table modifiée.
+ Si vous choisissez Oracle comme point de terminaison source, une journalisation supplémentaire complète doit être activée sur la source Oracle. Dans le cas contraire, s’il existe des colonnes à la source qui n’ont pas été modifiées, les données seront chargées dans Amazon DocumentDB tant que valeurs nulles.
+ Le paramètre de tâche de réplication `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` n’est pas pris en charge pour une utilisation avec un point de terminaison cible DocumentDB.
+ Les collections plafonnées MongoDB ne sont pas prises en charge dans Amazon DocumentDB. Cependant, migre AWS DMS automatiquement les objets tels que les collections non plafonnées sur la DocumentDB cible.
+ L'application parallèle du CDC aux cibles Amazon DocumentDB peut provoquer des erreurs clés dupliquées ou bloquer l'application CDC pour les charges de travail qui utilisent des index uniques secondaires ou nécessitent un ordre strict des modifications. Pour de telles charges de travail, utilisez la configuration d'application CDC à thread unique par défaut.
## Utilisation des paramètres de point de terminaison avec Amazon DocumentDB en tant que cible
Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données cible Amazon DocumentDB comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON.
Les paramètres de point de terminaison que vous pouvez utiliser avec Amazon DocumentDB en tant que cible sont indiqués dans le tableau suivant.
| Nom d’attribut | Valeurs valides | Valeur par défaut et description |
| --- | --- | --- |
| `replicateShardCollections` | boolean `true` `false` | Lorsque ce paramètre de point de terminaison est défini sur `true`, il a les effets suivants et impose les limitations suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Types de données cibles pour Amazon DocumentDB
Dans le tableau suivant, vous trouverez les types de données cibles Amazon DocumentDB pris en charge lors de l'utilisation de AWS DMS, ainsi que le mappage par défaut à partir des types de données AWS DMS. Pour plus d'informations sur les types de données AWS DMS, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS Type de données DMS | Type de données Amazon DocumentDB |
| --- | --- |
| BOOLEAN | Booléen |
| BYTES | Données binaires |
| DATE | Date |
| TIME | Chaîne (UTF8) |
| DATETIME | Date |
| INT1 | Entier 32 bits |
| INT2 | Entier 32 bits |
| INT4 | Entier 32 bits |
| INT8 | Entier 64 bits |
| NUMERIC | Chaîne (UTF8) |
| REAL4 | Double |
| REAL8 | Double |
| CHAÎNE | Si les données sont reconnues en tant que JSON, elles sont AWS DMS migrées vers Amazon DocumentDB sous forme de document. Sinon, les données sont mappées à String (UTF8). |
| UINT1 | Entier 32 bits |
| UINT2 | Entier 32 bits |
| UINT4 | Entier 64 bits |
| UINT8 | Chaîne (UTF8) |
| WSTRING | Si les données sont reconnues en tant que JSON, elles sont AWS DMS migrées vers Amazon DocumentDB sous forme de document. Sinon, les données sont mappées à String (UTF8). |
| BLOB | Binaire |
| CLOB | Si les données sont reconnues en tant que JSON, elles sont AWS DMS migrées vers Amazon DocumentDB sous forme de document. Sinon, les données sont mappées à String (UTF8). |
| NCLOB | Si les données sont reconnues en tant que JSON, elles sont AWS DMS migrées vers Amazon DocumentDB sous forme de document. Sinon, les données sont mappées à String (UTF8). |
# Utiliser Amazon Neptune comme cible pour AWS Database Migration Service
Amazon Neptune est un service de base de données orientée graphe entièrement géré et fiable, qui facilite la création et l'exécution d'applications fonctionnant avec des jeux de données hautement connectés. Le cœur de Neptune est un moteur de base de données orientée graphe spécialisé et hautes performances. Ce moteur est optimisé pour le stockage de milliards de relations et l’interrogation du graphe avec une latence de l’ordre de quelques millisecondes. Neptune prend en charge les langages de requête graphique populaires Apache TinkerPop Gremlin et le SPARQL du W3C. Pour plus d’informations sur Amazon Neptune, consultez [Qu’est-ce qu’Amazon Neptune ?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) dans le *Guide de l’utilisateur Amazon Neptune*.
Sans une base de données orientée graphe telle que Neptune, vous modélisez probablement des données hautement connectées dans une base de données relationnelle. Étant donné que les données ont des connexions potentiellement dynamiques, les applications qui utilisent de telles sources de données doivent modéliser les requêtes de données connectées dans SQL. Cette approche nécessite que vous écriviez une couche supplémentaire pour convertir les requêtes de graphe en SQL. En outre, les bases de données relationnelles sont dotées d'une rigidité de schéma. Toute modification du schéma pour modéliser les connexions changeantes nécessite des temps d'arrêt et une maintenance supplémentaire de la conversion de requête pour prendre en charge le nouveau schéma. Les performances des requêtes sont également une autre contrainte importante à prendre en compte lors de la conception de vos applications.
Les bases de données graphiques peuvent grandement simplifier de telles situations. Libre d'un schéma, une couche de requête graphique enrichie (Gremlin ou SPARQL) et des index optimisés pour les requêtes graphiques augmentent la flexibilité et les performances. La base de données orientée graphe Amazon Neptune comporte également des fonctionnalités d’entreprise telles que le chiffrement au repos, une couche d’autorisation sécurisée, les sauvegardes par défaut, la prise en charge de Multi-AZ, la prise en charge de réplicas en lecture, etc.
Vous pouvez AWS DMS ainsi migrer des données relationnelles modélisant un graphe hautement connecté vers un point de terminaison cible Neptune à partir d'un point de terminaison source DMS pour n'importe quelle base de données SQL prise en charge.
Pour plus de détails, consultez les sections suivantes.
**Topics**
+ [Vue d’ensemble de la migration vers Amazon Neptune en tant que cible](#CHAP_Target.Neptune.MigrationOverview)
+ [Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.EndpointSettings)
+ [Création d’une fonction de service IAM pour l’accès à Amazon Neptune en tant que cible](#CHAP_Target.Neptune.ServiceRole)
+ [Spécification de règles de mappage de graphe à l’aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.GraphMapping)
+ [Types de données pour la migration Gremlin et R2RML vers Amazon Neptune en tant que cible](#CHAP_Target.Neptune.DataTypes)
+ [Limitations de l’utilisation d’Amazon Neptune en tant que cible](#CHAP_Target.Neptune.Limitations)
## Vue d’ensemble de la migration vers Amazon Neptune en tant que cible
Avant de commencer une migration vers une cible Neptune, créez les ressources suivantes dans votre AWS compte :
+ Un cluster Neptune pour le point de terminaison cible.
+ Une base de données relationnelle SQL prise en charge par le point AWS DMS de terminaison source.
+ Un compartiment Amazon S3 pour le point de terminaison cible. Créez ce compartiment S3 dans la même AWS région que votre cluster Neptune. AWS DMS utilise ce compartiment S3 comme stockage de fichiers intermédiaire pour les données cibles qu'il charge en masse dans la base de données Neptune. Pour plus d’informations sur la création d’un compartiment S3, consultez [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
+ Un point de terminaison de cloud privé virtuel (VPC) pour S3 dans le même VPC que le cluster Neptune.
+ Rôle Gestion des identités et des accès AWS (IAM) qui inclut une politique IAM. Cette stratégie doit spécifier les autorisations `GetObject`, `PutObject`, `DeleteObject` et `ListObject` pour le compartiment S3 pour votre point de terminaison cible. Ce rôle est assumé à la fois par Neptune AWS DMS et par Neptune avec un accès IAM au compartiment S3 cible et à la base de données Neptune. Pour de plus amples informations, veuillez consulter [Création d’une fonction de service IAM pour l’accès à Amazon Neptune en tant que cible](#CHAP_Target.Neptune.ServiceRole).
Une fois ces ressources disponibles, la configuration et le démarrage d’une migration vers une cible Neptune sont similaires à toute migration de chargement complet à l’aide de la console ou de l’API DMS. Toutefois, une migration vers une cible Neptune nécessite des étapes uniques.
**Pour migrer une base de données AWS DMS relationnelle vers Neptune**
1. Créez une instance de réplication comme décrit dans [Création d'une instance de réplication](CHAP_ReplicationInstance.Creating.md).
1. Créez et testez une base de données relationnelle SQL prise en charge par le point AWS DMS de terminaison source.
1. Créez et testez le point de terminaison cible pour la base de données Neptune.
Pour connecter le point de terminaison cible à la base de données Neptune, spécifiez le nom du serveur pour le point de terminaison du cluster Neptune ou le point de terminaison de l’instance d’écriture Neptune. Spécifiez également le dossier du compartiment S3 AWS DMS pour stocker ses fichiers intermédiaires à charger en bloc dans la base de données Neptune.
Pendant la migration, AWS DMS stocke toutes les données cibles migrées dans ce dossier de compartiment S3 jusqu'à la taille de fichier maximale que vous spécifiez. Lorsque ce stockage de fichiers atteint cette taille maximale, charge AWS DMS en bloc les données S3 stockées dans la base de données cible. Il efface le dossier pour permettre le stockage de toutes les données cibles supplémentaires pour le chargement ultérieur dans la base de données cible. Pour de plus amples informations sur la spécification de ces paramètres, veuillez consulter [Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.EndpointSettings).
1. Créez une tâche de réplication à chargement complet avec les ressources créées aux étapes 1 à 3 et procédez comme suit :
1. Utilisez le mappage de tables de tâches comme d'habitude pour identifier des schémas, tables et vues sources spécifiques à migrer depuis votre base de données relationnelle à l'aide de règles de sélection et de transformation appropriées. Pour de plus amples informations, veuillez consulter [Utilisation du mappage de table pour spécifier des paramètres de tâche](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Spécifiez les mappages de cible en choisissant l’une des options suivantes pour spécifier les règles de mappage à partir de tables et de vues sources vers votre graphe de base de données cible Neptune :
+ Gremlin JSON : pour en savoir plus sur l’utilisation de Gremlin JSON pour charger une base de données Neptune, consultez [Format des données de chargement Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) dans le *Guide de l’utilisateur Amazon Neptune*.
+ SPARQL RDB to Resource Description Framework Mapping Language (R2RML) : pour en savoir plus sur l’utilisation de SPARQL R2RML, consultez la spécification W3C [R2RML: RDB to RDF mapping language](https://www.w3.org/TR/r2rml/).
1. Effectuez l’une des actions suivantes :
+ À l'aide de la AWS DMS console, spécifiez les options de mappage de graphes à l'aide des **règles de mappage de graphes** sur la page **Créer une tâche de migration de base de données**.
+ À l'aide de l' AWS DMS API, spécifiez ces options à l'aide du paramètre de `TaskData` requête de l'appel d'`CreateReplicationTask`API.
Pour de plus amples informations et consulter des exemples utilisant Gremlin JSON et SPARQL R2RML afin de spécifier des règles de mappage graphique, veuillez consulter [Spécification de règles de mappage de graphe à l’aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.GraphMapping).
1. Démarrez la réplication de votre tâche de migration.
## Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible
Pour créer ou modifier un point de terminaison cible, vous pouvez utiliser la console, `CreateEndpoint` ou les opérations d'API `ModifyEndpoint`.
**Pour une cible Neptune dans la AWS DMS console, spécifiez les **paramètres spécifiques au point de terminaison sur la page Créer un point** **de terminaison ou Modifier un point de terminaison**.** Pour `CreateEndpoint` et `ModifyEndpoint`, spécifiez les paramètres de demande pour l'option `NeptuneSettings`. L’exemple suivant montre comment procéder à l’aide de l’interface de ligne de commande.
```
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}‘
```
Ici, l’option `--server-name` de l’interface CLI spécifie le nom du serveur pour le point de terminaison d’écriture de cluster Neptune. Vous pouvez également spécifier le nom du serveur pour un point de terminaison d’instance d’écriture Neptune.
Les paramètres de demande d'option `--neptune-settings` sont les suivants :
+ `ServiceAccessRoleArn` : (Obligatoire) Amazon Resource Name (ARN) de la fonction de service que vous avez créée pour le point de terminaison cible Neptune. Pour de plus amples informations, veuillez consulter [Création d’une fonction de service IAM pour l’accès à Amazon Neptune en tant que cible](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName` : (Obligatoire) nom du compartiment S3 dans lequel DMS peut stocker temporairement des données de graphe migrées dans des fichiers .csv avant de les charger en bloc dans la base de données cible Neptune. DMS mappe les données source SQL aux données de graphique avant de les stocker dans ces fichiers .csv.
+ `S3BucketFolder` : (Obligatoire) chemin d’accès au dossier dans lequel vous souhaitez que DMS stocke les données de graphe migrées dans le compartiment S3 spécifié par `S3BucketName`.
+ `ErrorRetryDuration` : (Facultatif) nombre de millisecondes pendant lesquelles DMS doit attendre pour réessayer une charge groupée de données de graphe migrées vers la base de données cible Neptune avant de déclencher une erreur. La valeur par défaut est 250.
+ `MaxFileSize` : (Facultatif) taille maximale en Ko de données de graphe migrées stockées dans un fichier .csv avant que DMS charge en bloc les données dans la base de données cible Neptune. La valeur par défaut est de 1 048 576 Ko (1 Go). En cas de succès, DMS efface le compartiment, prêt à stocker le prochain lot de données de graphique migrées.
+ `MaxRetryCount` : (Facultatif) nombre de fois où DMS peut réessayer une charge en bloc de données de graphe migrées vers la base de données cible Neptune avant de déclencher une erreur. La valeur par défaut est 5.
+ `IAMAuthEnabled` : (Facultatif) si vous souhaitez que l’autorisation IAM soit activée pour ce point de terminaison, définissez ce paramètre sur `true` et attachez le document de politique IAM approprié à votre fonction de service spécifié par `ServiceAccessRoleArn`. La valeur par défaut est `false`.
## Création d’une fonction de service IAM pour l’accès à Amazon Neptune en tant que cible
Pour accéder à Neptune en tant que cible, créez un rôle de service à l'aide d'IAM. Selon la configuration du point de terminaison Neptune, attachez à ce rôle une partie ou la totalité des documents de politique IAM et d’approbation suivants. Lorsque vous créez le point de terminaison Neptune, vous fournissez l’ARN de cette fonction de service. Cela permet à Amazon Neptune AWS DMS d'obtenir les autorisations nécessaires pour accéder à la fois à Neptune et à son compartiment Amazon S3 associé.
Si vous définissez le paramètre `IAMAuthEnabled` dans `NeptuneSettings` sur `true` dans votre configuration de point de terminaison Neptune, attachez une politique IAM telle que la suivante à votre fonction de service. Si vous définissez `IAMAuthEnabled` sur `false`, vous pouvez ignorer cette stratégie.
```
// 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/*"
}
]
}
```
La politique IAM précédente permet un accès complet au cluster cible Neptune spécifié par `Resource`.
Joignez une stratégie IAM telle que la suivante à votre rôle de service. Cette stratégie permet à DMS de stocker temporairement des données de graphe migrées dans le compartiment S3 que vous avez créé pour le chargement en bloc dans la base de données cible Neptune.
```
//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/"
]
}
]
}
```
La politique IAM précédente permet à votre compte d’interroger le contenu du compartiment S3 (`arn:aws:s3:::amzn-s3-demo-bucket`) créé pour votre cible Neptune. Elle permet également à votre compte de fonctionner pleinement sur le contenu de tous les fichiers et dossiers de compartiment (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Modifiez la relation de confiance et associez le rôle IAM suivant à votre rôle de service pour permettre à la fois au service de base de données Amazon Neptune AWS DMS et Amazon Neptune d'assumer ce rôle.
------
#### [ 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"
}
]
}
```
------
Pour en savoir plus sur la spécification de cette fonction de service pour votre point de terminaison cible Neptune, consultez [Spécification des paramètres de point de terminaison pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.EndpointSettings).
## Spécification de règles de mappage de graphe à l’aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible
Les règles de mappage de graphe que vous créez spécifient comment les données extraites d’une source de base de données relationnelle SQL sont chargées dans une cible de cluster de base de données Neptune. Le format de ces règles de mappage varie selon qu'elles concernent le chargement de données de graphes de propriétés à l'aide d'Apache TinkerPop Gremlin ou de données du Resource Description Framework (RDF) à l'aide de R2RML. Vous trouverez ci-dessous des informations sur ces formats et sur les autres ressources disponibles.
Vous pouvez spécifier ces règles de mappage lorsque vous créez la tâche de migration à l'aide de la console ou de l'API DMS.
À l'aide de la console, spécifiez ces règles de mappage à l'aide des **règles de mappage de graphique** sur la page **Créer une tâche de migration de base de données**. Dans **Règles de mappage de graphique**, vous pouvez entrer et modifier les règles de mappage directement à l'aide de l'éditeur fourni. Vous pouvez également rechercher un fichier contenant les règles de mappage dans le format de mappage de graphique approprié.
À l'aide de l'API, spécifiez ces options à l'aide du paramètre de demande `TaskData` de l'appel d'API `CreateReplicationTask`. Définissez `TaskData` sur le chemin d'accès d'un fichier contenant les règles de mappage dans le format de mappage de graphique approprié.
### Règles de mappage de graphique pour générer des données de graphique de propriétés à l'aide de Gremlin
À l'aide de Gremlin pour générer les données du graphique de propriétés, spécifiez un objet JSON avec une règle de mappage pour chaque entité de graphique à générer à partir des données source. Le format de ce code JSON est défini spécifiquement pour charger Amazon Neptune en bloc. Le modèle suivant montre à quoi ressemble chaque règle de cet objet.
```
{
"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)"
}
]
}
]
}
]
}
```
La présence d'une étiquette de sommet implique que le sommet est créé ici. Son absence implique que le sommet est créé par une source différente, et cette définition n'ajoute que des propriétés de sommet. Spécifiez autant de définitions de sommets et de tronçons que nécessaire pour spécifier les mappages pour l'ensemble de la source de base de données relationnelle.
Voici un exemple de règle pour une table `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"
}
]
}
]
}
]
}
```
Ici, les définitions de sommets et de tronçons mappent une relation de reporting à partir d'un nœud `employee` avec l'ID d'employé (`EmpID`) et d'un nœud `employee` avec un ID de responsable (`managerId`).
Pour plus d’informations sur la création de règles de mappage de graphe à l’aide de Gremlin JSON, consultez [Format des données de chargement Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) dans le *Guide de l’utilisateur Amazon Neptune*.
### Règles de mappage graphique pour générer des données RDF/SPARQL
Si vous chargez des données RDF à interroger à l'aide de SPARQL, écrivez les règles de mappage de graphique dans R2RML. R2RML est un langage W3C standard pour mapper des données relationnelles vers RDF. Dans un fichier R2RML, un *mappage de triples* (par exemple, `<#TriplesMap1>` suivant) spécifie une règle pour convertir chaque ligne d'une table logique en zéro ou plusieurs triples RDF. Un *mappage de sujet* (par exemple, tout élément `rr:subjectMap` suivant) spécifie une règle pour générer les sujets des triples RDF générés par un mappage de triples. Un *mappage prédicat-objet* (par exemple, tout élément `rr:predicateObjectMap` suivant) est une fonction qui crée une ou plusieurs paires prédicat-objet pour chaque ligne de table logique d'une table logique.
Voici un exemple simple de table `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" ];
]
```
Dans l'exemple précédent, le mappage définit des nœuds de graphique mappés à partir d'une table d'employés.
Voici un autre exemple simple de table `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" ]
].
```
Dans l'exemple précédent, le mappage définit les nœuds du graphe mappant friend-of-a-friend les relations entre les personnes d'une `Student` table.
Pour de plus amples informations sur la création de règles de mappage de graphique à l'aide de SPARQL R2RML, veuillez consulter la spécification W3C [R2RML : RDB to RDF Mapping Language](https://www.w3.org/TR/r2rml/).
## Types de données pour la migration Gremlin et R2RML vers Amazon Neptune en tant que cible
AWS DMS effectue le mappage des types de données entre votre point de terminaison source SQL et votre cible Neptune de deux manières. La solution choisie dépend du format de mappage de graphe que vous utilisez pour charger la base de données Neptune :
+ Apache TinkerPop Gremlin, à l'aide d'une représentation JSON des données de migration.
+ SPARQL du W3C, en utilisant une représentation R2RML des données de migration.
Pour de plus amples informations sur ces deux formats de mappage de graphique, veuillez consulter [Spécification de règles de mappage de graphe à l’aide de Gremlin et de R2RML pour Amazon Neptune en tant que cible](#CHAP_Target.Neptune.GraphMapping).
Vous trouverez ci-dessous des descriptions des mappages de types de données pour chaque format.
### Mappages de type de données cible source SQL vers Gremlin
Le tableau suivant présente les mappages de type de données d'une source SQL vers une cible formatée Gremlin.
AWS DMS mappe n'importe quel type de données source SQL non répertorié à un `String` Gremlin.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Neptune.html)
Pour plus d’informations sur les types de données Gremlin pour le chargement de Neptune, consultez [Types de données Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) dans le *Guide de l’utilisateur Neptune*.
### Mappages de type de données cible Source SQL vers R2RML (RDF)
Le tableau suivant présente les mappages de types de données d'une source SQL vers une cible formatée R2RML.
Tous les types de données RDF répertoriés distinguent les majuscules et minuscules, à l'exception du format RDF littéral. AWS DMS mappe tout type de données source SQL non répertorié à un littéral RDF.
Un *littéral RDF* est l'une des diverses formes lexicales littérales et l'un des différents types de données. Pour de plus amples informations, veuillez consulter [Littéraux RDF](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) dans la spécification W3C *Resource Description Framework (RDF) : Concepts and Abstract Syntax*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Neptune.html)
Pour plus d’informations sur les types de données RDF pour charger Neptune et leurs mappages aux types de données sources SQL, consultez [Datatype conversions](https://www.w3.org/TR/r2rml/#datatype-conversions) dans la spécification W3C *R2RML: RDB to RDF Mapping Language*.
## Limitations de l’utilisation d’Amazon Neptune en tant que cible
Les limitations suivantes s’appliquent lorsque vous utilisez Neptune en tant que cible :
+ AWS DMS prend actuellement en charge les tâches de chargement complet uniquement pour la migration vers une cible Neptune. La migration CDC (capture des données de modification) vers une cible Neptune n’est pas prise en charge.
+ Assurez-vous d’effacer manuellement toutes les données de la base de données Neptune cible avant de commencer la tâche de migration, comme dans les exemples suivants.
Pour supprimer toutes les données (sommets et arêtes) dans le graphe, exécutez la commande Gremlin suivante.
```
gremlin> g.V().drop().iterate()
```
Pour supprimer les sommets portant l’étiquette `'customer'`, exécutez la commande Gremlin suivante.
```
gremlin> g.V().hasLabel('customer').drop()
```
**Note**
La suppression d'un jeu de données volumineux peut prendre un certain temps. Vous pouvez vouloir itérer `drop()` avec une limite, par exemple `limit(1000)`.
Pour supprimer les arêtes portant l’étiquette `'rated'`, exécutez la commande Gremlin suivante.
```
gremlin> g.E().hasLabel('rated').drop()
```
**Note**
La suppression d'un jeu de données volumineux peut prendre un certain temps. Vous pouvez vouloir itérer `drop()` avec une limite, par exemple `limit(1000)`.
+ L’opération d’API DMS `DescribeTableStatistics` peut renvoyer des résultats inexacts sur une table donnée en raison de la nature des structures de données de graphe Neptune.
Pendant la migration, AWS DMS analyse chaque table source et utilise le mappage de graphes pour convertir les données sources en un graphe Neptune. Les données converties sont d'abord stockées dans le dossier de compartiment S3 spécifié pour le point de terminaison cible. Si la source est analysée et que ces données S3 intermédiaires sont générées avec succès, `DescribeTableStatistics` suppose que les données ont été chargées avec succès dans la base de données cible Neptune. Mais ce n'est pas toujours vrai. Pour vérifier que les données ont été chargées correctement pour une table donnée, comparez les valeurs `count()` renvoyées aux deux extrémités de la migration pour cette table.
Dans l'exemple suivant, AWS DMS a chargé une `customer` table à partir de la base de données source, à laquelle l'étiquette est attribuée `'customer'` dans le graphe de la base de données Neptune cible. Vous pouvez vous assurer que cette étiquette est écrite dans la base de données cible. Pour ce faire, comparez le nombre de lignes `customer` disponibles à partir de la base de données source avec le nombre de lignes étiquetées `'customer'` chargées dans la base de données cible Neptune une fois la tâche terminée.
Pour obtenir le nombre de lignes client disponibles à partir de la base de données source à l'aide de SQL, exécutez la procédure suivante.
```
select count(*) from customer;
```
Pour obtenir le nombre de lignes étiquetées `'customer'` chargées dans le graphique de base de données cible à l'aide de Gremlin, exécutez la procédure suivante.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Actuellement, si une seule table n'est pas chargée, c'est toute la tâche qui échoue. Contrairement à une cible de base de données relationnelle, les données dans Neptune sont hautement connectées, ce qui rend impossible dans de nombreux cas la reprise d’une tâche. Si une tâche ne peut pas être reprise correctement en raison de ce type d'échec de chargement des données, créez une nouvelle tâche pour charger la table qui n'a pas pu être chargée. Avant d’exécuter cette nouvelle tâche, effacez manuellement la table partiellement chargée de la cible Neptune.
**Note**
Vous pouvez reprendre une tâche dont la migration vers une cible Neptune a échoué si l’échec est récupérable (par exemple, une erreur de transit réseau).
+ AWS DMS prend en charge la plupart des normes pour R2RML. Cependant, il AWS DMS ne prend pas en charge certaines normes R2RML, notamment les expressions inverses, les jointures et les vues. Une solution de contournement pour une vue R2RML consiste à créer une vue SQL personnalisée correspondante dans la base de données source. Dans la tâche de migration, utilisez le mappage de table pour choisir la vue en tant qu'entrée. Mappez ensuite la vue à une table qui est ensuite consommée par R2RML pour générer des données de graphique.
+ Lorsque vous migrez des données sources avec des types de données SQL non pris en charge, les données cibles résultantes peuvent avoir une perte de précision. Pour de plus amples informations, veuillez consulter [Types de données pour la migration Gremlin et R2RML vers Amazon Neptune en tant que cible](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS ne prend pas en charge la migration de données LOB vers une cible Neptune.
# Utilisation de Redis OSS comme cible pour AWS Database Migration Service
Redis OSS est un magasin de structure de données en mémoire open source utilisé comme base de données, cache et courtier de messages. La gestion des données en mémoire peut entraîner des opérations de lecture ou d’écriture de moins d’une milliseconde et des centaines de millions d’opérations par seconde. En tant que magasin de données en mémoire, Redis OSS alimente les applications les plus exigeantes nécessitant des temps de réponse inférieurs à la milliseconde.
Vous pouvez AWS DMS ainsi migrer les données de n'importe quelle base de données source prise en charge vers un magasin de données Redis OSS cible avec un temps d'arrêt minimal. Pour plus d'informations sur Redis OSS, consultez la documentation [Redis OSS](https://redis.io/documentation).
Outre Redis OSS sur site, AWS Database Migration Service prend en charge les éléments suivants :
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) en tant que magasin de données cible. ElastiCache (Redis OSS) fonctionne avec vos clients Redis OSS et utilise le format de données ouvert Redis OSS pour stocker vos données.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) en tant que magasin de données cible. MemoryDB est compatible avec Redis OSS et vous permet de créer des applications en utilisant toutes les structures de données et commandes Redis OSS APIs utilisées aujourd'hui.
Pour plus d'informations sur l'utilisation de Redis OSS comme cible pour AWS DMS, consultez les sections suivantes :
**Topics**
+ [Conditions préalables à l'utilisation d'un cluster Redis OSS comme cible pour AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Limitations liées à l'utilisation de Redis comme cible pour AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migration de données d'une base de données relationnelle ou non relationnelle vers une cible Redis OSS](#CHAP_Target.Redis.Migrating)
+ [Spécification des paramètres de point de terminaison pour Redis OSS en tant que cible](#CHAP_Target.Redis.EndpointSettings)
## Conditions préalables à l'utilisation d'un cluster Redis OSS comme cible pour AWS DMS
*DMS prend en charge une cible Redis OSS sur site dans une configuration autonome ou en tant que cluster Redis OSS dans lequel les données sont automatiquement réparties sur plusieurs nœuds.* Le partitionnement est le processus qui consiste à séparer les données en petits fragments appelés « partitions », répartis sur plusieurs serveurs ou nœuds. Une partition contient un sous-ensemble de l’ensemble de données total qui couvre une partie de la charge de travail globale.
**Redis OSS étant un magasin de données NoSQL à valeur clé, la convention de dénomination des clés Redis OSS à utiliser lorsque votre source est une base de données relationnelle est schema-name.table-name.primary-key.** Dans Redis OSS, la clé et la valeur ne doivent pas contenir le caractère spécial %. Dans le cas contraire, DMS ignore l’enregistrement.
**Note**
Si vous utilisez ElastiCache (Redis OSS) comme cible, DMS prend uniquement en charge les configurations *activées en mode cluster*. Pour plus d'informations sur l'utilisation de ElastiCache (Redis OSS) version 6.x ou ultérieure pour créer un magasin de données cible compatible avec le mode cluster, consultez [Getting started](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) dans le guide de l'utilisateur *Amazon ElastiCache (Redis OSS)*.
Avant de commencer une migration de base de données, lancez votre cluster Redis OSS selon les critères suivants.
+ Votre cluster possède une ou plusieurs partitions.
+ Si vous utilisez une cible ElastiCache (Redis OSS), assurez-vous que votre cluster n'utilise pas le contrôle d'accès basé sur les rôles IAM. Utilisez plutôt Redis OSS Auth pour authentifier les utilisateurs.
+ Activez Multi-AZ (zones de disponibilité).
+ Assurez-vous que le cluster dispose de suffisamment de mémoire pour accueillir les données à migrer depuis la base de données.
+ Assurez-vous que votre cluster Redis OSS cible est exempt de toutes les données avant de commencer la tâche de migration initiale.
Vous devez déterminer vos exigences de sécurité pour la migration des données avant de créer la configuration de votre cluster. DMS prend en charge la migration vers les groupes de réplication cibles, quelle que soit leur configuration de chiffrement. Mais vous ne pouvez activer ou désactiver le chiffrement que lorsque vous créez la configuration de votre cluster.
## Limitations liées à l'utilisation de Redis comme cible pour AWS Database Migration Service
Les limites suivantes s'appliquent lors de l'utilisation de Redis OSS comme cible :
+ Redis OSS étant un magasin de données no-sql à valeur clé, la convention de dénomination des clés Redis OSS à utiliser lorsque votre source est une base de données relationnelle est la suivante. `schema-name.table-name.primary-key`
+ Dans Redis OSS, la valeur clé ne peut pas contenir le caractère spécial. `%` Dans le cas contraire, DMS ignore l’enregistrement.
+ DMS ne migrera pas les lignes contenant le `%` caractère.
+ DMS ne migrera pas les champs dont le nom contient le `%` caractère.
+ Le Mode LOB complet n'est pas pris en charge.
+ Une autorité de certification (CA) privée n'est pas prise en charge lors de l'utilisation de ElastiCache (Redis OSS) comme cible.
+ AWS DMS ne prend pas en charge les données source contenant des `'\0'` caractères incorporés lors de l'utilisation de Redis comme point de terminaison cible. Les données contenant des `'\0'` caractères incorporés seront tronquées au premier `'\0'` caractère.
## Migration de données d'une base de données relationnelle ou non relationnelle vers une cible Redis OSS
Vous pouvez migrer les données de n'importe quel magasin de données SQL ou NoSQL source directement vers une cible Redis OSS. La configuration et le démarrage d'une migration vers une cible Redis OSS sont similaires à toute migration de chargement complet et de capture de données à l'aide de la console ou de l'API DMS. Pour effectuer une migration de base de données vers une cible Redis OSS, procédez comme suit.
+ Créez une instance de réplication pour effectuer tous les processus de la migration. Pour de plus amples informations, veuillez consulter [Création d'une instance de réplication](CHAP_ReplicationInstance.Creating.md).
+ Spécifiez un point de terminaison source. Pour de plus amples informations, veuillez consulter [Création de points de terminaison source et cible](CHAP_Endpoints.Creating.md).
+ Trouvez le numéro de port et le nom DNS de votre cluster.
+ Téléchargez un ensemble de certificats que vous pouvez utiliser pour vérifier les connexions SSL.
+ Spécifiez un point de terminaison cible, comme décrit ci-dessous.
+ Créez une tâche ou un ensemble de tâches pour définir les tables et processus de réplication à utiliser. Pour de plus amples informations, veuillez consulter [Création d’une tâche](CHAP_Tasks.Creating.md).
+ Migrez les données de la base de données source vers votre cluster cible.
Commencez une migration de base de données de l’une des deux manières suivantes :
1. Vous pouvez choisir la AWS DMS console et y effectuer chaque étape.
1. Vous pouvez utiliser le AWS Command Line Interface (AWS CLI). Pour plus d'informations sur l'utilisation de la CLI avec AWS DMS, consultez [AWS CLI pour AWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html).
**Pour trouver le numéro de port et le nom DNS de votre cluster**
+ Utilisez la AWS CLI commande suivante pour `replication-group-id` fournir le nom de votre groupe de réplication.
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Ici, la sortie indique le nom DNS dans l’attribut `Address` et le numéro de port dans l’attribut `Port` du nœud primaire du cluster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Si vous utilisez MemoryDB comme cible, utilisez la AWS CLI commande suivante pour fournir une adresse de point de terminaison à votre cluster Redis OSS.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Téléchargez un ensemble de certificats à utiliser pour vérifier les connexions SSL.**
+ Entrez la commande `wget` suivante sur la ligne de commande. Wget est un utilitaire de ligne de commande GNU gratuit qui permet de télécharger des fichiers à partir d’Internet.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Ici, `aws-api-domain` complète le domaine Amazon S3 de votre AWS région requis pour accéder au compartiment S3 spécifié et au rds-combined-ca-bundle fichier .pem qu'il fournit.
**Pour créer un point de terminaison cible à l'aide de la AWS DMS console**
Ce point de terminaison est destiné à votre cible Redis OSS déjà en cours d'exécution.
+ Dans la console, choisissez **Points de terminaison** dans le volet de navigation, puis **Créer un point de terminaison**. Le tableau suivant décrit les paramètres.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Redis.html)
Lorsque vous avez terminé de fournir toutes les informations pour votre point de terminaison, AWS DMS crée votre point de terminaison cible Redis OSS à utiliser lors de la migration de la base de données.
Pour en savoir plus sur la création d’une tâche de migration et le démarrage de la migration de la base de données, consultez [Création d’une tâche](CHAP_Tasks.Creating.md).
## Spécification des paramètres de point de terminaison pour Redis OSS en tant que cible
Pour créer ou modifier un point de terminaison cible, vous pouvez utiliser la console, `CreateEndpoint` ou les opérations d'API `ModifyEndpoint`.
Pour une cible Redis OSS dans la AWS DMS console, spécifiez les **paramètres spécifiques au point de terminaison sur la page Créer un point** **de terminaison ou **Modifier** la console de point de terminaison**.
Lorsque vous utilisez les opérations d’API `CreateEndpoint` et `ModifyEndpoint`, spécifiez les paramètres de demande pour l’option `RedisSettings`. L’exemple suivant montre comment procéder à l’aide d’ 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"
}
}
}
```
Les paramètres `--redis-settings` sont les suivants :
+ `ServerName`— (Obligatoire) De type`string`, spécifie le cluster Redis OSS vers lequel les données seront migrées et qui se trouve dans votre même VPC.
+ `Port` : (Obligatoire) pour le type `number`, valeur du port utilisé pour accéder au point de terminaison.
+ `SslSecurityProtocol` : (Facultatif) les valeurs valides incluent `plaintext` et `ssl-encryption`. La valeur par défaut est `ssl-encryption`.
L'option `plaintext` ne fournit pas le chiffrement du protocole TLS (Transport Layer Security) pour le trafic entre le point de terminaison et la base de données.
Utilisez `ssl-encryption` pour établir une connexion chiffrée. `ssl-encryption` ne requiert pas d’ARN d’autorité de certification (CA) SSL pour vérifier le certificat d’un serveur, mais il est possible d’en identifier un à l’aide du paramètre `SslCaCertificateArn`. Si aucun ARN de CA n’est fourni, DMS utilise la CA racine Amazon.
Lorsque vous utilisez une cible Redis OSS sur site, vous pouvez l'utiliser `SslCaCertificateArn` pour importer une autorité de certification (CA) publique ou privée dans DMS et fournir cet ARN pour l'authentification du serveur. Une autorité de certification privée n'est pas prise en charge lors de l'utilisation de ElastiCache (Redis OSS) comme cible.
+ `AuthType`— (Obligatoire) Indique le type d'authentification à effectuer lors de la connexion à Redis OSS. Les valeurs valides sont `none`, `auth-token` et `auth-role`.
L'`auth-token`option nécessite que les caractères *AuthPassword* « » soient fournis, tandis que l'`auth-role`option nécessite que *AuthUserName* « » et « *AuthPassword* » soient fournis.
# Utiliser Babelfish comme cible pour AWS Database Migration Service
Vous pouvez migrer les données d'une base de données source Microsoft SQL Server vers une cible Babelfish à l'aide de. AWS Database Migration Service
Babelfish pour Aurora PostgreSQL étend l’Édition compatible avec PostgreSQL de votre base de données Amazon Aurora et permet d’accepter les connexions de base de données à partir de clients Microsoft SQL Server. Les applications initialement conçues pour SQL Server peuvent ainsi être utilisées avec Aurora PostgreSQL, sans apporter de changements significatifs au code par rapport à une migration traditionnelle et sans modifier les pilotes de base de données.
Pour plus d'informations sur les versions de Babelfish compatibles AWS DMS en tant que cible, consultez. [Objectifs pour AWS DMS](CHAP_Introduction.Targets.md) Les versions antérieures de Babelfish sur Aurora PostgreSQL nécessitent une mise à niveau avant d’utiliser le point de terminaison Babelfish.
**Note**
Le point de terminaison cible Aurora PostgreSQL est la méthode privilégiée pour migrer des données vers Babelfish. Pour de plus amples informations, veuillez consulter [Utilisation de Babelfish for Aurora PostgreSQL en tant que cible](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
Pour en savoir plus sur l’utilisation de Babelfish comme point de terminaison de base de données, consultez [Babelfish for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) dans le *Guide de l’utilisateur Amazon Aurora pour Aurora*.
## Prérequis pour utiliser Babelfish comme cible pour AWS DMS
Vous devez créer vos tables avant de migrer les données afin de vous assurer que celles-ci AWS DMS utilisent les types de données et les métadonnées de table appropriés. Si vous ne créez pas vos tables sur la cible avant d'exécuter la migration, vous AWS DMS risquez de créer les tables avec des types de données et des autorisations incorrects. Par exemple, AWS DMS crée une colonne d'horodatage au format binaire (8) à la place et ne fournit pas les fonctionnalités attendues timestamp/rowversion .
**Pour préparer et créer vos tables avant la migration**
1. Exécutez vos instructions DDL de création de table qui incluent des contraintes uniques, des clés primaires ou des contraintes par défaut.
N’incluez pas de contraintes de clé étrangère ni d’instructions DDL pour des objets tels que des vues, des procédures stockées, des fonctions ou des déclencheurs. Vous pouvez les appliquer après avoir migré la base de données source.
1. Identifiez les colonnes d’identité, les colonnes calculées ou les colonnes contenant des types de données rowversion ou timestamp pour vos tables. Créez ensuite les règles de transformation nécessaires pour gérer les problèmes connus lors de l’exécution de la tâche de migration. Pour plus d'informations, voir,[Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifiez les colonnes contenant des types de données que Babelfish ne prend pas en charge. Modifiez ensuite les colonnes concernées dans la table cible pour utiliser les types de données pris en charge, ou créez une règle de transformation qui les supprime lors de la tâche de migration. Pour plus d'informations, voir,[Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
Le tableau suivant répertorie les types de données source non pris en charge par Babelfish, ainsi que le type de données cible recommandé correspondant à utiliser.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Babelfish.html)
**Pour définir le niveau des unités de capacité Aurora (ACUs) pour votre base de données source Aurora PostgreSQL Serverless V2**
Vous pouvez améliorer les performances de votre tâche de AWS DMS migration avant de l'exécuter en définissant la valeur ACU minimale.
+ Dans la fenêtre des **paramètres de capacité de Severless v2**, définissez un niveau **minimum ACUs** de **2** ou un niveau raisonnable pour votre cluster de base de données Aurora.
Pour plus d’informations sur la définition des unités de capacité Aurora, consultez [Choix de la plage de capacité Aurora sans serveur v2 pour un cluster Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html) dans le *Guide de l’utilisateur Amazon Aurora*.
Après avoir exécuté votre tâche de AWS DMS migration, vous pouvez rétablir la valeur minimale de votre base ACUs de données source Aurora PostgreSQL Serverless V2 à un niveau raisonnable.
## Exigences de sécurité lors de l'utilisation de Babelfish comme cible pour AWS Database Migration Service
Ce qui suit décrit les exigences de sécurité pour une utilisation AWS DMS avec une cible Babelfish :
+ Le nom d’utilisateur de l’administrateur (utilisateur Admin) utilisé pour créer la base de données.
+ L’identifiant de connexion PSQL et l’utilisateur disposant des autorisations SELECT, INSERT, UPDATE, DELETE et REFERENCES suffisantes.
## Autorisations utilisateur pour utiliser Babelfish comme cible pour AWS DMS
**Important**
À des fins de sécurité, le compte d’utilisateur utilisé pour la migration des données doit être un utilisateur enregistré dans une base de données Babelfish que vous utilisez en tant que cible.
Votre point de terminaison cible Babelfish nécessite des autorisations utilisateur minimales pour exécuter une migration AWS DMS .
**Pour créer un identifiant de connexion et un utilisateur Transact-SQL (T-SQL) à faible privilège**
1. Créez un identifiant de connexion et un mot de passe à utiliser lors de la connexion au serveur.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Créez la base de données virtuelle pour votre cluster Babelfish.
```
CREATE DATABASE my_database;
GO
```
1. Créez l’utilisateur T-SQL pour la base de données cible.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Pour chaque table de la base de données Babelfish, accordez (GRANT) des autorisations aux tables.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Limitations relatives à l'utilisation de Babelfish comme cible pour AWS Database Migration Service
Les limitations suivantes s’appliquent lors de l’utilisation d’une base de données Babelfish en tant que cible pour AWS DMS :
+ Seul le mode de préparation de table « **Ne rien faire** » est pris en charge.
+ Le type de données ROWVERSION nécessite une règle de mappage de table qui supprime le nom de colonne de la table pendant la tâche de migration.
+ Le type de données sql\$1variant n’est pas pris en charge.
+ Le mode LOB complet est pris en charge. L'utilisation de SQL Server comme point de terminaison source nécessite que le paramètre `ForceFullLob=True` d'attribut de connexion du point de terminaison SQL Server soit défini afin de LOBs pouvoir être migré vers le point de terminaison cible.
+ Les paramètres de la tâche de réplication présentent les limitations suivantes :
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Les types de données TIME DATETIME2 (7), (7) et DATETIMEOFFSET (7) dans Babelfish limitent la valeur de précision pour la partie secondes du temps à 6 chiffres. Envisagez d’utiliser une valeur de précision de 6 pour votre table cible lorsque vous utilisez ces types de données. Pour les versions 2.2.0 et supérieures de Babelfish, lorsque vous utilisez TIME (7) et DATETIME2 (7), le septième chiffre de précision est toujours zéro.
+ En mode DO\$1NOTHING, DMS vérifie si la table existe déjà. Si la table n’existe pas dans le schéma cible, DMS crée la table en fonction de la définition de table source et mappe tous les types de données définis par l’utilisateur à leur type de données de base.
+ Une tâche de AWS DMS migration vers une cible Babelfish ne prend pas en charge les tables dont les colonnes utilisent les types de données ROWVERSION ou TIMESTAMP. Vous pouvez utiliser une règle de mappage de table qui supprime le nom de colonne de la table pendant le processus de transfert. Dans l’exemple de règle de transformation suivant, une table nommée `Actor` dans votre source est transformée pour supprimer toutes les colonnes commençant par les caractères `col` de la table `Actor` dans votre cible.
```
{
"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%"
}
}]
}
```
+ Pour les tables comportant des colonnes d’identité ou calculées, où les tables cibles utilisent des noms en casse mixte tels que Catégories, vous devez créer une action de règle de transformation qui convertit les noms des table en minuscules pour votre tâche DMS. L'exemple suivant montre comment créer l'action de règle de transformation **Make lowercase** à l'aide de la AWS DMS console. Pour de plus amples informations, veuillez consulter [Règles et actions de transformation](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Règle de transformation Babelfish\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Avant Babelfish version 2.2.0, DMS limitait le nombre de colonnes que vous pouviez répliquer vers un point de terminaison cible Babelfish à vingt (20) colonnes. Avec Babelfish 2.2.0, la limite est passée à 100 colonnes. Mais avec Babelfish versions 2.4.0 et ultérieures, le nombre de colonnes que vous pouvez répliquer augmente à nouveau. Vous pouvez exécuter l’exemple de code suivant sur la base de données SQL Server pour déterminer quelles tables sont trop longues.
```
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
;
```
## Types de données cibles pour Babelfish
Le tableau suivant indique les types de données cibles de Babelfish pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.
Pour plus d'informations sur AWS DMS les types de données, consultez[Types de données pour AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS DMS type de données | Type de données Babelfish |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY(Length) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC(p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| CHAÎNE | Si la colonne est une colonne de date ou d'heure, effectuez les opérations suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Babelfish.html) Si la colonne n'est pas une colonne de date ou d'heure, utilisez VARCHAR (length). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(length) |
| BLOB | VARBINARY(max) Pour utiliser ce type de données avec DMS, vous devez activer l'utilisation de BLOBs pour une tâche spécifique. DMS prend en charge les types de données BLOB uniquement dans les tables qui contiennent une clé primaire. |
| CLOB | VARCHAR(max) Pour utiliser ce type de données avec DMS, vous devez activer l'utilisation de CLOBs pour une tâche spécifique. |
| NCLOB | NVARCHAR(max) Pour utiliser ce type de données avec DMS, vous devez activer l'utilisation de NCLOBs pour une tâche spécifique. Au cours de la CDC, DMS prend en charge les types de données NCLOB uniquement dans les tables qui contiennent une clé primaire. |
# Utiliser Amazon Timestream comme cible pour AWS Database Migration Service
Vous pouvez l'utiliser AWS Database Migration Service pour migrer les données de votre base de données source vers un point de terminaison cible Amazon Timestream, en prenant en charge les migrations de données Full Load et CDC.
Amazon Timestream est un service de base de données de séries temporelles rapide, évolutif et sans serveur, conçu pour l’ingestion de grands volumes de données. Les données de séries temporelles sont une séquence de points de données collectés pendant un intervalle de temps et utilisés pour mesurer des événements qui évoluent au fil du temps. Il est utilisé pour collecter, stocker et analyser les métriques des applications IoT, des DevOps applications et des applications d'analyse. Une fois que vous avez enregistré vos données dans Timestream, vous pouvez visualiser et identifier des tendances et des modèles dans vos données en temps quasi réel. Pour plus d’informations sur Amazon Timestream, consultez [Qu’est-ce qu’Amazon Timestream ?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) dans le *Guide du développeur Amazon Timestream*.
**Topics**
+ [Conditions préalables à l'utilisation d'Amazon Timestream comme cible pour AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Paramètres de tâche de chargement complet multithread](#CHAP_Target.Timestream.FLTaskSettings)
+ [Paramètres de tâche de chargement CDC multithread](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Paramètres du point de terminaison lors de l'utilisation de Timestream comme cible pour AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Création et modification d’un point de terminaison Amazon Timestream cible](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Utilisation du mappage d’objet pour migrer des données vers une rubrique Timestream](#CHAP_Target.Timestream.ObjectMapping)
+ [Limitations liées à l'utilisation d'Amazon Timestream comme cible pour AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Conditions préalables à l'utilisation d'Amazon Timestream comme cible pour AWS Database Migration Service
Avant de configurer Amazon Timestream comme cible AWS DMS pour, assurez-vous de créer un rôle IAM. Ce rôle doit permettre AWS DMS d'accéder aux données en cours de migration vers Amazon Timestream. L’ensemble d’autorisations d’accès minimum pour le rôle que vous utilisez pour migrer vers Timestream figure dans la politique IAM suivante.
------
#### [ 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"
}
]
}
```
------
Si vous avez l'intention de migrer toutes les tables, utilisez `*` for *TABLE\$1NAME* dans l'exemple ci-dessus.
Notez ce qui suit à propos de l’utilisation de Timestream comme cible :
+ Si vous avez l’intention d’ingérer des données historiques dont l’horodatage remonte à plus d’un an, nous vous recommandons d’utiliser AWS DMS pour écrire les données dans Amazon S3 au format CSV (valeurs séparées par des virgules). Utilisez ensuite le chargement par lots de Timestream pour ingérer les données. Pour plus d’informations, consultez [Utilisation du chargement par lots dans Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) dans le [Guide du développeur Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Pour les migrations de données à chargement complet datant de moins d’un an, nous recommandons de définir une période de conservation de la mémoire de la table Timestream supérieure ou égale à l’horodatage le plus ancien. Ensuite, une fois la migration terminée, modifiez la période de conservation de la mémoire de la table à la valeur souhaitée. Par exemple, pour migrer des données dont l’horodatage le plus ancien date de 2 mois, procédez comme suit :
+ Définissez la période de conservation de la mémoire de la table cible Timestream sur 2 mois.
+ Démarrez la migration des données à l'aide de AWS DMS.
+ Une fois la migration des données terminée, modifiez la période de conservation de la table Timestream cible à la valeur souhaitée.
Nous vous recommandons d’estimer le coût de stockage de la mémoire avant la migration en utilisant les informations des pages suivantes :
+ [Tarification d’Amazon Timestream](https://aws.amazon.com/timestream/pricing)
+ [AWS calculateur de prix](https://calculator.aws/#/addService)
+ Pour les migrations de données CDC, nous recommandons de définir la période de conservation de la mémoire de la table cible de manière à ce que les données ingérées se situent dans les limites de cette période. Pour plus d’informations, consultez [Bonnes pratiques en matière d’écriture](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) dans le [Guide du développeur Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Paramètres de tâche de chargement complet multithread
Pour accélérer le transfert de données, AWS DMS prend en charge une tâche de migration multithread à chargement complet vers un point de terminaison cible Timestream avec les paramètres de tâche suivants :
+ `MaxFullLoadSubTasks` : utilisez cette option pour indiquer le nombre maximal de tables sources à charger en parallèle. DMS charge chaque table dans sa table Amazon Timestream cible correspondante à l’aide d’une sous-tâche dédiée. La valeur par défaut est 8 ; la valeur maximale 49.
+ `ParallelLoadThreads`— Utilisez cette option pour spécifier le nombre de threads AWS DMS utilisés pour charger chaque table dans sa table cible Amazon Timestream. La valeur maximale pour une cible Timestream est 32. Vous pouvez demander une augmentation de cette limite maximale.
+ `ParallelLoadBufferSize` : utilisez cette option pour spécifier le nombre maximal d’enregistrements à stocker dans la mémoire tampon utilisée par les threads de chargement parallèles pour charger les données dans la cible Amazon Timestream. La valeur par défaut est 50. La valeur maximale est 1 000. Utilisez ce paramètre avec `ParallelLoadThreads`. `ParallelLoadBufferSize` est valide uniquement dans le cas de plusieurs threads.
+ `ParallelLoadQueuesPerThread` : utilisez cette option pour spécifier le nombre de files d’attente auxquelles chaque thread simultané accède pour extraire les enregistrements de données des files d’attente et générer un chargement par lots pour la cible. La valeur par défaut est 1. Toutefois, pour les cibles Amazon Timestream de différentes tailles de charge utile, la plage valide est comprise entre 5 et 512 files d’attente par thread.
## Paramètres de tâche de chargement CDC multithread
Pour améliorer les performances du CDC, AWS DMS prend en charge les paramètres de tâche suivants :
+ `ParallelApplyThreads`— Spécifie le nombre de threads simultanés AWS DMS utilisés lors d'un chargement CDC pour transférer des enregistrements de données vers un point de terminaison cible Timestream. La valeur par défaut est 0 et la valeur maximale est 32.
+ `ParallelApplyBufferSize` : spécifie le nombre maximal d’enregistrements à stocker dans chaque file d’attente de la mémoire tampon pour que les threads simultanés soient transférés vers un point de terminaison cible Timestream lors d’un chargement CDC. La valeur par défaut est 100 et la valeur maximale est 1 000. Utilisez cette option lorsque `ParallelApplyThreads` spécifie plusieurs threads.
+ `ParallelApplyQueuesPerThread` : spécifie le nombre de files d’attente auxquelles chaque thread accède pour extraire les enregistrements de données et générer un chargement par lots pour un point de terminaison Timestream lors d’un chargement CDC. La valeur par défaut est 1 et la valeur maximale est 512.
## Paramètres du point de terminaison lors de l'utilisation de Timestream comme cible pour AWS DMS
Vous pouvez utiliser des paramètres de point de terminaison pour configurer votre base de données Timestream cible comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--timestream-settings '{"EndpointSetting": "value", ...}'` JSON.
Les paramètres de point de terminaison que vous pouvez utiliser avec Timestream comme cible sont indiqués dans le tableau suivant.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_Target.Timestream.html)
## Création et modification d’un point de terminaison Amazon Timestream cible
Une fois que vous avez créé un rôle IAM et défini l'ensemble minimal d'autorisations d'accès, vous pouvez créer un point de terminaison cible Amazon Timestream à l'aide de la console ou à l' AWS DMS aide de la commande contenue [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)dans le, `create-endpoint` avec la syntaxe JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
Les exemples suivants montrent comment créer et modifier un point de terminaison Timestream cible à l’aide de l’ AWS CLI.
**Commande de création d’un point de terminaison Timestream cible**
```
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,
}
```
**Commande de modification d’un point de terminaison Timestream cible**
```
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,
}
```
## Utilisation du mappage d’objet pour migrer des données vers une rubrique Timestream
AWS DMS utilise des règles de mappage de tables pour mapper les données de la source à la rubrique Timestream cible. Pour mapper des données à une rubrique cible, vous utilisez un type de règle de mappage de table appelé « mappage d’objet ». Vous utilisez le mappage d’objet pour définir la façon dont les enregistrements de données de la source sont mappés aux enregistrements de données publiés dans une rubrique Timestream.
Les rubriques Timestream ne disposent pas d’une structure prédéfinie autre que le fait d’avoir une clé de partition.
**Note**
Vous n’avez pas besoin d’utiliser le mappage d’objet. Vous pouvez utiliser un mappage de table standard pour différentes transformations. Cependant, le type de clé de partition suivra les comportements par défaut suivants :
La clé primaire est utilisée comme clé de partition pour le chargement complet.
Si aucun paramètre de tâche parallel-apply n’est utilisé, `schema.table` est utilisé comme clé de partition pour la CDC.
Si des paramètres de tâche parallel-apply sont utilisés, la clé primaire est utilisée comme clé de partition pour la CDC.
Pour créer une règle de mappage d'objet, spécifiez `rule-type` comme `object-mapping`. Cette règle spécifie le type de mappage d'objet que vous souhaitez utiliser. La structure de la règle est la suivante.
```
{
"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 prend actuellement en charge `map-record-to-record` et `map-record-to-document` en tant que seules valeurs valides pour le `rule-action` paramètre. Les `map-record-to-document` valeurs `map-record-to-record` et spécifient ce qui est AWS DMS fait par défaut aux enregistrements qui ne sont pas exclus de la liste d'`exclude-columns`attributs. Ces valeurs n'affectent en aucune façon les mappages d'attributs.
Utilisez `map-record-to-record` lorsque vous migrez une base de données relationnelle vers une rubrique Timestream. Ce type de règle utilise la valeur `taskResourceId.schemaName.tableName` de la base de données relationnelle comme clé de partition dans la rubrique Timestream, et crée un attribut pour chaque colonne de la base de données source. Lors de l'utilisation`map-record-to-record`, pour toute colonne de la table source non répertoriée dans la liste d'`exclude-columns`attributs, AWS DMS crée un attribut correspondant dans le sujet cible. Cet attribut correspondant est créé que la colonne source soit ou non utilisée dans un mappage d'attribut.
Une manière de comprendre `map-record-to-record` est de le voir en action. Dans cet exemple, imaginons que vous commencez avec une ligne de table d'une base de données relationnelle, présentant la structure et les données suivantes :
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Pour migrer ces informations à partir d’un schéma nommé `Test` vers une rubrique Timestream, vous créez des règles pour mapper les données à la rubrique cible. La règle suivante illustre ce mappage.
```
{
"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"
}
}
]
}
```
L’exemple ci-dessous illustre le format d’enregistrement obtenu avec une rubrique Timestream et une clé de partition (en l’occurrence, `taskResourceId.schemaName.tableName`) à l’aide de notre exemple de données dans la rubrique Timestream cible :
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Limitations liées à l'utilisation d'Amazon Timestream comme cible pour AWS Database Migration Service
Les limites suivantes s’appliquent lorsque vous utilisez Amazon Timestream comme cible :
+ **Dimensions et horodatages :** Timestream utilise les dimensions et les horodatages des données sources comme clé primaire composite, et ne vous autorise pas à mettre à jour ces valeurs. Cela signifie que si vous modifiez l’horodatage ou les dimensions d’un enregistrement dans la base de données source, la base de données Timestream essaiera de créer un nouvel enregistrement. Il est donc possible que si vous modifiez la dimension ou l'horodatage d'un enregistrement afin qu'ils correspondent à ceux d'un autre enregistrement existant, vous mettiez AWS DMS à jour les valeurs de l'autre enregistrement au lieu de créer un nouvel enregistrement ou de mettre à jour l'enregistrement correspondant précédent.
+ **Commandes DDL :** La version actuelle AWS DMS ne prend en charge que `CREATE TABLE` les commandes `DROP TABLE` DDL.
+ **Limites des enregistrements :** Timestream impose des limites pour les enregistrements (taille des enregistrements et des mesures, par exemple). Pour plus d’informations, consultez [Quotas](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) dans le [Guide du développeur Amazon Timestream](https://docs.aws.amazon.com/).
+ **Suppression des enregistrements et valeurs nulles :** Timestream ne prend pas en charge la suppression des enregistrements. Pour faciliter la migration des enregistrements supprimés de la source, AWS DMS efface les champs correspondants dans les enregistrements de la base de données cible Timestream. AWS DMS modifie les valeurs des champs de l'enregistrement cible correspondant avec **0** pour les champs numériques, **null** pour les champs de texte et **faux** pour les champs booléens.
+ Timestream en tant que cible ne prend pas en charge les sources qui ne sont pas des bases de données relationnelles (SGBDR).
+ AWS DMS ne prend en charge Timestream en tant que cible que dans les régions suivantes :
+ USA Est (Virginie du Nord)
+ USA Est (Ohio)
+ USA Ouest (Oregon)
+ Europe (Irlande)
+ Europe (Francfort)
+ Asie-Pacifique (Sydney)
+ Asia Pacific (Tokyo)
+ Timestream en tant que cible ne prend pas en charge la valeur `TRUNCATE_BEFORE_LOAD` pour le paramètre `TargetTablePrepMode`. Nous vous recommandons d’utiliser `DROP_AND_CREATE` pour ce paramètre.
# Utilisation d'Amazon RDS pour Db2 et d'IBM Db2 LUW comme cible pour AWS DMS
Vous pouvez migrer des données vers une base de données Amazon RDS pour DB2 ou une base de données DB2 locale à partir d'une base de données DB2 LUW en utilisant (). AWS Database Migration Service AWS DMS
Pour plus d'informations sur les versions de DB2 LUW prises AWS DMS en charge en tant que cible, consultez. [Objectifs pour AWS DMS](CHAP_Introduction.Targets.md)
Vous pouvez utiliser le protocole SSL pour chiffrer les connexions entre votre point de terminaison Db2 LUW et l'instance de réplication. Pour plus d’informations sur l’utilisation de SSL avec un point de terminaison Db2 LUW, consultez [Utilisation du protocole SSL avec AWS Database Migration Service](CHAP_Security.SSL.md).
## Limitations liées à l'utilisation de Db2 LUW comme cible pour AWS DMS
Les limitations suivantes s'appliquent lors de l'utilisation de la base de données DB2 LUW comme cible pour. AWS DMS Pour connaître les limites d’utilisation de Db2 LUW en tant que source, consultez [Limitations liées à l'utilisation de DB2 LUW comme source pour AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations).
+ AWS DMS prend uniquement en charge Db2 LUW en tant que cible lorsque la source est Db2 LUW ou Db2 for z/OS.
+ L’utilisation de Db2 LUW en tant que cible ne prend pas en charge les réplications en mode LOB complet.
+ L’utilisation de DB2 LUW en tant que cible ne prend pas en charge le type de données XML pendant la phase de chargement complet. Il s’agit d’une limite de l’utilitaire IBM dbload. Pour plus d’informations, consultez [Utilitaire dbload](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) dans la documentation *Serveurs IBM Informix*.
+ AWS DMS tronque les champs BLOB avec des valeurs correspondant au guillemet double («). Il s’agit d’une limite de l’utilitaire IBM dbload.
+ AWS DMS ne prend pas en charge l'option de chargement complet en parallèle lors de la migration vers une cible DB2 LUW dans la version 3.5.3 de DMS. Cette option est disponible à partir de la version 3.5.4 ou ultérieure de DMS.
## Paramètres du point de terminaison lors de l'utilisation de DB2 LUW comme cible pour AWS DMS
Vous pouvez utiliser des paramètres de point de terminaison pour configurer votre base de données Db2 LUW cible comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à l'aide de la AWS DMS console ou à l'aide de la `create-endpoint` commande dans le [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), avec la syntaxe `--ibm-db2-settings '{"EndpointSetting": "value", ...}'` JSON.
Les paramètres de point de terminaison que vous pouvez utiliser avec Db2 LUW en tant que cible sont indiqués dans le tableau suivant.
| Nom | Description |
| --- | --- |
| `KeepCsvFiles` | Si c'est vrai, AWS DMS enregistre tous les fichiers .csv sur la cible DB2 LUW qui ont été utilisés pour répliquer les données. DMS utilise ces fichiers à des fins d’analyse et de résolution des problèmes. |
| `LoadTimeout` | Durée (en millisecondes) avant l'expiration des opérations effectuées AWS DMS par DMS sur la cible Db2. La valeur par défaut est de 1 200 (20 minutes). |
| `MaxFileSize` | Spécifie la taille maximale (en Ko) des fichiers .csv utilisés pour transférer des données vers Db2 LUW. |
| `WriteBufferSize` | Taille (en Ko) du tampon d’écriture de fichier en mémoire utilisé lors de la génération des fichiers .csv sur le disque local au niveau de l’instance de réplication DMS. La valeur par défaut est 1 024 (1 Mo). |