}
```
L'esempio seguente evidenzia le sezioni utilizzate per l'espressione condizionale.
![\[Inizia con AWS DMS\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Utilizzo della mappatura degli attributi con la mappatura degli oggetti
La mappatura degli attributi consente di specificare una stringa di modello mediante i nomi di colonna di origine per ristrutturare i dati sulla destinazione. Non viene eseguita alcuna formattazione oltre a quella che l'utente specifica nel modello.
L'esempio seguente mostra la struttura del database di origine e la struttura desiderata della destinazione DynamoDB. In primo luogo è riportata la struttura dell'origine, in questo caso un database Oracle, quindi la struttura dei dati in DynamoDB. Al termine dell'esempio, il file JSON viene utilizzato per creare la struttura di destinazione desiderata.
La struttura dei dati Oracle è la seguente:
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Chiave primaria | N/D | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
La struttura dei dati DynamoDB è la seguente:
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Chiave di partizione | Chiave ordinamento | N/D |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
Il seguente file JSON mostra la mappatura degli oggetti e la mappatura delle colonne utilizzate per ottenere la struttura 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}\"}}"
}
]
}
}
]
}
```
Un altro modo per utilizzare la mappatura delle colonne consiste nell'utilizzo del formato DynamoDB come tipo di documento. Il seguente codice di esempio utilizza *dynamodb-map* come `attribute-sub-type` per la mappatura degli attributi.
```
{
"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}"
}
}
}
}
}
}
]
}
}
]
}
```
In alternativa`dynamodb-map`, è possibile utilizzare `dynamodb-list` come strumento attribute-sub-type per la mappatura degli attributi, come illustrato nell'esempio seguente.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Esempio 1: utilizzo della mappatura degli attributi con la mappatura degli oggetti
L'esempio seguente migra i dati da due tabelle di database MySQL*, nfl\$1data e sport\$1team,* *a due tabelle DynamoDB chiamate and*. *NFLTeams*SportTeams** Di seguito sono riportati la struttura delle tabelle e il file JSON utilizzato per mappare i dati dalle tabelle di database MySQL alle tabelle DynamoDB.
Di seguito è riportata la struttura della tabella di database MySQL *nfl\$1data*:
```
mysql> desc nfl_data;
+---------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| Position | varchar(5) | YES | | NULL | |
| player_number | smallint(6) | YES | | NULL | |
| Name | varchar(40) | YES | | NULL | |
| status | varchar(10) | YES | | NULL | |
| stat1 | varchar(10) | YES | | NULL | |
| stat1_val | varchar(10) | YES | | NULL | |
| stat2 | varchar(10) | YES | | NULL | |
| stat2_val | varchar(10) | YES | | NULL | |
| stat3 | varchar(10) | YES | | NULL | |
| stat3_val | varchar(10) | YES | | NULL | |
| stat4 | varchar(10) | YES | | NULL | |
| stat4_val | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
+---------------+-------------+------+-----+---------+-------+
```
Di seguito è riportata la struttura della tabella di database MySQL *sport\$1team*:
```
mysql> desc sport_team;
+---------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| name | varchar(30) | NO | | NULL | |
| abbreviated_name | varchar(10) | YES | | NULL | |
| home_field_id | smallint(6) | YES | MUL | NULL | |
| sport_type_name | varchar(15) | NO | MUL | NULL | |
| sport_league_short_name | varchar(10) | NO | | NULL | |
| sport_division_short_name | varchar(10) | YES | | NULL | |
```
Di seguito sono riportate le regole di mappatura delle tabelle utilizzate per mappare le due tabelle alle due tabelle DynamoDB:
```
{
"rules":[
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "nfl_data"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "sport_team"
},
"rule-action": "include"
},
{
"rule-type":"object-mapping",
"rule-id":"3",
"rule-name":"MapNFLData",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"nfl_data"
},
"target-table-name":"NFLTeams",
"mapping-parameters":{
"partition-key-name":"Team",
"sort-key-name":"PlayerName",
"exclude-columns": [
"player_number", "team", "name"
],
"attribute-mappings":[
{
"target-attribute-name":"Team",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${team}"
},
{
"target-attribute-name":"PlayerName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"PlayerInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${
stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}"
}
]
}
},
{
"rule-type":"object-mapping",
"rule-id":"4",
"rule-name":"MapSportTeam",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"sport_team"
},
"target-table-name":"SportTeams",
"mapping-parameters":{
"partition-key-name":"TeamName",
"exclude-columns": [
"name", "id"
],
"attribute-mappings":[
{
"target-attribute-name":"TeamName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"TeamInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}"
}
]
}
}
]
}
```
L'output di esempio per la tabella *NFLTeams*DynamoDB è mostrato di seguito:
```
"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'output di esempio per la tabella SportsTeams *DynamoDB* è mostrato di seguito:
```
{
"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"
}
```
## Tipi di dati di destinazione per DynamoDB
L'endpoint DynamoDB per AWS DMS supporta la maggior parte dei tipi di dati DynamoDB. La tabella seguente mostra i tipi di dati di AWS DMS destinazione di Amazon supportati durante l'utilizzo AWS DMS e la mappatura predefinita AWS DMS dei tipi di dati.
Per ulteriori informazioni sui tipi di AWS DMS dati, consulta[Tipi di dati per AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Quando AWS DMS migriamo dati da database eterogenei, mappiamo i tipi di dati dal database di origine a tipi di dati intermedi denominati tipi di dati. AWS DMS Mappiamo quindi i tipi di dati intermedi ai tipi di dati di destinazione. La tabella seguente mostra ogni tipo di AWS DMS dati e il tipo di dati a cui è mappato in DynamoDB:
| AWS DMS tipo di dati | Tipo di dati DynamoDB |
| --- | --- |
| Stringa | Stringa |
| WString | Stringa |
| Booleano | Booleano |
| Data | Stringa |
| DateTime | Stringa |
| INT1 | Numero |
| INT2 | Numero |
| INT4 | Numero |
| INT8 | Numero |
| Numerico | Numero |
| Real4 | Numero |
| Real8 | Numero |
| UINT1 | Numero |
| UINT2 | Numero |
| UINT4 | Numero |
| UINT8 | Numero |
| CLOB | Stringa |
# Utilizzo di Amazon Kinesis Data Streams come destinazione per AWS Database Migration Service
Puoi utilizzarlo AWS DMS per migrare i dati verso un flusso di dati Amazon Kinesis. I flussi di dati Amazon Kinesis fanno parte del servizio Flusso di dati Amazon Kinesis. Puoi utilizzare i flussi di dati Kinesis per raccogliere ed elaborare flussi di grandi dimensioni di record di dati in tempo reale.
Un flusso di dati Kinesis è costituito da partizioni. Gli *shard* sono sequenze identificate in modo univoco di record di dati in un flusso. Per ulteriori informazioni sulle partizioni in Flusso di dati Amazon Kinesis, consulta [Shard](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) nella *Guida per gli sviluppatori di Flusso di dati Amazon Kinesis*.
AWS Database Migration Service pubblica i record in un flusso di dati Kinesis utilizzando JSON. Durante la conversione, AWS DMS serializza ogni record dal database di origine in una coppia attributo-valore in formato JSON o in un formato di messaggio JSON\$1UNFORMATTED. Un formato di messaggio JSON\$1UNFORMATTED è una stringa JSON a riga singola con nuovo delimitatore di riga. Consente ad Amazon Data Firehose di distribuire dati Kinesis a una destinazione Amazon S3 e quindi di interrogarli utilizzando vari motori di query tra cui Amazon Athena.
È possibile utilizzare la mappatura degli oggetti per migrare i dati da qualsiasi origine dati supportata a un flusso di destinazione. Con la mappatura degli oggetti, determini il modo in cui strutturare i record di dati nel flusso. Puoi inoltre definire una chiave di partizione per ogni tabella che viene utilizzata dai flussi di dati Kinesis per raggruppare i dati nelle partizioni.
AWS DMS imposta anche diversi valori dei parametri Kinesis Data Streams. Il costo per la creazione della tabella dipende dalla quantità di dati e dal numero di tabelle da migrare.
**Nota**
L'opzione **SSL Mode** sulla AWS DMS console o sull'API non si applica ad alcuni servizi di streaming di dati e NoSQL come Kinesis e DynamoDB. **Sono sicuri per impostazione predefinita, quindi AWS DMS mostra che l'impostazione della modalità SSL è uguale a none (modalità SSL = Nessuno).** Per utilizzare SSL non è necessario eseguire alcuna configurazione aggiuntiva per l'endpoint. Ad esempio, l'utilizzo di Kinesis come endpoint di destinazione è sicuro per impostazione predefinita. Tutte le chiamate API a Kinesis utilizzano SSL, quindi non è necessaria un'opzione SSL aggiuntiva nell'endpoint. AWS DMS È possibile inserire dati e recuperarli in modo sicuro tramite gli endpoint SSL utilizzando il protocollo HTTPS, usato da AWS DMS per impostazione predefinita per la connessione a un flusso di dati Kinesis.
**Impostazioni degli endpoint del flusso di dati Kinesis**
Quando utilizzi gli endpoint target di Kinesis Data Streams, puoi ottenere i dettagli delle transazioni e del controllo `KinesisSettings` utilizzando l'opzione nell'API. AWS DMS
Puoi configurare le impostazioni di connessione nei modi seguenti:
+ Nella AWS DMS console, utilizzando le impostazioni degli endpoint.
+ Nella CLI, utilizzando l'`kinesis-settings`opzione del [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)comando.
Nella CLI utilizza i seguenti parametri di richiesta dell'opzione `kinesis-settings`:
**Nota**
Il supporto per l'impostazione dell'endpoint `IncludeNullAndEmpty` è disponibile in AWS DMS 3.4.1 e versioni successive. Tuttavia, il supporto per le altre impostazioni degli endpoint seguenti per i target Kinesis Data Streams è disponibile in. AWS DMS
+ `MessageFormat`: il formato di output per i record creati nell'endpoint. Il formato del messaggio è `JSON` (predefinito) o `JSON_UNFORMATTED` (una singola riga senza tabulazione).
+ `IncludeControlDetails`: mostra informazioni dettagliate sul controllo per la definizione di tabella, la definizione di colonna e le modifiche di tabelle e colonne nell'output dei messaggi Kinesis. Il valore predefinito è `false`.
+ `IncludeNullAndEmpty`: include le colonne vuote e NULL nella destinazione. Il valore predefinito è `false`.
+ `IncludePartitionValue`: mostra il valore della partizione all'interno dell'output dei messaggi di Kinesis, a meno che il tipo della partizione non sia `schema-table-type`. Il valore predefinito è `false`.
+ `IncludeTableAlterOperations`: include tutte le operazioni DDL (Data Definition Language) che modificano i dati di controllo della tabella, ad esempio `rename-table`, `drop-table`, `add-column`, `drop-column` e `rename-column`. Il valore predefinito è `false`.
+ `IncludeTransactionDetails`: fornisce informazioni dettagliate sulle transazioni dal database di origine. Tali informazioni includono un timestamp di commit, una posizione nel log e valori per `transaction_id`, `previous_transaction_id` e `transaction_record_id `(l'offset del record all'interno di una transazione). Il valore predefinito è `false`.
+ `PartitionIncludeSchemaTable`: aggiunge ai nomi di schemi e tabelle il prefisso con i valori di partizione, quando il tipo di partizione è `primary-key-type`. In questo modo si aumenta la distribuzione dei dati tra gli shard di Kinesis. Ad esempio, si supponga che uno schema `SysBench` includa migliaia di tabelle e che ogni tabella faccia riferimento solo a un intervallo limitato di valori della chiave primaria. In questo caso, la stessa chiave primaria viene inviata da migliaia di tabelle allo stesso shard, causando un rallentamento. Il valore predefinito è `false`.
+ `UseLargeIntegerValue`— Usa un massimo di 18 cifre int invece di inserire gli int come doppi, disponibile a partire dalla versione 3.5.4. AWS DMS Il valore predefinito è false.
L'esempio seguente mostra l'opzione `kinesis-settings` in uso con un comando `create-endpoint` di esempio emesso utilizzando la 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
```
**Impostazioni attività a pieno carico multithread**
Per contribuire ad aumentare la velocità di trasferimento, AWS DMS supporta un caricamento completo multithread su un'istanza di destinazione Kinesis Data Streams. DMS supporta questo multithreading con impostazioni delle attività che includono le seguenti:
+ `MaxFullLoadSubTasks`: imposta questa opzione per indicare il numero massimo di tabelle da caricare in parallelo. DMS consente di caricare ogni tabella nella corrispondente tabella di destinazione Kinesis utilizzando un'attività secondaria dedicata. Il valore predefinito è 8; il valore il massimo è 49.
+ `ParallelLoadThreads`— Utilizzate questa opzione per specificare il numero di thread da utilizzare per caricare ogni tabella nella relativa tabella di destinazione Kinesis. AWS DMS Il valore massimo per una destinazione del flusso di dati Kinesis è 32. Puoi chiedere che questo limite massimo venga aumentato.
+ `ParallelLoadBufferSize`: utilizza questa opzione per specificare il numero massimo di record da archiviare nel buffer utilizzato dai thread di caricamento parallelo per caricare i dati nella destinazione Kinesis. Il valore predefinito è 50. Il valore massimo è 1.000. Utilizzare questo parametro con `ParallelLoadThreads`; `ParallelLoadBufferSize` è valido solo quando è presente più di un thread.
+ `ParallelLoadQueuesPerThread`: utilizza questa opzione per specificare il numero di code a cui accede ogni thread simultaneo per eliminare i record di dati dalle code e generare un carico batch per la destinazione. Il valore di default è 1. Tuttavia, per le destinazioni Kinesis di varie dimensioni del payload, l'intervallo valido è compreso tra 5 e 512 code per thread.
**Impostazioni attività di carico CDC multithread**
È possibile migliorare le prestazioni dell'acquisizione dei dati di modifica (CDC) per gli endpoint di destinazione in streaming dei dati in tempo reale come Kinesis utilizzando le impostazioni delle attività per modificare il comportamento della chiamata API `PutRecords`. A tale scopo, è possibile specificare il numero di thread simultanei, di code per thread e di record da memorizzare in un buffer utilizzando le impostazioni delle attività `ParallelApply*`. Ad esempio, si supponga di voler eseguire un carico CDC e applicare 128 thread in parallelo. Si desidera inoltre accedere a 64 code per thread, con 50 record memorizzati per buffer.
Per promuovere le prestazioni del CDC, AWS DMS supporta le seguenti impostazioni delle attività:
+ `ParallelApplyThreads`— specifica il numero di thread simultanei che vengono AWS DMS utilizzati durante un caricamento CDC per inviare i record di dati a un endpoint di destinazione Kinesis. Il valore predefinito è zero (0) e il valore massimo è 32.
+ `ParallelApplyBufferSize`: specifica il numero massimo di record da archiviare in ogni coda di buffer per eseguire il push dei thread simultanei a un endpoint di destinazione Kinesis durante un carico CDC. Il valore predefinito è 100 e il valore massimo è 1.000. Utilizzare questa opzione quando `ParallelApplyThreads` specifica più di un thread.
+ `ParallelApplyQueuesPerThread`: specifica il numero di code a cui ogni thread accede per eliminare i record di dati dalle code e generare un carico batch per un endpoint Kinesis durante CDC. Il valore predefinito è 1 e il valore massimo è 512.
Quando si utilizzano le impostazioni delle attività `ParallelApply*`, l'impostazione di `partition-key-type` predefinita è la `primary-key` della tabella, non `schema-name.table-name`.
## Utilizzo di un'immagine precedente per visualizzare i valori originali delle righe CDC per un flusso di dati Kinesis come destinazione
Quando si scrivono aggiornamenti CDC su una destinazione di streaming dati come Kinesis, è possibile visualizzare i valori originali di una riga di database di origine prima di apportare modifiche da un aggiornamento. Per rendere possibile ciò, AWS DMS compila un'*immagine precedente* degli eventi di aggiornamento sulla base dei dati forniti dal motore di database di origine.
Diversi motori di database di origine forniscono diverse quantità di informazioni per un'immagine precedente:
+ Oracle fornisce aggiornamenti alle colonne solo se cambiano.
+ PostgreSQL fornisce solo i dati per le colonne che fanno parte della chiave primaria (modificata o meno). Per fornire dati per tutte le colonne (modificate o meno), devi impostare su `REPLICA_IDENTITY` su `FULL` invece di `DEFAULT`. Tieni presente che occorre scegliere attentamente l'impostazione `REPLICA_IDENTITY` per ogni tabella. Se si imposta `REPLICA_IDENTITY` su `FULL`, tutti i valori delle colonne vengono scritti continuamente nel WAL (Write-Ahead Logging). Ciò può causare problemi di prestazioni o di risorse con le tabelle che vengono aggiornate frequentemente.
+ MySQL generalmente fornisce dati per tutte le colonne ad eccezione dei tipi di dati BLOB e CLOB (modificati o meno).
Per consentire prima dell'imaging di aggiungere valori originali dal database di origine all'output AWS DMS , utilizzare l'impostazione dell'attività `BeforeImageSettings` o il parametro `add-before-image-columns`. Questo parametro applica una regola di trasformazione della colonna.
`BeforeImageSettings` aggiunge un nuovo attributo JSON a ogni operazione di aggiornamento con valori raccolti dal sistema di database di origine, come illustrato di seguito.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Nota**
Si applica solo `BeforeImageSettings` alle AWS DMS attività che contengono un componente CDC, come le attività a pieno carico e le attività CDC (che migrano i dati esistenti e replicano le modifiche in corso) o alle attività solo CDC (che replicano solo le modifiche ai dati). Non applicare `BeforeImageSettings` alle attività a pieno carico.
Per le opzioni `BeforeImageSettings`, si applica quanto segue:
+ Impostare l'opzione `EnableBeforeImage` su `true` da abilitare prima dell'imaging. Il valore predefinito è `false`.
+ Utilizzare l'opzione `FieldName` per assegnare un nome al nuovo attributo JSON. Quando `EnableBeforeImage` è `true`, `FieldName` è richiesto e non può essere vuoto.
+ L'opzione `ColumnFilter` specifica una colonna da aggiungere utilizzando l'imaging precedente. Per aggiungere solo colonne che fanno parte delle chiavi primarie della tabella, utilizzare il valore predefinito, `pk-only`. Per aggiungere qualsiasi colonna con un valore immagine prima, utilizzare `all`. Tieni presente che l'immagine precedente non contiene colonne con tipi di dati LOB, come CLOB o BLOB.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**Nota**
Le destinazioni Amazon S3 non supportano `BeforeImageSettings`. Per le destinazioni S3, utilizzare solo la regola di trasformazione `add-before-image-columns` da eseguire prima dell'imaging durante CDC.
### Utilizzo di una regola di trasformazione dell'immagine precedente
In alternativa alle impostazioni delle attività, è possibile utilizzare il parametro `add-before-image-columns`, che applica una regola di trasformazione delle colonne. Con questo parametro, è possibile abilitare l'imaging precedente durante CDC su destinazioni di flusso di dati come Kinesis.
Utilizzando `add-before-image-columns` in una una regola di trasformazione, è possibile applicare un controllo più dettagliato dei risultati dell'immagine precedente. Le regole di trasformazione consentono di utilizzare un localizzatore di oggetti che consente di controllare le tabelle selezionate per la regola. Inoltre, è possibile concatenare le regole di trasformazione, consentendo l'applicazione di regole diverse a tabelle diverse. È quindi possibile manipolare le colonne prodotte utilizzando altre regole.
**Nota**
Non utilizzare il parametro `add-before-image-columns` insieme all'impostazione dell'attività `BeforeImageSettings` all'interno della stessa attività. Utilizzare invece il parametro o l'impostazione, ma non entrambi, per una singola attività.
Un tipo di regola `transformation` regola con il parametro `add-before-image-columns` per una colonna deve fornire una sezione `before-image-def`. Di seguito viene riportato un esempio.
```
{
"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,
}
}
```
Il valore di `column-prefix` viene anteposto a un nome di colonna e il valore predefinito di `column-prefix` è `BI_`. Il valore di `column-suffix` viene aggiunto al nome della colonna e il valore predefinito è vuoto. Non impostare sia `column-prefix` sia `column-suffix` sull'opzione per svuotare le stringhe.
Scegliere un valore per `column-filter`. Per aggiungere solo colonne che fanno parte delle chiavi primarie della tabella, scegliere `pk-only` . Scegliere `non-lob` per aggiungere solo colonne non di tipo LOB. Oppure scegliere `all` per aggiungere qualsiasi colonna con un valore immagine precedente.
### Esempio di una regola di trasformazione dell'immagine precedente
La regola di trasformazione nell'esempio seguente aggiunge una nuova colonna chiamata `BI_emp_no` nella destinazione. Quindi una dichiarazione come `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` popola il campo `BI_emp_no` con 1. Quando si scrivono aggiornamenti CDC alle destinazioni Amazon S3, la colonna `BI_emp_no` indica quale riga originale è stata aggiornata.
```
{
"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"
}
}
]
}
```
Per informazioni sull'utilizzo dell'operazione della regola `add-before-image-columns`, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Prerequisiti per l'utilizzo di un flusso di dati Kinesis come destinazione per AWS Database Migration Service
### Ruolo IAM per l'utilizzo di un flusso di dati Kinesis come destinazione per AWS Database Migration Service
Prima di configurare un flusso di dati Kinesis come destinazione per AWS DMS, assicurati di creare un ruolo IAM. Questo ruolo deve consentire di AWS DMS assumere e concedere l'accesso ai flussi di dati Kinesis in cui viene effettuata la migrazione. Nella seguente policy IAM viene mostrato il set minimo di autorizzazioni di accesso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Il ruolo utilizzato per la migrazione a un flusso di dati Kinesis deve disporre delle seguenti autorizzazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Accesso a un flusso di dati Kinesis come destinazione per AWS Database Migration Service
Nella AWS DMS versione 3.4.7 e successive, per connetterti a un endpoint Kinesis, devi eseguire una delle seguenti operazioni:
+ Configura DMS per utilizzare gli endpoint VPC. Per informazioni sulla configurazione di DMS per utilizzare gli endpoint VPC, consulta [Configurazione degli endpoint VPC per AWS DMS](CHAP_VPC_Endpoints.md).
+ Configura DMS per utilizzare routing pubblici, ovvero per rendere pubblica l'istanza di replica. Per ulteriori informazioni sulle istanze di replica pubbliche, consulta [Istanze di replica pubbliche e private](CHAP_ReplicationInstance.PublicPrivate.md).
## Limitazioni nell'utilizzo di Kinesis Data Streams come destinazione per AWS Database Migration Service
Le seguenti limitazioni si applicano quando si utilizza il flusso di dati Kinesis come destinazione:
+ AWS DMS pubblica ogni aggiornamento di un singolo record nel database di origine come un unico record di dati in un determinato flusso di dati Kinesis indipendentemente dalle transazioni. Tuttavia, è possibile includere i dettagli della transazione per ogni record di dati utilizzando i parametri pertinenti dell'API `KinesisSettings`.
+ La modalità LOB completa non è supportata.
+ La dimensione massima del LOB supportata è 1 MB.
+ I flussi di dati Kinesis non supportano la deduplicazione. Le applicazioni che utilizzano i dati provenienti da un flusso devono gestire i record duplicati. Per ulteriori informazioni, consulta [Handling duplicate records](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) nella *Guida per gli sviluppatori di Flusso di dati Amazon Kinesis*.
+ AWS DMS supporta i seguenti quattro moduli per le chiavi di partizione:
+ `SchemaName.TableName`: una combinazione del nome dello schema e quello della tabella.
+ `${AttributeName}`: il valore di uno dei campi nel formato JSON o la chiave primaria della tabella del database di origine.
+ `transaction-id`: L'ID della transazione CDC. Tutti i record all'interno della stessa transazione vengono inseriti nella stessa partizione.
+ `constant`: un valore letterale fisso per ogni record indipendentemente dalla tabella o dai dati. Tutti i record vengono inviati allo stesso valore della chiave di partizione «costante», che fornisce un ordinamento globale rigoroso in tutte le tabelle.
```
{
"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"
}
}
```
+ Per informazioni sulla crittografia dei dati a riposo all'interno del flusso di dati Kinesis, consulta [Data protection in Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
+ L'impostazione dell'`IncludeTransactionDetails`endpoint è supportata solo quando l'endpoint di origine è Oracle, SQL Server, PostgreSQL o MySQL. Per altri tipi di endpoint di origine, i dettagli della transazione non verranno inclusi.
+ `BatchApply` non è supportato per un endpoint Kinesis. L'utilizzo di Batch Apply (ad esempio, l'impostazione del task dei metadati di `BatchApplyEnabled` destinazione) per un target Kinesis causa il fallimento dell'attività e la perdita di dati. Non abilitarlo `BatchApply` quando si utilizza Kinesis come endpoint di destinazione.
+ Le destinazioni Kinesis sono supportate solo per un flusso di dati Kinesis nello stesso AWS account e nello stesso dell'istanza di replica. Regione AWS
+ Quando si esegue la migrazione da una fonte MySQL, i dati non includono BeforeImage i tipi di dati CLOB e BLOB. Per ulteriori informazioni, consulta [Utilizzo di un'immagine precedente per visualizzare i valori originali delle righe CDC per un flusso di dati Kinesis come destinazione](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS non supporta la migrazione di valori di tipi di `BigInt` dati con più di 16 cifre. Per aggirare questa limitazione puoi utilizzare la seguente regola di trasformazione per convertire la colonna `BigInt` in una stringa. Per ulteriori informazioni sulle regole di trasformazione, consulta [Operazioni e regole di trasformazione](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
}
}
```
+ Quando più operazioni DML all'interno di una singola transazione modificano una colonna Large Object (LOB) nel database di origine, il database di destinazione conserva solo il valore LOB finale dell'ultima operazione della transazione. I valori LOB intermedi impostati dalle operazioni precedenti nella stessa transazione vengono sovrascritti, il che può causare potenziali perdite di dati o incongruenze. Questo comportamento si verifica a causa del modo in cui i dati LOB vengono elaborati durante la replica.
+ AWS DMS non supporta i dati di origine contenenti `'\0'` caratteri incorporati quando si utilizza Kinesis come endpoint di destinazione. I dati contenenti `'\0'` caratteri incorporati verranno troncati al primo carattere. `'\0'`
## Utilizzo della mappatura degli oggetti per la migrazione dei dati a un flusso di dati Kinesis
AWS DMS utilizza regole di mappatura delle tabelle per mappare i dati dal flusso di dati Kinesis di origine a quello di destinazione. Per mappare i dati a un flusso di destinazione, è necessario utilizzare una regola di mappatura delle tabelle denominata mappatura degli oggetti. La mappatura degli oggetti consente di definire il modo in cui i record di dati nell'origine vengono mappati ai record di dati pubblicati nel flusso di dati Kinesis.
I flussi di dati Kinesis non dispongono di una struttura preimpostata oltre a una chiave di partizione. In una regola di mapping degli oggetti, i valori possibili di una `partition-key-type` per i record di dati sono `schema-table`, `transaction-id`, `primary-key`, `constant` e `attribute-name`.
Per creare una regola di mappatura degli oggetti, è necessario specificare il parametro `rule-type` come `object-mapping`. Questa regola specifica il tipo di mappatura degli oggetti da utilizzare.
Di seguito è riportata la struttura per la regola.
```
{
"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 attualmente supporta `map-record-to-record` e è `map-record-to-document` l'unico valore valido per il parametro. `rule-action` Queste impostazioni influiscono sui valori che non sono esclusi come parte dell'elenco degli attributi `exclude-columns`. I `map-record-to-document` valori `map-record-to-record` and specificano come AWS DMS gestisce questi record per impostazione predefinita. Questi valori non influiscono in alcun modo sulle mappature degli attributi.
Utilizza `map-record-to-record` per la migrazione da un database relazionale a un flusso di dati Kinesis. Questo tipo di regola utilizza il valore `taskResourceId.schemaName.tableName` dal database relazionale come chiave di partizione nel flusso di dati Kinesis e crea un attributo per ogni colonna nel database di origine.
Quando utilizzi `map-record-to-record`, tieni presente quanto segue:
+ Questa impostazione ha effetto solo sulle colonne escluse dall'elenco `exclude-columns`.
+ Per ogni colonna di questo tipo, AWS DMS crea un attributo corrispondente nell'argomento di destinazione.
+ AWS DMS crea questo attributo corrispondente indipendentemente dal fatto che la colonna di origine venga utilizzata in una mappatura degli attributi.
Utilizza `map-record-to-document` per inserire le colonne di origine in un unico documento flat nel flusso di destinazione appropriato utilizzando il nome dell'attributo "\$1doc". AWS DMS posiziona i dati in un'unica mappa flat sull'origine chiamata "`_doc`". Questo posizionamento si applica a qualsiasi colonna della tabella di origine non elencata nell'elenco di attributi `exclude-columns`.
Per comprendere il funzionamento di `map-record-to-record`, è opportuno esaminarne il comportamento in azione. Per questo esempio, supponiamo che tu stia iniziando con una riga di tabella del database relazionale con la struttura e i dati seguenti.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Per eseguire la migrazione di queste informazioni da uno schema denominato `Test` a un flusso di dati Kinesis, crea le regole per mappare i dati sul flusso di destinazione. La regola seguente illustra la mappatura.
```
{
"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"
}
}
]
}
```
Di seguito viene illustrato il formato di record risultante nel flusso di dati Kinesis:
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaname.tableName
+ Dati: //Il seguente messaggio JSON
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
Supponi tuttavia di utilizzare le stesse regole ma modificando il parametro `rule-action` su `map-record-to-document` ed escludendo determinate colonne. La regola seguente illustra la mappatura.
```
{
"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"
]
}
}
]
}
```
In questo caso, le colonne non elencate nel parametro `exclude-columns`, `FirstName`, `LastName`, `StoreId` e `DateOfBirth` sono mappate a `_doc`. Di seguito viene illustrato il formato di record risultante.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Ristrutturazione dei dati con la mappatura degli attributi
Puoi ristrutturare i dati mentre li stai migrando a un flusso di dati Kinesis utilizzando una mappa degli attributi. Ad esempio, potresti voler combinare più campi nell'origine in un unico campo nella destinazione. La seguente mappa degli attributi illustra come ristrutturare i dati.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Per impostare un valore costante per, specificare`partition-key`, questo imposta il valore della partizione su. `"partition-key-type: "constant"` `constant` Ad esempio, potresti eseguire questa operazione per forzare l'archiviazione di tutti i dati in un singolo shard. Questo approccio viene illustrato nella mappatura seguente.
```
{
"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}"
}
]
}
}
]
}
```
**Nota**
Il valore `partition-key` per un record di controllo per una tabella specifica è `TaskId.SchemaName.TableName`. Il valore `partition-key` per un record di controllo per un'attività specifica è il `TaskId` del record. La specifica si un valore `partition-key` nella mappatura degli oggetti non influisce sul parametro `partition-key` per un record di controllo.
Quando `partition-key-type` è impostato su `attribute-name` in una regola di mappatura della tabella, è necessario specificare`partition-key-name`, che deve fare riferimento a una colonna della tabella di origine o a una colonna personalizzata definita nella mappatura. Inoltre, `attribute-mappings` deve essere fornito per definire il modo in cui le colonne di origine vengono mappate al Kinesis Stream di destinazione.
### Formato del messaggio per il flusso di dati Kinesis
L'output JSON è semplicemente un elenco di coppie chiave-valore. Un formato di messaggio JSON\$1UNFORMATTED è una stringa JSON a riga singola con nuovo delimitatore di riga.
AWS DMS fornisce i seguenti campi riservati per semplificare l'utilizzo dei dati provenienti da Kinesis Data Streams:
**RecordType**
Il tipo di record può essere relativo ai dati o al controllo. I *record di dati *rappresentano le righe effettive nell'origine. I *record di controllo* sono per eventi importanti nel flusso, ad esempio un riavvio dell'attività.
**Operation**
Per i record di dati, l'operazione può essere `load`, `insert`, `update` o `delete`.
Per i record di controllo, l'operazione può essere `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` o `column-type-change`.
**SchemaName**
Lo schema di origine per il record. Questo campo può essere vuoto per un record di controllo.
**TableName**
La tabella di origine per il record. Questo campo può essere vuoto per un record di controllo.
**Time stamp**
Il timestamp relativo al momento della creazione del messaggio JSON. Il campo viene formattato con il formato ISO 8601.
# Usare Apache Kafka come obiettivo per AWS Database Migration Service
È possibile utilizzarlo AWS DMS per migrare i dati in un cluster Apache Kafka. Apache Kafka è una piattaforma di streaming distribuita. È possibile utilizzare Apache Kafka per l'inserimento e l'elaborazione dei dati di streaming in tempo reale.
AWS offre anche Amazon Managed Streaming for Apache Kafka (Amazon MSK) da utilizzare come destinazione. AWS DMS Amazon MSK è un servizio di streaming Apache Kafka completamente gestito che semplifica l'implementazione e la gestione delle istanze Apache Kafka. Funziona con le versioni open source di Apache Kafka e accedi alle istanze Amazon MSK come AWS DMS destinazioni esattamente come qualsiasi istanza di Apache Kafka. Per ulteriori informazioni, consulta [Che cos'è Amazon MSK?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) nella *Guida per sviluppatori di Streaming gestito da Amazon per Apache Kafka*.
Un cluster Kafka archivia i flussi di record in categorie denominate argomenti che sono suddivisi in partizioni. Le *partizioni* sono sequenze di record di dati (messaggi) identificate in modo univoco in un argomento. Le partizioni possono essere distribuite tra più broker in un cluster per consentire l'elaborazione parallela dei record dell'argomento. Per ulteriori informazioni su argomenti e partizioni e la loro distribuzione in Apache Kafka, consulta [Argomenti e registri](https://kafka.apache.org/documentation/#intro_topics) e [Distribuzione](https://kafka.apache.org/documentation/#intro_distribution).
Il cluster Kafka può essere un'istanza Amazon MSK, un cluster in esecuzione su un'istanza Amazon EC2 o un cluster on-premise. Un'istanza Amazon MSK o un cluster su un'istanza Amazon EC2 può trovarsi nello stesso VPC o in uno diverso. Se il cluster è on-premise, è possibile utilizzare il server dei nomi on-premise dell'istanza di replica per risolvere il nome host del cluster. Per informazioni sulla configurazione di un server dei nomi per l'istanza di replica, consulta [Utilizzo del server dei nomi in locale](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Per ulteriori informazioni sulla configurazione di una rete, consulta [Configurazione di una rete per un'istanza di replica](CHAP_ReplicationInstance.VPC.md).
Quando utilizzi un cluster Amazon MSK, assicurati che il relativo gruppo di sicurezza consenta l'accesso dall'istanza di replica. Per informazioni sulla modifica del gruppo di sicurezza di un cluster Amazon MSK, consulta [Modifica del gruppo di sicurezza di un cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service pubblica i record relativi a un argomento di Kafka utilizzando JSON. Durante la conversione, AWS DMS serializza ogni record dal database di origine in una coppia attributo-valore in formato JSON.
È possibile usare la mappatura degli oggetti per migrare i dati da qualsiasi origine dati supportata a un cluster Kafka di destinazione. Con la mappatura degli oggetti, determini il modo in cui strutturare i record di dati nell'argomento di destinazione. Puoi inoltre definire una chiave di partizionamento per ogni tabella che viene utilizzata da Kafka per raggruppare i dati nelle sue partizioni.
Attualmente, AWS DMS supporta un singolo argomento per attività. Per una singola attività con più tabelle, tutti i messaggi vengono indirizzati a un unico argomento. Ogni messaggio include una sezione di metadati che identifica lo schema e la tabella di destinazione. AWS DMS le versioni 3.4.6 e successive supportano la replica multitopica utilizzando la mappatura degli oggetti. Per ulteriori informazioni, consulta [Replica di più argomenti con la mappatura degli oggetti](#CHAP_Target.Kafka.MultiTopic).
**Impostazioni endpoint Apache Kafka**
È possibile specificare i dettagli della connessione tramite le impostazioni dell'endpoint nella AWS DMS console o l'`--kafka-settings`opzione nella CLI. I requisiti per ogni impostazione sono i seguenti:
+ `Broker`: specifica le posizioni di uno o più broker nel cluster Kafka sotto forma di elenco di voci separate da virgole per ogni `broker-hostname:port`. Un esempio è `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Questa impostazione può specificare le posizioni di uno o tutti i broker del cluster. Tutti i broker del cluster comunicano per gestire il partizionamento dei record di dati migrati verso l'argomento.
+ `Topic` (facoltativo): specifica il nome dell'argomento con una lunghezza massima di 255 lettere e simboli. È possibile utilizzare punto (.), carattere di sottolineatura (\$1) e segno meno (-). I nomi degli argomenti con un punto (.) o un carattere di sottolineatura (\$1) possono interferire con le strutture dati interne. Nel nome dell'argomento utilizzare uno dei due simboli ma non entrambi. Se non specificate il nome di un argomento, AWS DMS lo usa `"kafka-default-topic"` come argomento di migrazione.
**Nota**
Se desiderate AWS DMS creare un argomento di migrazione specificato dall'utente o l'argomento predefinito, impostatelo `auto.create.topics.enable = true` come parte della configurazione del cluster Kafka. Per ulteriori informazioni, consulta [Limitazioni nell'utilizzo di Apache Kafka come destinazione per AWS Database Migration Service](#CHAP_Target.Kafka.Limitations)
+ `MessageFormat`: il formato di output per i record creati nell'endpoint. Il formato del messaggio è `JSON` (predefinito) o `JSON_UNFORMATTED` (una singola riga senza tabulazione).
+ `MessageMaxBytes`: la dimensione massima in byte per i record creati nell'endpoint. Il valore di default è 1.000.000.
**Nota**
È possibile utilizzare solo AWS CLI/SDK per passare `MessageMaxBytes` a un valore non predefinito. Ad esempio utilizza il seguente comando per modificare l'endpoint Kafka esistente e cambiare `MessageMaxBytes`.
```
aws dms modify-endpoint --endpoint-arn your-endpoint
--kafka-settings Broker="broker1-server:broker1-port,broker2-server:broker2-port,...",
Topic=topic-name,MessageMaxBytes=integer-of-max-message-size-in-bytes
```
+ `IncludeTransactionDetails`: fornisce informazioni dettagliate sulle transazioni dal database di origine. Tali informazioni includono un timestamp di commit, una posizione nel log e valori per `transaction_id`, `previous_transaction_id` e `transaction_record_id`(l'offset del record all'interno di una transazione). Il valore predefinito è `false`.
+ `IncludePartitionValue`: mostra il valore della partizione nell'output dei messaggi di Kafka, a meno che il tipo della partizione non sia `schema-table-type`. Il valore predefinito è `false`.
+ `PartitionIncludeSchemaTable`: aggiunge ai nomi di schemi e tabelle il prefisso con i valori di partizione, quando il tipo di partizione è `primary-key-type`. In questo modo si aumenta la distribuzione dei dati tra le partizioni di Kafka. Ad esempio, si supponga che uno schema `SysBench` includa migliaia di tabelle e che ogni tabella faccia riferimento solo a un intervallo limitato di valori della chiave primaria. In questo caso, la stessa chiave primaria viene inviata da migliaia di tabelle alla stessa partizione, causando un rallentamento. Il valore predefinito è `false`.
+ `IncludeTableAlterOperations`: include tutte le operazioni DDL (Data Definition Language) che modificano i dati di controllo della tabella, ad esempio `rename-table`, `drop-table`, `add-column`, `drop-column` e `rename-column`. Il valore predefinito è `false`.
+ `IncludeControlDetails`: mostra le informazioni dettagliate del controllo per la definizione di tabelle, la definizione di colonne e le modifiche di tabelle e colonne nell'output dei messaggi Kafka. Il valore predefinito è `false`.
+ `IncludeNullAndEmpty`: include le colonne vuote e NULL nella destinazione. Il valore predefinito è `false`.
+ `SecurityProtocol`: imposta una connessione sicura a un endpoint di destinazione Kafka utilizzando Transport Layer Security (TLS). Le opzioni includono `ssl-authentication`, `ssl-encryption` e `sasl-ssl`. L'utilizzo di `sasl-ssl` richiede `SaslUsername` e `SaslPassword`.
+ `SslEndpointIdentificationAlgorithm`— Imposta la verifica del nome host per il certificato. Questa impostazione è supportata nella AWS DMS versione 3.5.1 e successive. Le opzioni sono le seguenti:
+ `NONE`: Disattiva la verifica del nome host del broker nella connessione del client.
+ `HTTPS`: Abilita la verifica del nome host del broker nella connessione del client.
+ `useLargeIntegerValue`— Usa fino a 18 cifre int invece di emettere int come doppi, disponibile a partire dalla AWS DMS versione 3.5.4. Il valore predefinito è false.
È possibile utilizzare le impostazioni per aumentare la velocità del trasferimento. Per farlo, AWS DMS supporta il pieno carico multithread in un cluster Apache Kafka di destinazione. AWS DMS supporta il multithreading con le impostazioni delle attività seguenti:
+ `MaxFullLoadSubTasks`— Utilizzate questa opzione per indicare il numero massimo di tabelle di origine da caricare in parallelo. AWS DMS carica ogni tabella nella tabella di destinazione Kafka corrispondente utilizzando una sottoattività dedicata. Il valore predefinito è 8; il valore il massimo è 49.
+ `ParallelLoadThreads`— Utilizzate questa opzione per specificare il numero di thread da utilizzare per caricare ogni tabella nella relativa tabella di destinazione Kafka. AWS DMS Il valore massimo per una destinazione Apache Kafka è 32. Puoi chiedere che questo limite massimo venga aumentato.
+ `ParallelLoadBufferSize`: utilizza questa opzione per specificare il numero massimo di record da archiviare nel buffer usato dai thread di caricamento parallelo per caricare i dati nella destinazione Kafka. Il valore predefinito è 50. Il valore massimo è 1.000. Utilizzare questo parametro con `ParallelLoadThreads`; `ParallelLoadBufferSize` è valido solo quando è presente più di un thread.
+ `ParallelLoadQueuesPerThread`: utilizza questa opzione per specificare il numero di code a cui accede ogni thread simultaneo per eliminare i record di dati dalle code e generare un carico batch per la destinazione. Il valore di default è 1. Il numero massimo è 512.
È possibile migliorare le prestazioni dell'acquisizione dei dati di modifica (CDC) per gli endpoint Kafka ottimizzando le impostazioni delle attività per thread paralleli e operazioni in blocco. A tale scopo, è possibile specificare il numero di thread simultanei, di code per thread e di record da memorizzare in un buffer utilizzando le impostazioni delle attività `ParallelApply*`. Ad esempio, si supponga di voler eseguire un carico CDC e applicare 128 thread in parallelo. Si desidera inoltre accedere a 64 code per thread, con 50 record memorizzati per buffer.
Per promuovere le prestazioni del CDC, AWS DMS supporta le seguenti impostazioni delle attività:
+ `ParallelApplyThreads`— specifica il numero di thread simultanei che vengono AWS DMS utilizzati durante un caricamento CDC per inviare i record di dati a un endpoint di destinazione Kafka. Il valore predefinito è zero (0) e il valore massimo è 32.
+ `ParallelApplyBufferSize`: specifica il numero massimo di record da archiviare in ogni coda di buffer per eseguire il push dei thread simultanei a un endpoint di destinazione Kafka durante un carico CDC. Il valore predefinito è 100 e il valore massimo è 1.000. Utilizzare questa opzione quando `ParallelApplyThreads` specifica più di un thread.
+ `ParallelApplyQueuesPerThread`: specifica il numero di code a cui ogni thread accede per eliminare i record di dati dalle code e generare un carico batch per un endpoint Kafka durante la CDC. Il valore di default è 1. Il numero massimo è 512.
Quando si utilizzano le impostazioni delle attività `ParallelApply*`, l'impostazione di `partition-key-type` predefinita è la `primary-key` della tabella, non `schema-name.table-name`.
## Connessione a Kafka utilizzando Transport Layer Security (TLS)
Il cluster Kafka accetta solo connessioni protette con Transport Layer Security (TLS). Con DMS, è possibile utilizzare una qualsiasi delle seguenti tre opzioni di protocollo di sicurezza per proteggere la connessione degli endpoint Kafka.
**Crittografia SSL (`server-encryption`)**
I client convalidano l'identità del server tramite il certificato del server. Quindi viene stabilita una connessione crittografata tra server e client.
**Autenticazione SSL (`mutual-authentication`)**
Server e client convalidano l'identità reciprocamente tramite i propri certificati. Quindi viene stabilita una connessione crittografata tra server e client.
**SASL-SSL (`mutual-authentication`)**
Il metodo Simple Authentication and Security Layer (SASL) sostituisce il certificato del client con un nome utente e una password per convalidare l'identità del client. In particolare, si forniscono un nome utente e una password registrati dal server in modo che il server possa convalidare l'identità del client. Quindi viene stabilita una connessione crittografata tra server e client.
**Importante**
Apache Kafka e Amazon MSK accettano certificati risolti. Questa è una limitazione nota di Kafka e Amazon MSK da risolvere. Per ulteriori informazioni, consulta [Apache Kafka issues, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Se utilizzi Amazon MSK, prendi in considerazione l'utilizzo delle liste di controllo degli accessi (ACLs) come soluzione alternativa a questa limitazione nota. Per ulteriori informazioni sull'utilizzo ACLs, consulta la sezione [Apache Kafka ACLs](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) della *Amazon Managed Streaming for Apache Kafka Developer* Guide.
Se utilizzi un cluster Kafka autogestito, consulta il [commento datato 21 ottobre 2018](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376) per informazioni sulla configurazione del cluster.
### Utilizzo della crittografia SSL con Amazon MSK o un cluster Kafka autogestito
È possibile utilizzare la crittografia SSL per proteggere la connessione di un endpoint ad Amazon MSK o a un cluster Kafka autogestito. Quando usi il metodo di autenticazione con crittografia SSL, i client convalidano l'identità di un server tramite il certificato del server. Quindi viene stabilita una connessione crittografata tra server e client.
**Per utilizzare la crittografia SSL per connettersi ad Amazon MSK**
+ Configura l'impostazione dell'endpoint del protocollo di sicurezza (`SecurityProtocol`) utilizzando l'opzione `ssl-encryption` quando crei l'endpoint Kafka di destinazione.
L'esempio JSON che segue imposta il protocollo di sicurezza come crittografia SSL.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**Per utilizzare la crittografia SSL per un cluster Kafka autogestito**
1. Se utilizzi un'autorità di certificazione (CA, Certification Authority) privata nel cluster Kafka on-premise, carica il certificato CA privato e ottieni un nome della risorsa Amazon (ARN).
1. Configura l'impostazione dell'endpoint del protocollo di sicurezza (`SecurityProtocol`) utilizzando l'opzione `ssl-encryption` quando crei l'endpoint Kafka di destinazione. L'esempio JSON che segue imposta il protocollo di sicurezza come `ssl-encryption`.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Se utilizzi una CA privata, imposta `SslCaCertificateArn` nell'ARN che hai ottenuto nella prima fase precedente.
### Utilizzo dell'autenticazione SSL
È possibile utilizzare l'autenticazione SSL per proteggere la connessione di un endpoint ad Amazon MSK o a un cluster Kafka autogestito.
Per abilitare l'autenticazione e la crittografia del client utilizzando l'autenticazione SSL per la connessione ad Amazon MSK, procedi come segue:
+ Prepara una chiave privata e un certificato pubblico per Kafka.
+ Carica i certificati nella gestione certificati DMS.
+ Crea un endpoint di destinazione Kafka con il certificato corrispondente specificato nelle impostazioni dell'endpoint Kafka. ARNs
**Per preparare una chiave privata e un certificato pubblico per Amazon MSK**
1. Crea un'istanza EC2 e configura un client per utilizzare l'autenticazione come descritto nelle fasi da 1 a 9 della sezione [Client Authentication](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) della *Guida per sviluppatori di Streaming gestito da Amazon per Apache Kafka*.
Dopo aver completato queste fasi, avrai un Certificate-ARN (l'ARN del certificato pubblico salvato in ACM) e una chiave privata contenuta in un file `kafka.client.keystore.jks`.
1. Recupera il certificato pubblico e copia il certificato nel file `signed-certificate-from-acm.pem` utilizzando il comando seguente:
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
Il comando restituisce informazioni simili a quelle mostrate nell'esempio seguente:
```
{"Certificate": "123", "CertificateChain": "456"}
```
Quindi copia l'equivalente di `"123"` nel file `signed-certificate-from-acm.pem`.
1. Recupera la chiave privata importando la chiave `msk-rsa` da `kafka.client.keystore.jks to keystore.p12`, come mostrato nel seguente esempio.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Utilizza il comando seguente per esportare `keystore.p12` nel formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
Viene visualizzato il messaggio **Enter PEM pass phrase** che richiede la chiave applicata per crittografare il certificato.
1. Rimuovi gli attributi contenitore e gli attributi chiave dal file `.pem` per assicurarti che la prima riga inizi con la stringa seguente.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**Per caricare un certificato pubblico e una chiave privata nella gestione certificati DMS e testare la connessione ad Amazon MSK**
1. Carica nella gestione certificati DMS utilizzando il comando seguente.
```
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. Crea un endpoint di destinazione Amazon MSK e verifica la connessione per assicurarti che l'autenticazione TLS funzioni.
```
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
```
**Importante**
È possibile utilizzare l'autenticazione SSL per proteggere una connessione a un cluster Kafka autogestito. In alcuni casi, si potrebbe utilizzare un'autorità di certificazione (CA) privata nel cluster Kafka on-premise. In tal caso, carica la catena di CA, il certificato pubblico e la chiave privata nella gestione certificati DMS. Quindi, utilizza il corrispondente nome della risorsa Amazon (ARN) nelle impostazioni degli endpoint quando crei l'endpoint di destinazione Kafka on-premise.
**Per preparare una chiave privata e un certificato firmato per un cluster Kafka autogestito**
1. Genera una coppia di chiavi come nel seguente esempio.
```
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. Genera una richiesta di firma del certificato (CSR, Certificate Sign Request).
```
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. Usa la CA nel truststore del cluster per firmare la CSR. Se non disponi di una CA, puoi creare una CA privata.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Importa `ca-cert` nel truststore e nel keystore del server. Se non si dispone di un truststore, utilizza il comando seguente per crearlo e importare `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. Firma il certificato.
```
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. Importa il certificato firmato nel keystore.
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. Utilizza il seguente comando per importare la chiave `on-premise-rsa` da `kafka.server.keystore.jks` a `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. Utilizza il comando seguente per esportare `keystore.p12` nel formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Carica `encrypted-private-server-key.pem` e `signed-certificate.pem` e `ca-cert` nella gestione certificati DMS.
1. Crea un endpoint utilizzando il valore restituito. 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
```
### Utilizzo dell'autenticazione SASL-SSL per connettersi ad Amazon MSK
Il metodo Simple Authentication and Security Layer (SASL) utilizza un nome utente e una password per convalidare l'identità di un client e stabilisce una connessione crittografata tra server e client.
Per utilizzare SASL, devi prima creare un nome utente e una password sicuri quando configuri il cluster Amazon MSK. Per una descrizione di come configurare un nome utente e una password sicuri per un cluster Amazon MSK, consulta [Configurazione dell' SASL/SCRAM autenticazione per un cluster Amazon MSK nella Amazon Managed Streaming for](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) *Apache Kafka Developer Guide*.
Quindi, quando crei l'endpoint di destinazione Kafka, imposta l'impostazione dell'endpoint del protocollo di sicurezza (`SecurityProtocol`) utilizzando l'opzione `sasl-ssl`. Imposti anche le opzioni `SaslUsername` e `SaslPassword`. Assicurati che siano coerenti con il nome utente e la password sicuri creati durante la configurazione del cluster Amazon MSK, come mostrato nel seguente esempio JSON.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**Nota**
Attualmente, AWS DMS supporta solo SASL-SSL pubblico supportato da CA. DMS non supporta SASL-SSL per l'uso con Kafka autogestito supportato da una CA privata.
Per l'autenticazione SASL-SSL, supporta il meccanismo SCRAM-SHA-512 per impostazione predefinita. AWS DMS AWS DMS le versioni 3.5.0 e successive supportano anche il meccanismo Plain. Per supportare il meccanismo Plain, imposta il parametro `SaslMechanism` del tipo di dati API `KafkaSettings` su `PLAIN`. Il tipo di dati `PLAIN` è supportato da Kafka, ma non da Amazon Kafka (MSK).
## Utilizzo di un'immagine precedente per visualizzare i valori originali delle righe CDC per Apache Kafka come destinazione
Quando si scrivono aggiornamenti CDC su una destinazione di streaming dati come Kafka, è possibile visualizzare i valori originali di una riga di database di origine prima di apportare modifiche da un aggiornamento. Per rendere possibile ciò, AWS DMS compila un'*immagine precedente degli eventi di aggiornamento in base ai dati forniti* dal motore di database di origine.
Diversi motori di database di origine forniscono diverse quantità di informazioni per un'immagine precedente:
+ Oracle fornisce aggiornamenti alle colonne solo se cambiano.
+ PostgreSQL fornisce solo i dati per le colonne che fanno parte della chiave primaria (modificata o meno). Se è in uso la replica logica e REPLICA IDENTITY FULL è impostato per la tabella di origine, è possibile ottenere informazioni complete prima e dopo sulla riga scritta WALs e disponibile qui.
+ MySQL generalmente fornisce dati per tutte le colonne (modificate o meno).
Per consentire prima dell'imaging di aggiungere valori originali dal database di origine all'output AWS DMS , utilizzare l'impostazione dell'attività `BeforeImageSettings` o il parametro `add-before-image-columns`. Questo parametro applica una regola di trasformazione della colonna.
`BeforeImageSettings` aggiunge un nuovo attributo JSON a ogni operazione di aggiornamento con valori raccolti dal sistema di database di origine, come illustrato di seguito.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Nota**
Applicare `BeforeImageSettings` alle attività CDC a pieno carico e alle attività CDC (che eseguono la migrazione dei dati esistenti e replicano le modifiche in corso) o solo alle attività CDC (che replicano solo le modifiche dei dati). Non applicare `BeforeImageSettings` alle attività a pieno carico.
Per le opzioni `BeforeImageSettings`, si applica quanto segue:
+ Impostare l'opzione `EnableBeforeImage` su `true` da abilitare prima dell'imaging. Il valore predefinito è `false`.
+ Utilizzare l'opzione `FieldName` per assegnare un nome al nuovo attributo JSON. Quando `EnableBeforeImage` è `true`, `FieldName` è richiesto e non può essere vuoto.
+ L'opzione `ColumnFilter` specifica una colonna da aggiungere utilizzando l'imaging precedente. Per aggiungere solo colonne che fanno parte delle chiavi primarie della tabella, utilizzare il valore predefinito, `pk-only`. Per aggiungere solo colonne non di tipo LOB, utilizzare `non-lob`. Per aggiungere qualsiasi colonna con un valore immagine prima, utilizzare `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Utilizzo di una regola di trasformazione dell'immagine precedente
In alternativa alle impostazioni delle attività, è possibile utilizzare il parametro `add-before-image-columns`, che applica una regola di trasformazione delle colonne. Con questo parametro, è possibile abilitare l'imaging precedente durante il CDC su destinazioni di streaming dati come Kafka.
Utilizzando `add-before-image-columns` in una una regola di trasformazione, è possibile applicare un controllo più dettagliato dei risultati dell'immagine precedente. Le regole di trasformazione consentono di utilizzare un localizzatore di oggetti che consente di controllare le tabelle selezionate per la regola. Inoltre, è possibile concatenare le regole di trasformazione, consentendo l'applicazione di regole diverse a tabelle diverse. È quindi possibile manipolare le colonne prodotte utilizzando altre regole.
**Nota**
Non utilizzare il parametro `add-before-image-columns` insieme all'impostazione dell'attività `BeforeImageSettings` all'interno della stessa attività. Utilizzare invece il parametro o l'impostazione, ma non entrambi, per una singola attività.
Un tipo di regola `transformation` regola con il parametro `add-before-image-columns` per una colonna deve fornire una sezione `before-image-def`. Di seguito viene riportato un esempio.
```
{
"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,
}
}
```
Il valore di `column-prefix` viene anteposto a un nome di colonna e il valore predefinito di `column-prefix` è `BI_`. Il valore di `column-suffix` viene aggiunto al nome della colonna e il valore predefinito è vuoto. Non impostare sia `column-prefix` sia `column-suffix` sull'opzione per svuotare le stringhe.
Scegliere un valore per `column-filter`. Per aggiungere solo colonne che fanno parte delle chiavi primarie della tabella, scegliere `pk-only` . Scegliere `non-lob` per aggiungere solo colonne non di tipo LOB. Oppure scegliere `all` per aggiungere qualsiasi colonna con un valore immagine precedente.
### Esempio di una regola di trasformazione dell'immagine precedente
La regola di trasformazione nell'esempio seguente aggiunge una nuova colonna chiamata `BI_emp_no` nella destinazione. Quindi una dichiarazione come `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` popola il campo `BI_emp_no` con 1. Quando si scrivono aggiornamenti CDC alle destinazioni Amazon S3, la colonna `BI_emp_no` indica quale riga originale è stata aggiornata.
```
{
"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"
}
}
]
}
```
Per informazioni sull'utilizzo dell'operazione della regola `add-before-image-columns`, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Limitazioni nell'utilizzo di Apache Kafka come destinazione per AWS Database Migration Service
Utilizzando Apache Kafka come destinazione valgono le seguenti limitazioni:
+ AWS DMS Gli endpoint target Kafka non supportano il controllo degli accessi IAM per Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ La modalità LOB completa non è supportata.
+ Specificate un file di configurazione Kafka per il vostro cluster con proprietà che consentano di creare automaticamente nuovi argomenti. AWS DMS Includere l'impostazione `auto.create.topics.enable = true`. Se si utilizza Amazon MSK, è possibile specificare la configurazione predefinita alla creazione del cluster Kafka, quindi modificare l'impostazione `auto.create.topics.enable` su `true`. Per ulteriori informazioni sulle impostazioni di configurazione predefinite, consulta [La configurazione predefinita di Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) nella *Guida per gli sviluppatori di Streaming gestito da Amazon per Apache Kafka*. Se devi modificare un cluster Kafka esistente creato utilizzando Amazon MSK, esegui il AWS CLI comando `aws kafka create-configuration` per aggiornare la configurazione di Kafka, come nell'esempio seguente:
```
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"
}
```
Qui, `//~/kafka_configuration` è il file di configurazione creato con le impostazioni delle proprietà richieste.
Se utilizzi la tua istanza Kafka installata su Amazon EC2, modifica la configurazione del cluster Kafka con l'impostazione per AWS DMS consentire `auto.create.topics.enable = true` la creazione automatica di nuovi argomenti, utilizzando le opzioni fornite con l'istanza.
+ AWS DMS pubblica ogni aggiornamento di un singolo record nel database di origine come un unico record di dati (messaggio) in un determinato argomento Kafka indipendentemente dalle transazioni.
+ AWS DMS supporta i seguenti quattro moduli per le chiavi di partizione:
+ `SchemaName.TableName`: una combinazione del nome dello schema e quello della tabella.
+ `${AttributeName}`: il valore di uno dei campi nel formato JSON o la chiave primaria della tabella del database di origine.
+ `transaction-id`: L'ID della transazione CDC. Tutti i record all'interno della stessa transazione vengono inseriti nella stessa partizione.
+ `constant`: un valore letterale fisso per ogni record indipendentemente dalla tabella o dai dati. Tutti i record vengono inviati allo stesso valore della chiave di partizione «costante», che fornisce un ordinamento globale rigoroso in tutte le tabelle.
```
{
"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"
}
}
```
+ L'impostazione dell'`IncludeTransactionDetails`endpoint è supportata solo quando l'endpoint di origine è Oracle, SQL Server, PostgreSQL o MySQL. Per altri tipi di endpoint di origine, i dettagli della transazione non verranno inclusi.
+ `BatchApply` non è supportato per un endpoint Kafka. L'utilizzo dell'applicazione in batch, ad esempio l'impostazione dell'attività dei metadati di destinazione `BatchApplyEnabled`, per una destinazione Kafka potrebbe causare la perdita di dati.
+ AWS DMS non supporta la migrazione di valori di tipo di `BigInt` dati con più di 16 cifre. Per aggirare questa limitazione puoi utilizzare la seguente regola di trasformazione per convertire la colonna `BigInt` in una stringa. Per ulteriori informazioni sulle regole di trasformazione, consulta [Operazioni e regole di trasformazione](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 Gli endpoint target Kafka non supportano Amazon MSK servless.
+ Quando si definiscono regole di mappatura, non sono supportate sia la regola di mappatura degli oggetti che una regola di trasformazione. È necessario impostare una sola regola.
+ AWS DMS supporta l'autenticazione SASL per le versioni di Apache Kafka fino alla 3.8. Se utilizzi Kafka 4.0 o versioni successive, puoi connetterti solo senza autenticazione SASL.
+ AWS DMS non supporta i dati di origine contenenti `'\0'` caratteri incorporati quando si utilizza Kafka come endpoint di destinazione. I dati contenenti `'\0'` caratteri incorporati verranno troncati al primo carattere. `'\0'`
## Utilizzo della mappatura degli oggetti per la migrazione dei dati in un argomento Kafka
AWS DMS utilizza regole di mappatura delle tabelle per mappare i dati dall'argomento Kafka di origine a quello di destinazione. Per mappare i dati a un argomento di destinazione, è necessario utilizzare una regola di mappatura delle tabelle denominata mappatura degli oggetti. La mappatura degli oggetti consente di definire il modo in cui i record di dati nell'origine vengono mappati ai record di dati pubblicati nell'argomento Kafka.
Gli argomenti Kafka non dispongono di una struttura preimpostata oltre a una chiave di partizione.
**Nota**
Non è necessario utilizzare la mappatura degli oggetti. È possibile utilizzare la normale mappatura delle tabelle per varie trasformazioni. Tuttavia, il tipo di chiave della partizione segue questi comportamenti predefiniti:
La chiave primaria viene utilizzata come chiave di partizione per il pieno carico.
Se non vengono utilizzate le impostazioni delle attività di applicazione parallela, `schema.table` viene usato come chiave di partizione per la CDC.
Se vengono utilizzate le impostazioni delle attività di applicazione parallela, la chiave primaria viene utilizzata come chiave di partizione per CDC.
Per creare una regola di mappatura degli oggetti, è necessario impostare il parametro `rule-type` su `object-mapping`. Questa regola specifica il tipo di mappatura degli oggetti da utilizzare.
Di seguito è riportata la struttura per la regola.
```
{
"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 attualmente supporta `map-record-to-record` e `map-record-to-document` è l'unico valore valido per il parametro. `rule-action` Queste impostazioni influiscono sui valori che non sono esclusi come parte dell'elenco degli attributi `exclude-columns`. I `map-record-to-document` valori `map-record-to-record` and specificano come AWS DMS gestisce questi record per impostazione predefinita. Questi valori non influiscono in alcun modo sulle mappature degli attributi.
Nel caso di migrazione da un database relazionale a un argomento Kafka utilizza `map-record-to-record`. Questo tipo di regola utilizza il valore `taskResourceId.schemaName.tableName` dal database relazionale come chiave di partizione nell'argomento Kafka e crea un attributo per ogni colonna nel database di origine.
Quando utilizzi `map-record-to-record`, tieni presente quanto segue:
+ Questa impostazione ha effetto solo sulle colonne escluse dall'elenco `exclude-columns`.
+ Per ogni colonna di questo tipo, AWS DMS crea un attributo corrispondente nell'argomento di destinazione.
+ AWS DMS crea questo attributo corrispondente indipendentemente dal fatto che la colonna di origine venga utilizzata in una mappatura degli attributi.
Per comprendere il funzionamento di `map-record-to-record`, è opportuno esaminarne il comportamento in azione. Per questo esempio, supponiamo che tu stia iniziando con una riga di tabella del database relazionale con la struttura e i dati seguenti.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Per eseguire la migrazione di queste informazioni da uno schema denominato `Test` verso un argomento Kafka, crea le regole per mappare i dati sull'argomento di destinazione. La regola seguente illustra la mappatura.
```
{
"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"
}
}
]
}
```
Dato un argomento Kafka e una chiave di partizione (in questo caso, `taskResourceId.schemaName.tableName`), il seguente esempio illustra il formato di record risultante per l'argomento di destinazione Kafka utilizzando i dati di esempio:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
**Topics**
+ [Ristrutturazione dei dati con la mappatura degli attributi](#CHAP_Target.Kafka.AttributeMapping)
+ [Replica di più argomenti con la mappatura degli oggetti](#CHAP_Target.Kafka.MultiTopic)
+ [Formato dei messaggi per Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Ristrutturazione dei dati con la mappatura degli attributi
Utilizzando una mappa degli attributi puoi modificare la struttura dei dati mentre li stai migrando verso un argomento Kafka. Ad esempio, potresti voler combinare più campi nell'origine in un unico campo nella destinazione. La seguente mappa degli attributi illustra come ristrutturare i dati.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Per impostare un valore costante per`partition-key`, specifica`"partition-key-type: "constant"`, questo imposta il valore della partizione su. `constant` Ad esempio, potresti eseguire questa operazione per forzare la memorizzazione di tutti i dati in una singola partizione. Questo approccio viene illustrato nella mappatura seguente.
```
{
"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}"
}
]
}
}
]
}
```
**Nota**
Il valore `partition-key` per un record di controllo per una tabella specifica è `TaskId.SchemaName.TableName`. Il valore `partition-key` per un record di controllo per un'attività specifica è il `TaskId` del record. La specifica si un valore `partition-key` nella mappatura degli oggetti non influisce sul parametro `partition-key` per un record di controllo.
Quando `partition-key-type` è impostato su `attribute-name` in una regola di mappatura della tabella, è necessario specificare`partition-key-name`, che deve fare riferimento a una colonna della tabella di origine o a una colonna personalizzata definita nella mappatura. Inoltre, `attribute-mappings` deve essere fornito per definire il modo in cui le colonne di origine vengono mappate all'argomento Kafka di destinazione.
### Replica di più argomenti con la mappatura degli oggetti
Per impostazione predefinita, AWS DMS le attività migrano tutti i dati di origine su uno degli argomenti di Kafka seguenti:
+ Come specificato nel campo **Argomento** dell'endpoint di destinazione. AWS DMS
+ quello specificato da `kafka-default-topic` se il campo **Argomento** dell'endpoint di destinazione non è compilato e l'impostazione Kafka `auto.create.topics.enable` è impostata su `true`.
Con le versioni AWS DMS del motore 3.4.6 e successive, è possibile utilizzare l'`kafka-target-topic`attributo per mappare ogni tabella di origine migrata su un argomento separato. Ad esempio, le regole di mappatura degli oggetti riportate di seguito migrano le tabelle di origine `Customer` e `Address` agli argomenti Kafka `customer_topic` e `address_topic` rispettivamente. Allo stesso tempo, AWS DMS migra tutte le altre tabelle di origine, inclusa la `Bills` tabella nello `Test` schema, all'argomento specificato nell'endpoint di destinazione.
```
{
"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"
}
}
]
}
```
Utilizzando la replica di più argomenti Kafka, è possibile raggruppare e migrare le tabelle di origine su argomenti Kafka separati utilizzando un'unica attività di replica.
### Formato dei messaggi per Apache Kafka
L'output JSON è semplicemente un elenco di coppie chiave-valore.
**RecordType**
Il tipo di record può essere relativo ai dati o al controllo. I *record di dati *rappresentano le righe effettive nell'origine. I *record di controllo* sono per eventi importanti nel flusso, ad esempio un riavvio dell'attività.
**Operation**
Per i record di dati, l'operazione può essere `load`, `insert`, `update` o `delete`.
Per i record di controllo, l'operazione può essere `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` o `column-type-change`.
**SchemaName**
Lo schema di origine per il record. Questo campo può essere vuoto per un record di controllo.
**TableName**
La tabella di origine per il record. Questo campo può essere vuoto per un record di controllo.
**Time stamp**
Il timestamp relativo al momento della creazione del messaggio JSON. Il campo viene formattato con il formato ISO 8601.
Il seguente esempio di messaggio JSON illustra un tipo di dati con tutti i metadati aggiuntivi.
```
{
"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"
}
}
```
Il seguente esempio di messaggio JSON illustra un tipo di controllo.
```
{
"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"
}
}
```
# Utilizzo di un cluster Amazon OpenSearch Service come destinazione per AWS Database Migration Service
Puoi utilizzarlo AWS DMS per migrare i dati su Amazon OpenSearch Service (OpenSearch Service). OpenSearch Service è un servizio gestito che semplifica la distribuzione, il funzionamento e la scalabilità di un cluster di OpenSearch servizi.
In OpenSearch Service, si lavora con indici e documenti. Un *indice* è una raccolta di documenti e un *documento* è un oggetto JSON contenente valori scalari, matrici e altri oggetti. OpenSearch fornisce un linguaggio di interrogazione basato su JSON, in modo da poter interrogare i dati in un indice e recuperare i documenti corrispondenti.
Quando AWS DMS crea indici per un endpoint di destinazione per OpenSearch Service, crea un indice per ogni tabella dall'endpoint di origine. Il costo per la creazione di un indice di OpenSearch servizio dipende da diversi fattori. Questi sono il numero di indici creati, la quantità totale di dati in questi indici e la piccola quantità di metadati archiviati per ogni documento. OpenSearch
Configura il cluster OpenSearch di servizi con risorse di elaborazione e archiviazione appropriate per l'ambito della migrazione. È consigliabile considerare i seguenti fattori, a seconda dell'attività di replica che desideri utilizzare:
+ Per un caricamento di dati completo, considera la quantità totale di dati da migrare, nonché la velocità del trasferimento.
+ Per replicare le modifiche in corso, considera la frequenza degli aggiornamenti e i requisiti di end-to-end latenza.
Inoltre, configura le impostazioni dell'indice sul OpenSearch cluster, prestando molta attenzione al numero di documenti.
**Impostazioni attività a pieno carico multithread**
Per contribuire ad aumentare la velocità di trasferimento, AWS DMS supporta un caricamento completo multithread su un cluster di destinazione OpenSearch del servizio. AWS DMS supporta questo multithreading con impostazioni delle attività che includono quanto segue:
+ `MaxFullLoadSubTasks`: imposta questa opzione per indicare il numero massimo di tabelle da caricare in parallelo. DMS carica ogni tabella nell'indice di destinazione del OpenSearch servizio corrispondente utilizzando una sottoattività dedicata. Il valore predefinito è 8; il valore il massimo è 49.
+ `ParallelLoadThreads`— Utilizzate questa opzione per specificare il numero di thread da utilizzare per caricare ogni tabella nel relativo indice di destinazione del OpenSearch servizio. AWS DMS Il valore massimo per un oggetto OpenSearch di servizio è 32. Puoi chiedere che questo limite massimo venga aumentato.
**Nota**
Se non si modifica il valore predefinito di `ParallelLoadThreads` (0), AWS DMS trasferisce un singolo record alla volta. Questo approccio comporta un carico eccessivo sul cluster OpenSearch di servizi. Assicurati di impostare questa opzione per 1 o più.
+ `ParallelLoadBufferSize`— Utilizzare questa opzione per specificare il numero massimo di record da archiviare nel buffer utilizzato dai thread di caricamento parallelo per caricare i dati nella destinazione del OpenSearch servizio. Il valore predefinito è 50. Il valore massimo è 1.000. Utilizzare questo parametro con `ParallelLoadThreads`; `ParallelLoadBufferSize` è valido solo quando è presente più di un thread.
Per ulteriori informazioni su come DMS carica un cluster di OpenSearch servizi utilizzando il multithreading, consulta il AWS post del blog Scale [Amazon OpenSearch Service](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) for migations. AWS Database Migration Service
**Impostazioni attività di carico CDC multithread**
Puoi migliorare le prestazioni dell'acquisizione dei dati di modifica (CDC) per un cluster di destinazione del OpenSearch servizio utilizzando le impostazioni delle attività per modificare il comportamento della chiamata API. `PutRecords` A tale scopo, è possibile specificare il numero di thread simultanei, di code per thread e di record da memorizzare in un buffer utilizzando le impostazioni delle attività `ParallelApply*`. Ad esempio, si supponga di voler eseguire un carico CDC e applicare 32 thread in parallelo. Si desidera inoltre accedere a 64 code per thread, con 50 record memorizzati per buffer.
**Nota**
Il supporto per l'uso delle impostazioni delle `ParallelApply*` attività durante gli endpoint di destinazione CDC to Amazon OpenSearch Service è disponibile nelle AWS DMS versioni 3.4.0 e successive.
Per promuovere le prestazioni del CDC, AWS DMS supporta le seguenti impostazioni delle attività:
+ `ParallelApplyThreads`— specifica il numero di thread simultanei che vengono AWS DMS utilizzati durante un caricamento CDC per inviare i record di dati a un endpoint di destinazione del servizio. OpenSearch Il valore predefinito è zero (0) e il valore massimo è 32.
+ `ParallelApplyBufferSize`— Speciifica il numero massimo di record da archiviare in ogni coda di buffer per i thread simultanei da inviare a un endpoint di destinazione del servizio durante un caricamento CDC. OpenSearch Il valore predefinito è 100 e il valore massimo è 1.000. Utilizzare questa opzione quando `ParallelApplyThreads` specifica più di un thread.
+ `ParallelApplyQueuesPerThread`— Speciifica il numero di code a cui ogni thread accede per estrarre i record di dati dalle code e generare un caricamento in batch per un endpoint di servizio durante il CDC. OpenSearch
Quando si utilizzano le impostazioni delle attività `ParallelApply*`, l'impostazione di `partition-key-type` predefinita è la `primary-key` della tabella, non `schema-name.table-name`.
## Migrazione da una tabella di database relazionale a un indice di servizio OpenSearch
AWS DMS supporta la migrazione dei dati verso i tipi di dati scalari del OpenSearch Servizio. Durante la migrazione da un database relazionale come Oracle o MySQL a OpenSearch Service, potresti voler ristrutturare il modo in cui archivi questi dati.
AWS DMS supporta i seguenti tipi di dati scalari di Service: OpenSearch
+ Booleano
+ Data
+ Float
+ Int
+ Stringa
AWS DMS converte i dati di tipo Date in dati di tipo String. Puoi specificare la mappatura personalizzata per interpretare queste date.
AWS DMS non supporta la migrazione dei tipi di dati LOB.
## Prerequisiti per l'utilizzo OpenSearch di Amazon Service come destinazione per AWS Database Migration Service
Prima di iniziare a utilizzare un database di OpenSearch Service come destinazione AWS DMS, assicurati di creare un ruolo AWS Identity and Access Management (IAM). Questo ruolo dovrebbe consentire AWS DMS l'accesso agli indici del OpenSearch servizio sull'endpoint di destinazione. Nella seguente policy IAM viene mostrato il set minimo di autorizzazioni di accesso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Il ruolo utilizzato per la migrazione al OpenSearch Servizio deve disporre delle seguenti autorizzazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
Nell'esempio precedente, sostituiscilo `region` con l'identificativo AWS della regione, *`account-id`* con l'ID del tuo AWS account e `domain-name` con il nome del tuo dominio Amazon OpenSearch Service. Un esempio è `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`
## Impostazioni degli endpoint quando si utilizza OpenSearch Service come destinazione per AWS DMS
Puoi utilizzare le impostazioni degli endpoint per configurare il database di destinazione OpenSearch del servizio in modo simile all'utilizzo di attributi di connessione aggiuntivi. Le impostazioni vengono specificate quando si crea l'endpoint di destinazione utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintassi `--elasticsearch-settings '{"EndpointSetting": "value", ...}'` JSON.
La tabella seguente mostra le impostazioni dell'endpoint che è possibile utilizzare con OpenSearch Service come destinazione.
| Nome attributo | Valori validi | Valore predefinito e descrizione |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Un numero intero positivo maggiore di 0 ma non superiore a 100. | 10 - Per un'attività di caricamento completo, questo attributo determina la soglia di errori consentita prima che l'attività abbia esito negativo. Ad esempio, supponiamo che vi siano 1.500 righe sull'endpoint di origine e che questo parametro sia impostato su 10. Quindi l'operazione ha esito negativo se AWS DMS rileva più di 150 errori (il 10% del conteggio delle righe) durante la scrittura sull'endpoint di destinazione. |
| `ErrorRetryDuration` | Un numero intero positivo maggiore di 0. | 300 — Se si verifica un errore sull'endpoint di destinazione, AWS DMS riprova per questo numero di secondi. In caso contrario, l'attività ha esito negativo. |
| `UseNewMappingType` | true o false | `false`, ma per funzionare con opensearch v2.x dovrebbe essere impostato su. `true` |
## Limitazioni nell'utilizzo OpenSearch di Amazon Service come destinazione per AWS Database Migration Service
Le seguenti limitazioni si applicano quando si utilizza Amazon OpenSearch Service come destinazione:
+ OpenSearch Il servizio utilizza la mappatura dinamica (ipotesi automatica) per determinare i tipi di dati da utilizzare per i dati migrati.
+ OpenSearch Il servizio archivia ogni documento con un ID univoco. Di seguito è riportato un ID di esempio.
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Ogni ID documento è lungo 64 byte, quindi è possibile prevedere questo valore come requisito di storage. Ad esempio, se si migrano 100.000 righe da un' AWS DMS origine, l'indice di OpenSearch servizio risultante richiede lo spazio di archiviazione per altri 6.400.000 byte.
+ Con OpenSearch Service, non è possibile apportare aggiornamenti agli attributi della chiave primaria. Questa restrizione è importante quando si utilizza la replica continua con l'acquisizione dei dati di modifica (CDC), perché può causare la presenza di dati indesiderati nella destinazione. In modalità CDC, le chiavi primarie vengono mappate su SHA256 valori lunghi 32 byte. Queste vengono convertite in stringhe da 64 byte leggibili dall'uomo e vengono utilizzate come documento di servizio. OpenSearch IDs
+ Se AWS DMS rileva elementi che non possono essere migrati, scrive messaggi di errore su Amazon Logs. CloudWatch Questo comportamento è diverso da quello di altri endpoint di AWS DMS destinazione, che scrivono errori in una tabella di eccezioni.
+ AWS DMS non supporta la connessione a un cluster Amazon ES con controllo granulare degli accessi abilitato con utente principale e password.
+ AWS DMS non supporta Service serverless OpenSearch .
+ OpenSearch Il servizio non supporta la scrittura di dati su indici preesistenti.
+ L'impostazione dell'attività di replica non `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` è supportata per l'uso con un endpoint di destinazione. OpenSearch
+ Quando si migrano i dati su Amazon Elasticsearch utilizzando AWS DMS, i dati di origine devono avere una chiave primaria o una colonna identificativa univoca. Se i dati di origine non hanno una chiave primaria o un identificatore univoco, devi definirne uno utilizzando la regola di trasformazione. define-primary-key
## Tipi di dati di destinazione per Amazon OpenSearch Service
Quando AWS DMS migra dati da database eterogenei, il servizio mappa i tipi di dati dal database di origine a tipi di dati intermedi chiamati tipi di dati. AWS DMS Il servizio mappa quindi i tipi di dati intermedi ai tipi di dati di destinazione. La tabella seguente mostra ogni tipo di dati e il tipo di AWS DMS dati a cui è mappato nel Servizio. OpenSearch
| AWS DMS tipo di dati | OpenSearch tipo di dati del servizio |
| --- | --- |
| Booleano | Booleano |
| Data | stringa |
| Orario | data |
| Timestamp | data |
| INT4 | intero |
| Real4 | virgola mobile |
| UINT4 | intero |
Per ulteriori informazioni sui tipi di AWS DMS dati, vedere[Tipi di dati per AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Utilizzo di Amazon DocumentDB come destinazione per AWS Database Migration Service
Per informazioni sulle versioni di Amazon DocumentDB (con compatibilità con MongoDB) supportate, consulta. AWS DMS [Obiettivi per AWS DMS](CHAP_Introduction.Targets.md) Puoi utilizzare AWS DMS per eseguire la migrazione dei dati a Amazon DocumentDB (compatibile con MongoDB) da uno qualsiasi dei motori dei dati di origine supportati da AWS DMS . Il motore di origine può trovarsi su un servizio AWS gestito come Amazon RDS, Aurora o Amazon S3. In alternativa, il motore può essere un database autogestito, ad esempio MongoDB in esecuzione su Amazon EC2 o on-premise.
Puoi utilizzarli AWS DMS per replicare i dati di origine su database, raccolte o documenti Amazon DocumentDB.
**Nota**
Se l'endpoint di origine è MongoDB o Amazon DocumentDB, esegui la migrazione in **modalità documento**.
MongoDB archivia i dati in un formato JSON binario (BSON). AWS DMS supporta tutti i tipi di dati BSON supportati da Amazon DocumentDB. Per un elenco di questi tipi di dati, consulta [Supported APIs MongoDB, operations and data](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) types nella *Amazon DocumentDB* Developer Guide.
Se l'endpoint di origine è un database relazionale, AWS DMS mappa gli oggetti del database su Amazon DocumentDB come segue:
+ Un database relazionale, o schema di database, viene mappato a un *database* Amazon DocumentDB.
+ Le tabelle all'interno di un database relazionale vengono mappate a *raccolte* in Amazon DocumentDB.
+ I record in una tabella relazionale vengono mappati a *documenti* in Amazon DocumentDB. Ogni documento viene costruito da dati nel record di origine.
Se l'endpoint di origine è Amazon S3, allora gli oggetti Amazon DocumentDB risultanti corrispondono a regole di mappatura AWS DMS per Amazon S3. Considera, ad esempio, l'URI seguente:
```
s3://amzn-s3-demo-bucket/hr/employee
```
In questo caso, AWS DMS mappa gli oggetti in `amzn-s3-demo-bucket` Amazon DocumentDB come segue:
+ La parte URI di alto livello (`hr`) viene mappata a un database Amazon DocumentDB.
+ La parte URI successiva (`employee`) viene mappata a una raccolta Amazon DocumentDB.
+ Ogni oggetto in `employee` viene mappato a un documento in Amazon DocumentDB.
Per ulteriori informazioni sulle regole di mappatura per Amazon S3, consulta [Utilizzo di Amazon S3 come sorgente per AWS DMS](CHAP_Source.S3.md).
**Impostazioni degli endpoint Amazon DocumentDB**
Nelle AWS DMS versioni 3.5.0 e successive, puoi migliorare le prestazioni del change data capture (CDC) per gli endpoint Amazon DocumentDB ottimizzando le impostazioni delle attività per thread paralleli e operazioni in blocco. A tale scopo, è possibile specificare il numero di thread simultanei, di code per thread e di record da memorizzare in un buffer utilizzando le impostazioni delle attività `ParallelApply*`. Ad esempio, si supponga di voler eseguire un carico CDC e applicare 128 thread in parallelo. Si desidera inoltre accedere a 64 code per thread, con 50 record memorizzati per buffer.
Per promuovere le prestazioni del CDC, supporta le seguenti impostazioni delle attività: AWS DMS
+ `ParallelApplyThreads`: specifica il numero di thread simultanei da AWS DMS utilizzare durante un caricamento CDC per inviare i record di dati a un endpoint di destinazione Amazon DocumentDB. Il valore predefinito è zero (0) e il valore massimo è 32.
+ `ParallelApplyBufferSize`: specifica il numero massimo di record da archiviare in ogni coda di buffer per eseguire il push dei thread simultanei a un endpoint di destinazione Amazon DocumentDB durante un carico CDC. Il valore predefinito è 100 e il valore massimo è 1.000. Utilizzare questa opzione quando `ParallelApplyThreads` specifica più di un thread.
+ `ParallelApplyQueuesPerThread`: specifica il numero di code a cui ogni thread accede per eliminare i record di dati dalle code e generare un carico batch per un endpoint Amazon DocumentDB durante CDC. Il valore di default è 1. Il numero massimo è 512.
**Nota**
Per le destinazioni Amazon DocumentDB, l'applicazione CDC parallela può causare errori di chiave duplicati o l'applicazione di CDC in stallo per carichi di lavoro che utilizzano indici univoci secondari o richiedono un ordine rigoroso delle modifiche. Utilizza la configurazione di applicazione CDC a thread singolo predefinita per questi carichi di lavoro.
Per ulteriori dettagli sull'utilizzo di Amazon DocumentDB come destinazione AWS DMS, consulta le seguenti sezioni:
**Topics**
+ [Mappatura dei dati da un'origine a una destinazione Amazon DocumentDB](#CHAP_Target.DocumentDB.data-mapping)
+ [Connessione ai cluster elastici Amazon DocumentDB come destinazione](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Replica continua con Amazon DocumentDB come destinazione](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Limitazioni all'utilizzo di Amazon DocumentDB come destinazione](#CHAP_Target.DocumentDB.limitations)
+ [Utilizzo delle impostazioni degli endpoint con Amazon DocumentDB come destinazione](#CHAP_Target.DocumentDB.ECAs)
+ [Tipi di dati di destinazione per Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**Nota**
Per una step-by-step procedura dettagliata del processo di migrazione, consulta Migrazione [da MongoDB ad Amazon DocumentDB nella Guida alla migrazione](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html). AWS Database Migration Service Step-by-Step
## Mappatura dei dati da un'origine a una destinazione Amazon DocumentDB
AWS DMS legge i record dall'endpoint di origine e costruisce documenti JSON in base ai dati letti. Per ogni documento JSON, AWS DMS deve determinare un `_id` campo che funga da identificatore univoco. Quindi scrive il documento JSON in una raccolta Amazon DocumentDB, utilizzando il campo `_id` come chiave primaria.
### Dati di origine che sono una singola colonna
Se i dati di origine sono costituiti da una singola colonna, i dati devono essere di un tipo stringa. (A seconda del motore di origine, il tipo di dati effettivo potrebbe essere VARCHAR, NVARCHAR, TEXT, LOB, CLOB o simili.) AWS DMS presuppone che i dati siano un documento JSON valido e li replica su Amazon DocumentDB così come sono.
Se il documento JSON risultante contiene un campo denominato `_id`, tale campo viene utilizzato come `_id` univoco in Amazon DocumentDB.
Se il documento JSON non contiene un campo `_id`, Amazon DocumentDB. genera automaticamente un valore `_id`.
### Dati di origine che sono colonne multiple
Se i dati di origine sono composti da più colonne, AWS DMS costruisce un documento JSON da tutte queste colonne. Per determinare il `_id` campo per il documento, AWS DMS procedi come segue:
+ Se una delle colonne è denominata `_id`, allora i dati in tale colonna vengono utilizzati come destinazione`_id`.
+ Se non è presente alcuna `_id` colonna, ma i dati di origine hanno una chiave primaria o un indice univoco, AWS DMS utilizza tale chiave o valore di indice come `_id` valore. I dati della chiave primaria o dell'indice univoco vengono visualizzati come campi espliciti nel documento JSON.
+ Se non esiste una colonna `_id` né una chiave primaria o indice univoco, Amazon DocumentDB genera automaticamente un valore `_id`.
### Assegnazione forzata di un tipo di dati all'endpoint di destinazione
AWS DMS può modificare le strutture di dati quando scrive su un endpoint di destinazione Amazon DocumentDB. Puoi richiedere tali modifiche rinominando colonne e tabelle a livello di endpoint di origine, oppure fornendo le regole di trasformazione che vengono applicate durante l'esecuzione di un'attività.
#### Utilizzo di un documento JSON nidificato (prefisso json\$1)
Per forzare un tipo di dati, puoi anteporre al nome della colonna di origine `json_` (ovvero `json_columnName`) manualmente o utilizzando una trasformazione. In questo caso, la colonna viene creata come un documento JSON nidificato all'interno del documento di destinazione, anziché come un campo stringa.
Ad esempio, supponiamo di voler migrare il seguente documento da un endpoint di origine MongoDB.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Se non forzi uno qualsiasi dei tipi di dati di origine, il documento `ContactDetails` incorporato viene migrato come stringa.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
Tuttavia, puoi aggiungere una regola di trasformazione per forzare `ContactDetails` a un oggetto JSON. Ad esempio, supponiamo che il nome della colonna di origine originale sia `ContactDetails`. Per forzare il tipo di dati a Nested JSON, la colonna sull'endpoint di origine deve essere rinominata come «json\$1ContactDetails» aggiungendo il prefisso «\$1json\$1\$1 «all'origine manualmente o tramite regole di trasformazione. Ad esempio, puoi utilizzare la seguente regola di trasformazione:
```
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "1",
"rule-name": "1",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "ContactDetails"
},
"rule-action": "rename",
"value": "json_ContactDetails",
"old-value": null
}
]
}
```
AWS DMS ContactDetails replica il campo come JSON annidato, come segue.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Utilizzo di un array JSON (prefisso array\$1)
Per forzare un tipo di dati, puoi anteporre al nome della colonna `array_` (ovvero `array_columnName`) manualmente o utilizzando una trasformazione. In questo caso, AWS DMS considera la colonna come una matrice JSON e la crea come tale nel documento di destinazione.
Supponiamo di voler migrare il seguente documento da un endpoint di origine MongoDB.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Se non forzi uno qualsiasi dei tipi di dati di origine, il documento `ContactDetails` incorporato viene migrato come stringa.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
Tuttavia, puoi aggiungere regole di trasformazione per forzare `ContactAddress` e `ContactPhoneNumbers` ad array JSON, come mostrato nella seguente tabella.
****
| Nome colonna di origine originale | Colonna di origine rinominata |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS replica `ContactAddress` e `ContactPhoneNumbers` come segue.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Connessione ad Amazon DocumentDB tramite TLS
Per impostazione predefinita, un nuovo cluster Amazon DocumentDB creato accetta solo connessioni protette con Transport Layer Security (TLS). Quando TLS è abilitato, ogni connessione ad Amazon DocumentDB richiede una chiave pubblica.
Puoi recuperare la chiave pubblica per Amazon DocumentDB scaricando il file da AWS un `rds-combined-ca-bundle.pem` bucket Amazon S3 ospitato. Per ulteriori informazioni sul download di questo file, consulta [Crittografia delle connessioni con TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) nella *Guida per gli sviluppatori di Amazon DocumentDB*
Dopo aver scaricato questo file.pem, puoi importare la chiave pubblica che contiene come descritto di seguito. AWS DMS
#### Console di gestione AWS
**Per importare il file della chiave pubblica (.pem)**
1. [Apri la AWS DMS console in /dms. https://console.aws.amazon.com](https://console.aws.amazon.com/dms)
1. Nel riquadro di navigazione, scegliere **Certificates (Certificati)**.
1. Scegliere **Import certificate (Importa certificato)** ed effettuare le seguenti operazioni:
+ Per **Certificate identifier (Identificatore certificato)**, immettere un nome univoco per il certificato, ad esempio `docdb-cert`.
+ Per **Import file (Importa file)**, passare al percorso in cui è stato salvato il file .pem.
Dopo aver selezionato le impostazioni desiderate, selezionare **Add new CA certificate (Aggiungi un nuovo certificato CA)**.
#### AWS CLI
Utilizza il comando `aws dms import-certificate` come visualizzato nell'esempio seguente.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Quando crei un endpoint di AWS DMS destinazione, fornisci l'identificatore del certificato (ad esempio,). `docdb-cert` Inoltre, imposta il parametro Modalità SSL su `verify-full`.
## Connessione ai cluster elastici Amazon DocumentDB come destinazione
Nelle AWS DMS versioni 3.4.7 e successive, puoi creare un endpoint di destinazione Amazon DocumentDB come cluster elastico. Se crei l'endpoint di destinazione come cluster elastico, è necessario allegare un nuovo certificato SSL all'endpoint del cluster elastico Amazon DocumentDB in quanto il certificato SSL esistente non funzionerà.
**Per collegare un nuovo certificato SSL all'endpoint del cluster elastico Amazon DocumentDB**
1. In un browser, apri [ https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) e salva il contenuto in un `.pem` file con un nome file univoco, ad esempio. `SFSRootCAG2.pem` Questo è il file di certificato che dovrai importare nelle fasi successive.
1. Crea l'endpoint del cluster elastico e imposta le seguenti opzioni:
1. In **Configurazione dell'endpoint** scegli **Aggiungi un nuovo certificato CA**.
1. Per **Identificativo del certificato** immetti **SFSRootCAG2.pem**.
1. Per **Importa file del certificato** seleziona **Scegli file** e passa al file `SFSRootCAG2.pem` scaricato in precedenza.
1. Seleziona e apri il file `SFSRootCAG2.pem` scaricato.
1. Selezionare **Import certificate (Importa certificato)**.
1. **Dal menu a discesa **Scegli un certificato**, scegli SFSRoot CAG2 .pem.**
Il nuovo certificato SSL del file `SFSRootCAG2.pem` scaricato è ora collegato all'endpoint del cluster elastico Amazon DocumentDB.
## Replica continua con Amazon DocumentDB come destinazione
Se la replica continua (acquisizione dei dati di modifica o CDC) è abilitata per Amazon DocumentDB come destinazione, AWS DMS 3.5.0 e versioni successive forniscono un miglioramento delle prestazioni venti volte superiore rispetto alle versioni precedenti. Nelle versioni precedenti, in cui AWS DMS gestiva fino a 250 record al secondo, AWS DMS ora elabora in modo efficiente oltre 5000 record al secondo. AWS DMS assicura inoltre che i documenti in Amazon DocumentDB rimangano sincronizzati con il codice sorgente. Quando un record di origine viene creato o aggiornato, AWS DMS deve prima determinare quale record Amazon DocumentDB è interessato effettuando le seguenti operazioni:
+ Se il record di origine dispone di una colonna denominata `_id`, il valore di tale colonna determina l'elemento `_id` corrispondente nella raccolta Amazon DocumentDB.
+ Se non è presente alcuna `_id` colonna, ma i dati di origine hanno una chiave primaria o un indice univoco, AWS DMS utilizza tale chiave o valore di indice come `_id` raccolta Amazon DocumentDB.
+ Se il record di origine non ha una `_id` colonna, una chiave primaria o un indice univoco, AWS DMS abbina tutte le colonne di origine ai campi corrispondenti nella raccolta Amazon DocumentDB.
Quando viene creato un nuovo record sorgente, AWS DMS scrive un documento corrispondente su Amazon DocumentDB. Se viene aggiornato un record di origine esistente, AWS DMS aggiorna i campi corrispondenti nel documento di destinazione in Amazon DocumentDB. Gli eventuali campi esistenti nel documento di destinazione ma non nel record di origine non vengono modificati.
Quando viene eliminato un record di origine, AWS DMS elimina il documento corrispondente da Amazon DocumentDB.
### Modifiche strutturali (DDL) all'origine
Con la replica continua, le eventuali modifiche alle strutture di dati di origine (ad esempio tabelle, colonne e così via) vengono propagate alle relative controparti in Amazon DocumentDB. Nei database relazionali, tali modifiche vengono avviate utilizzando istruzioni DDL (Data Definition Language). Puoi vedere come AWS DMS propaga queste modifiche ad Amazon DocumentDB nella tabella seguente.
****
| DDL all'origine | Effetto sulla destinazione Amazon DocumentDB |
| --- | --- |
| CREATE TABLE | Crea una raccolta vuota. |
| Istruzione che rinomina una tabella (RENAME TABLE, ALTER TABLE...RENAME e simili) | Rinomina la raccolta. |
| TRUNCATE TABLE | Rimuove tutti i documenti dalla raccolta, ma solo se HandleSourceTableTruncated è true. Per ulteriori informazioni, consulta [Impostazioni delle attività per la gestione di DDL durante l'elaborazione delle modifiche](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Elimina la raccolta, ma solo se HandleSourceTableDropped è true. Per ulteriori informazioni, consulta [Impostazioni delle attività per la gestione di DDL durante l'elaborazione delle modifiche](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Istruzione che aggiunge una colonna a una tabella (ALTER TABLE...ADD e simili) | L'istruzione DDL viene ignorata e viene emesso un avviso. Quando viene eseguita la prima istruzione INSERT presso l'origine, il nuovo campo viene aggiunto al documento di destinazione. |
| ALTER TABLE...RENAME COLUMN | L'istruzione DDL viene ignorata e viene emesso un avviso. Quando viene eseguita la prima istruzione INSERT presso l'origine, il campo con il nuovo nome viene aggiunto al documento di destinazione. |
| ALTER TABLE...DROP COLUMN | L'istruzione DDL viene ignorata e viene emesso un avviso. |
| Istruzione che modifica il tipo di dati della colonna (ALTER COLUMN...MODIFY e simili) | L'istruzione DDL viene ignorata e viene emesso un avviso. Quando la prima istruzione INSERT viene eseguita presso l'origine con il nuovo tipo di dati, il documento di destinazione viene creato con un campo di tale nuovo tipo di dati. |
## Limitazioni all'utilizzo di Amazon DocumentDB come destinazione
Le seguenti limitazioni si applicano quando si utilizza Amazon DocumentDB come destinazione per: AWS DMS
+ In Amazon DocumentDB i nomi di raccolte non possono contenere il simbolo di dollaro (\$1). Inoltre, i nomi di database non possono contenere caratteri Unicode.
+ AWS DMS non supporta l'unione di più tabelle di origine in un'unica raccolta Amazon DocumentDB.
+ Quando AWS DMS i processi vengono modificati da una tabella di origine che non ha una chiave primaria, tutte le colonne LOB in quella tabella vengono ignorate.
+ Se l'opzione **Change table (Modifica tabella)** è abilitata e AWS DMS incontra una colonna di origine denominata "*\$1id*", allora tale colonna viene visualizzata come "*\$1\$1id*" (due trattini bassi) nella tabella di modifica.
+ Se scegli Oracle come un endpoint di origine, allora l'abilitazione del log supplementare deve essere abilitata nell'origine Oracle. In caso contrario, se presso l'origine sono presenti colonne che non sono state modificate, allora i dati vengono caricati in Amazon DocumentDB come valori nulli.
+ L'impostazione dell'attività di replica `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` non è supportata per l'uso con un endpoint di destinazione DocumentDB.
+ Le raccolte limitate di MongoDB non sono supportate in Amazon DocumentDB. Tuttavia, migra AWS DMS automaticamente tali oggetti come raccolte illimitate su DocumentDB di destinazione.
+ L'applicazione di un CDC parallelo alle destinazioni di Amazon DocumentDB può causare errori di chiave duplicati o un CDC in stallo per carichi di lavoro che utilizzano indici univoci secondari o richiedono un ordine rigoroso delle modifiche. Per tali carichi di lavoro, utilizza la configurazione di applicazione CDC a thread singolo predefinita.
## Utilizzo delle impostazioni degli endpoint con Amazon DocumentDB come destinazione
È possibile utilizzare le impostazioni degli endpoint per configurare il database di destinazione Amazon DocumentDB in modo simile a come si usano gli attributi aggiuntivi di connessione. Le impostazioni vengono specificate quando si crea l'endpoint di destinazione utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in, con la sintassi JSON [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html). `--doc-db-settings '{"EndpointSetting": "value", ...}'`
La tabella seguente mostra le impostazioni degli endpoint che puoi utilizzare con Amazon DocumentDB come destinazione.
| Nome attributo | Valori validi | Valore predefinito e descrizione |
| --- | --- | --- |
| `replicateShardCollections` | booleano `true` `false` | Quando questa impostazione dell'endpoint è `true` ha gli effetti e le limitazioni indicati di seguito: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Tipi di dati di destinazione per Amazon DocumentDB
Nella tabella seguente, puoi trovare i tipi di dati di destinazione di Amazon DocumentDB supportati quando si utilizza AWS DMS e la mappatura predefinita dei tipi di dati AWS DMS. Per ulteriori informazioni sui tipi di dati AWS DMS, consulta. [Tipi di dati per AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS Tipo di dati DMS | Tipi di dati Amazon DocumentDB |
| --- | --- |
| BOOLEAN | Booleano |
| BYTES | Dati binari |
| DATE | Data |
| TIME | Stringa () UTF8 |
| DATETIME | Data |
| INT1 | Intero a 32 bit |
| INT2 | Intero a 32 bit |
| INT4 | Intero a 32 bit |
| INT8 | Intero a 64 bit |
| NUMERIC | Stringa (UTF8) |
| REAL4 | Double |
| REAL8 | Double |
| STRING | Se i dati vengono riconosciuti come JSON, li AWS DMS migra in Amazon DocumentDB come documento. Altrimenti, i dati vengono mappati su String (). UTF8 |
| UINT1 | Intero a 32 bit |
| UINT2 | Intero a 32 bit |
| UINT4 | Intero a 64 bit |
| UINT8 | Stringa () UTF8 |
| WSTRING | Se i dati vengono riconosciuti come JSON, li AWS DMS migra in Amazon DocumentDB come documento. Altrimenti, i dati vengono mappati su String (). UTF8 |
| BLOB | Binario |
| CLOB | Se i dati vengono riconosciuti come JSON, li AWS DMS migra in Amazon DocumentDB come documento. Altrimenti, i dati vengono mappati su String (). UTF8 |
| NCLOB | Se i dati vengono riconosciuti come JSON, li AWS DMS migra in Amazon DocumentDB come documento. Altrimenti, i dati vengono mappati su String (). UTF8 |
# Utilizzo di Amazon Neptune come obiettivo per AWS Database Migration Service
Amazon Neptune è un servizio di database a grafo gestito rapido e affidabile che rende più semplice la creazione e l'esecuzione di applicazioni che funzionano con set di dati altamente connessi. Il cuore di Neptune è un motore di database a grafo ad alte prestazioni appositamente progettato. Questo motore è ottimizzato per archiviare miliardi di relazioni ed eseguire query sul database a grafo con una latenza di millisecondi. Neptune supporta i popolari linguaggi di query grafiche TinkerPop Apache Gremlin e SPARQL del W3C. Per ulteriori informazioni su Amazon Neptune, consulta [What is Amazon Neptune?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) nella *Guida per l'utente di Amazon Neptune*.
Senza un database a grafo come Neptune, è probabile che dati altamente connessi vengano modellati in un database relazionale. Poiché i dati dispongono di connessioni potenzialmente dinamiche, le applicazioni che utilizzano tali origini dati devono modellare query di dati connessi in SQL. Questo approccio richiede la scrittura di un livello aggiuntivo per convertire le query a grafo in SQL. Inoltre, i database relazionali sono dotati di uno schema rigido. Qualsiasi modifica nello schema per modellare il cambio di connessioni richiede tempi di inattività e una ulteriore manutenzione della conversione della query per supportare il nuovo schema. Le prestazioni delle query sono un altro grande limite da considerare durante la progettazione delle applicazioni.
I database a grafo possono semplificare notevolmente tali situazioni. Libero da uno schema, un livello avanzato di query a grafo (Gremlin o SPARQL) e indici ottimizzati per le query a grafo aumentano la flessibilità e le prestazioni. Il database a grafo Amazon Neptune dispone anche di funzionalità aziendali come la crittografia a riposo, un livello di autorizzazione sicuro, backup predefiniti, supporto Multi-AZ, supporto delle repliche di lettura e altre ancora.
Utilizzando AWS DMS, è possibile migrare i dati relazionali che modellano un grafo altamente connesso a un endpoint di destinazione Neptune da un endpoint di origine DMS per qualsiasi database SQL supportato.
Per ulteriori dettagli, consulta quanto segue:
**Topics**
+ [Panoramica sulla migrazione a Amazon Neptune come destinazione](#CHAP_Target.Neptune.MigrationOverview)
+ [Specifica delle impostazioni degli endpoint per Amazon Neptune come destinazione](#CHAP_Target.Neptune.EndpointSettings)
+ [Creazione di un ruolo di servizio IAM per l'accesso ad Amazon Neptune come destinazione](#CHAP_Target.Neptune.ServiceRole)
+ [Specifica delle regole di mappatura del grafo utilizzando Gremlin e R2RML per Amazon Neptune come destinazione](#CHAP_Target.Neptune.GraphMapping)
+ [Tipi di dati per la migrazione di Gremlin e R2RML ad Amazon Neptune come destinazione](#CHAP_Target.Neptune.DataTypes)
+ [Limitazioni all'utilizzo di Amazon Neptune come destinazione](#CHAP_Target.Neptune.Limitations)
## Panoramica sulla migrazione a Amazon Neptune come destinazione
Prima di iniziare una migrazione verso un target di Neptune, crea le seguenti risorse nel tuo account: AWS
+ Un cluster Neptune per l'endpoint di destinazione.
+ Un database relazionale SQL supportato da AWS DMS per l'endpoint di origine.
+ Un bucket Amazon S3 per l'endpoint di destinazione. Crea questo bucket S3 nella stessa AWS regione del tuo cluster Neptune. AWS DMS utilizza questo bucket S3 come archivio di file intermedio per i dati di destinazione che carica in blocco nel database Neptune. Per ulteriori informazioni sulla creazione di un bucket S3, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
+ Un endpoint del cloud privato virtuale (VPC) per S3 nello stesso VPC del cluster Neptune.
+ Un ruolo AWS Identity and Access Management (IAM) che include una policy IAM. Questa policy deve specificare al bucket S3 le autorizzazioni `GetObject`, `PutObject`, `DeleteObject` e `ListObject` per l'endpoint di destinazione. Questo ruolo viene assunto sia AWS DMS da Neptune che da Neptune con accesso IAM sia al bucket S3 di destinazione che al database Neptune. Per ulteriori informazioni, consulta [Creazione di un ruolo di servizio IAM per l'accesso ad Amazon Neptune come destinazione](#CHAP_Target.Neptune.ServiceRole).
Una volta in possesso di queste risorse, la configurazione e l'avvio di una migrazione a una destinazione Neptune è simile a qualsiasi migrazione di pieno carico tramite la console o l'API DMS. Tuttavia, una migrazione a una destinazione Neptune richiede alcuni passaggi specifici.
**Per migrare un database AWS DMS relazionale su Neptune**
1. Creare un'istanza di replica nel modo descritto in [Creazione di un'istanza di replica](CHAP_ReplicationInstance.Creating.md).
1. Crea e testa un database relazionale SQL supportato da AWS DMS per l'endpoint di origine.
1. Crea e testa l'endpoint di destinazione per il database Neptune.
Per connettere l'endpoint di destinazione al database Neptune, specifica il nome del server per l'endpoint del cluster Neptune o per l'endpoint dell'istanza di scrittura Neptune. Inoltre, specifica la cartella del bucket S3 in cui AWS DMS archiviare i file intermedi per il caricamento in blocco nel database Neptune.
Durante la migrazione, AWS DMS archivia tutti i dati di destinazione migrati in questa cartella bucket S3 fino alla dimensione massima del file specificata. Quando questo archivio di file raggiunge questa dimensione massima, carica in AWS DMS blocco i dati S3 archiviati nel database di destinazione. Cancella la cartella per consentire lo storage di eventuali altri dati di destinazione per un successivo caricamento nel database di destinazione. Per ulteriori informazioni su come specificare queste impostazioni, consulta [Specifica delle impostazioni degli endpoint per Amazon Neptune come destinazione](#CHAP_Target.Neptune.EndpointSettings).
1. Crea un'attività di replica di pieno carico con le risorse create nelle fasi da 1 a 3 ed effettua le seguenti operazioni:
1. Utilizzare come sempre la mappatura delle tabelle dell'attività per identificare schemi, tabelle e viste di origine specifici di cui eseguire la migrazione dal database relazionale utilizzando le regole di selezione e trasformazione appropriate. Per ulteriori informazioni, consulta [Utilizzo della mappatura delle tabelle per specificare le impostazioni delle attività](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Specifica le mappature di destinazione scegliendo una delle seguenti opzioni per indicare le regole di mappatura dalle tabelle e dalle viste di origine al database a grafo di destinazione Neptune:
+ Gremlin JSON: per informazioni sull'utilizzo di Gremlin JSON per caricare un database Neptune, consulta [Gremlin load data format](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) nella *Guida per l'utente di Amazon Neptune*.
+ SPARQL RDB to Resource Description Framework Mapping Language (R2RML): per informazioni sull'utilizzo di SPARQL R2RML, consulta la specifica W3C [R2RML: RDB to RDF mapping language](https://www.w3.org/TR/r2rml/).
1. Esegui una delle seguenti operazioni:
+ **Utilizzando la AWS DMS console, specificate le opzioni di mappatura grafica utilizzando le **regole di mappatura dei grafici nella pagina Crea** attività di migrazione del database.**
+ Utilizzando l' AWS DMS API, specificate queste opzioni utilizzando il parametro di `TaskData` richiesta della chiamata API. `CreateReplicationTask`
Per ulteriori informazioni ed esempi sull'utilizzo di Gremlin JSON e SPARQL R2RML per specificare le regole di mappatura a grafo, consulta [Specifica delle regole di mappatura del grafo utilizzando Gremlin e R2RML per Amazon Neptune come destinazione](#CHAP_Target.Neptune.GraphMapping).
1. Avviare la replica per l'attività di migrazione.
## Specifica delle impostazioni degli endpoint per Amazon Neptune come destinazione
Per creare o modificare un endpoint di destinazione, è possibile utilizzare la console o le operazioni API `CreateEndpoint` o `ModifyEndpoint`.
**Per un target Neptune nella console, **specifica le impostazioni specifiche AWS DMS dell'endpoint nella pagina **Crea** endpoint** o Modifica console endpoint.** Per `CreateEndpoint` e `ModifyEndpoint`, specificare i parametri di richiesta per l'opzione `NeptuneSettings`. Nell'esempio seguente viene illustrato come eseguire questa operazione utilizzando la CLI.
```
dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com
--port 8192
--neptune-settings
'{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
"S3BucketName":"amzn-s3-demo-bucket",
"S3BucketFolder":"amzn-s3-demo-bucket-folder",
"ErrorRetryDuration":57,
"MaxFileSize":100,
"MaxRetryCount": 10,
"IAMAuthEnabled":false}‘
```
Qui, l'opzione `--server-name` della CLI indica il nome del server per l'endpoint di scrittura del cluster Neptune. In alternativa, è possibile specificare il nome del server per un endpoint dell'istanza di scrittura Neptune.
Seguono i parametri di richiesta dell'opzione `--neptune-settings`:
+ `ServiceAccessRoleArn` (obbligatorio): il nome della risorsa Amazon (ARN) del ruolo di servizio creato per l'endpoint di destinazione Neptune. Per ulteriori informazioni, consulta [Creazione di un ruolo di servizio IAM per l'accesso ad Amazon Neptune come destinazione](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName` (obbligatorio): il nome del bucket Amazon S3 in cui DMS può archiviare temporaneamente i dati a grafo migrati in file.csv prima di caricarli in blocco nel database di destinazione Neptune. DMS mappa i dati di origine SQL ai dati a grafo prima di archiviarli in questi file .csv.
+ `S3BucketFolder` (obbligatorio): il percorso di una cartella in cui si desidera che DMS archivi i dati a grafo migrati nel bucket S3 specificato da `S3BucketName`.
+ `ErrorRetryDuration` (facoltativo): il numero di millisecondi che DMS deve attendere per riprovare a caricare in blocco dati a grafo migrati nel database di destinazione Neptune prima di generare un errore. Il valore di default è 250.
+ `MaxFileSize` (facoltativo): la dimensione massima in KB di dati a grafo migrati archiviati in un file con estensione .csv prima che DMS carichi in blocco i dati nel database di destinazione Neptune. Il valore predefinito è 1.048.576 KB (1 GB). In caso di esito positivo del caricamento, DMS cancella il bucket, pronto per memorizzare il successivo batch di dati a grafo migrati.
+ `MaxRetryCount` (facoltativo): il numero di tentativi eseguiti da DMS per caricare in blocco i dati a grafo migrati nel database di destinazione Neptune prima di generare un errore. Il predefinito è 5.
+ `IAMAuthEnabled` (facoltativo): per abilitare l'autorizzazione IAM per l'endpoint, imposta questo parametro su `true` e collega il documento della policy IAM appropriato al ruolo di servizio specificato da `ServiceAccessRoleArn`. Il valore predefinito è `false`.
## Creazione di un ruolo di servizio IAM per l'accesso ad Amazon Neptune come destinazione
Per accedere a Neptune come destinazione, creare un ruolo del servizio utilizzando IAM. A seconda della configurazione dell'endpoint Neptune, collega a questo ruolo alcuni o tutti i documenti di trust e della policy IAM descritti di seguito. Quando si crea l'endpoint Neptune, occorre fornire l'ARN del ruolo di servizio. In questo modo, AWS DMS Amazon Neptune può assumere le autorizzazioni per accedere sia a Neptune che al bucket Amazon S3 associato.
Se imposti il parametro `IAMAuthEnabled` in `NeptuneSettings` su `true` nella configurazione dell'endpoint Neptune, collega al ruolo di servizio una policy IAM come la seguente. Se si imposta `IAMAuthEnabled` su `false`, è possibile ignorare questa policy.
```
// 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 policy IAM precedente consente l'accesso completo al cluster di destinazione Neptune specificato da `Resource`.
Collegare una policy IAM come la seguente al ruolo del servizio. Questa policy consente a DMS di archiviare temporaneamente i dati a grafo migrati nel bucket S3 creato per il caricamento in blocco nel database di destinazione 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 policy IAM precedente consente all'account di eseguire query sui contenuti del bucket S3 (`arn:aws:s3:::amzn-s3-demo-bucket`) creato per la destinazione Neptune. Permette inoltre all'account di operare in modo completo sui contenuti di tutti i file e le cartelle del bucket (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Modifica la relazione di trust e associa il seguente ruolo IAM al tuo ruolo di servizio per consentire AWS DMS sia al servizio di database Amazon Neptune di assumere il ruolo.
------
#### [ 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"
}
]
}
```
------
Per informazioni su come specificare questo ruolo di servizio per l'endpoint di destinazione Neptune, consulta [Specifica delle impostazioni degli endpoint per Amazon Neptune come destinazione](#CHAP_Target.Neptune.EndpointSettings).
## Specifica delle regole di mappatura del grafo utilizzando Gremlin e R2RML per Amazon Neptune come destinazione
Le regole di mappatura del grafo create specificano il modo in cui i dati estratti da un'origine di database relazionale SQL vengono caricati in una destinazione del cluster di database Neptune. Il formato di queste regole di mappatura varia a seconda che si tratti di regole per caricare i dati del grafico delle proprietà utilizzando TinkerPop Apache Gremlin o i dati del Resource Description Framework (RDF) utilizzando R2RML. Di seguito è possibile trovare informazioni su questi formati e su dove approfondirle.
È possibile specificare queste regole di mappatura quando si crea l'attività di migrazione utilizzando la console o l'API DMS.
Tramite la console, specificare queste regole di mappatura utilizzando le **Regole di mappatura a grafo** nella pagina **Crea attività di migrazione del database** . In **Regole di mappatura a grafo** è possibile immettere e modificare le regole di mappatura direttamente utilizzando l'editor fornito. In alternativa, è possibile cercare un file che contenga le regole di mappatura nel formato di mappatura a grafo appropriato.
Tramite l'API, specificare queste opzioni utilizzando il parametro di richiesta `TaskData` della chiamata API `CreateReplicationTask`. Impostare `TaskData` sul percorso di un file contenente le regole di mappatura nel formato di mappatura a grafo appropriato.
### Regole di mappatura a grafo per la generazione di dati del grafo di proprietà mediante Gremlin
Utilizzando Gremlin per generare i dati del grafo di proprietà, specificare un oggetto JSON con una regola di mappatura per ogni entità a grafo da generare dai dati di origine. Il formato di questo JSON è definito specificamente per il caricamento in blocco su Amazon Neptune. Il modello seguente mostra l'aspetto di ogni regola in questo oggetto.
```
{
"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 presenza di un'etichetta del vertice implica che il vertice viene creato qui. La sua assenza implica che il vertice viene creato da un'origine diversa e che questa definizione aggiunge solo le proprietà del vertice. Specificare tutte le definizioni di vertici e di edge necessarie per specificare le mappature per l'intera origine del database relazionale.
Segue una regola di esempio per una tabella `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"
}
]
}
]
}
]
}
```
Qui, le definizioni dei vertici e degli edge mappano una relazione gerarchica da un nodo `employee` con ID dipendente (`EmpID`) e un nodo `employee` con un ID manager (`managerId`).
Per ulteriori informazioni sulla creazione di regole di mappatura a grafo utilizzando Gremlin JSON, consulta [Gremlin load data format](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) nella *Guida per l'utente di Amazon Neptune*.
### Regole di RDF/SPARQL mappatura grafica per la generazione di dati
Se si caricano dati RDF di cui eseguire query tramite SPARQL, scrivere le regole di mappatura a grafo in R2RML. R2RML è un linguaggio W3C standard per la mappatura dei dati relazionali a RDF. In un file R2RML, una *mappa delle triple* (ad esempio `<#TriplesMap1>` di seguito) specifica una regola per convertire ogni riga di una tabella logica in zero o più triple RDF. Una *mappa dei soggetti* (ad esempio, qualsiasi `rr:subjectMap` seguente) specifica una regola per generare i soggetti delle triple RDF generate da una mappa delle triple. Una *mappa predicato-oggetto* (ad esempio, qualsiasi `rr:predicateObjectMap` seguente) è una funzione che crea una o più coppie predicato-oggetto per ogni riga di una tabella logica.
Segue un semplice esempio per una tabella `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" ];
]
```
Nell'esempio precedente, la mappatura definisce i nodi del grafo mappati da una tabella di dipendenti.
Segue un altro semplice esempio per una tabella `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" ]
].
```
Nell'esempio precedente, la mappatura definisce i nodi grafici che mappano friend-of-a-friend le relazioni tra le persone in una tabella. `Student`
Per ulteriori informazioni sulla creazione di regole di mappatura a grafo utilizzando SPARQL R2RML, consulta la specifica W3C [R2RML: RDB to RDF Mapping Language](https://www.w3.org/TR/r2rml/).
## Tipi di dati per la migrazione di Gremlin e R2RML ad Amazon Neptune come destinazione
AWS DMS esegue la mappatura dei tipi di dati dall'endpoint di origine SQL al target Neptune in due modi. Il modo che scegli dipende dal formato di mappatura del grafo utilizzato per caricare il database Neptune:
+ Apache TinkerPop Gremlin, utilizzando una rappresentazione JSON dei dati di migrazione.
+ SPARQL di W3C, tramite una rappresentazione R2RML dei dati di migrazione.
Per ulteriori informazioni su questi due formati di mappatura del grafo, consulta [Specifica delle regole di mappatura del grafo utilizzando Gremlin e R2RML per Amazon Neptune come destinazione](#CHAP_Target.Neptune.GraphMapping).
Di seguito è possibile trovare le descrizioni delle mappature dei tipi di dati per ogni formato.
### Mappatura dei tipi di dati da un'origine SQL a una destinazione Gremlin
Nella tabella seguente vengono illustrate le mappature dei tipi di dati da un'origine SQL a una destinazione in formato Gremlin.
AWS DMS mappa qualsiasi tipo di dati sorgente SQL non elencato su un Gremlin. `String`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Neptune.html)
Per ulteriori informazioni sui tipi di dati Gremlin per il caricamento di Neptune, consulta [Gremlin data types](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) nella *Guida per l'utente di Amazon Neptune*.
### Mappatura dei tipi di dati da un'origine SQL a una destinazione R2RML (RDF)
Nella tabella seguente vengono illustrate le mappature dei tipi di dati da un'origine SQL a una destinazione in formato R2RML.
Tutti i tipi di dati RDF elencati fanno distinzione tra maiuscole e minuscole, ad eccezione del formato RDF letterale. AWS DMS mappa qualsiasi tipo di dati sorgente SQL non elencato su un valore letterale RDF.
Un *letterale RDF* è un valore di una serie di forme lessicali letterali e di tipi di dati. Per ulteriori informazioni, consulta [RDF Literals](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) nella specifica W3C *Resource Description Framework (RDF): Concepts and Abstract Syntax*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Neptune.html)
Per ulteriori informazioni sui tipi di dati RDF per il caricamento su Neptune e le relative mappature ai tipi di dati di origine SQL, consulta [Datatype conversions](https://www.w3.org/TR/r2rml/#datatype-conversions) nella specifica W3C *R2RML: RDB to RDF Mapping Language*.
## Limitazioni all'utilizzo di Amazon Neptune come destinazione
Le seguenti limitazioni si applicano quando si utilizza Neptune come destinazione:
+ AWS DMS attualmente supporta attività a pieno carico solo per la migrazione verso un target Neptune. La migrazione di acquisizione dei dati di modifica (CDC) a una destinazione Neptune non è supportata.
+ Assicurati di eliminare manualmente tutti i dati nel database Neptune di destinazione prima di avviare l'attività di migrazione, come negli esempi seguenti.
Per eliminare tutti i dati (vertici ed edge) all'interno del grafo, esegui il comando Gremlin seguente.
```
gremlin> g.V().drop().iterate()
```
Per eliminare i vertici con etichetta `'customer'`, esegui il comando Gremlin seguente.
```
gremlin> g.V().hasLabel('customer').drop()
```
**Nota**
L’eliminazione di un set di dati di grandi dimensioni può richiedere del tempo. È consigliabile ripetere `drop()` con un limite, ad esempio `limit(1000)`.
Per eliminare gli edge con etichetta `'rated'`, esegui il comando Gremlin seguente.
```
gremlin> g.E().hasLabel('rated').drop()
```
**Nota**
L’eliminazione di un set di dati di grandi dimensioni può richiedere del tempo. È consigliabile ripetere `drop()` con un limite, ad esempio `limit(1000)`.
+ L'operazione API DMS `DescribeTableStatistics` può restituire risultati imprecisi su una determinata tabella a causa della natura della struttura dei dati a grafo di Neptune.
Durante la migrazione, AWS DMS analizza ogni tabella di origine e utilizza la mappatura grafica per convertire i dati di origine in un grafico di Neptune. I dati convertiti vengono innanzitutto archiviati nella cartella del bucket S3 specificata per l'endpoint di destinazione. Se l'origine viene sottoposta a scansione e questi dati intermedi S3 vengono generati correttamente, `DescribeTableStatistics` presuppone che i dati siano stati caricati correttamente nel database di destinazione Neptune. Ma ciò non è sempre vero. Per verificare che i dati siano stati caricati correttamente per una determinata tabella, confrontare i valori `count()` restituiti a entrambe le estremità della migrazione per tale tabella.
Nell'esempio seguente, AWS DMS ha caricato una `customer` tabella dal database di origine, a cui viene assegnata l'etichetta `'customer'` nel grafico del database Neptune di destinazione. È possibile verificare che questa etichetta sia scritta nel database di destinazione. A tale scopo, confronta il numero di righe `customer` disponibili nel database di origine con il numero di righe con etichetta `'customer'` caricate nel database di destinazione Neptune al termine dell'attività.
Per ottenere il numero di righe cliente disponibili dal database di origine tramite SQL, eseguire le operazioni seguenti.
```
select count(*) from customer;
```
Per ottenere il numero di righe con etichetta `'customer'` caricate nel grafo del database di destinazione tramite Gremlin, eseguire le operazioni seguenti.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Attualmente, se il caricamento di una singola tabella non riesce, l'intera attività ha esito negativo. A differenza di una destinazione di database relazionale, i dati in Neptune sono altamente connessi, il che rende impossibile in molti casi il ripristino di un'attività. Se non è possibile ripristinare un'attività a causa di questo tipo di errore nel caricamento dei dati, creare una nuova attività per caricare la tabella che non è stato possibile caricare. Prima di eseguire questa nuova attività, elimina manualmente dalla destinazione Neptune la tabella parzialmente caricata.
**Nota**
È possibile ripristinare un'attività che non riesce a eseguire la migrazione a una destinazione Neptune se l'errore è recuperabile (ad esempio un errore di transito di rete).
+ AWS DMS supporta la maggior parte degli standard per R2RML. Tuttavia, AWS DMS non supporta determinati standard R2RML, tra cui espressioni inverse, join e viste. Una soluzione alternativa per una vista R2RML consiste nel creare una vista SQL personalizzata corrispondente nel database di origine. Nell'attività di migrazione, utilizzare la mappatura delle tabelle per scegliere la vista come input. Quindi, mappare la vista a una tabella che viene quindi utilizzata da R2RML per generare dati a grafo.
+ Quando si esegue la migrazione dei dati di origine con tipi di dati SQL non supportati, i dati di destinazione risultanti possono difettare di precisione. Per ulteriori informazioni, consulta [Tipi di dati per la migrazione di Gremlin e R2RML ad Amazon Neptune come destinazione](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS non supporta la migrazione dei dati LOB in un target Neptune.
# Utilizzo di Redis OSS come obiettivo per AWS Database Migration Service
Redis OSS è un archivio di strutture di dati in memoria open source utilizzato come database, cache e broker di messaggi. La gestione dei dati in memoria può eseguire operazioni di lettura o scrittura che richiedono meno di un millisecondo e centinaia di milioni di operazioni ogni secondo. In qualità di archivio dati in memoria, Redis OSS supporta le applicazioni più esigenti che richiedono tempi di risposta inferiori al millisecondo.
Utilizzando AWS DMS, è possibile migrare i dati da qualsiasi database di origine supportato a un data store Redis OSS di destinazione con tempi di inattività minimi. [Per ulteriori informazioni su Redis OSS, consulta la documentazione Redis OSS.](https://redis.io/documentation)
Oltre a Redis OSS locale, AWS Database Migration Service supporta quanto segue:
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) come archivio dati di destinazione. ElastiCache (Redis OSS) funziona con i client Redis OSS e utilizza il formato di dati Redis OSS aperto per archiviare i dati.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) come archivio dati di destinazione. MemoryDB è compatibile con Redis OSS e consente di creare applicazioni utilizzando tutte le strutture di dati e i comandi Redis OSS attualmente in uso. APIs
Per ulteriori informazioni sull'utilizzo di Redis OSS come destinazione per AWS DMS, consulta le seguenti sezioni:
**Topics**
+ [Prerequisiti per l'utilizzo di un cluster Redis OSS come destinazione per AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Limitazioni nell'utilizzo di Redis come destinazione per AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migrazione dei dati da un database relazionale o non relazionale a un target Redis OSS](#CHAP_Target.Redis.Migrating)
+ [Specificazione delle impostazioni degli endpoint per Redis OSS come destinazione](#CHAP_Target.Redis.EndpointSettings)
## Prerequisiti per l'utilizzo di un cluster Redis OSS come destinazione per AWS DMS
*DMS supporta un target Redis OSS locale in una configurazione autonoma o come cluster Redis OSS in cui i dati vengono automaticamente condivisi su più nodi.* Il partizionamento è il processo di separazione dei dati in blocchi più piccoli, denominati partizioni, distribuiti su più server o nodi. In effetti, si tratta di una partizione di dati che contiene un sottoinsieme del set di dati totale e serve una parte del carico di lavoro complessivo.
**Poiché Redis OSS è un data store NoSQL chiave-valore, la convenzione di denominazione delle chiavi Redis OSS da utilizzare quando l'origine è un database relazionale è schema-name.table-name.primary-key.** In Redis OSS, la chiave e il valore non devono contenere il carattere speciale%. In caso contrario, DMS ignora il record.
**Nota**
Se si utilizza ElastiCache (Redis OSS) come destinazione, DMS supporta solo configurazioni *abilitate per la modalità cluster*. Per ulteriori informazioni sull'utilizzo di ElastiCache (Redis OSS) versione 6.x o successiva per creare un data store di destinazione abilitato alla modalità cluster, consulta la [Guida introduttiva](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) alla *Amazon ElastiCache (Redis OSS)* User Guide.
Prima di iniziare una migrazione del database, avvia il cluster Redis OSS con i seguenti criteri.
+ Il cluster ha una o più partizioni.
+ Se utilizzi un target ElastiCache (Redis OSS), assicurati che il cluster non utilizzi il controllo degli accessi basato sui ruoli IAM. Utilizza invece Redis OSS Auth per autenticare gli utenti.
+ Abilita Multi-AZ (zone di disponibilità).
+ Assicurati che il cluster abbia memoria disponibile sufficiente per contenere i dati da migrare dal database.
+ Assicurati che il cluster Redis OSS di destinazione sia privo di tutti i dati prima di iniziare l'attività di migrazione iniziale.
È necessario determinare i requisiti di sicurezza per la migrazione dei dati prima di creare la configurazione del cluster. DMS supporta la migrazione in gruppi di replica di destinazione indipendentemente dalla configurazione della crittografia. Tuttavia, è possibile abilitare o disabilitare la crittografia solo quando si crea la configurazione del cluster.
## Limitazioni nell'utilizzo di Redis come destinazione per AWS Database Migration Service
Le seguenti limitazioni si applicano quando si utilizza Redis OSS come destinazione:
+ Poiché Redis OSS è un archivio dati no-sql con valore chiave, la convenzione di denominazione delle chiavi Redis OSS da utilizzare quando l'origine è un database relazionale è. `schema-name.table-name.primary-key`
+ In Redis OSS, il valore-chiave non può contenere il carattere speciale. `%` In caso contrario, DMS ignora il record.
+ DMS non migrerà le righe che contengono il carattere. `%`
+ DMS non migrerà i campi che contengono il `%` carattere nel nome del campo.
+ La modalità LOB completa non è supportata.
+ Un'autorità di certificazione (CA) privata non è supportata quando si utilizza ElastiCache (Redis OSS) come destinazione.
+ AWS DMS non supporta i dati di origine contenenti `'\0'` caratteri incorporati quando si utilizza Redis come endpoint di destinazione. I dati contenenti `'\0'` caratteri incorporati verranno troncati al primo carattere. `'\0'`
## Migrazione dei dati da un database relazionale o non relazionale a un target Redis OSS
È possibile migrare i dati da qualsiasi data store SQL o NoSQL di origine direttamente su una destinazione Redis OSS. La configurazione e l'avvio di una migrazione verso un target Redis OSS sono simili a qualsiasi migrazione di acquisizione dati a pieno carico e modifica tramite la console DMS o l'API. Per eseguire una migrazione del database verso una destinazione Redis OSS, procedi come segue.
+ Crea un'istanza di replica che esegua tutti i processi per la migrazione. Per ulteriori informazioni, consulta [Creazione di un'istanza di replica](CHAP_ReplicationInstance.Creating.md).
+ Specifica un endpoint di origine. Per ulteriori informazioni, consulta [Creazione di endpoint di origine e destinazione](CHAP_Endpoints.Creating.md).
+ Individua il nome DNS e il numero della porta del cluster.
+ Scarica un bundle di certificati che puoi usare per verificare le connessioni SSL.
+ Specifica un endpoint di destinazione, come descritto di seguito.
+ Crea un'attività o una serie di attività per definire le tabelle e i processi di replica da utilizzare. Per ulteriori informazioni, consulta [Creazione di un'attività](CHAP_Tasks.Creating.md).
+ Esegui la migrazione dei dati dal database di origine al cluster di destinazione.
È possibile avviare una migrazione del database in due modi:
1. Puoi scegliere la AWS DMS console ed eseguire ogni passaggio da lì.
1. Puoi usare il AWS Command Line Interface (AWS CLI). [Per ulteriori informazioni sull'utilizzo della CLI con AWS DMS, vedere AWS CLI for. AWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)
**Per individuare il nome DNS e il numero della pota del cluster**
+ Utilizzate il AWS CLI comando seguente per `replication-group-id` fornire il nome del gruppo di replica.
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Qui, l'output mostra il nome DNS nell'attributo `Address` e il numero di porta nell'attributo `Port` del nodo primario del cluster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Se utilizzate MemoryDB come destinazione, utilizzate il AWS CLI comando seguente per fornire un indirizzo endpoint al cluster Redis OSS.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Download di un bundle di certificati da usare per verificare le connessioni SSL**
+ Nella riga di comando, immetti il comando `wget` seguente. Wget è uno strumento di utilità a riga di comando GNU gratuito utilizzato per scaricare i file da Internet.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Qui, `aws-api-domain` completa il dominio Amazon S3 nella AWS tua regione necessario per accedere al bucket S3 specificato e rds-combined-ca-bundle al file.pem che fornisce.
**Per creare un AWS DMS endpoint di destinazione utilizzando la console**
Questo endpoint è destinato al target Redis OSS già in esecuzione.
+ Nel riquadro di navigazione della console IAM, scegli **Endpoint** quindi seleziona **Crea endpoint**. Nella tabella seguente vengono illustrate le impostazioni.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Redis.html)
Quando hai finito di fornire tutte le informazioni per l'endpoint, AWS DMS crea l'endpoint di destinazione Redis OSS da utilizzare durante la migrazione del database.
Per informazioni sulla creazione di un'attività di migrazione e sull'avvio della migrazione del database, consulta [Creazione di un'attività](CHAP_Tasks.Creating.md).
## Specificazione delle impostazioni degli endpoint per Redis OSS come destinazione
Per creare o modificare un endpoint di destinazione, è possibile utilizzare la console o le operazioni API `CreateEndpoint` o `ModifyEndpoint`.
**Per un target Redis OSS nella AWS DMS console, specifica le **impostazioni specifiche dell'endpoint** nella pagina **Crea** endpoint o Modifica console endpoint.**
Quando si utilizzano le operazioni API `CreateEndpoint` e `ModifyEndpoint`, specifica i parametri della richiesta per l'opzione `RedisSettings`. Nell'esempio seguente viene illustrato come eseguire questa operazione utilizzando la 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"
}
}
}
```
Di seguito sono riportati i parametri `--redis-settings`:
+ `ServerName`— (Obbligatorio) Di tipo`string`, specifica il cluster Redis OSS verso cui verranno migrati i dati e si trova nello stesso VPC.
+ `Port` (obbligatorio): di tipo `number`, il valore della porta utilizzato per accedere all'endpoint.
+ `SslSecurityProtocol` (facoltativo): i valori validi sono `plaintext` e `ssl-encryption`. Il valore predefinito è `ssl-encryption`.
L'opzione `plaintext` non fornisce la crittografia Transport Layer Security (TLS) per il traffico tra endpoint e database.
Utilizza `ssl-encryption` per creare una connessione crittografata. `ssl-encryption` non richiede l'ARN dell'Autorità di certificazione (CA) SSL per verificare il certificato di un server, ma è possibile indentificarne facoltativamente uno utilizzando l'impostazione `SslCaCertificateArn`. Se non viene fornito l'ARN dell'Autorità di certificazione, DMS utilizza la CA root di Amazon.
Quando si utilizza un target Redis OSS locale, è possibile `SslCaCertificateArn` importare un'Autorità di certificazione (CA) pubblica o privata in DMS e fornire tale ARN per l'autenticazione del server. Una CA privata non è supportata quando si utilizza ElastiCache (Redis OSS) come destinazione.
+ `AuthType`— (Obbligatorio) Indica il tipo di autenticazione da eseguire durante la connessione a Redis OSS. I valori validi includono `none`, `auth-token` e `auth-role`.
L'`auth-token`opzione richiede che venga fornito un *AuthPassword* "", mentre l'`auth-role`opzione richiede che vengano forniti *AuthUserName* "" e *AuthPassword* "».
# Usare Babelfish come bersaglio per AWS Database Migration Service
È possibile migrare i dati da un database di origine di Microsoft SQL Server a un target Babelfish utilizzando. AWS Database Migration Service
Babelfish per Aurora PostgreSQL estende l'Edizione compatibile con PostgreSQL database Amazon Aurora con la possibilità di accettare connessioni al database dai client Microsoft SQL Server. In questo modo, le applicazioni create originariamente per SQL Server possono funzionare direttamente con Aurora PostgreSQL con poche modifiche al codice rispetto a una migrazione tradizionale e senza modificare i driver del database.
Per informazioni sulle versioni di Babelfish AWS DMS supportate come destinazione, consulta. [Obiettivi per AWS DMS](CHAP_Introduction.Targets.md) Le versioni precedenti di Babelfish su Aurora PostgreSQL richiedono un aggiornamento prima di utilizzare l'endpoint Babelfish.
**Nota**
L'endpoint di destinazione Aurora PostgreSQL è il modo preferito per migrare i dati su Babelfish. Per ulteriori informazioni, consulta [Utilizzo di Babelfish per Aurora PostgreSQL come destinazione](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
Per informazioni sull'utilizzo di Babelfish come endpoint di database, consulta [Babelfish per Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) nella *Guida per l'utente di Amazon Aurora User Guide*
## Prerequisiti per utilizzare Babelfish come bersaglio per AWS DMS
È necessario creare le tabelle prima di migrare i dati per assicurarsi che vengano AWS DMS utilizzati i tipi di dati e i metadati delle tabelle corretti. Se non crei le tabelle sulla destinazione prima di eseguire la migrazione, è possibile che le tabelle AWS DMS vengano create con tipi di dati e autorizzazioni errati. Ad esempio, AWS DMS crea invece una colonna timestamp come binaria (8) e non fornisce le funzionalità previste. timestamp/rowversion
**Per preparare e creare le tabelle prima della migrazione**
1. Esegui le istruzioni DDL di creazione della tabella che includono vincoli univoci, chiavi primarie o limiti predefiniti.
Non includere vincoli di chiave esterna o istruzioni DDL per oggetti come viste, stored procedure, funzioni o trigger. È possibile applicarli dopo la migrazione del database di origine.
1. Identifica eventuali colonne di identità, colonne calcolate o colonne contenenti tipi di dati rowversion o timestamp per le tabelle. Quindi, crea le regole di trasformazione necessarie per gestire i problemi noti durante l'esecuzione dell'attività di migrazione. Per ulteriori informazioni, consultare [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifica le colonne con tipi di dati che Babelfish non supporta. Quindi, modifica le colonne interessate nella tabella di destinazione per utilizzare i tipi di dati supportati o crea una regola di trasformazione che le rimuova durante l'attività di migrazione. Per ulteriori informazioni, consultare [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
La tabella seguente elenca i tipi di dati di origine non supportati da Babelfish e il corrispondente tipo di dati di destinazione consigliato per l'uso.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Babelfish.html)
**Per impostare il livello delle unità di capacità Aurora (ACUs) per il database di origine Aurora PostgreSQL Serverless V2**
È possibile migliorare le prestazioni dell'attività di AWS DMS migrazione prima di eseguirla impostando il valore ACU minimo.
+ Nella finestra delle **impostazioni della capacità Severless v2**, imposta **Minimo ACUs** su o un livello ragionevole per il tuo cluster Aurora DB. **2**
Per ulteriori informazioni sulle unità di capacità di Aurora, consulta [Scelta dell'intervallo di capacità di Aurora serverless v2 per un cluster Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html) nella *Guida per l'utente di Amazon Aurora*.
Dopo aver eseguito l'attività di AWS DMS migrazione, puoi reimpostare il valore minimo del tuo database di ACUs origine Aurora PostgreSQL Serverless V2 a un livello ragionevole.
## Requisiti di sicurezza quando si utilizza Babelfish come destinazione per AWS Database Migration Service
Di seguito vengono descritti i requisiti di sicurezza per l'utilizzo AWS DMS con un target Babelfish:
+ Il nome utente dell'amministratore (l'utente Admin) utilizzato per creare il database.
+ Accesso PSQL e utente con le autorizzazioni SELECT, INSERT, UPDATE, DELETE e REFERENCES sufficienti.
## Autorizzazioni utente per l'utilizzo di Babelfish come destinazione per AWS DMS
**Importante**
Per motivi di sicurezza, l'account utente utilizzato per la migrazione dei dati deve corrispondere a un utente registrato in qualsiasi database Babelfish utilizzato come destinazione.
L'endpoint di destinazione Babelfish richiede le autorizzazioni utente minime per eseguire una migrazione AWS DMS .
**Per creare un accesso e un utente Transact-SQL (T-SQL) con privilegi limitati**
1. Crea un accesso e una password da utilizzare per la connessione al server.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Crea il database virtuale per il cluster Babelfish.
```
CREATE DATABASE my_database;
GO
```
1. Crea l'utente T-SQL per il database di destinazione.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Per ogni tabella del database Babelfish, CONCEDI le autorizzazioni alle tabelle.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Limitazioni all'uso di Babelfish come obiettivo per AWS Database Migration Service
Quando si utilizza un database Babelfish come destinazione per AWS DMS, si applicano le seguenti limitazioni:
+ È supportata solo la modalità di preparazione delle tabelle "**Nessuna operazione**".
+ Il tipo di dati ROWVERSION richiede una regola di mappatura delle tabelle che rimuove il nome della colonna dalla tabella durante l'attività di migrazione.
+ Il tipo di dati sql\$1variant non è supportato.
+ La modalità LOB completa è supportata. L'utilizzo di SQL Server come endpoint di origine richiede l'impostazione `ForceFullLob=True` dell'attributo di connessione di SQL Server Endpoint per la migrazione LOBs all'endpoint di destinazione.
+ Le impostazioni delle attività di replica presentano le seguenti limitazioni:
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ I tipi di dati TIME (7), DATETIME2 (7) e DATETIMEOFFSET (7) in Babelfish limitano il valore di precisione per la parte in secondi del tempo a 6 cifre. Prendi in considerazione l'utilizzo di un valore di precisione di 6 cifre per la tabella di destinazione quando utilizzi questi tipi di dati. Per le versioni 2.2.0 e successive di Babelfish, quando si utilizza TIME (7) e DATETIME2 (7), la settima cifra di precisione è sempre zero.
+ In modalità DO\$1NOTHING, DMS verifica se la tabella è già presente. Se la tabella non esiste nello schema di destinazione, DMS crea la tabella in base alla definizione della tabella di origine e mappa i tipi di dati definiti dall'utente al relativo tipo di dati di base.
+ Un'attività di AWS DMS migrazione verso un target Babelfish non supporta tabelle con colonne che utilizzano tipi di dati ROWVERSION o TIMESTAMP. È possibile utilizzare una regola di mappatura delle tabelle che rimuove il nome della colonna dalla tabella durante il processo di trasferimento. Nell'esempio di regola di trasformazione seguente, viene trasformata la tabella denominata `Actor` nell'origine per rimuovere tutte le colonne che iniziano con i caratteri `col` nella tabella `Actor` della destinazione.
```
{
"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%"
}
}]
}
```
+ Per le tabelle con colonne identiche o calcolate, in cui le tabelle di destinazione utilizzano nomi con maiuscole e minuscole come Categorie, è necessario creare un'azione della regola di trasformazione che converta i nomi delle tabelle in lettere minuscole per l'attività DMS. L'esempio seguente mostra come creare l'azione della regola di trasformazione, **Make** lowercase utilizzando la console. AWS DMS Per ulteriori informazioni, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Regola di trasformazione di Babelfish\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Prima di Babelfish 2.2.0, DMS limitava a venti (20) il numero di colonne che era possibile replicare su un endpoint di destinazione Babelfish. Con Babelfish 2.2.0 il limite è aumentato a 100 colonne. Con Babelfish 2.4.0 e versioni successive il numero di colonne che è possibile replicare aumenta nuovamente. È possibile eseguire il seguente esempio di codice sul database SQL Server per determinare quali tabelle sono troppo lunghe.
```
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
;
```
## Tipi di dati di destinazione per Babelfish
La tabella seguente mostra i tipi di dati target di Babelfish supportati durante l'utilizzo AWS DMS e la mappatura predefinita dei tipi di dati. AWS DMS
Per ulteriori informazioni sui tipi di AWS DMS dati, vedere. [Tipi di dati per AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS DMS tipo di dati | Tipo di dati di Babelfish |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY (lunghezza) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC(p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | Se la colonna è di ora o data, effettuare le seguenti operazioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Babelfish.html) Se la colonna non è di ora o data, utilizzare VARCHAR (lunghezza). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(length) |
| BLOB | VARBINARY(max) Per utilizzare questo tipo di dati con DMS, è necessario abilitare l'uso di BLOBs per un'attività specifica. DMS supporta i tipi di dati BLOB solo nelle tabelle che includono una chiave primaria. |
| CLOB | VARCHAR(max) Per utilizzare questo tipo di dati con DMS, è necessario abilitarne l'uso CLOBs per un'attività specifica. |
| NCLOB | NVARCHAR(max) Per utilizzare questo tipo di dati con DMS, è necessario abilitarne l'uso NCLOBs per un'attività specifica. Durante la CDC, DMS supporta i tipi di dati NCLOB solo nelle tabelle che includono una chiave primaria. |
# Utilizzo di Amazon Timestream come obiettivo per AWS Database Migration Service
Puoi utilizzarli AWS Database Migration Service per migrare i dati dal tuo database di origine a un endpoint di destinazione Amazon Timestream, con supporto per le migrazioni di dati Full Load e CDC.
Amazon Timestream è un servizio di database di serie temporali veloce, dimensionabile e serverless creato per l'importazione di grandi volumi di dati. I dati di serie temporali sono una sequenza di punti dati raccolti in un intervallo di tempo che vengono utilizzati per misurare gli eventi che cambiano nel tempo. Viene utilizzato per raccogliere, archiviare e analizzare metriche da applicazioni IoT, DevOps applicazioni e applicazioni di analisi. Una volta che i dati sono disponibili in Timestream, puoi visualizzarne e identificarne le tendenze e i modelli pressoché in tempo reale. Per informazioni su Amazon Timestream, consulta [What is Amazon Timestream?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) nella *Guida per gli sviluppatori di Amazon Timestream*.
**Topics**
+ [Prerequisiti per l'utilizzo di Amazon Timestream come destinazione per AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Impostazioni attività a pieno carico multithread](#CHAP_Target.Timestream.FLTaskSettings)
+ [Impostazioni attività di carico CDC multithread](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Impostazioni dell'endpoint quando si utilizza Timestream come destinazione per AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Creazione e modifica di un endpoint di destinazione Amazon Timestream](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Utilizzo della mappatura degli oggetti per la migrazione dei dati in un argomento Timestream](#CHAP_Target.Timestream.ObjectMapping)
+ [Limitazioni nell'utilizzo di Amazon Timestream come destinazione per AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Prerequisiti per l'utilizzo di Amazon Timestream come destinazione per AWS Database Migration Service
Prima di configurare Amazon Timestream come obiettivo AWS DMS per, assicurati di creare un ruolo IAM. Questo ruolo deve consentire l'accesso AWS DMS ai dati migrati in Amazon Timestream. Il set minimo di autorizzazioni di accesso per il ruolo utilizzato per la migrazione a Timestream è illustrato nella seguente policy IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDescribeEndpoints",
"Effect": "Allow",
"Action": [
"timestream:DescribeEndpoints"
],
"Resource": "*"
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"timestream:ListTables",
"timestream:DescribeDatabase"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"timestream:DeleteTable",
"timestream:WriteRecords",
"timestream:UpdateTable",
"timestream:CreateTable"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME/table/TABLE_NAME"
}
]
}
```
------
Se intendi migrare tutte le tabelle, usa `*` for *TABLE\$1NAME* nell'esempio precedente.
Tieni presenti le seguenti indicazioni sull'utilizzo di Timestream come destinazione:
+ Se intendi importare dati storici con timestamp creati da più di un anno, ti consigliamo di usare AWS DMS per scrivere i dati su Amazon S3 nel formato con valori separati da virgole (csv). Quindi, utilizza il caricamento in batch di Timestream per importare i dati in Timestream. Per ulteriori informazioni, consulta [Using batch load in Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) nella [Guida per gli sviluppatori di Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Per le migrazioni di dati di tipo pieno carico eseguite da meno di un anno, ti consigliamo di impostare un periodo di conservazione dell'archivio di memoria della tabella Timestream maggiore o uguale al timestamp più vecchio. Quindi, una volta completata la migrazione, modifica il periodo di conservazione dell'archivio di memoria della tabella impostando il valore desiderato. Ad esempio, per migrare i dati con un timestamp creato da più 2 mesi, procedi come segue:
+ Imposta il periodo di conservazione dell'archivio di memoria della tabella di destinazione Timestream su 2 mesi.
+ Inizia la migrazione dei dati utilizzando AWS DMS.
+ Una volta completata la migrazione dei dati, modifica il periodo di conservazione della tabella di destinazione Timestream impostando il valore desiderato.
Ti consigliamo di stimare il costo dell'archivio di memoria prima della migrazione utilizzando le informazioni presenti nelle pagine seguenti:
+ [Prezzi di Amazon Timestream](https://aws.amazon.com/timestream/pricing)
+ [AWS calcolatore dei prezzi](https://calculator.aws/#/addService)
+ Per le migrazioni dei dati di tipo CDC, ti consigliamo di impostare il periodo di conservazione dell'archivio di memoria della tabella di destinazione in modo che i dati importati rientrino nei limiti stabiliti. Per ulteriori informazioni, consulta [Writes Best Practices](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) nella [Guida per gli sviluppatori di Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Impostazioni attività a pieno carico multithread
Per contribuire ad aumentare la velocità di trasferimento dei dati, AWS DMS supporta un'attività di migrazione multithread a pieno carico verso un endpoint di destinazione Timestream con queste impostazioni di attività:
+ `MaxFullLoadSubTasks`: imposta questa opzione per indicare il numero massimo di tabelle da caricare in parallelo. DMS carica ogni tabella nella tabella di destinazione Amazon Timestream corrispondente utilizzando una sottoattività dedicata. Il valore predefinito è 8; il valore il massimo è 49.
+ `ParallelLoadThreads`— Usa questa opzione per specificare il numero di thread da utilizzare per caricare ogni tabella nella relativa tabella di destinazione Amazon Timestream. AWS DMS Il valore massimo per una destinazione Timestream è 32. Puoi chiedere che questo limite massimo venga aumentato.
+ `ParallelLoadBufferSize`: utilizza questa opzione per specificare il numero massimo di record da archiviare nel buffer usato dai thread di caricamento parallelo per caricare i dati nella destinazione Amazon Timestream. Il valore predefinito è 50. Il valore massimo è 1.000. Utilizzare questo parametro con `ParallelLoadThreads`; `ParallelLoadBufferSize` è valido solo quando è presente più di un thread.
+ `ParallelLoadQueuesPerThread`: utilizza questa opzione per specificare il numero di code a cui accede ogni thread simultaneo per eliminare i record di dati dalle code e generare un carico batch per la destinazione. Il valore di default è 1. Tuttavia, per le destinazioni Amazon Timestream con varie dimensioni del payload, l'intervallo valido è compreso tra 5 e 512 code per thread.
## Impostazioni attività di carico CDC multithread
Per promuovere le prestazioni del CDC, AWS DMS supporta le seguenti impostazioni delle attività:
+ `ParallelApplyThreads`— specifica il numero di thread simultanei che vengono AWS DMS utilizzati durante un caricamento CDC per inviare i record di dati a un endpoint di destinazione Timestream. Il valore predefinito è 0 e il valore massimo è 32.
+ `ParallelApplyBufferSize`: specifica il numero massimo di record da archiviare in ogni coda di buffer per eseguire il push dei thread simultanei a un endpoint di destinazione Timestream durante un carico CDC. Il valore predefinito è 100 e il valore massimo è 1.000. Utilizzare questa opzione quando `ParallelApplyThreads` specifica più di un thread.
+ `ParallelApplyQueuesPerThread`: specifica il numero di code a cui ogni thread accede per eliminare i record di dati dalle code e generare un carico in batch per un endpoint Timestream durante la CDC. Il valore predefinito è 1 e il valore massimo è 512.
## Impostazioni dell'endpoint quando si utilizza Timestream come destinazione per AWS DMS
È possibile utilizzare le impostazioni di endpoint per configurare il database di destinazione Timestream in modo simile a come si usano gli attributi aggiuntivi di connessione. Le impostazioni vengono specificate quando si crea l'endpoint di destinazione utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintassi JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con Timestream come destinazione.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Target.Timestream.html)
## Creazione e modifica di un endpoint di destinazione Amazon Timestream
Dopo aver creato un ruolo IAM e stabilito il set minimo di autorizzazioni di accesso, puoi creare un endpoint di destinazione Amazon Timestream AWS DMS utilizzando la console o `create-endpoint` utilizzando il comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)in, con la sintassi JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
Negli esempi seguenti viene illustrato come creare o modificare un endpoint di destinazione Timestream mediante la AWS CLI.
**Comando per creare l'endpoint di destinazione Timestream**
```
aws dms create-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"DatabaseName":"db_name",
"MagneticDuration": 3,
"CdcInsertsAndUpdates": true,
"EnableMagneticStoreWrites": true,
}
```
**Comando per modificare l'endpoint di destinazione Timestream**
```
aws dms modify-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"MagneticDuration": 3,
}
```
## Utilizzo della mappatura degli oggetti per la migrazione dei dati in un argomento Timestream
AWS DMS utilizza regole di mappatura delle tabelle per mappare i dati dall'argomento Timestream di origine a quello di destinazione. Per mappare i dati a un argomento di destinazione, è necessario utilizzare una regola di mappatura delle tabelle denominata mappatura degli oggetti. La mappatura degli oggetti consente di definire il modo in cui i record di dati dell'origine vengono mappati ai record di dati pubblicati nell'argomento Timestream.
Gli argomenti Timestream non dispongono di una struttura preimpostata oltre a una chiave di partizione.
**Nota**
Non è necessario utilizzare la mappatura degli oggetti. È possibile utilizzare la normale mappatura delle tabelle per varie trasformazioni. Tuttavia, il tipo di chiave della partizione segue questi comportamenti predefiniti:
La chiave primaria viene utilizzata come chiave di partizione per il pieno carico.
Se non vengono utilizzate le impostazioni delle attività di applicazione parallela, `schema.table` viene usato come chiave di partizione per la CDC.
Se vengono utilizzate le impostazioni delle attività di applicazione parallela, la chiave primaria viene utilizzata come chiave di partizione per CDC.
Per creare una regola di mappatura degli oggetti, è necessario impostare il parametro `rule-type` su `object-mapping`. Questa regola specifica il tipo di mappatura degli oggetti da utilizzare. Di seguito è riportata la struttura per la regola.
```
{
"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 attualmente supporta `map-record-to-record` e `map-record-to-document` è l'unico valore valido per il parametro. `rule-action` `map-record-to-document`I valori `map-record-to-record` and specificano cosa AWS DMS fa per impostazione predefinita ai record che non sono esclusi dall'elenco degli `exclude-columns` attributi. Questi valori non influiscono in alcun modo sulle mappature degli attributi.
Utilizza `map-record-to-record` per la migrazione da un database relazionale a un argomento Timestream. Questo tipo di regola utilizza il valore `taskResourceId.schemaName.tableName` del database relazionale come chiave di partizione nell'argomento Timestream e crea un attributo per ogni colonna del database di origine. Quando si utilizza`map-record-to-record`, per ogni colonna della tabella di origine non elencata nell'elenco `exclude-columns` degli attributi, AWS DMS crea un attributo corrispondente nell'argomento di destinazione. Questo attributo corrispondente viene creato indipendentemente dal fatto che tale colonna di origine venga utilizzata o meno in una mappatura degli attributi.
Per comprendere il funzionamento di `map-record-to-record`, è opportuno esaminarne il comportamento in azione. Per questo esempio, supponiamo che tu stia iniziando con una riga di tabella del database relazionale con la struttura e i dati seguenti.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Per eseguire la migrazione di queste informazioni da uno schema denominato `Test` a un argomento Timestream, crea le regole per mappare i dati sull'argomento di destinazione. La regola seguente illustra la mappatura.
```
{
"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"
}
}
]
}
```
Dato un argomento Timestream e una chiave di partizione (in questo caso, `taskResourceId.schemaName.tableName`), il seguente esempio illustra il formato di record risultante per l'argomento di destinazione Timestream utilizzando i dati di esempio:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Limitazioni nell'utilizzo di Amazon Timestream come destinazione per AWS Database Migration Service
Quando si utilizza Amazon Timestream come destinazione si applicano le seguenti limitazioni:
+ **Dimensioni e timestamp:** Timestream utilizza le dimensioni e i timestamp dei dati di origine come chiave primaria composita e non consente di alterare questi valori. Ciò significa che se modifichi il timestamp o le dimensioni di un record nel database di origine, il database Timestream prova a creare un nuovo record. È quindi possibile che, se modifichi la dimensione o il timestamp di un record in modo che corrispondano a quelli di un altro record esistente, AWS DMS aggiorni i valori dell'altro record anziché creare un nuovo record o aggiornare il record precedente corrispondente.
+ **Comandi DDL:** la versione corrente dei AWS DMS soli supporti `CREATE TABLE` e `DROP TABLE` comandi DDL.
+ **Limitazioni relative ai record:** Timestream include delle limitazioni per i record, ad esempio la dimensione del record e la dimensione della misura. Per ulteriori informazioni, consultare [Quote](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) nella [Guida per gli sviluppatori di Amazon Timestream](https://docs.aws.amazon.com/).
+ **Eliminazione di record e valori nulli:** Timestream non supporta l'eliminazione di record. Per supportare la migrazione dei record eliminati dall'origine, AWS DMS cancella i campi corrispondenti nei record nel database di destinazione Timestream. AWS DMS **modifica i valori nei campi del record di destinazione corrispondente con **0** per i campi numerici, **null** per i campi di testo e false per i campi booleani.**
+ Timestream come destinazione non supporta origini diverse da database relazionali.
+ AWS DMS supporta Timestream come destinazione solo nelle seguenti regioni:
+ Stati Uniti orientali (Virginia settentrionale)
+ Stati Uniti orientali (Ohio)
+ Stati Uniti occidentali (Oregon)
+ Europa (Irlanda)
+ Europa (Francoforte)
+ Asia Pacifico (Sydney)
+ Asia Pacifico (Tokyo)
+ Timestream come destinazione non supporta l'impostazione di `TargetTablePrepMode` su `TRUNCATE_BEFORE_LOAD`. Ti consigliamo di utilizzare `DROP_AND_CREATE` per questa impostazione.
# Utilizzo di Amazon RDS for Db2 e IBM Db2 LUW come destinazione per AWS DMS
Puoi migrare i dati verso un Amazon RDS for Db2 o un database Db2 locale da un database Db2 LUW utilizzando (). AWS Database Migration Service AWS DMS
Per informazioni sulle versioni di Db2 LUW supportate come destinazione, consulta. AWS DMS [Obiettivi per AWS DMS](CHAP_Introduction.Targets.md)
Puoi utilizzare il protocollo Secure Sockets Layer (SSL) per crittografare le connessioni tra l'endpoint Db2 LUW e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint Db2 LUW, consulta [Utilizzo di SSL con AWS Database Migration Service](CHAP_Security.SSL.md).
## Limitazioni nell'utilizzo di Db2 LUW come destinazione per AWS DMS
Le seguenti limitazioni si applicano quando si utilizza il database Db2 LUW come destinazione per. AWS DMS Per le limitazioni relative all'utilizzo di Db2 LUW come origine, consulta [Limitazioni nell'utilizzo di Db2 LUW come sorgente per AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations).
+ AWS DMS supporta Db2 LUW come destinazione solo quando la sorgente è Db2 LUW o Db2 for z/OS.
+ L'utilizzo di Db2 LUW come destinazione non supporta le repliche con la modalità LOB completa.
+ L'utilizzo di Db2 LUW come destinazione non supporta il tipo di dati XML nella fase di pieno carico. Questa è una limitazione dell'utilità IBM dbload. Per ulteriori informazioni, consulta [The dbload utility](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) nella documentazione *IBM Informix Servers*.
+ AWS DMS tronca i campi BLOB con valori corrispondenti alle virgolette doppie («). Questa è una limitazione dell'utilità IBM dbload.
+ AWS DMS non supporta l'opzione parallel full load durante la migrazione a un target Db2 LUW nella versione DMS 3.5.3. Questa opzione è disponibile a partire dalla versione DMS 3.5.4 o successiva.
## Impostazioni degli endpoint quando si utilizza Db2 LUW come destinazione per AWS DMS
È possibile utilizzare le impostazioni degli endpoint per configurare il database di destinazione Db2 LUW in modo simile a come si usano gli attributi aggiuntivi di connessione. Le impostazioni vengono specificate quando si crea l'endpoint di destinazione utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintassi JSON. `--ibm-db2-settings '{"EndpointSetting": "value", ...}'`
La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con Db2 LUW come destinazione.
| Nome | Description |
| --- | --- |
| `KeepCsvFiles` | Se impostato su true, AWS DMS salva tutti i file.csv nella destinazione Db2 LUW che sono stati utilizzati per replicare i dati. DMS utilizza questi file per l'analisi e la risoluzione dei problemi. |
| `LoadTimeout` | La quantità di tempo (in millisecondi) prima delle operazioni di AWS DMS timeout eseguite da DMS sulla destinazione Db2. Il valore predefinito è di 1200 (20 minuti). |
| `MaxFileSize` | Specifica la dimensione massima (in KB) dei file .csv utilizzati per il trasferimento dei dati a Db2 LUW. |
| `WriteBufferSize` | La dimensione (in KB) del buffer di scrittura dei file in memoria utilizzato durante la generazione di file .csv sul disco locale nell'istanza di replica DMS. Il valore predefinito è 1024 (1 MB). |