}
```
O exemplo a seguir destaca as seções utilizadas para expressão condicional.
![\[Comece com AWS DMS\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Usar o mapeamento de atributo com mapeamento de objeto
O mapeamento de atributo permite especificar uma string de modelo utilizando nomes de colunas de origem para reestruturar dados no destino. Não há formatação feita além do que o usuário especifica no modelo.
O exemplo a seguir mostra a estrutura do banco de dados de origem e a estrutura desejada do destino do DynamoDB. Primeiramente, é mostrada a estrutura da origem: nesse caso um banco de dados Oracle, e, depois, a estrutura desejada dos dados no DynamoDB. O exemplo termina com o JSON utilizado para criar a estrutura de destino desejada.
A estrutura dos dados do Oracle é a seguinte:
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Chave primária | N/D | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 29/02/1988 |
A estrutura dos dados do DynamoDB é a seguinte:
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Chave de partição | Chave de classificação | 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
|
O JSON a seguir mostra o mapeamento de objetos e o mapeamento de colunas utilizados para alcançar a estrutura do 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}\"}}"
}
]
}
}
]
}
```
Outra maneira de utilizar o mapeamento de colunas é utilizar o formato do DynamoDB como o tipo de documento. O código a seguir utiliza *dynamodb-map* como `attribute-sub-type` para o mapeamento de atributo.
```
{
"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}"
}
}
}
}
}
}
]
}
}
]
}
```
Como alternativa`dynamodb-map`, você pode usar `dynamodb-list` como mapeamento attribute-sub-type de atributos, conforme mostrado no exemplo a seguir.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Exemplo 1: Usar o mapeamento de atributo com mapeamento de objeto
O exemplo a seguir migra dados de duas tabelas do banco de dados MySQL*, nfl\$1data e *sport\$1team*,* para duas tabelas do DynamoDB chamadas e. *NFLTeams*SportTeams** A estrutura das tabelas e do JSON utilizados para mapear os dados das tabelas do banco de dados MySQL para as tabelas do DynamoDB é mostrada a seguir.
A estrutura da tabela do banco de dados MySQL *nfl\$1data* é mostrada abaixo:
```
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 | |
+---------------+-------------+------+-----+---------+-------+
```
A estrutura do banco de dados MySQL *sport\$1team* é mostrada abaixo:
```
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 | |
```
As regras de mapeamento de tabela utilizadas para mapear as duas tabelas para as duas tabelas do DynamoDB são mostradas abaixo:
```
{
"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}\"}"
}
]
}
}
]
}
```
O exemplo de saída para a tabela do *NFLTeams*DynamoDB é mostrado abaixo:
```
"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"
}
```
O exemplo de saída para a tabela do SportsTeams *DynamoDB* é mostrado abaixo:
```
{
"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"
}
```
## Tipos de dados de destino do DynamoDB
O endpoint do DynamoDB for é AWS DMS compatível com a maioria dos tipos de dados do DynamoDB. A tabela a seguir mostra os tipos de dados de AWS DMS destino da Amazon que são compatíveis com o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados.
Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Ao AWS DMS migrar dados de bancos de dados heterogêneos, mapeamos tipos de dados do banco de dados de origem para tipos de dados intermediários chamados AWS DMS tipos de dados. Em seguida, mapeamos os tipos de dados intermediários para os tipos de dados de destino. A tabela a seguir mostra cada tipo de AWS DMS dados e o tipo de dados para o qual ele é mapeado no DynamoDB:
| AWS DMS tipo de dados | Tipo de dados do DynamoDB |
| --- | --- |
| String | String |
| WString | String |
| Booleano | Booleano |
| Data | String |
| DateTime | String |
| INT1 | Número |
| INT2 | Número |
| INT4 | Número |
| INT8 | Número |
| Numérico | Número |
| Real4 | Número |
| Real8 | Número |
| UINT1 | Número |
| UINT2 | Número |
| UINT4 | Número |
| UINT8 | Número |
| CLOB | String |
# Usando o Amazon Kinesis Data Streams como alvo para AWS Database Migration Service
Você pode usar AWS DMS para migrar dados para um stream de dados do Amazon Kinesis. O Amazon Kinesis Data Streams faz parte do serviço Amazon Kinesis Data Streams. É possível utilizar os fluxos de dados do Kinesis para coletar e processar grandes registros de dados em tempo real.
O fluxo de dados do Kinesis é composto por fragmentos. O *estilhaço* é uma sequência de registros de dados identificada de forma exclusiva em um stream. Para obter mais informações sobre fragmentos no Amazon Kinesis Data Streams, consulte o [Fragmento](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) no *Guia do desenvolvedor do Amazon Kinesis Data Streams.*
AWS Database Migration Service publica registros em um stream de dados do Kinesis usando JSON. Durante a conversão, o AWS DMS serializa cada registro do banco de dados de origem em um par atributo/valor no formato JSON ou em um formato de mensagem JSON\$1UNFORMATTED. Um formato de mensagem JSON\$1UNFORMATTED é uma string JSON de linha única com novo delimitador de linha. Ele permite que o Amazon Data Firehose entregue dados do Kinesis para um destino do Amazon S3 e consulte-os utilizando vários mecanismos de consulta, incluindo o Amazon Athena.
O mapeamento de objetos é utilizado para migrar os dados de uma fonte de dados compatível para um fluxo de destino. Com o mapeamento do objeto, você determina como estruturar os registros de dados no stream. Também é possível definir uma chave de partição para cada tabela, que será utilizada pelo Kinesis Data Streams para agrupar os dados em fragmentos.
AWS DMS também define vários valores de parâmetros do Kinesis Data Streams. O custo de criação da tabela depende da quantidade de dados e do número de tabelas a serem migradas.
**nota**
A opção **Modo SSL** no AWS DMS console ou na API não se aplica a alguns serviços de streaming de dados e NoSQL, como Kinesis e DynamoDB. Eles são seguros por padrão, então AWS DMS mostra que a configuração do modo SSL é igual a nenhuma (**Modo SSL** = Nenhuma). Não é necessário fornecer nenhuma configuração adicional para que o endpoint utilize o SSL. Por exemplo, ao utilizar o Kinesis como um endpoint de destino, ele é seguro por padrão. Todas as chamadas de API para o Kinesis usam SSL, portanto, não há necessidade de uma opção adicional de SSL no endpoint. AWS DMS É possível colocar e recuperar dados com segurança por meio de endpoints SSL utilizando o protocolo HTTPS, que o AWS DMS utiliza por padrão ao se conectar a um fluxo de dados Kinesis.
**Configurações do endpoint do Kinesis Data Streams**
Ao usar os endpoints de destino do Kinesis Data Streams, você pode obter detalhes da transação e do controle `KinesisSettings` usando a opção na API. AWS DMS
É possível definir as configurações da conexão de uma das seguintes maneiras:
+ No AWS DMS console, usando as configurações do endpoint.
+ Na CLI, usando a `kinesis-settings` opção do [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)comando.
Na CLI, utilize os seguintes parâmetros de solicitação da opção `kinesis-settings`:
**nota**
Compatibilidade com a configuração do endpoints do `IncludeNullAndEmpty` está disponível nas versões 3.4.1 e superiores do AWS DMS . Mas o suporte para as outras configurações de endpoint a seguir para destinos do Kinesis Data Streams está disponível em. AWS DMS
+ `MessageFormat`: o formato de saída dos registros criados no endpoint. O formato da mensagem é `JSON` (padrão) ou `JSON_UNFORMATTED` (uma única linha sem guia).
+ `IncludeControlDetails`: mostra informações detalhadas de controle para definição de tabelas, definição de colunas e alterações de tabelas e colunas na saída de mensagem do Kinesis. O padrão é `false`.
+ `IncludeNullAndEmpty`: inclui colunas NULL e vazias no destino. O padrão é `false`.
+ `IncludePartitionValue`: mostra o valor da partição na saída da mensagem do Kinesis, a menos que o tipo de partição seja `schema-table-type`. O padrão é `false`.
+ `IncludeTableAlterOperations`: inclui todas as operações da linguagem de definição de dados (DDL) que alteram a tabela nos dados de controle, como `rename-table`, `drop-table`, `add-column`, `drop-column` e `rename-column`. O padrão é `false`.
+ `IncludeTransactionDetails`: fornece informações detalhadas sobre transações do banco de dados de origem. Essas informações incluem um timestamp de confirmação, uma posição no log e valores para `transaction_id`, `previous_transaction_id` e `transaction_record_id ` (o deslocamento de registro dentro de uma transação). O padrão é `false`.
+ `PartitionIncludeSchemaTable`: prefixa os nomes de esquema e de tabela em valores de partições, quando o tipo de partição for `primary-key-type`. Isso aumenta a distribuição de dados entre estilhaços do Kinesis. Por exemplo, suponha que um esquema `SysBench` tenha milhares de tabelas, e cada tabela tenha apenas um intervalo limitado para uma chave primária. Nesse caso, a mesma chave primária é enviada de milhares de tabelas para o mesmo estilhaço, o que provoca o controle de utilização. O padrão é `false`.
+ `UseLargeIntegerValue`— Use int de até 18 dígitos em vez de converter ints como duplos, disponível a partir da AWS DMS versão 3.5.4. O padrão é falso.
O exemplo a seguir mostra a opção `kinesis-settings` em uso com um exemplo de comando `create-endpoint` emitido utilizando a 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
```
**Configurações da tarefa de carga máxima com vários threads**
Para ajudar a aumentar a velocidade da transferência, AWS DMS oferece suporte a uma carga completa multisegmentada em uma instância de destino do Kinesis Data Streams. O DMS oferece suporte a esse multithreading com configurações de tarefa que incluem o seguinte:
+ `MaxFullLoadSubTasks`: utilize esta opção para indicar o número máximo de tabelas de origem a serem carregadas em paralelo. O DMS carrega cada tabela na tabela de destino do Kinesis correspondente utilizando uma subtarefa dedicada. O padrão é 8; o valor máximo é 49.
+ `ParallelLoadThreads`— Use essa opção para especificar o número de threads AWS DMS usados para carregar cada tabela em sua tabela de destino do Kinesis. O valor máximo para um destino do Kinesis Data Streams é 32. Você pode solicitar o aumento desse limite máximo.
+ `ParallelLoadBufferSize`: utilize essa opção para especificar o número máximo de registros a serem armazenados em buffer utilizado pelos threads de carga paralela para carregar dados no destino do Kinesis. O valor padrão é 50. Valor máximo de 1.000. Use essa configuração com `ParallelLoadThreads`; `ParallelLoadBufferSize` é válido somente quando há mais de um thread.
+ `ParallelLoadQueuesPerThread`: utilize esta opção para especificar o número de filas que cada thread simultâneo acessa para extrair registros de dados das filas e gerar uma carga em lote para o destino. O padrão é um. No entanto, para destinos do Kinesis de vários tamanhos de carga útil, o intervalo válido é de 5 a 512 filas por thread.
**Configurações da tarefa de carga de CDC multithread**
É possível melhorar o desempenho da captura de dados de alterações (CDC) para endpoints de destino de streaming de dados em tempo real, como o Kinesis, utilizando configurações de tarefa para modificar o comportamento da chamada da API `PutRecords`. Para fazer isso, especifique o número de threads simultâneos, filas por thread e o número de registros a serem armazenados em um buffer usando as configurações da tarefa `ParallelApply*`. Por exemplo, suponha que você queira executar um carregamento de CDC e aplicar 128 threads em paralelo. Você também quer acessar 64 filas por thread, com 50 registros armazenados por buffer.
Para promover o desempenho do CDC, AWS DMS oferece suporte a estas configurações de tarefas:
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos que são AWS DMS usados durante o carregamento do CDC para enviar registros de dados para um endpoint de destino do Kinesis. O valor padrão é zero (0) e o valor máximo é 32.
+ `ParallelApplyBufferSize`: especifica o número máximo de registros a serem armazenados em cada fila de buffer para threads simultâneos enviarem para um endpoint de destino do Kinesis durante uma carga de CDC. O valor padrão é 100 e o valor máximo é 1.000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`: especifica o número de filas que cada thread acessa para extrair registros de dados das filas e gerar uma carga em lote para um endpoint do Kinesis durante a CDC. O valor padrão é 1 e o valor máximo é 512.
Ao usar configurações da tarefa `ParallelApply*`, o `partition-key-type` padrão é a `primary-key` da tabela, não o `schema-name.table-name`.
## Utilizar uma imagem anterior para visualizar valores originais de linhas da CDC para um fluxo de dados do Kinesis como destino
Ao gravar atualizações da CDC em um destino de streaming de dados, como o Kinesis, é possível visualizar os valores originais de linhas do banco de dados de origem antes da alteração por uma atualização. Para tornar isso possível, AWS DMS preenche uma *imagem anterior* dos eventos de atualização com base nos dados fornecidos pelo mecanismo do banco de dados de origem.
Diferentes mecanismos de banco de dados de origem fornecem diferentes quantidades de informações para uma imagem anterior:
+ O Oracle fornece atualizações para colunas somente se elas forem alteradas.
+ O PostgreSQL fornece somente dados para colunas que fazem parte da chave primária (alterada ou não). Para fornecer dados para todas as colunas (alteradas ou não), você precisa definir `REPLICA_IDENTITY` como `FULL` em vez de `DEFAULT`. Observe que você deve escolher cuidadosamente a configuração `REPLICA_IDENTITY` para cada tabela. Se você definir `REPLICA_IDENTITY` como `FULL`, todos os valores da coluna serão gravados continuamente no registro em log de gravação antecipada (WAL). Isso pode causar problemas de desempenho ou de recursos com tabelas que são atualizadas com frequência.
+ O MySQL geralmente fornece dados para todas as colunas, exceto para os tipos de dados BLOB e CLOB (alterados ou não).
Para habilitar a criação de imagem anterior para adicionar valores originais do banco de dados de origem à saída do AWS DMS , use a configuração de tarefa `BeforeImageSettings` ou o parâmetro `add-before-image-columns`. Esse parâmetro aplica uma regra de transformação de coluna.
`BeforeImageSettings` adiciona um novo atributo JSON a cada operação de atualização com valores coletados do sistema de banco de dados de origem, conforme mostrado a seguir.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**nota**
Aplique somente `BeforeImageSettings` às AWS DMS tarefas que contêm um componente do CDC, como carga total mais tarefas do CDC (que migram dados existentes e replicam as alterações em andamento), ou às tarefas somente do CDC (que replicam somente as alterações de dados). Não aplique `BeforeImageSettings` a tarefas que são somente de carga total.
Para opções `BeforeImageSettings`, aplica-se o seguinte:
+ Defina a opção `EnableBeforeImage` como `true` para habilitar a criação de imagem anterior. O padrão é `false`.
+ Use a opção `FieldName` para atribuir um nome ao novo atributo JSON. Quando `EnableBeforeImage` for `true`, `FieldName` será necessário e não poderá estar vazio.
+ A opção `ColumnFilter` especifica uma coluna a ser adicionada usando imagem anterior. Para adicionar somente colunas que fazem parte das chaves primárias da tabela, use o valor padrão, `pk-only`. Para adicionar qualquer coluna que tenha um valor de imagem anterior, use `all`. Observe que a imagem anterior não contém colunas com tipos de dados LOB, como CLOB ou BLOB.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**nota**
Os destinos do Amazon S3 não são compatíveis com `BeforeImageSettings`. Para destinos do S3, utilize somente a regra de transformação `add-before-image-columns` para executar a criação da imagem anterior durante a CDC.
### Usar uma regra de transformação de imagem anterior
Como alternativa às configurações de tarefa, é possível usar o parâmetro `add-before-image-columns`, que aplica uma regra de transformação de coluna. Com esse parâmetro, é possível ativar a imagem anterior durante a CDC em destinos de streaming de dados, como o Kinesis.
Usando `add-before-image-columns` em uma regra de transformação, é possível aplicar um controle mais refinado dos resultados da imagem anterior. As regras de transformação permitem que você use um localizador de objetos que oferece controle sobre as tabelas selecionadas para a regra. Além disso, é possível encadear regras de transformação, o que permite que regras diferentes sejam aplicadas a tabelas diferentes. Depois, você poderá manipular as colunas produzidas usando outras regras.
**nota**
Não use o parâmetro `add-before-image-columns` junto com a configuração da tarefa `BeforeImageSettings` na mesma tarefa. Em vez disso, use o parâmetro ou a configuração, mas não ambos, para uma única tarefa.
Um tipo de regra `transformation` com o parâmetro `add-before-image-columns` de uma coluna deve fornecer uma seção `before-image-def`. Por exemplo:
```
{
"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,
}
}
```
O valor de `column-prefix` precede um nome de coluna e o valor padrão de `column-prefix` é `BI_`. O valor de `column-suffix` é anexado ao nome da coluna e o padrão é vazio. Não defina `column-prefix` e `column-suffix` como strings vazias.
Escolha um valor para `column-filter`. Para adicionar somente colunas que fazem parte das chaves primárias da tabela, escolha `pk-only`. Escolha `non-lob` para adicionar somente colunas que não sejam do tipo LOB. Ou escolha `all` para adicionar qualquer coluna que tenha um valor de imagem anterior.
### Exemplo de uma regra de transformação de imagem anterior
A regra de transformação no exemplo a seguir adiciona uma nova coluna chamada `BI_emp_no` no destino. Portanto, uma instrução como `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` preenche o campo `BI_emp_no` com 1. Ao gravar atualizações da CDC em destinos do Amazon S3, a coluna `BI_emp_no` possibilita identificar qual linha original foi atualizada.
```
{
"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"
}
}
]
}
```
Para obter informações sobre como usar a ação da regra `add-before-image-columns`, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Pré-requisitos para usar um stream de dados do Kinesis como destino para AWS Database Migration Service
### Função do IAM para usar um stream de dados do Kinesis como destino para AWS Database Migration Service
Antes de configurar um stream de dados do Kinesis como destino AWS DMS, certifique-se de criar uma função do IAM. Essa função deve permitir AWS DMS assumir e conceder acesso aos fluxos de dados do Kinesis para os quais estão sendo migrados. O conjunto mínimo de permissões de acesso é mostrado na seguinte política do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
O perfil que você utiliza para a migração para um fluxo de dados do Kinesis deve ter as seguintes permissões:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Acessando um stream de dados do Kinesis como destino para AWS Database Migration Service
Na AWS DMS versão 3.4.7 e superior, para se conectar a um endpoint do Kinesis, você deve fazer o seguinte:
+ Configure o DMS para usar endpoints da VPC. Para obter mais informações sobre a configuração de endpoints da VPC, consulte [Configurando endpoints VPC para AWS DMS](CHAP_VPC_Endpoints.md).
+ Configure o DMS para usar rotas públicas; ou seja, torne a instância de replicação pública. Para obter mais informações sobre instâncias de replicação públicas, consulte [Instâncias de replicação públicas e privadas](CHAP_ReplicationInstance.PublicPrivate.md).
## Limitações ao usar o Kinesis Data Streams como destino para AWS Database Migration Service
Aplicam-se as seguintes limitações ao utilizar o Kinesis Data Streams como destino:
+ AWS DMS publica cada atualização em um único registro no banco de dados de origem como um registro de dados em um determinado stream de dados do Kinesis, independentemente das transações. No entanto, é possível incluir detalhes da transação para cada registro de dados utilizando parâmetros relevantes da API do `KinesisSettings`.
+ O modo Full LOB não é compatível.
+ O tamanho máximo do LOB compatível é 1 MB.
+ Os Kinesis Data Streams não é compatível com a desduplicação. As aplicações que consumem dados de um fluxo precisam tratar os registros duplicados. Para obter mais informações, consulte [Tratar registros duplicados](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) no *Guia do desenvolvedor do Amazon Kinesis Data Streams*.
+ AWS DMS suporta as quatro formas a seguir para chaves de partição:
+ `SchemaName.TableName`: uma combinação de esquema e nome da tabela.
+ `${AttributeName}`: o valor de um dos campos no JSON ou a chave primária da tabela no banco de dados de origem.
+ `transaction-id`: O ID da transação do CDC. Todos os registros da mesma transação vão para a mesma partição.
+ `constant`: um valor literal fixo para cada registro, independentemente da tabela ou dos dados. Todos os registros são enviados para o mesmo valor de chave de partição “constante”, fornecendo uma ordenação global estrita em todas as tabelas.
```
{
"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"
}
}
```
+ Para obter informações sobre como criptografar dados em repouso no Kinesis Data Streams, consulte [Proteção de dados no Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html), no *Guia do desenvolvedor do AWS Key Management Service *.
+ A configuração do `IncludeTransactionDetails` endpoint só é suportada quando o endpoint de origem é Oracle, SQL Server, PostgreSQL ou MySQL. Para outros tipos de endpoint de origem, os detalhes da transação não serão incluídos.
+ O `BatchApply` não é compatível com um endpoint do Kinesis. A utilização da aplicação em lote (por exemplo, a configuração `BatchApplyEnabled` da tarefa de metadados de destino) para um destino do Kinesis pode resultar em falha da tarefa e perda de dados. Não habilite `BatchApply` ao utilizar o Kinesis como endpoint de destino.
+ Os destinos do Kinesis só são compatíveis com um stream de dados do Kinesis na mesma AWS conta e na Região da AWS mesma instância de replicação.
+ Ao migrar de uma fonte MySQL, os dados não incluem BeforeImage os tipos de dados CLOB e BLOB. Para obter mais informações, consulte [Utilizar uma imagem anterior para visualizar valores originais de linhas da CDC para um fluxo de dados do Kinesis como destino](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS não suporta a migração de valores do tipo de `BigInt` dados com mais de 16 dígitos. Para contornar essa limitação, você pode usar a regra de transformação a seguir para converter a coluna `BigInt` em uma string. Para obter mais informações sobre regras transformação, consulte [Regras de transformação e ações](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 várias operações do DML em uma única transação modificam uma coluna de objeto grande (LOB) no banco de dados de origem, o banco de dados de destino retém somente o valor final do LOB da última operação nessa transação. Os valores de LOB intermediários definidos por operações anteriores na mesma transação são sobrescritos, o que pode resultar em possíveis perdas de dados ou inconsistências. Esse comportamento ocorre devido à forma como os dados de LOB são processados durante a replicação.
+ AWS DMS não suporta dados de origem contendo `'\0'` caracteres incorporados ao usar o Kinesis como um endpoint de destino. Os dados contendo `'\0'` caracteres incorporados serão truncados no primeiro `'\0'` caractere.
## Utilizar o mapeamento de objetos para migrar dados para um fluxo de dados do Kinesis
AWS DMS usa regras de mapeamento de tabelas para mapear dados da fonte para o stream de dados do Kinesis de destino. Para mapear dados para um fluxo de destino, utilize um tipo de regra de mapeamento de tabela chamado mapeamento de objetos. Utilize o mapeamento de objetos para definir como os registros de dados na origem são mapeados para os registros de dados publicados para o fluxo de dados do Kinesis.
O fluxo de dados do Kinesis não tem estrutura predefinida além de uma chave de partição. Em uma regra de mapeamento de objeto, os valores possíveis de um `partition-key-type` para registros de dados são `schema-table`, `transaction-id`, `primary-key` `constant` e `attribute-name`.
Para criar uma regra de mapeamento de objetos, especifique `rule-type` como `object-mapping`. Essa regra especifica o tipo de mapeamento de objeto que você deseja usar.
A estrutura da regra é a seguinte:
```
{
"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 atualmente suporta `map-record-to-record` e `map-record-to-document` como os únicos valores válidos para o `rule-action` parâmetro. Essas configurações afetam valores que não são excluídos como parte da lista de atributos `exclude-columns`. Os `map-record-to-document` valores `map-record-to-record` e especificam como AWS DMS manipula esses registros por padrão. Esses valores não afetam os mapeamentos de atributos de forma alguma.
Utilize `map-record-to-record` ao migrar de um banco de dados relacional para um fluxo de dados do Kinesis. Esse tipo de regra utiliza o valor `taskResourceId.schemaName.tableName` encontrado no banco de dados relacional como a chave de partição no fluxo de dados do Kinesis e cria um atributo para cada coluna no banco de dados de origem.
Ao utilizar `map-record-to-record`, observe o seguinte:
+ Essa configuração afeta somente as colunas excluídas pela lista `exclude-columns`.
+ Para cada coluna desse tipo, AWS DMS cria um atributo correspondente no tópico de destino.
+ AWS DMS cria esse atributo correspondente independentemente de a coluna de origem ser usada em um mapeamento de atributos.
Utilize `map-record-to-document` para colocar colunas de origem em um único documento sem formatação no fluxo de destino apropriado utilizando o nome do atributo “\$1doc”. O AWS DMS coloca os dados em um único mapa sem formatação na origem chamada “`_doc`”. Esse posicionamento se aplica a qualquer coluna na tabela de origem que não aparece na lista de atributos `exclude-columns`.
Uma maneira de compreender o `map-record-to-record` é vê-lo em ação. Para este exemplo, suponha que você está começando com uma linha de tabela do banco de dados relacional com a seguinte estrutura de dados:
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 29/02/1988 |
Para migrar essas informações de um esquema chamado `Test` para um fluxo de dados do Kinesis, crie regras para mapear os dados para o fluxo de destino. A regra a seguir ilustra o mapeamento.
```
{
"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"
}
}
]
}
```
Veja a seguir uma ilustração do formato do registro resultante no fluxo de dados do Kinesis:
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaname.tableName
+ Data: //A seguinte mensagem do JSON
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
No entanto, suponha que você utilize as mesmas regras, mas altere o parâmetro `rule-action` para `map-record-to-document` e exclua determinadas colunas. A regra a seguir ilustra o mapeamento.
```
{
"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"
]
}
}
]
}
```
Nesse caso, as colunas não listadas no parâmetro `exclude-columns`, `FirstName`, `LastName`, `StoreId` e `DateOfBirth` são mapeadas para `_doc`. Veja a seguir o formato do registro resultante.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Reestruturação de dados com mapeamento de atributo
É possível reestruturar os dados enquanto estiver migrando-os para um fluxo de dados do Kinesis utilizando um mapa de atributo. Por exemplo, você pode combinar vários campos na origem em um único campo no destino. O mapa de atributo a seguir ilustra como reestruturar os dados.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Para definir um valor constante para`partition-key`, especifique`"partition-key-type: "constant"`, isso define o valor da partição como`constant`. Por exemplo, é possível fazer isso para forçar o armazenamento de todos os dados em um único fragmento. O mapeamento a seguir ilustra esse método.
```
{
"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**
O valor do `partition-key` para um registro de controle para uma tabela específica é `TaskId.SchemaName.TableName`. O valor do `partition-key` para um registro de controle específico para uma tarefa é o `TaskId` daquele registro. A especificação de um valor do `partition-key` no mapeamento do objeto não tem impacto sobre o `partition-key` no caso dos registros de controle.
Quando `partition-key-type` está definido como `attribute-name` em uma regra de mapeamento de tabela, você deve especificar`partition-key-name`, que deve fazer referência a uma coluna da tabela de origem ou a uma coluna personalizada definida no mapeamento. Além disso, `attribute-mappings` deve ser fornecido para definir como as colunas de origem são mapeadas para o Kinesis Stream de destino.
### Formato de mensagem do Kinesis Data Streams
A saída JSON é simplesmente uma lista de pares chave/valor. Um formato de mensagem JSON\$1UNFORMATTED é uma string JSON de linha única com novo delimitador de linha.
AWS DMS fornece os seguintes campos reservados para facilitar o consumo dos dados do Kinesis Data Streams:
**RecordType**
O tipo de registro pode ser dados ou controle. Os *registros de dados *representam as linhas reais na origem. Os *registros de controle* são relacionados a importantes eventos no stream, como a reinicialização de uma tarefa, por exemplo.
**Operation**
Para registros de dados, a operação pode ser `load`, `insert`, `update` ou `delete`.
Para registros de controle, a operação pode ser `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` ou `column-type-change`.
**SchemaName**
O esquema de origem para o registro. Esse campo pode estar vazio para um registro de controle.
**TableName**
A tabela de origem para um registro. Esse campo pode estar vazio para um registro de controle.
**Timestamp**
A marca de data e hora de quando a mensagem do JSON foi criada. O campo é formatado com o formato ISO 8601.
# Usando o Apache Kafka como alvo para AWS Database Migration Service
Você pode usar AWS DMS para migrar dados para um cluster Apache Kafka. O Apache Kafka é uma plataforma de streaming distribuída. É possível utilizar o Apache Kafka para a ingestão e o processamento de dados de streaming em tempo real.
AWS também oferece Amazon Managed Streaming for Apache Kafka (Amazon MSK) para uso como destino. AWS DMS O Amazon MSK é um serviço de streaming totalmente gerenciado do Apache Kafka que simplifica a implementação e o gerenciamento de instâncias do Apache Kafka. Ele funciona com versões de código aberto do Apache Kafka, e você acessa instâncias do Amazon MSK como AWS DMS destinos, exatamente como qualquer instância do Apache Kafka. Para obter mais informações, consulte [O que é o Amazon MSK?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) no *Guia do desenvolvedor do Amazon Managed Streaming for Apache Kafka*.
Um cluster do Kafka armazena fluxos de registros em categorias chamadas tópicos que são divididos em partições. As *partições* são sequências de registros de dados identificadas exclusivamente (mensagens) em um tópico. As partições podem ser distribuídas entre vários agentes em um cluster para permitir o processamento paralelo dos registros de um tópico. Para obter mais informações sobre tópicos e partições e sua distribuição no Apache Kafka, consulte [Tópicos e logs](https://kafka.apache.org/documentation/#intro_topics) e [Distribuição](https://kafka.apache.org/documentation/#intro_distribution).
O cluster do Kafka pode ser uma instância do Amazon MSK, um cluster em execução em uma instância do Amazon EC2 ou um cluster on-premises. Uma instância do Amazon MSK ou um cluster em uma instância do Amazon EC2 pode estar na mesma VPC ou em uma diferente. Se o cluster estiver on-premises, será possível utilizar o seu próprio servidor de nomes on-premises para a instância de replicação para resolver o nome do host do cluster. Para obter informações sobre como configurar um servidor de nomes na instância de replicação, consulte [Utilização do seu próprio servidor de nomes on-premises](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Para obter mais informações sobre a configuração de uma rede, consulte [Configurar uma rede para uma instância de replicação](CHAP_ReplicationInstance.VPC.md).
Ao utilizar um cluster do Amazon MSK, verifique se o grupo de segurança permite acesso da instância de replicação. Para obter informações sobre como alterar o grupo de segurança de um cluster do Amazon MSK, consulte [Alterar o grupo de segurança de um cluster do Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service publica registros em um tópico do Kafka usando JSON. Durante a conversão, o AWS DMS serializa cada registro do banco de dados de origem em um par atributo-valor no formato JSON.
Para migrar os dados de uma fonte de dados compatível para um cluster de destino do Kafka, utilize o mapeamento de objetos. Com o mapeamento de objetos, você determina como estruturar os registros de dados no tópico de destino. Também é possível definir uma chave de partição para cada tabela, que será utilizada pelo Apache Kafka para agrupar os dados em suas partições.
Atualmente, AWS DMS oferece suporte a um único tópico por tarefa. Para uma única tarefa com várias tabelas, todas as mensagens vão para um único tópico. Cada mensagem inclui uma seção de metadados que identifica o esquema e a tabela de destino. AWS DMS as versões 3.4.6 e superiores oferecem suporte à replicação multitópica usando mapeamento de objetos. Para obter mais informações, consulte [Replicação de multitópico utilizando o mapeamento de objetos](#CHAP_Target.Kafka.MultiTopic).
**Configurações do endpoint do Apache Kafka**
Você pode especificar os detalhes da conexão por meio das configurações do endpoint no AWS DMS console ou da `--kafka-settings` opção na CLI. Os requisitos para cada configuração são os seguintes:
+ `Broker`: especifique a localização de um ou mais agentes no cluster do Kafka na forma de uma lista separada por vírgulas de cada `broker-hostname:port`. Um exemplo é `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Essa configuração pode especificar os locais de qualquer um ou de todos os agentes no cluster. Todos os agentes de cluster se comunicam para lidar com o particionamento de registros de dados migrados para o tópico.
+ `Topic`: (opcional) especifique o nome do tópico com um comprimento máximo de 255 letras e símbolos. É possível utilizar ponto (.), sublinhado (\$1) e sinal de subtração (-). Os nomes de tópicos com um ponto (.) ou sublinhado (\$1) podem colidir em estruturas de dados internas. Utilize qualquer um, mas não esses dois símbolos no nome do tópico. Se você não especificar um nome de tópico, AWS DMS use `"kafka-default-topic"` como tópico de migração.
**nota**
Para AWS DMS criar um tópico de migração especificado por você ou o tópico padrão, defina-o `auto.create.topics.enable = true` como parte da configuração do cluster do Kafka. Para obter mais informações, consulte [Limitações ao usar o Apache Kafka como alvo para AWS Database Migration Service](#CHAP_Target.Kafka.Limitations).
+ `MessageFormat`: o formato de saída dos registros criados no endpoint. O formato da mensagem é `JSON` (padrão) ou `JSON_UNFORMATTED` (uma única linha sem guia).
+ `MessageMaxBytes`: o tamanho máximo em bytes dos registros criados no endpoint. O padrão é 1.000.000.
**nota**
Você só pode usar o AWS CLI/SDK para mudar `MessageMaxBytes` para um valor não padrão. Por exemplo, para modificar o endpoint existente do Kafka e alterar `MessageMaxBytes`, utilize o comando a seguir.
```
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`: fornece informações detalhadas sobre transações do banco de dados de origem. Essas informações incluem um timestamp de confirmação, uma posição no log e valores para `transaction_id`, `previous_transaction_id` e `transaction_record_id` (o deslocamento de registro dentro de uma transação). O padrão é `false`.
+ `IncludePartitionValue`: mostra o valor da partição na saída da mensagem do Kafka, a menos que o tipo de partição seja `schema-table-type`. O padrão é `false`.
+ `PartitionIncludeSchemaTable`: prefixa os nomes de esquema e de tabela em valores de partições, quando o tipo de partição for `primary-key-type`. Isso aumenta a distribuição de dados entre partições do Kafka. Por exemplo, suponha que um esquema `SysBench` tenha milhares de tabelas, e cada tabela tenha apenas um intervalo limitado para uma chave primária. Nesse caso, a mesma chave primária é enviada de milhares de tabelas para a mesma partição, o que provoca o controle de utilização. O padrão é `false`.
+ `IncludeTableAlterOperations`: inclui todas as operações da linguagem de definição de dados (DDL) que alteram a tabela nos dados de controle, como `rename-table`, `drop-table`, `add-column`, `drop-column` e `rename-column`. O padrão é `false`.
+ `IncludeControlDetails`: mostra informações detalhadas de controle para definição de tabela, definição de coluna e alterações de tabela e coluna na saída de mensagem do Kafka. O padrão é `false`.
+ `IncludeNullAndEmpty`: inclui colunas NULL e vazias no destino. O padrão é `false`.
+ `SecurityProtocol`: define uma conexão segura a um endpoint de destino do Kafka utilizando Transport Layer Security (TLS). As opções incluem `ssl-authentication`, `ssl-encryption` e `sasl-ssl`. A utilização de `sasl-ssl` requer `SaslUsername` e `SaslPassword`.
+ `SslEndpointIdentificationAlgorithm`: define a verificação do nome de host para o certificado. Essa configuração é compatível com o AWS DMS versão 3.5.1 e posteriores. As opções incluem o seguinte:
+ `NONE`: desabilite a verificação do nome do host do broker na conexão do cliente.
+ `HTTPS`: habilite a verificação do nome do host do broker na conexão do cliente.
+ `useLargeIntegerValue`— Use int de até 18 dígitos em vez de converter ints como duplos, disponível a partir da AWS DMS versão 3.5.4. O padrão é falso.
É possível utilizar configurações para ajudar a aumentar a velocidade da transferência. Para fazer isso, o AWS DMS é compatível com uma carga multithreaded completa para um cluster de destino do Apache Kafka. O AWS DMS é compatível com esse multithreading com configurações de tarefa que incluem o seguinte:
+ `MaxFullLoadSubTasks`— Use essa opção para indicar o número máximo de tabelas de origem a serem carregadas paralelamente. AWS DMS carrega cada tabela em sua tabela de destino correspondente do Kafka usando uma subtarefa dedicada. O padrão é 8; o valor máximo é 49.
+ `ParallelLoadThreads`— Use essa opção para especificar o número de segmentos AWS DMS usados para carregar cada tabela em sua tabela de destino do Kafka. O valor máximo para um destino do Apache Kafka é 32. Você pode solicitar o aumento desse limite máximo.
+ `ParallelLoadBufferSize`: utilize esta opção para especificar o número máximo de registros a serem armazenados no buffer utilizado pelos threads de carregamento paralelo utilizam para carregar dados no destino do Kafka. O valor padrão é 50. Valor máximo de 1.000. Use essa configuração com `ParallelLoadThreads`; `ParallelLoadBufferSize` é válido somente quando há mais de um thread.
+ `ParallelLoadQueuesPerThread`: utilize esta opção para especificar o número de filas que cada thread simultâneo acessa para extrair registros de dados das filas e gerar uma carga em lote para o destino. O padrão é um. O máximo é 512.
É possível melhorar o desempenho da captura de dados de alteração (CDC) para endpoints do Kafka ajustando as configurações da tarefa para threads paralelos e operações em massa. Para fazer isso, especifique o número de threads simultâneos, filas por thread e o número de registros a serem armazenados em um buffer usando as configurações da tarefa `ParallelApply*`. Por exemplo, suponha que você queira executar um carregamento de CDC e aplicar 128 threads em paralelo. Você também quer acessar 64 filas por thread, com 50 registros armazenados por buffer.
Para promover o desempenho do CDC, AWS DMS oferece suporte a estas configurações de tarefas:
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos que são AWS DMS usados durante um carregamento do CDC para enviar registros de dados para um endpoint de destino do Kafka. O valor padrão é zero (0) e o valor máximo é 32.
+ `ParallelApplyBufferSize`: especifica o número máximo de registros a serem armazenados em cada fila de buffer para threads simultâneos enviarem para um endpoint de destino do Kafka durante uma carga de CDC. O valor padrão é 100 e o valor máximo é 1.000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`: especifica o número de filas que cada thread acessa para extrair registros de dados das filas e gerar uma carga em lote para um endpoint do Kafka durante a CDC. O padrão é um. O máximo é 512.
Ao usar configurações da tarefa `ParallelApply*`, o `partition-key-type` padrão é a `primary-key` da tabela, não o `schema-name.table-name`.
## Conectar-se ao Kafka utilizando Transport Layer Security (TLS)
O cluster do Kafka aceita conexões seguras utilizando Transport Layer Security (TLS). Com o DMS, é possível utilizar qualquer uma das três opções de protocolo de segurança a seguir para proteger uma conexão de endpoint do Kafka.
**Criptografia SSL (`server-encryption`)**
Os clientes validam a identidade do servidor por meio do certificado do servidor. Uma conexão criptografada é feita entre o servidor e o cliente.
**Autenticação SSL (`mutual-authentication`)**
O servidor e o cliente validam a identidade entre si por meio de seus próprios certificados. Uma conexão criptografada é feita entre o servidor e o cliente.
**SASL-SSL (`mutual-authentication`)**
O método Simple Authentication and Security Layer (SASL) substitui o certificado do cliente por um nome de usuário e senha para validar a identidade do cliente. Especificamente, forneça um nome de usuário e uma senha que o servidor registrou para que o servidor possa validar a identidade de um cliente. Uma conexão criptografada é feita entre o servidor e o cliente.
**Importante**
O Apache Kafka e o Amazon MSK aceitam certificados resolvidos. Essa é uma limitação conhecida do Kafka e do Amazon MSK a ser resolvida. Para obter mais informações, consulte [Problemas do Apache Kafka, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Se você estiver usando o Amazon MSK, considere usar listas de controle de acesso (ACLs) como uma solução alternativa para essa limitação conhecida. Para obter mais informações sobre o uso ACLs, consulte a seção [Apache Kafka ACLs do Guia do desenvolvedor](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) do *Amazon Managed Streaming for Apache Kafka*.
Se estiver utilizando um cluster do Kafka autogerenciado, consulte [Comentário datado de 18/out/21](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376) para obter informações sobre como configurar o cluster.
### Utilizar criptografia SSL com o Amazon MSK ou um cluster do Kafka autogerenciado
É possível utilizar a criptografia SSL para proteger uma conexão de endpoint ao Amazon MSK ou um cluster do Kafka autogerenciado. Ao utilizar o método de autenticação de criptografia SSL, os clientes validam a identidade de um servidor por meio do certificado do servidor. Uma conexão criptografada é feita entre o servidor e o cliente.
**Como utilizar a criptografia SSL para conectar-se ao Amazon MSK**
+ Defina a configuração do endpoint do protocolo de segurança (`SecurityProtocol`) utilizando a opção `ssl-encryption` ao criar o endpoint do Kafka de destino.
O exemplo de JSON a seguir define o protocolo de segurança como criptografia SSL.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**Para utilizar a criptografia SSL para um cluster do Kafka autogerenciado**
1. Se estiver utilizando uma Autoridade de Certificação (CA) privada no cluster do Kafka on-premises, faça upload do certificado da CA privada e obtenha um nome do recurso da Amazon (ARN).
1. Defina a configuração do endpoint do protocolo de segurança (`SecurityProtocol`) utilizando a opção `ssl-encryption` ao criar o endpoint do Kafka de destino. O exemplo de JSON a seguir define o protocolo de segurança como `ssl-encryption`.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Se estiver utilizando uma CA privada, defina `SslCaCertificateArn` no ARN obtido na primeira etapa acima.
### Utilizar autenticação SSL
É possível utilizar a autenticação SSL para proteger uma conexão de endpoint ao Amazon MSK ou um cluster do Kafka autogerenciado.
Para ativar a autenticação e a criptografia do cliente utilizando a autenticação SSL para conectar-se ao Amazon MSK, faça o seguinte:
+ Prepare uma chave privada e um certificado público para o Kafka.
+ Faça upload dos certificados no gerenciador de certificados do DMS.
+ Crie um endpoint de destino do Kafka com o certificado correspondente ARNs especificado nas configurações do endpoint do Kafka.
**Como preparar uma chave privada e um certificado público para o Amazon MSK.**
1. Crie uma instância do EC2 e configure um cliente para utilizar a autenticação conforme descrito nas etapas de 1 a 9 na seção [Autenticação de cliente](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) do *Guia do desenvolvedor do Amazon Managed Streaming for Apache Kafka*.
Depois de concluir essas etapas, você tem o ARN de um certificado (o ARN do certificado público salvo no ACM) e uma chave privada contida em um arquivo `kafka.client.keystore.jks`.
1. Obtenha o certificado público e copie o certificado no arquivo `signed-certificate-from-acm.pem`, utilizando o comando a seguir:
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
O comando retorna informações semelhantes às do exemplo a seguir.
```
{"Certificate": "123", "CertificateChain": "456"}
```
Copie o equivalente de `"123"` no arquivo `signed-certificate-from-acm.pem`.
1. Obtenha a chave privada importando a chave `msk-rsa` de `kafka.client.keystore.jks to keystore.p12`, conforme mostrado no exemplo a seguir.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Utilize o comando a seguir para exportar `keystore.p12` para o formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
A mensagem **Inserir frase secreta do PEM** é exibida e identifica a chave aplicada para criptografar o certificado.
1. Remova os atributos bag e os atributos-chave do arquivo `.pem` para garantir que a primeira linha comece com a sequência de caracteres a seguir.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**Como fazer upload de um certificado público e de uma chave privada no gerenciador de certificados do DMS e testar a conexão ao Amazon MSK**
1. Faça upload do gerenciador de certificados do DMS utilizando o comando a seguir.
```
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. Crie um endpoint de destino do Amazon MSK e teste a conexão para garantir que a autenticação TLS funcione.
```
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**
É possível utilizar a autenticação SSL para proteger uma conexão a um cluster do Kafka autogerenciado. Em alguns casos, é possível utilizar uma Autoridade de Certificação (CA) privada no cluster do Kafka on-premises. Nesse caso, faça upload da cadeia de CAs, do certificado público e da chave privada para o gerenciador de certificados do DMS. Utilize o nome do recurso da Amazon (ARN) correspondente nas configurações do endpoint ao criar o endpoint de destino do Kafka on-premises.
**Como preparar uma chave privada e um certificado assinado para um cluster do Kafka autogerenciado**
1. Gere um par de chaves como mostrado no exemplo a seguir.
```
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. Gere uma solicitação de assinatura de certificado (CSR).
```
keytool -keystore kafka.server.keystore.jks -certreq -file server-cert-sign-request-rsa -alias on-premise-rsa -storepass your-key-store-password
-keypass your-key-password
```
1. Utilize a CA no truststore do cluster para assinar a CSR. Se não tiver uma CA, você poderá criar sua própria CA privada.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Importe `ca-cert` para o truststore e o keystore do servidor. Se você não tiver um truststore, utilize o seguinte comando para criar o truststore e importar `ca-cert ` nele.
```
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. Assine o certificado.
```
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. Importe o certificado assinado para o 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. Utilize o comando a seguir para importar a chave `on-premise-rsa` de `kafka.server.keystore.jks` para `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. Utilize o comando a seguir para exportar `keystore.p12` para o formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Faça upload de `encrypted-private-server-key.pem`, `signed-certificate.pem` e `ca-cert` para o gerenciador de certificados do DMS.
1. Crie um endpoint usando o retornado 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
```
### Utilizar a autenticação SASL-SSL para se conectar ao Amazon MSK
O método Simple Authentication and Security Layer (SASL) utiliza um nome de usuário e uma senha para validar a identidade de um cliente e faz uma conexão criptografada entre o servidor e o cliente.
Para utilizar o SASL, primeiro crie um nome de usuário e uma senha seguros ao configurar o cluster do Amazon MSK. Para obter uma descrição de como configurar um nome de usuário e senha seguros para um cluster Amazon MSK, consulte Como [configurar a SASL/SCRAM autenticação para um cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) no Guia do desenvolvedor do *Amazon Managed Streaming for Apache Kafka*.
Crie o endpoint de destino do Kafka, defina a configuração do endpoint do protocolo de segurança (`SecurityProtocol`) utilizando a opção `sasl-ssl`. Defina também as opções `SaslUsername` e `SaslPassword`. Verifique se essas opções são consistentes com o nome de usuário e senha seguros criados ao configurar o cluster do Amazon MSK pela primeira vez, conforme mostrado no exemplo de JSON a seguir.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**nota**
Atualmente, AWS DMS oferece suporte somente a SASL-SSL público apoiado pela CA. O DMS não é compatível com SASL-SSL para utilização com o Kafka autogerenciado compatível com a CA privada.
Para autenticação SASL-SSL, AWS DMS suporta o mecanismo SCRAM-SHA-512 por padrão. AWS DMS as versões 3.5.0 e superiores também suportam o mecanismo Plain. Para ser compatível com o mecanismo Plain, defina o parâmetro `SaslMechanism` do tipo de dados da API do `KafkaSettings` como `PLAIN`. É possível usar o tipo de dados `PLAIN` no Kafka, mas não no Amazon for Kafka (MSK).
## Utilizar uma imagem anterior para visualizar os valores originais de linhas da CDC para o Apache Kafka como destino
Ao gravar as atualizações de CDC em um destino de streaming de dados, como o Kafka, é possível visualizar os valores originais de linhas do banco de dados de origem antes da alteração por uma atualização. Para tornar isso possível, AWS DMS preenche uma *imagem anterior* dos eventos de atualização com base nos dados fornecidos pelo mecanismo do banco de dados de origem.
Diferentes mecanismos de banco de dados de origem fornecem diferentes quantidades de informações para uma imagem anterior:
+ O Oracle fornece atualizações para colunas somente se elas forem alteradas.
+ O PostgreSQL fornece somente dados para colunas que fazem parte da chave primária (alterada ou não). Se a replicação lógica estiver em uso e REPLICA IDENTITY FULL estiver definida para a tabela de origem, você poderá obter informações completas de antes e depois na linha gravada no WALs e disponível aqui.
+ O MySQL geralmente fornece dados para todas as colunas (alteradas ou não).
Para habilitar a criação de imagem anterior para adicionar valores originais do banco de dados de origem à saída do AWS DMS , use a configuração de tarefa `BeforeImageSettings` ou o parâmetro `add-before-image-columns`. Esse parâmetro aplica uma regra de transformação de coluna.
`BeforeImageSettings` adiciona um novo atributo JSON a cada operação de atualização com valores coletados do sistema de banco de dados de origem, conforme mostrado a seguir.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**nota**
Aplique `BeforeImageSettings` às tarefas de carga máxima e de CDC (que migram dados existentes e replicam alterações contínuas) ou às tarefas de somente CDC (que replicam somente as alterações de dados). Não aplique `BeforeImageSettings` a tarefas que são somente de carga total.
Para opções `BeforeImageSettings`, aplica-se o seguinte:
+ Defina a opção `EnableBeforeImage` como `true` para habilitar a criação de imagem anterior. O padrão é `false`.
+ Use a opção `FieldName` para atribuir um nome ao novo atributo JSON. Quando `EnableBeforeImage` for `true`, `FieldName` será necessário e não poderá estar vazio.
+ A opção `ColumnFilter` especifica uma coluna a ser adicionada usando imagem anterior. Para adicionar somente colunas que fazem parte das chaves primárias da tabela, use o valor padrão, `pk-only`. Para adicionar somente colunas que não são do tipo LOB, utilize `non-lob`. Para adicionar qualquer coluna que tenha um valor de imagem anterior, use `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Usar uma regra de transformação de imagem anterior
Como alternativa às configurações de tarefa, é possível usar o parâmetro `add-before-image-columns`, que aplica uma regra de transformação de coluna. Com esse parâmetro, é possível habilitar a criação de imagem anterior durante a CDC em destinos de streaming de dados, como o Kafka.
Usando `add-before-image-columns` em uma regra de transformação, é possível aplicar um controle mais refinado dos resultados da imagem anterior. As regras de transformação permitem que você use um localizador de objetos que oferece controle sobre as tabelas selecionadas para a regra. Além disso, é possível encadear regras de transformação, o que permite que regras diferentes sejam aplicadas a tabelas diferentes. Depois, você poderá manipular as colunas produzidas usando outras regras.
**nota**
Não use o parâmetro `add-before-image-columns` junto com a configuração da tarefa `BeforeImageSettings` na mesma tarefa. Em vez disso, use o parâmetro ou a configuração, mas não ambos, para uma única tarefa.
Um tipo de regra `transformation` com o parâmetro `add-before-image-columns` de uma coluna deve fornecer uma seção `before-image-def`. Por exemplo:
```
{
"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,
}
}
```
O valor de `column-prefix` precede um nome de coluna e o valor padrão de `column-prefix` é `BI_`. O valor de `column-suffix` é anexado ao nome da coluna e o padrão é vazio. Não defina `column-prefix` e `column-suffix` como strings vazias.
Escolha um valor para `column-filter`. Para adicionar somente colunas que fazem parte das chaves primárias da tabela, escolha `pk-only`. Escolha `non-lob` para adicionar somente colunas que não sejam do tipo LOB. Ou escolha `all` para adicionar qualquer coluna que tenha um valor de imagem anterior.
### Exemplo de uma regra de transformação de imagem anterior
A regra de transformação no exemplo a seguir adiciona uma nova coluna chamada `BI_emp_no` no destino. Portanto, uma instrução como `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` preenche o campo `BI_emp_no` com 1. Ao gravar atualizações da CDC em destinos do Amazon S3, a coluna `BI_emp_no` possibilita identificar qual linha original foi atualizada.
```
{
"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"
}
}
]
}
```
Para obter informações sobre como usar a ação da regra `add-before-image-columns`, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Limitações ao usar o Apache Kafka como alvo para AWS Database Migration Service
Aplicam-se as seguintes limitações ao utilizar o Apache Kafka como destino:
+ AWS DMS Os endpoints de destino do Kafka não oferecem suporte ao controle de acesso do IAM para o Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ O modo Full LOB não é compatível.
+ Especifique um arquivo de configuração do Kafka para seu cluster com propriedades que permitem AWS DMS criar novos tópicos automaticamente. Inclua a configuração, `auto.create.topics.enable = true`. Se estiver utilizando o Amazon MSK, será possível especificar a configuração padrão ao criar o cluster do Kafka e alterar a configuração `auto.create.topics.enable` para `true`. Para obter mais informações sobre as configurações padrão, consulte [A configuração padrão do Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) no *Guia do desenvolvedor do Amazon Managed Streaming for Apache Kafka*. Se você precisar modificar um cluster existente do Kafka criado usando o Amazon MSK, execute o AWS CLI comando `aws kafka create-configuration` para atualizar sua configuração do Kafka, como no exemplo a seguir:
```
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"
}
```
Aqui, `//~/kafka_configuration` é o arquivo configuração criado com as configurações de propriedades necessárias.
Se você estiver usando sua própria instância do Kafka instalada no Amazon EC2, modifique a configuração do cluster Kafka com `auto.create.topics.enable = true` a configuração para AWS DMS permitir a criação automática de novos tópicos, usando as opções fornecidas com sua instância.
+ AWS DMS publica cada atualização em um único registro no banco de dados de origem como um registro de dados (mensagem) em um determinado tópico do Kafka, independentemente das transações.
+ AWS DMS suporta as quatro formas a seguir para chaves de partição:
+ `SchemaName.TableName`: uma combinação de esquema e nome da tabela.
+ `${AttributeName}`: o valor de um dos campos no JSON ou a chave primária da tabela no banco de dados de origem.
+ `transaction-id`: O ID da transação do CDC. Todos os registros da mesma transação vão para a mesma partição.
+ `constant`: um valor literal fixo para cada registro, independentemente da tabela ou dos dados. Todos os registros são enviados para o mesmo valor de chave de partição “constante”, fornecendo uma ordem global estrita em todas as tabelas.
```
{
"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"
}
}
```
+ A configuração do `IncludeTransactionDetails` endpoint só é suportada quando o endpoint de origem é Oracle, SQL Server, PostgreSQL ou MySQL. Para outros tipos de endpoint de origem, os detalhes da transação não serão incluídos.
+ O `BatchApply` não é compatível com um endpoint do Kafka. A utilização da aplicação em lote (por exemplo, a configuração da tarefa de metadados de destino `BatchApplyEnabled`) para um destino do Kafka pode resultar em perda de dados.
+ AWS DMS não suporta a migração de valores do tipo de `BigInt` dados com mais de 16 dígitos. Para contornar essa limitação, você pode usar a regra de transformação a seguir para converter a coluna `BigInt` em uma string. Para obter mais informações sobre regras transformação, consulte [Regras de transformação e ações](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 Os endpoints de destino do Kafka não oferecem suporte ao Amazon MSK servless.
+ Ao definir regras de mapeamento, não é possível ter uma regra de mapeamento de objetos e uma regra de transformação. Você deve definir somente uma regra.
+ AWS DMS suporta autenticação SASL para versões do Apache Kafka até 3.8. Se você estiver usando o Kafka 4.0 ou superior, só poderá se conectar sem a autenticação SASL.
+ AWS DMS não suporta dados de origem contendo `'\0'` caracteres incorporados ao usar o Kafka como um endpoint de destino. Os dados contendo `'\0'` caracteres incorporados serão truncados no primeiro `'\0'` caractere.
## Utilizar o mapeamento de objetos para migrar dados para um tópico do Kafka
AWS DMS usa regras de mapeamento de tabelas para mapear dados da fonte para o tópico de destino do Kafka. Para mapear dados para um tópico de destino, utilize um tipo de regra de mapeamento de tabelas chamado mapeamento de objetos. Utilize o mapeamento de objetos para definir como os registros de dados na origem são mapeados para os registros de dados publicados em um tópico do Kafka.
Os tópicos do Kafka não têm uma estrutura predefinida além de uma chave de partição.
**nota**
Não é necessário utilizar o mapeamento de objetos. É possível utilizar o mapeamento de tabela normal para várias transformações. No entanto, o tipo de chave de partição seguirá estes comportamentos padrão:
A chave primária é utilizada como uma chave de partição para a carga máxima.
Se nenhuma configuração de tarefas de aplicação paralela for utilizada, `schema.table` será usada como uma chave de partição para a CDC.
Se as configurações de tarefas de aplicação paralela forem utilizadas, a chave primária será utilizada como uma chave de partição para a CDC.
Para criar uma regra de mapeamento de objetos, especifique `rule-type` como `object-mapping`. Essa regra especifica o tipo de mapeamento de objeto que você deseja usar.
A estrutura da regra é a seguinte:
```
{
"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 atualmente suporta `map-record-to-record` e `map-record-to-document` como os únicos valores válidos para o `rule-action` parâmetro. Essas configurações afetam valores que não são excluídos como parte da lista de atributos `exclude-columns`. Os `map-record-to-document` valores `map-record-to-record` e especificam como AWS DMS manipula esses registros por padrão. Esses valores não afetam os mapeamentos de atributos de forma alguma.
Utilize o `map-record-to-record` ao migrar de um banco de dados relacional para um tópico do Kafka. Esse tipo de regra utiliza o valor `taskResourceId.schemaName.tableName` encontrado no banco de dados relacional como a chave de partição no tópico do Kafka e cria um atributo para cada coluna no banco de dados de origem.
Ao utilizar `map-record-to-record`, observe o seguinte:
+ Essa configuração afeta somente as colunas excluídas pela lista `exclude-columns`.
+ Para cada coluna desse tipo, AWS DMS cria um atributo correspondente no tópico de destino.
+ AWS DMS cria esse atributo correspondente independentemente de a coluna de origem ser usada em um mapeamento de atributos.
Uma maneira de compreender o `map-record-to-record` é vê-lo em ação. Para este exemplo, suponha que você está começando com uma linha de tabela do banco de dados relacional com a seguinte estrutura de dados:
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 29/02/1988 |
Para migrar essas informações de um esquema chamado `Test` para um tópico do Kafka, crie regras para mapear os dados para o tópico de destino. A regra a seguir ilustra o mapeamento.
```
{
"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"
}
}
]
}
```
Com um tópico do Kafka e uma chave de partição determinados (neste caso, `taskResourceId.schemaName.tableName`), o seguinte ilustra o formato do registro resultante utilizando os nossos exemplos de dados no tópico de destino do Kafka:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
**Topics**
+ [Reestruturação de dados com mapeamento de atributo](#CHAP_Target.Kafka.AttributeMapping)
+ [Replicação de multitópico utilizando o mapeamento de objetos](#CHAP_Target.Kafka.MultiTopic)
+ [Formato de mensagem do Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Reestruturação de dados com mapeamento de atributo
É possível reestruturar os dados ao migrá-los para um tópico do Kafka utilizando um mapa de atributos. Por exemplo, você pode combinar vários campos na origem em um único campo no destino. O mapa de atributo a seguir ilustra como reestruturar os dados.
```
{
"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}"
}
}
}
]
}
}
]
}
```
Para definir um valor constante para`partition-key`, especifique`"partition-key-type: "constant"`, isso define o valor da partição como`constant`. Por exemplo, é possível fazer isso para forçar o armazenamento de todos os dados em uma única partição. O mapeamento a seguir ilustra esse método.
```
{
"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**
O valor do `partition-key` para um registro de controle para uma tabela específica é `TaskId.SchemaName.TableName`. O valor do `partition-key` para um registro de controle específico para uma tarefa é o `TaskId` daquele registro. A especificação de um valor do `partition-key` no mapeamento do objeto não tem impacto sobre o `partition-key` no caso dos registros de controle.
Quando `partition-key-type` está definido como `attribute-name` em uma regra de mapeamento de tabela, você deve especificar`partition-key-name`, que deve fazer referência a uma coluna da tabela de origem ou a uma coluna personalizada definida no mapeamento. Além disso, `attribute-mappings` deve ser fornecido para definir como as colunas de origem são mapeadas para o tópico de destino do Kafka.
### Replicação de multitópico utilizando o mapeamento de objetos
Por padrão, AWS DMS as tarefas migram todos os dados de origem para um dos tópicos do Kafka a seguir:
+ Conforme especificado no campo **Tópico** do endpoint de AWS DMS destino.
+ Conforme especificado por `kafka-default-topic`, se o campo **Tópico** do endpoint de destino não estiver preenchido e a configuração `auto.create.topics.enable` do Kafka estiver definida como `true`.
Com as versões 3.4.6 e posteriores do AWS DMS mecanismo, você pode usar o `kafka-target-topic` atributo para mapear cada tabela de origem migrada para um tópico separado. Por exemplo, as regras de mapeamento de objetos a seguir migram as tabelas de origem `Customer` e `Address` para os tópicos `customer_topic` e `address_topic` do Kafka, respectivamente. Ao mesmo tempo, AWS DMS migra todas as outras tabelas de origem, incluindo a `Bills` tabela no `Test` esquema, para o tópico especificado no endpoint de destino.
```
{
"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"
}
}
]
}
```
Ao utilizar a replicação de multitópico do Kafka, é possível agrupar e migrar tabelas de origem para tópicos separados do Kafka utilizando uma única tarefa de replicação.
### Formato de mensagem do Apache Kafka
A saída JSON é simplesmente uma lista de pares chave/valor.
**RecordType**
O tipo de registro pode ser dados ou controle. Os *registros de dados *representam as linhas reais na origem. Os *registros de controle* são relacionados a importantes eventos no stream, como a reinicialização de uma tarefa, por exemplo.
**Operation**
Para registros de dados, a operação pode ser `load`, `insert`, `update` ou `delete`.
Para registros de controle, a operação pode ser `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` ou `column-type-change`.
**SchemaName**
O esquema de origem para o registro. Esse campo pode estar vazio para um registro de controle.
**TableName**
A tabela de origem para um registro. Esse campo pode estar vazio para um registro de controle.
**Timestamp**
A marca de data e hora de quando a mensagem do JSON foi criada. O campo é formatado com o formato ISO 8601.
O exemplo de mensagem JSON a seguir ilustra uma mensagem de tipo de dados com todos os metadados adicionais.
```
{
"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"
}
}
```
O exemplo de mensagem JSON a seguir ilustra uma mensagem de tipo de controle.
```
{
"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"
}
}
```
# Usando um cluster do Amazon OpenSearch Service como destino para AWS Database Migration Service
Você pode usar AWS DMS para migrar dados para o Amazon OpenSearch Service (OpenSearch Service). OpenSearch O serviço é um serviço gerenciado que facilita a implantação, a operação e a escalabilidade de um cluster OpenSearch de serviços.
No OpenSearch Service, você trabalha com índices e documentos. Um *índice* é uma coleção de documentos, e um *documento* é um objeto JSON contendo valores escalares, matrizes e outros objetos. OpenSearch fornece uma linguagem de consulta baseada em JSON, para que você possa consultar dados em um índice e recuperar os documentos correspondentes.
Ao AWS DMS criar índices para um endpoint de destino para o OpenSearch Service, ele cria um índice para cada tabela do endpoint de origem. O custo da criação de um índice OpenSearch de serviços depende de vários fatores. Esses são o número de índices criados, a quantidade total de dados nesses índices e a pequena quantidade de metadados que são OpenSearch armazenados para cada documento.
Configure seu cluster de OpenSearch serviços com recursos de computação e armazenamento adequados ao escopo de sua migração. É recomendável considerar os seguintes fatores, dependendo da tarefa de replicação a ser utilizada:
+ Para uma carga máxima de dados, considere a quantidade total de dados a ser migrada e a velocidade da transferência.
+ Para replicar as mudanças em andamento, considere a frequência das atualizações e seus requisitos de end-to-end latência.
Além disso, defina as configurações de índice em seu OpenSearch cluster, prestando muita atenção à contagem de documentos.
**Configurações da tarefa de carga máxima com vários threads**
Para ajudar a aumentar a velocidade da transferência, AWS DMS oferece suporte a uma carga completa de vários segmentos em um cluster de destino do OpenSearch serviço. AWS DMS suporta esse multithreading com configurações de tarefas que incluem o seguinte:
+ `MaxFullLoadSubTasks`: utilize esta opção para indicar o número máximo de tabelas de origem a serem carregadas em paralelo. O DMS carrega cada tabela em seu índice de destino OpenSearch de serviço correspondente usando uma subtarefa dedicada. O padrão é 8; o valor máximo é 49.
+ `ParallelLoadThreads`— Use essa opção para especificar o número de threads AWS DMS usados para carregar cada tabela em seu índice OpenSearch de destino de serviço. O valor máximo para uma meta OpenSearch de serviço é 32. Você pode solicitar o aumento desse limite máximo.
**nota**
Se você não alterar `ParallelLoadThreads` de seu padrão (0), o AWS DMS transferirá um único registro por vez. Essa abordagem coloca uma carga indevida em seu cluster OpenSearch de serviços. Defina essa opção como 1 ou mais.
+ `ParallelLoadBufferSize`— Use essa opção para especificar o número máximo de registros a serem armazenados no buffer que os threads de carregamento paralelo usam para carregar dados no destino do OpenSearch serviço. O valor padrão é 50. Valor máximo de 1.000. Use essa configuração com `ParallelLoadThreads`; `ParallelLoadBufferSize` é válido somente quando há mais de um thread.
Para obter mais informações sobre como o DMS carrega um cluster de OpenSearch serviços usando multithreading, consulte a AWS postagem do blog Escale o [Amazon OpenSearch Service](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) para migrações. AWS Database Migration Service
**Configurações da tarefa de carga de CDC multithread**
Você pode melhorar o desempenho da captura de dados de alteração (CDC) para um cluster de destino do OpenSearch serviço usando as configurações de tarefas para modificar o comportamento da chamada da `PutRecords` API. Para fazer isso, especifique o número de threads simultâneos, filas por thread e o número de registros a serem armazenados em um buffer usando as configurações da tarefa `ParallelApply*`. Por exemplo, suponha que você queira executar uma carga de CDC e aplicar 32 threads em paralelo. Você também quer acessar 64 filas por thread, com 50 registros armazenados por buffer.
**nota**
Support para o uso de configurações de `ParallelApply*` tarefas durante o CDC para endpoints OpenSearch de destino do Amazon Service está disponível nas AWS DMS versões 3.4.0 e superiores.
Para promover o desempenho do CDC, AWS DMS oferece suporte a estas configurações de tarefas:
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos que são AWS DMS usados durante um carregamento do CDC para enviar registros de dados para um endpoint de destino do OpenSearch serviço. O valor padrão é zero (0) e o valor máximo é 32.
+ `ParallelApplyBufferSize`— Especifica o número máximo de registros a serem armazenados em cada fila de buffer para que threads simultâneos sejam enviados para um endpoint de destino do OpenSearch serviço durante um carregamento do CDC. O valor padrão é 100 e o valor máximo é 1.000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`— Especifica o número de filas que cada thread acessa para retirar registros de dados das filas e gerar uma carga em lote para um endpoint de OpenSearch serviço durante o CDC.
Ao usar configurações da tarefa `ParallelApply*`, o `partition-key-type` padrão é a `primary-key` da tabela, não o `schema-name.table-name`.
## Migrando de uma tabela de banco de dados relacional para um índice de serviços OpenSearch
AWS DMS suporta a migração de dados para os tipos OpenSearch de dados escalares do Service. Ao migrar de um banco de dados relacional como Oracle ou MySQL para o OpenSearch Service, talvez você queira reestruturar a forma como você armazena esses dados.
AWS DMS suporta os seguintes tipos de dados escalares de OpenSearch serviço:
+ Booleano
+ Data
+ Float
+ Int
+ String
AWS DMS converte dados do tipo Date no tipo String. É possível especificar o mapeamento personalizado para interpretar essas datas.
AWS DMS não oferece suporte à migração de tipos de dados LOB.
## Pré-requisitos para usar o Amazon OpenSearch Service como alvo para AWS Database Migration Service
Antes de começar a trabalhar com um banco de dados de OpenSearch serviço como destino AWS DMS, certifique-se de criar uma função AWS Identity and Access Management (IAM). Essa função deve permitir o AWS DMS acesso aos índices OpenSearch de serviço no endpoint de destino. O conjunto mínimo de permissões de acesso é mostrado na seguinte política do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
A função que você usa para a migração para o OpenSearch Serviço deve ter as seguintes permissões.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
No exemplo anterior, `region` substitua pelo identificador da AWS região, *`account-id`* pelo ID AWS da sua conta e `domain-name` pelo nome do seu domínio do Amazon OpenSearch Service. Um exemplo é `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`
## Configurações de endpoint ao usar o OpenSearch Serviço como destino para AWS DMS
Você pode usar as configurações do endpoint para configurar seu banco de dados OpenSearch de destino do serviço de forma semelhante ao uso de atributos de conexão extras. Você especifica as configurações ao criar o endpoint de destino usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--elasticsearch-settings '{"EndpointSetting": "value", ...}'` JSON.
A tabela a seguir mostra as configurações de endpoint que você pode usar com o OpenSearch Serviço como destino.
| Nome do atributo | Valores válidos | Valor padrão e descrição |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Um inteiro positivo maior que 0, mas não maior que 100. | 10: para uma tarefa de carga máxima, esse atributo determina o limite de erros permitidos antes que ocorra uma falha na tarefa. Por exemplo, suponha que haja 1.500 linhas no endpoint de origem e o parâmetro foi definido como 10. Em seguida, a tarefa falhará se AWS DMS encontrar mais de 150 erros (10% da contagem de linhas) ao gravar no endpoint de destino. |
| `ErrorRetryDuration` | Um inteiro positivo maior do que 0. | 300 — Se ocorrer um erro no endpoint de destino, AWS DMS tente novamente por esse número de segundos. Caso contrário, a tarefa apresentará falha. |
| `UseNewMappingType` | true ou false | `false`, mas para funcionar usando o OpenSearch v2.x, ele deve ser definido como `true`. |
## Limitações ao usar o Amazon OpenSearch Service como alvo para AWS Database Migration Service
As seguintes limitações se aplicam ao usar o Amazon OpenSearch Service como alvo:
+ OpenSearch O serviço usa mapeamento dinâmico (adivinhação automática) para determinar os tipos de dados a serem usados para os dados migrados.
+ OpenSearch O serviço armazena cada documento com uma ID exclusiva. Veja um exemplo a seguir:
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Cada ID de documento tem 64 bytes de comprimento; lembre-se de que você precisará desse espaço para armazenamento. Por exemplo, se você migrar 100.000 linhas de uma AWS DMS fonte, o índice de OpenSearch serviço resultante exigirá armazenamento para mais 6.400.000 bytes.
+ Com o OpenSearch Service, você não pode fazer atualizações nos atributos da chave primária. Essa restrição é importante quando se usa a replicação contínua com captura de dados de alterações (CDC), pois ela pode gerar dados indesejados no destino. No modo CDC, as chaves primárias são mapeadas para SHA256 valores com 32 bytes de comprimento. Eles são convertidos em strings de 64 bytes legíveis por humanos e são usados como documento de serviço. OpenSearch IDs
+ Se AWS DMS encontrar algum item que não possa ser migrado, ele grava mensagens de erro no Amazon Logs. CloudWatch Esse comportamento é diferente de outros endpoints de AWS DMS destino, que gravam erros em uma tabela de exceções.
+ AWS DMS não suporta conexão com um cluster Amazon ES que tenha controle de acesso refinado habilitado com usuário mestre e senha.
+ AWS DMS não oferece suporte ao OpenSearch Service serverless.
+ OpenSearch O serviço não oferece suporte à gravação de dados em índices preexistentes.
+ A configuração da tarefa de replicação não `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` é suportada para uso com um endpoint de OpenSearch destino.
+ Ao migrar dados para o Amazon Elasticsearch usando AWS DMS, os dados de origem devem ter uma chave primária ou uma coluna de identificador exclusivo. Se os dados de origem não tiverem uma chave primária ou um identificador exclusivo, você precisará definir um usando a regra de define-primary-key transformação.
## Tipos de dados de destino para o Amazon OpenSearch Service
Quando AWS DMS migra dados de bancos de dados heterogêneos, o serviço mapeia tipos de dados do banco de dados de origem para tipos de dados intermediários chamados AWS DMS tipos de dados. Em seguida, o serviço mapeia os tipos de dados intermediários para os tipos de dados de destino. A tabela a seguir mostra cada tipo de AWS DMS dados e o tipo de dados para o qual ele mapeia no OpenSearch Serviço.
| AWS DMS tipo de dados | OpenSearch Tipo de dados do serviço |
| --- | --- |
| Booleano | booleano |
| Data | string |
| Time | date |
| Marca de data e hora | date |
| INT4 | integer |
| Real4 | float |
| UINT4 | integer |
Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Usando o Amazon DocumentDB como destino para o AWS Database Migration Service
Para obter informações sobre quais versões do Amazon DocumentDB (com compatibilidade com o MongoDB) são compatíveis, consulte. AWS DMS [Metas para AWS DMS](CHAP_Introduction.Targets.md) É possível utilizar o AWS DMS para migrar os dados para o Amazon DocumentDB (compatível com MongoDB) de qualquer mecanismo de dados de origem compatível com o AWS DMS . O mecanismo de origem pode estar em um serviço AWS gerenciado, como Amazon RDS, Aurora ou Amazon S3. Ou o mecanismo pode estar em um banco de dados autogerenciado, como o MongoDB em execução no Amazon EC2 ou on-premises.
Você pode usar AWS DMS para replicar dados de origem para bancos de dados, coleções ou documentos do Amazon DocumentDB.
**nota**
Se o endpoint de origem for o MongoDB ou o Amazon DocumentDB, execute a migração no **Modo documento**.
O MongoDB armazena dados em um formato JSON binário (BSON). AWS DMS suporta todos os tipos de dados BSON que são compatíveis com o Amazon DocumentDB. Para obter uma lista desses tipos de dados, consulte [ APIsMongoDB, operações e tipos de dados suportados no Guia](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) do desenvolvedor do *Amazon DocumentDB*.
Se o endpoint de origem for um banco de dados relacional, AWS DMS mapeia objetos do banco de dados para o Amazon DocumentDB da seguinte forma:
+ Um banco de dados relacional ou esquema de banco de dados, é mapeado para um *banco de dados* Amazon DocumentDB.
+ As tabelas dentro de um banco de dados relacional são mapeadas para *coleções* no Amazon DocumentDB.
+ Os registros em uma tabela relacional são mapeados para *documentos* no Amazon DocumentDB. Cada documento é construído a partir de dados no registro de origem.
Se o endpoint de origem for o Amazon S3, os objetos resultantes do Amazon DocumentDB corresponderão às regras de mapeamento do AWS DMS para o Amazon S3. Por exemplo, considere o URI a seguir.
```
s3://amzn-s3-demo-bucket/hr/employee
```
Nesse caso, AWS DMS mapeia os objetos `amzn-s3-demo-bucket` para o Amazon DocumentDB da seguinte forma:
+ A parte de nível superior do URI (`hr`) é mapeada para um banco de dados Amazon DocumentDB.
+ A próxima parte do URI (`employee`) é mapeada para uma coleção do Amazon DocumentDB.
+ Cada objeto em `employee` é mapeado para um documento no Amazon DocumentDB.
Para obter mais informações sobre as regras de mapeamento do Amazon S3, consulte [Usando o Amazon S3 como fonte para AWS DMS](CHAP_Source.S3.md).
**Configurações do endpoint do Amazon DocumentDB**
Nas AWS DMS versões 3.5.0 e superiores, você pode melhorar o desempenho da captura de dados de alteração (CDC) para endpoints do Amazon DocumentDB ajustando as configurações de tarefas para threads paralelos e operações em massa. Para fazer isso, especifique o número de threads simultâneos, filas por thread e o número de registros a serem armazenados em um buffer usando as configurações da tarefa `ParallelApply*`. Por exemplo, suponha que você queira executar um carregamento de CDC e aplicar 128 threads em paralelo. Você também quer acessar 64 filas por thread, com 50 registros armazenados por buffer.
Para promover o desempenho do CDC, AWS DMS oferece suporte a estas configurações de tarefas:
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos que são AWS DMS usados durante um carregamento do CDC para enviar registros de dados para um endpoint de destino do Amazon DocumentDB. O valor padrão é zero (0) e o valor máximo é 32.
+ `ParallelApplyBufferSize`: especifica o número máximo de registros a serem armazenados em cada fila de buffer para que os threads simultâneos enviem para um endpoint de destino do Amazon DocumentDB durante uma carga de CDC. O valor padrão é 100 e o valor máximo é 1.000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`: especifica o número de filas que cada thread acessa para utilizar registros de dados das filas e gerar uma carga em lote para um endpoint do Amazon DocumentDB durante a CDC. O padrão é um. O máximo é 512.
**nota**
Para destinos do Amazon DocumentDB, a aplicação paralela do CDC pode causar erros de chave duplicada ou paralisar a aplicação do CDC para cargas de trabalho que usam índices exclusivos secundários ou exigem uma ordenação estrita das alterações. Use a configuração padrão de aplicação do CDC de thread único para essas cargas de trabalho.
Para obter detalhes adicionais sobre como trabalhar com o Amazon DocumentDB como destino AWS DMS, consulte as seguintes seções:
**Topics**
+ [Mapear dados de uma origem para um destino do Amazon DocumentDB](#CHAP_Target.DocumentDB.data-mapping)
+ [Conexão aos clusters elásticos do Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Replicação contínua com o Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Limitações da utilização do Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.limitations)
+ [Utilizar configurações de endpoint com o Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.ECAs)
+ [Tipos de dados de destino do Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**nota**
Para ver um step-by-step passo a passo do processo de migração, consulte [Migração do MongoDB para o Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html) no Guia de migração. AWS Database Migration Service Step-by-Step
## Mapear dados de uma origem para um destino do Amazon DocumentDB
AWS DMS lê registros do endpoint de origem e constrói documentos JSON com base nos dados que ele lê. Para cada documento JSON, é AWS DMS necessário determinar um `_id` campo para atuar como um identificador exclusivo. Ele grava o documento JSON em uma coleção do Amazon DocumentDB, utilizando o campo `_id` como uma chave primária.
### Dados de origem que são uma coluna individual
Se os dados de origem consistirem em uma única coluna, os dados deverão ser de um tipo de string. (Dependendo do mecanismo de origem, o tipo de dados real pode ser VARCHAR, NVARCHAR, TEXT, LOB, CLOB ou similar.) AWS DMS assume que os dados são um documento JSON válido e replica os dados para o Amazon DocumentDB no estado em que se encontram.
Se o documento JSON resultante contiver um campo chamado `_id`, o campo será utilizado como o `_id` exclusivo no Amazon DocumentDB.
Se o JSON não contiver um campo `_id`, o Amazon DocumentDB gerará um valor de `_id` automaticamente.
### Dados de origem que são várias colunas
Se os dados de origem consistirem em várias colunas, AWS DMS criará um documento JSON a partir de todas essas colunas. Para determinar o `_id` campo do documento, AWS DMS faça o seguinte:
+ Se uma das colunas for chamada `_id`, os dados dessa coluna serão utilizados como o `_id` de destino.
+ Se não houver uma `_id` coluna, mas os dados de origem tiverem uma chave primária ou um índice exclusivo, AWS DMS use essa chave ou o valor do índice como `_id` valor. Os dados da chave primária ou do índice exclusivo também aparece como campos explícitos no documento JSON.
+ Se não houver nenhuma coluna `_id` e nenhuma chave primária ou índice exclusivo, o Amazon DocumentDB gerará um valor de `_id` automaticamente.
### Coagir um tipo de dados no endpoint de destino
AWS DMS pode modificar estruturas de dados ao gravar em um endpoint de destino do Amazon DocumentDB. É possível solicitar essas alterações renomeando colunas e tabelas no endpoint de origem ou fornecendo regras de transformação que são aplicadas quando uma tarefa está sendo executada.
#### Utilizar um documento JSON aninhado (json\$1 prefix)
Para coagir um tipo de dados, é possível prefixar o nome da coluna de origem com `json_` (ou seja, `json_columnName`) manualmente ou utilizando uma transformação. Nesse caso, a coluna é criada como um documento JSON aninhado dentro do documento de destino, e não como um campo de string.
Por exemplo, suponha que você deseja migrar o documento a seguir de um endpoint de origem do MongoDB.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Se você não coagir nenhum dos tipos de dados de origem, o documento `ContactDetails` incorporado será migrado como uma string.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
No entanto, é possível adicionar uma regra de transformação para coagir `ContactDetails` para um objeto JSON. Por exemplo, suponha que o nome original da coluna de origem seja `ContactDetails`. Para coagir o tipo de dados como JSON aninhado, a coluna no endpoint de origem precisa ser renomeada como “json\$1ContactDetails” adicionando o prefixo “\$1json\$1\$1 “na origem manualmente ou por meio de regras de transformação. Por exemplo, é possível utilizar a regra de transformação abaixo:
```
{
"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 replica o ContactDetails campo como JSON aninhado, da seguinte forma.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Utilizar uma matriz JSON (array\$1 prefix)
Para coagir um tipo de dados, é possível prefixar o nome de uma coluna com `array_` (ou seja, `array_columnName`) manualmente ou utilizando uma transformação. Nesse caso, AWS DMS considera a coluna como uma matriz JSON e a cria como tal no documento de destino.
Suponha que você deseja migrar o documento a seguir de um endpoint de origem do MongoDB.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Se você não coagir nenhum dos tipos de dados de origem, o documento `ContactDetails` incorporado será migrado como uma string.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
No entanto, é possível adicionar regras de transformação para coagir `ContactAddress` e `ContactPhoneNumbers` para matrizes JSON, conforme mostrado na tabela a seguir.
****
| Nome original da coluna de origem | Coluna de origem renomeada |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS replica `ContactAddress` e da `ContactPhoneNumbers` seguinte forma.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Conectar-se ao Amazon DocumentDB utilizando TLS
Por padrão, um cluster recém-criado do Amazon DocumentDB aceita conexões seguras somente quando o Transport Layer Security (TLS) é utilizado. Quando o TLS está ativado, cada conexão ao Amazon DocumentDB requer uma chave pública.
Você pode recuperar a chave pública para o Amazon DocumentDB baixando o arquivo`rds-combined-ca-bundle.pem`,, de AWS um bucket hospedado do Amazon S3. Para obter mais informações sobre como baixar esse arquivo, consulte [Criptografar conexões utilizando TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) no *Guia do desenvolvedor do Amazon DocumentDB*
Depois de baixar esse arquivo.pem, você pode importar a chave pública que ele contém, AWS DMS conforme descrito a seguir.
#### Console de gerenciamento da AWS
**Para importar o arquivo (.pem) da chave pública**
1. Abra o AWS DMS console em [https://console.aws.amazon.com/dms](https://console.aws.amazon.com/dms).
1. No painel de navegação, escolha **Certificates**.
1. Selecione **Import certificate (Importar certificado)** e faça o seguinte:
+ Para **Certificate identifier (Identificador do certificado)**, insira um nome exclusivo para o certificado, por exemplo `docdb-cert`.
+ Em **Importar arquivo**, navegue até o local onde você salvou o arquivo .pem.
Quando estiver satisfeito com as configurações, selecione **Add new CA certificate (Adicionar novo certificado de CA)**.
#### AWS CLI
Utilize o comando `aws dms import-certificate`, conforme mostrado no exemplo a seguir.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Ao criar um endpoint de AWS DMS destino, forneça o identificador do certificado (por exemplo,`docdb-cert`). Além disso, defina o parâmetro do modo SSL como `verify-full`.
## Conexão aos clusters elásticos do Amazon DocumentDB como destino
Nas AWS DMS versões 3.4.7 e superiores, você pode criar um endpoint de destino do Amazon DocumentDB como um cluster elástico. Se você criar o endpoint de destino como um cluster elástico, precisará anexar um novo certificado SSL ao endpoint do cluster elástico do Amazon DocumentDB porque o certificado SSL existente não funcionará.
**Como anexar um novo certificado SSL ao endpoint do cluster elástico do Amazon DocumentDB**
1. Em um navegador, abra [ https://www.amazontrust.com/repository/SFSRootCAG2o.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) e salve o conteúdo em um `.pem` arquivo com um nome de arquivo exclusivo, por exemplo. `SFSRootCAG2.pem` Esse é o arquivo de certificado que você precisa importar nas etapas subsequentes.
1. Crie o endpoint do cluster elástico e defina as seguintes opções:
1. Em **Configuração do endpoint**, escolha **Adicionar novo certificado CA**.
1. Em **Identificador de certificado**, insira **SFSRootCAG2.pem**.
1. Em **Importar arquivo de certificado**, escolha **Escolher arquivo** e navegue até o arquivo `SFSRootCAG2.pem` baixado anteriormente.
1. Selecione e abra o arquivo `SFSRootCAG2.pem` baixado.
1. Escolha **Importar certificado**.
1. No menu suspenso **Escolha um certificado**, escolha **SFSRootCAG2.pem**.
O novo certificado SSL do arquivo `SFSRootCAG2.pem` baixado agora está anexado ao endpoint do cluster elástico do Amazon DocumentDB.
## Replicação contínua com o Amazon DocumentDB como destino
Se a replicação contínua (captura de dados de alteração, CDC) estiver ativada para o Amazon DocumentDB como destino, as versões 3.5.0 e superior do AWS DMS proporcionarão uma melhoria no desempenho vinte vezes maior do que nas versões anteriores. Em versões anteriores, onde AWS DMS processava até 250 registros por segundo, AWS DMS agora processa com eficiência mais de 5000 registros por segundo. AWS DMS também garante que os documentos no Amazon DocumentDB permaneçam sincronizados com a fonte. Quando um registro de origem é criado ou atualizado, primeiro é AWS DMS necessário determinar qual registro do Amazon DocumentDB é afetado, fazendo o seguinte:
+ Se o registro da origem tiver uma coluna chamada `_id`, o valor dessa coluna determinará o `_id` correspondente na coleção do Amazon DocumentDB.
+ Se não houver uma `_id` coluna, mas os dados de origem tiverem uma chave primária ou um índice exclusivo, AWS DMS use essa chave ou valor de índice como o da `_id` coleção Amazon DocumentDB.
+ Se o registro de origem não tiver uma `_id` coluna, uma chave primária ou um índice exclusivo, todas as colunas de origem AWS DMS corresponderão aos campos correspondentes na coleção Amazon DocumentDB.
Quando um novo registro de origem é criado, AWS DMS grava um documento correspondente no Amazon DocumentDB. Se um registro de origem existente for atualizado, AWS DMS atualiza os campos correspondentes no documento de destino no Amazon DocumentDB. Todos os campos que existem no documento de destino, mas não no registro da origem permanecem inalterados.
Quando um registro de origem é excluído, o documento correspondente é AWS DMS excluído do Amazon DocumentDB.
### Alterações estruturais (DDL) na origem
Com a replicação contínua, qualquer alteração nas estruturas de dados da origem (como tabelas, colunas e assim por diante) é propagada para seus equivalentes no Amazon DocumentDB. Em bancos de dados relacionais, essas alterações são iniciadas utilizando instruções da linguagem de definição de dados (DDL). Você pode ver como AWS DMS propaga essas alterações para o Amazon DocumentDB na tabela a seguir.
****
| DDL na origem | Efeito no destino do Amazon DocumentDB |
| --- | --- |
| CREATE TABLE | Cria uma coleção vazia. |
| Instrução que renomeia uma tabela (RENAME TABLE, ALTER TABLE...RENAME e semelhante) | Renomeia a coleção. |
| TRUNCATE TABLE | Remove todos os documentos da coleção, mas somente se HandleSourceTableTruncated for true. Para obter mais informações, consulte [Configurações de tarefa para processamento de DDL de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Exclui a coleção, mas somente se HandleSourceTableDropped for true. Para obter mais informações, consulte [Configurações de tarefa para processamento de DDL de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Instrução que adiciona uma coluna a uma tabela (ALTER TABLE...ADD e semelhante) | A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem, o novo campo é adicionado ao documento de destino. |
| ALTER TABLE...RENAME COLUMN | A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem, o campo recém-nomeado é adicionado ao documento de destino. |
| ALTER TABLE...DROP COLUMN | A instrução DDL é ignorada e um aviso é emitido. |
| Instrução que altera o tipo de dados da coluna (ALTER COLUMN...MODIFY e semelhante) | A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem com o novo tipo de dados, o documento de destino é criado com um campo desse novo tipo de dados. |
## Limitações da utilização do Amazon DocumentDB como destino
As seguintes limitações se aplicam ao usar o Amazon DocumentDB como destino para: AWS DMS
+ No Amazon DocumentDB, os nomes de coleção não podem conter o símbolo de dólar (\$1). Além disso, os nomes do banco de dados não podem conter caracteres Unicode.
+ AWS DMS não suporta a fusão de várias tabelas de origem em uma única coleção do Amazon DocumentDB.
+ Quando AWS DMS os processos são alterados de uma tabela de origem que não tem uma chave primária, todas as colunas LOB nessa tabela são ignoradas.
+ Se a opção **Alterar tabela** estiver habilitada, e o AWS DMS encontrar uma coluna de origem chamada “*\$1id*”, essa coluna aparecerá como “*\$1\$1id*” (dois sublinhados) na tabela de alteração.
+ Se você escolher o Oracle como o endpoint de origem, a origem do Oracle deverá ter o registro em log suplementar total ativado. Caso contrário, se houver colunas na origem que não foram alteradas, os dados serão carregados no Amazon DocumentDB como valores nulos.
+ A configuração de `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` da tarefa de replicação não é compatível para utilização com um endpoint de destino do DocumentDB.
+ Não é possível usar coleções limitadas do MongoDB no Amazon DocumentDB. No entanto, o AWS DMS migra automaticamente esses objetos como coleções ilimitadas no DocumentDB de destino.
+ A aplicação paralela do CDC aos destinos do Amazon DocumentDB pode causar erros de chave duplicada ou a aplicação paralisada do CDC para cargas de trabalho que usam índices exclusivos secundários ou exigem uma ordenação estrita das alterações. Para essas cargas de trabalho, use a configuração padrão de aplicação CDC de thread único.
## Utilizar configurações de endpoint com o Amazon DocumentDB como destino
É possível utilizar as configurações de endpoint para configurar o destino do Amazon DocumentDB de forma semelhante à utilização de atributos de conexão adicional. Você especifica as configurações ao criar o endpoint de destino usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON.
A tabela a seguir mostra as configurações do endpoint que é possível utilizar com o Amazon DocumentDB como destino.
| Nome do atributo | Valores válidos | Valor padrão e descrição |
| --- | --- | --- |
| `replicateShardCollections` | booleano `true` `false` | Quando `true`, essa configuração de endpoint tem os seguintes efeitos e impõe as seguintes limitações: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Tipos de dados de destino do Amazon DocumentDB
Na tabela a seguir, você pode encontrar os tipos de dados de destino do Amazon DocumentDB que são compatíveis com o uso do AWS DMS e o mapeamento padrão dos tipos de dados do AWS DMS. Para obter mais informações sobre os tipos de dados do AWS DMS, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS Tipo de dados DMS | Tipo de dados do Amazon DocumentDB |
| --- | --- |
| BOOLEAN | Booleano |
| BYTES | Dados binários |
| DATE | Data |
| TIME | Cadeia de caracteres (UTF8) |
| DATETIME | Data |
| INT1 | Inteiro de 32 bits |
| INT2 | Inteiro de 32 bits |
| INT4 | Inteiro de 32 bits |
| INT8 | Inteiro de 64 bits |
| NUMERIC | Cadeia de caracteres (UTF8) |
| REAL4 | Duplo |
| REAL8 | Duplo |
| STRING | Se os dados forem reconhecidos como JSON, eles serão AWS DMS migrados para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados para String (UTF8). |
| UINT1 | Inteiro de 32 bits |
| UINT2 | Inteiro de 32 bits |
| UINT4 | Inteiro de 64 bits |
| UINT8 | Cadeia de caracteres (UTF8) |
| WSTRING | Se os dados forem reconhecidos como JSON, eles serão AWS DMS migrados para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados para String (UTF8). |
| BLOB | Binário |
| CLOB | Se os dados forem reconhecidos como JSON, eles serão AWS DMS migrados para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados para String (UTF8). |
| NCLOB | Se os dados forem reconhecidos como JSON, eles serão AWS DMS migrados para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados para String (UTF8). |
# Usando o Amazon Neptune como alvo para AWS Database Migration Service
O Amazon Neptune é um serviço de banco de dados de grafos rápido, confiável e totalmente gerenciado que facilita a criação e a execução de aplicações que trabalham com conjuntos de dados altamente conectados. O recurso principal do Neptune é um mecanismo de banco de dados de grafos com projeto específico e alto desempenho. Esse mecanismo é otimizado para armazenar bilhões de relacionamentos e consultar grafos com latência de milissegundos. O Neptune suporta as populares linguagens de consulta gráfica TinkerPop Apache Gremlin e SPARQL do W3C. Para obter mais informações sobre o Amazon Neptune, consulte [O que é o Amazon Neptune?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) no *Guia do usuário do Amazon Neptune*.
Sem um banco de dados de grafo, como o Neptune, é provável que você modele os dados altamente conectados em um banco de dados relacional. Como os dados têm conexões potencialmente dinâmicas, as aplicações que utilizam essas fontes de dados precisam modelar consultas de dados conectadas no SQL. Essa abordagem exigirá que você grave uma camada extra para converter consultas gráficas em SQL. Além disso, os bancos de dados relacionais vêm com rigidez de esquema. Quaisquer alterações no esquema para modelar conexões alteradas requerem tempo de inatividade e manutenção adicional da conversão da consulta para oferecer suporte ao novo esquema. Além disso, o desempenho da consulta é outra grande restrição a ser considerada ao projetar seus aplicativos.
Os bancos de dados de grafos podem simplificar muito essas situações. Livre de um esquema, uma camada de consulta de grafos avançada (Gremlin ou SPARQL) e índices otimizados para consultas de grafos aumentam a flexibilidade e o desempenho. O banco de dados de grafo Amazon Neptune também tem recursos corporativos, como a criptografia em repouso, uma camada de autorização segura, backups padrão, suporte a multi-AZ, suporte a réplicas de leitura e outros.
Usando AWS DMS, você pode migrar dados relacionais que modelam um gráfico altamente conectado para um endpoint de destino do Neptune a partir de um endpoint de origem do DMS para qualquer banco de dados SQL compatível.
Para obter mais detalhes, consulte as informações a seguir.
**Topics**
+ [Visão geral da migração para o Amazon Neptune como destino](#CHAP_Target.Neptune.MigrationOverview)
+ [Especificar as configurações do endpoint do Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings)
+ [Criar um perfil de serviço do IAM para acessar o Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole)
+ [Especificar regras de mapeamento de grafos utilizando Gremlin e R2RML para o Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping)
+ [Tipos de dados para migração de Gremlin e R2RML para o Amazon Neptune como destino](#CHAP_Target.Neptune.DataTypes)
+ [Limitações da utilização do Amazon Neptune como destino](#CHAP_Target.Neptune.Limitations)
## Visão geral da migração para o Amazon Neptune como destino
Antes de iniciar uma migração para um alvo do Neptune, crie os seguintes recursos em sua conta: AWS
+ Um cluster do Neptune para o endpoint de destino.
+ Um banco de dados relacional SQL suportado AWS DMS pelo endpoint de origem.
+ Um bucket do Amazon S3 para o endpoint de destino. Crie esse bucket do S3 na mesma AWS região do seu cluster Neptune. AWS DMS usa esse bucket do S3 como armazenamento intermediário de arquivos para os dados de destino que ele carrega em massa no banco de dados Neptune. Para obter mais informações sobre como criar um bucket do S3, consulte [Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html), no *Guia do usuário do Amazon Simple Storage Service*.
+ Um endpoint de nuvem privada virtual (VPC) para o S3 na mesma VPC que o cluster do Neptune.
+ Uma função AWS Identity and Access Management (IAM) que inclui uma política de IAM. Essa política deve especificar as permissões `GetObject`, `PutObject`, `DeleteObject` e `ListObject` para o bucket do S3 do endpoint de destino. Essa função é assumida por ambos AWS DMS e por Neptune com acesso do IAM ao bucket S3 de destino e ao banco de dados Neptune. Para obter mais informações, consulte [Criar um perfil de serviço do IAM para acessar o Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole).
Depois de ter esses recursos, a configuração e a inicialização de uma migração para um destino do Neptune é semelhante a qualquer migração de carga máxima utilizando o console ou a API do DMS. No entanto, uma migração para um destino do Neptune exige algumas etapas exclusivas.
**Para migrar um banco de dados AWS DMS relacional para o Neptune**
1. Crie uma instância de replicação conforme descrito em [Criar uma instância de replicação](CHAP_ReplicationInstance.Creating.md).
1. Crie e teste um banco de dados relacional SQL compatível AWS DMS com o endpoint de origem.
1. Crie e teste o endpoint de destino do banco de dados Neptune.
Para conectar o endpoint de destino ao banco de dados Neptune, especifique o nome do servidor para o endpoint do cluster do Neptune ou para o endpoint da instância do gravador do Neptune. Além disso, especifique a pasta de bucket do S3 AWS DMS para armazenar seus arquivos intermediários para carregamento em massa no banco de dados Neptune.
Durante a migração, AWS DMS armazena todos os dados de destino migrados nessa pasta de bucket do S3 até o tamanho máximo de arquivo especificado por você. Quando esse armazenamento de arquivos atinge esse tamanho máximo, carrega AWS DMS em massa os dados do S3 armazenados no banco de dados de destino. Ele limpará a pasta para ativar o armazenamento de quaisquer dados de destino adicionais para carregamento posterior no banco de dados de destino. Para obter mais informações sobre como especificar essas configurações, consulte [Especificar as configurações do endpoint do Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings).
1. Crie uma tarefa de replicação de carga máxima com os recursos criados nas etapas 1 a 3 e siga estas etapas:
1. Utilize o mapeamento da tabela de tarefas como de costume para identificar esquemas, tabelas e visualizações de origem específicos para migrar do banco de dados relacional utilizando as regras de seleção e de transformação apropriadas. Para obter mais informações, consulte [Utilizar o mapeamento de tabela para especificar as configurações da tarefa](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Especifique os mapeamentos de destino, escolhendo uma das opções a seguir para especificar as regras de mapeamento de tabelas e visualizações de origem para o grafo do banco de dados de destino do Neptune:
+ JSON do Gremlin: para obter informações sobre como utilizar o JSON do Gremlin para carregar um banco de dados Neptune, consulte [Formato de dados de carga do Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) no *Guia do usuário do Amazon Neptune*.
+ SPARQL RDB to Resource Description Framework Mapping Language (R2RML): para obter informações sobre como utilizar SPARQL R2RML, consulte a especificação do W3C [R2RML: RDB para a linguagem de mapeamento RDF](https://www.w3.org/TR/r2rml/).
1. Execute um dos seguintes procedimentos:
+ Usando o AWS DMS console, especifique as opções de mapeamento **gráfico usando as regras de mapeamento gráfico na página** **Criar tarefa de migração de banco de dados**.
+ Usando a AWS DMS API, especifique essas opções usando o parâmetro de `TaskData` solicitação da chamada da `CreateReplicationTask` API.
Para obter mais informações e exemplos que utilizam JSON de Gremlin e o SPARQL R2RML para especificar regras de mapeamento de grafos, consulte [Especificar regras de mapeamento de grafos utilizando Gremlin e R2RML para o Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping).
1. Iniciar a replicação para sua tarefa de migração.
## Especificar as configurações do endpoint do Amazon Neptune como destino
Para criar ou modificar um endpoint de destino, é possível usar o console `CreateEndpoint` ou as operações de API `ModifyEndpoint`.
**Para um alvo do Neptune no console, **especifique as configurações específicas AWS DMS do Endpoint na página Criar endpoint** **ou Modificar endpoint do** console.** Para `CreateEndpoint` e `ModifyEndpoint`, especifique os parâmetros de solicitação para a opção `NeptuneSettings`. O exemplo a seguir mostra como fazer isso utilizando a 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}‘
```
Aqui, a opção da CLI `--server-name` especifica o nome do servidor para o endpoint do gravador de cluster do Neptune. Ou é possível especificar o nome do servidor para um endpoint de instância do gravador do Neptune.
Os parâmetros de solicitação de opção `--neptune-settings` são:
+ `ServiceAccessRoleArn`: (obrigatório) o nome do recurso da Amazon (ARN) do perfil de serviço criado para o endpoint de destino do Neptune. Para obter mais informações, consulte [Criar um perfil de serviço do IAM para acessar o Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName`: (obrigatório) o nome do bucket do S3 em que o DMS pode armazenar temporariamente dados de grafo migrados em arquivos .csv antes de carregá-los em massa para o banco de dados de destino Neptune. O DMS mapeia os dados de origem SQL para dados de grafo antes de armazená-los nesses arquivos .csv.
+ `S3BucketFolder`: (obrigatório) o caminho de uma pasta em que você deseja que o DMS armazene dados de grafo migrados no bucket do S3 especificado por `S3BucketName`.
+ `ErrorRetryDuration`: (opcional) o número de milissegundos de espera do DMS para repetir uma carga de dados de grafo migrados para o banco de dados de destino Neptune antes de gerar um erro. O padrão é 250.
+ `MaxFileSize`: (opcional) o tamanho máximo em KB de dados de grafo migrados armazenados em um arquivo .csv antes que o DMS execute a carga em massa dos dados para o banco de dados de destino Neptune. O padrão é 1.048.576 KB (1 GB). Se for bem-sucedido, o DMS limpará o bucket, pronto para armazenar o próximo lote de dados de grafo migrados.
+ `MaxRetryCount`: (opcional) o número de vezes para o DMS repetir uma carga em massa de dados de grafo migrados para o banco de dados de destino do Neptune antes de gerar um erro. O padrão é 5.
+ `IAMAuthEnabled`: (opcional) se desejar a autorização do IAM ativada para esse endpoint, defina esse parâmetro como `ServiceAccessRoleArn` e anexe o documento de política do IAM apropriado ao perfil de serviço especificado por `true`. O padrão é `false`.
## Criar um perfil de serviço do IAM para acessar o Amazon Neptune como destino
Para acessar o Neptune como destino, crie um perfil de serviço utilizando o IAM. Dependendo da configuração do endpoint do Neptune, anexe a esse perfil alguns ou todos os documentos de confiança e de política do IAM. Ao criar o endpoint do Neptune, forneça o ARN desse perfil de serviço. Isso permite AWS DMS que o Amazon Neptune assuma permissões para acessar o Neptune e seu bucket Amazon S3 associado.
Se você definir o parâmetro `IAMAuthEnabled` em `NeptuneSettings` como `true` na configuração do endpoint do Neptune, anexe uma política do IAM como a seguinte ao perfil de serviço. Se definir `IAMAuthEnabled` como `false`, é possível ignorar esta política.
```
// 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/*"
}
]
}
```
A política do IAM anterior permite acesso total ao cluster de destino do Neptune especificado por `Resource`.
Anexe uma política do IAM como a seguinte ao perfil de serviço. Essa política permite que o DMS armazene temporariamente dados de grafos migrados no bucket do S3 criados para carregamento em massa no banco de dados de destino do 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/"
]
}
]
}
```
A política do IAM anterior permite que a sua conta consulte o conteúdo do bucket do S3 (`arn:aws:s3:::amzn-s3-demo-bucket`) criado para o destino do Neptune. Ela também permite que sua conta opere totalmente no conteúdo de todos os arquivos e pastas do bucket (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Edite a relação de confiança e anexe a seguinte função do IAM à sua função de serviço para permitir que tanto o serviço de banco de dados Amazon Neptune AWS DMS quanto o Amazon Neptune assumam a função.
------
#### [ 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"
}
]
}
```
------
Para obter informações sobre como especificar esse perfil de serviço para o endpoint de destino Neptune, consulte [Especificar as configurações do endpoint do Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings).
## Especificar regras de mapeamento de grafos utilizando Gremlin e R2RML para o Amazon Neptune como destino
As regras de mapeamento de grafos criadas especificam como os dados extraídos de uma origem de banco de dados relacional SQL são carregados em um destino de cluster de banco de dados Neptune. O formato dessas regras de mapeamento difere dependendo se as regras são para carregar dados do gráfico de propriedades usando o Apache TinkerPop Gremlin ou dados do Resource Description Framework (RDF) usando R2RML. A seguir, você encontrará informações sobre esses formatos e muito mais.
É possível especificar essas regras de mapeamento ao criar a tarefa de migração utilizando o console ou a API do DMS.
Utilizando o console, especifique essas regras de mapeamento utilizando **Regras de mapeamento de grafos** na página **Criar tarefa de migração de banco de dados**. Em **Regras de mapeamento de grafos**, é possível inserir e editar as regras de mapeamento diretamente utilizando o editor fornecido. Ou é possível procurar um arquivo que contenha as regras de mapeamento no formato apropriado de mapeamento de grafos.
Utilizando a API, especifique essas opções utilizando o parâmetro de solicitação `TaskData` da chamada de API `CreateReplicationTask`. Defina `TaskData` como o caminho de um arquivo que contém as regras de mapeamento no formato de mapeamento de grafos apropriado.
### Regras de mapeamento de grafos para geração de dados de grafo de propriedade utilizando o Gremlin
Utilizando o Gremlin para gerar os dados de grafos de propriedade, especifique um objeto JSON com uma regra de mapeamento para cada entidade de grafo a ser gerada dos dados de origem. O formato deste JSON é definido especificamente para carga em massa do Amazon Neptune. O modelo a seguir mostra como é cada regra nesse objeto:
```
{
"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)"
}
]
}
]
}
]
}
```
A presença de um rótulo de vértice implica que o vértice está sendo criado aqui. Sua ausência implica que o vértice está sendo criado por uma origem diferente, e essa definição está adicionando apenas propriedades de vértice. Especifique quantas definições de vértice e borda forem necessárias para especificar os mapeamentos para toda a origem do banco de dados relacional.
Veja a seguir uma regra de exemplo para uma tabela `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"
}
]
}
]
}
]
}
```
Aqui, as definições de vértice e borda mapeiam uma relação hierárquica de um nó `employee` com ID de funcionário (`EmpID`) e um nó `employee` com um ID de gerente (`managerId`).
Para obter mais informações sobre como criar regras de mapeamento de grafos utilizando JSON do Gremlin, consulte [Formato de dados de carga do Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) no *Guia do usuário do Amazon Neptune*.
### Regras de mapeamento gráfico para gerar dados RDF/SPARQL
Se você estiver carregando dados RDF a serem consultados utilizando SPARQL, grave as regras de mapeamento de grafos no R2RML. R2RML é uma linguagem W3C padrão de mapeamento de dados relacionais para RDF. Em um arquivo R2RML, um *mapa triplo* (por exemplo, `<#TriplesMap1>` a seguir) especifica uma regra para transformar cada linha de uma tabela lógica em RDF triplos. Um *mapa de assunto* (por exemplo, `rr:subjectMap` a seguir) especifica uma regra para gerar os assuntos dos RDF triplos gerados por um mapa triplo. Um *mapa de objeto de predicado* (por exemplo, qualquer `rr:predicateObjectMap` a seguir) é um perfil que cria um ou mais pares de objetos de predicado para cada linha de uma tabela lógica.
Segue um exemplo simples para uma tabela de `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" ];
]
```
No exemplo anterior, o mapeamento define nós de grafo mapeados a partir de uma tabela de funcionários.
Veja outro exemplo simples de tabela `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" ]
].
```
No exemplo anterior, o mapeamento define nós gráficos que friend-of-a-friend mapeiam relacionamentos entre pessoas em uma `Student` tabela.
Para obter mais informações sobre como criar regras de mapeamento de grafos utilizando SPARQL R2RML, consulte a especificação W3C [R2RML: RDB to RDF Mapping Language](https://www.w3.org/TR/r2rml/).
## Tipos de dados para migração de Gremlin e R2RML para o Amazon Neptune como destino
AWS DMS executa o mapeamento do tipo de dados do endpoint de origem do SQL para o destino do Neptune de duas maneiras. O modo utilizado depende do formato do mapeamento de grafos utilizado para carregar o banco de dados Neptune:
+ Apache TinkerPop Gremlin, usando uma representação JSON dos dados de migração.
+ SPARQL do W3C, utilizando uma representação R2RML dos dados de migração.
Para obter mais informações sobre esses dois formatos de mapeamento de grafos, consulte [Especificar regras de mapeamento de grafos utilizando Gremlin e R2RML para o Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping).
Veja a seguir descrições dos mapeamentos de tipos de dados para cada formato.
### Mapeamentos de tipos de dados de origem SQL para destino Gremlin
A tabela a seguir mostra os mapeamentos de tipos de dados de uma origem SQL para um destino Gremlin formatado.
AWS DMS mapeia qualquer tipo de dados de origem SQL não listado para um `String` Gremlin.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Neptune.html)
Para obter mais informações sobre os tipos de dados do Gremlin para carregamento do Neptune, consulte [Tipos de dados do Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) no *Guia do usuário do Neptune*.
### Mapeamentos de tipos de dados de origem SQL para destino R2RML (RDF)
A tabela a seguir mostra os mapeamentos de tipos de dados de uma origem SQL para um destino R2RML formatado.
Todos os tipos de dados RDF listados diferenciam maiúsculas de minúsculas, exceto RDF literal. AWS DMS mapeia qualquer tipo de dados de origem SQL não listado para um literal RDF.
Um *RDF literal* é uma de muitas formas e tipos de dados lexicais e literais. Para obter mais informações, consulte [RDF Literals](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) na especificação W3C *Resource Description Framework (RDF): conceitos e sintaxe abstrata*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Neptune.html)
Para obter mais informações sobre os tipos de dados RDF para carregamento do Neptune e de seus mapeamentos para tipos de dados de origem SQL, consulte [Conversões de tipo de dados](https://www.w3.org/TR/r2rml/#datatype-conversions) na especificação do *W3C R2RML: RDB para linguagem de mapeamento RDF*.
## Limitações da utilização do Amazon Neptune como destino
Aplicam-se as seguintes limitações ao utilizar o Neptune como destino:
+ AWS DMS atualmente suporta tarefas de carga total somente para migração para um destino de Neptune. A migração de captura de dados de alterações (CDC) para um destino do Neptune não é compatível.
+ Verifique se o banco de dados Neptune de destino é limpo manualmente de todos os dados antes de iniciar a tarefa de migração, como nos exemplos a seguir.
Para descartar todos os dados (vértices e bordas) dentro do grafo, execute o seguinte comando do Gremlin.
```
gremlin> g.V().drop().iterate()
```
Para descartar vértices com o rótulo `'customer'`, execute o seguinte comando do Gremlin.
```
gremlin> g.V().hasLabel('customer').drop()
```
**nota**
A remoção de um grande conjunto de dados pode levar algum tempo. Talvez você queira iterar `drop()` com uma limitação, por exemplo, `limit(1000)`.
Para descartar bordas com o rótulo `'rated'`, execute o seguinte comando do Gremlin.
```
gremlin> g.E().hasLabel('rated').drop()
```
**nota**
A remoção de um grande conjunto de dados pode levar algum tempo. Talvez você queira iterar `drop()` com uma limitação, por exemplo, `limit(1000)`.
+ A operação da API do DMS `DescribeTableStatistics` pode retornar resultados imprecisos sobre determinada tabela devido à natureza das estruturas de dados do grafo do Neptune.
Durante a migração, AWS DMS verifica cada tabela de origem e usa o mapeamento gráfico para converter os dados de origem em um gráfico de Netuno. Os dados convertidos são armazenados primeiro na pasta de bucket do S3 especificada para o endpoint de destino. Se a origem for verificada e esses dados intermediários do S3 forem gerados com êxito, `DescribeTableStatistics` pressupõe que os dados foram carregados com êxito no banco de dados de destino do Neptune. Entretanto, isso nem sempre é verdade. Para verificar se os dados foram carregados corretamente para determinada tabela, compare os valores de retorno `count()` nas extremidades da migração para essa tabela.
No exemplo a seguir, AWS DMS carregou uma `customer` tabela do banco de dados de origem, à qual é atribuído o rótulo `'customer'` no gráfico do banco de dados Neptune de destino. É possível certificar-se de que esse rótulo seja gravado no banco de dados de destino. Para isso, compare o número de linhas do `customer` disponíveis no banco de dados de origem com o número de linhas rotuladas do `'customer'` carregadas no banco de dados de destino do Neptune após a conclusão da tarefa.
Para obter o número de linhas disponíveis do cliente no banco de dados de origem utilizando SQL, execute o seguinte procedimento.
```
select count(*) from customer;
```
Para obter o número de linhas rotuladas `'customer'` carregadas no grafo do banco de dados de destino utilizando Gremlin, execute o seguinte procedimento.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Atualmente, se uma única tabela não for carregada, toda a tarefa falhará. Diferentemente de um banco de dados relacional de destino, os dados no Neptune são altamente conectados, o que torna impossível, em muitos casos, retomar uma tarefa. Se uma tarefa não puder ser retomada com êxito devido a esse tipo de falha de carga de dados, crie uma nova tarefa para carregar a tabela que apresentou falha no carregamento. Antes de executar essa nova tarefa, limpe manualmente a tabela parcialmente carregada do destino do Neptune.
**nota**
É possível retomar uma tarefa com falha na migração para um destino do Neptune se a falha for recuperável (por exemplo, um erro de trânsito de rede).
+ AWS DMS suporta a maioria dos padrões para R2RML. No entanto, AWS DMS não é compatível com determinados padrões R2RML, incluindo expressões inversas, junções e visualizações. Uma solução alternativa para uma exibição R2RML é criar uma exibição SQL personalizada correspondente no banco de dados de origem. Na tarefa de migração, utilize o mapeamento de tabela para escolher a exibição como entrada. Mapeie a exibição para uma tabela que seja então consumida pelo R2RML para gerar dados de grafo.
+ Ao migrar dados de origem com tipos de dados SQL não é compatível com dos, os dados de destino resultantes podem ter perda de precisão. Para obter mais informações, consulte [Tipos de dados para migração de Gremlin e R2RML para o Amazon Neptune como destino](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS não suporta a migração de dados LOB para um destino do Neptune.
# Usando o Redis OSS como alvo para AWS Database Migration Service
O Redis OSS é um armazenamento de estrutura de dados de código aberto em memória utilizado como um banco de dados, cache e agente de mensagens. O gerenciamento de dados na memória pode resultar em operações de leitura ou gravação que demoram menos de um milissegundo e centenas de milhões de operações executadas a cada segundo. Como um datastore em memória, o Redis OSS capacita as aplicações que exigem tempos de resposta inferiores a um milissegundo.
Usando AWS DMS, você pode migrar dados de qualquer banco de dados de origem compatível para um armazenamento de dados Redis OSS de destino com o mínimo de tempo de inatividade. Para ter informações adicionais sobre o Redis OSS, consulte a [documentação do Redis OSS](https://redis.io/documentation).
Além do Redis OSS local, AWS Database Migration Service oferece suporte ao seguinte:
+ [Amazon ElastiCache (Redis OSS) como armazenamento](https://aws.amazon.com/elasticache/redis/) de dados de destino. ElastiCache (Redis OSS) trabalha com seus clientes do Redis OSS e usa o formato de dados aberto do Redis OSS para armazenar seus dados.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) como datastore de destino. O MemoryDB é compatível com o Redis OSS e permite que você crie aplicativos usando todas as estruturas de dados e comandos do Redis OSS em uso atualmente APIs.
Para obter informações adicionais sobre como trabalhar com o Redis OSS como alvo AWS DMS, consulte as seções a seguir:
**Topics**
+ [Pré-requisitos para usar um cluster Redis OSS como destino para AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Limitações ao usar o Redis como alvo para AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migrar dados de um banco de dados relacional ou não relacional para um destino do Redis OSS](#CHAP_Target.Redis.Migrating)
+ [Especificar as configurações de endpoint para o Redis OSS como destino](#CHAP_Target.Redis.EndpointSettings)
## Pré-requisitos para usar um cluster Redis OSS como destino para AWS DMS
O DMS é compatível com um destino do Redis OSS on-premises em uma configuração independente ou como um cluster do Redis OSS em que os dados são automaticamente *fragmentados* em vários nós. A fragmentação é o processo de separar os dados em blocos menores, chamados de fragmentos, que são espalhados por vários servidores ou nós. Na verdade, um fragmento é uma partição de dados que contém um subconjunto do conjunto total de dados e serve como uma fatia da workload geral.
Como o Redis OSS é um datastore NoSQL de chave/valor, a convenção de nomenclatura de chaves do Redis OSS a ser utilizada quando a origem for um banco de dados relacional é **schema-name.table-name.primary-key**. No Redis OSS, a chave e o valor não devem conter o caractere especial %. Caso contrário, o DMS ignorará o registro.
**nota**
Se você estiver usando ElastiCache (Redis OSS) como destino, o DMS suporta somente configurações *habilitadas para o modo de cluster*. Para obter mais informações sobre o uso do ElastiCache (Redis OSS) versão 6.x ou superior para criar um armazenamento de dados de destino habilitado para o modo de cluster, consulte [Introdução](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) no Guia do usuário da *Amazon ElastiCache (Redis OSS*).
Antes de começar a migração de um banco de dados, inicie o cluster do Redis OSS com os seguintes critérios.
+ O cluster tem um ou mais fragmentos.
+ Se você estiver usando um destino ElastiCache (Redis OSS), certifique-se de que seu cluster não use o controle de acesso baseado em funções do IAM. Em vez disso, utilize o Redis OSS Auth para autenticar usuários.
+ Ative multi-AZ (zonas de disponibilidade).
+ Verifique se o cluster tem memória suficiente disponível para comportar os dados a serem migrados do banco de dados.
+ Verifique se todos os dados do cluster do Redis OSS de destino estão limpos antes de iniciar a tarefa de migração inicial.
Determine os requisitos de segurança da migração de dados antes de criar a configuração do cluster. O DMS é compatível com a migração para grupos de replicação de destino, independentemente de sua configuração de criptografia. Mas é possível ativar ou desativar a criptografia somente ao criar a configuração do cluster.
## Limitações ao usar o Redis como alvo para AWS Database Migration Service
Aplicam-se as seguintes limitações ao utilizar o Redis OSS como destino:
+ Como o Redis OSS é um datastore no-sql de chave/valor, a convenção de nomenclatura de chaves do Redis OSS a ser utilizada quando a origem for um banco de dados relacional é `schema-name.table-name.primary-key`.
+ No Redis OSS, a chave/valor não pode conter o caractere especial `%`. Caso contrário, o DMS ignorará o registro.
+ O DMS não migrará linhas que contenham o caractere `%`.
+ O DMS não migrará campos que contenham o caractere `%` no nome do campo.
+ O modo Full LOB não é compatível.
+ Não há suporte para uma Autoridade de Certificação (CA) privada ao usar ElastiCache (Redis OSS) como destino.
+ AWS DMS não oferece suporte a dados de origem contendo `'\0'` caracteres incorporados ao usar o Redis como um endpoint de destino. Os dados contendo `'\0'` caracteres incorporados serão truncados no primeiro `'\0'` caractere.
## Migrar dados de um banco de dados relacional ou não relacional para um destino do Redis OSS
É possível migrar dados de qualquer datastore SQL ou NoSQL de origem diretamente para um destino do Redis OSS. A configuração e o início de uma migração para um destino do Redis OSS é semelhante a qualquer migração de carga máxima e de captura de dados de alteração utilizando o console ou a API do DMS. Para executar uma migração de banco de dados para um destino do Redis OSS, faça o seguinte.
+ Crie uma instância de replicação para executar todos os processos da migração. Para obter mais informações, consulte [Criar uma instância de replicação](CHAP_ReplicationInstance.Creating.md).
+ Especifique um endpoint de origem. Para obter mais informações, consulte [Criar endpoints de origem e de destino](CHAP_Endpoints.Creating.md).
+ Localize o nome DNS e o número da porta do cluster.
+ Baixe um pacote de certificado que pode ser utilizado para verificar conexões SSL.
+ Especifique um endpoint de destino, conforme descrito abaixo.
+ Crie uma tarefa ou um conjunto de tarefas para definir as tabelas e os processos de replicação a serem utilizados. Para obter mais informações, consulte [Criar uma tarefa](CHAP_Tasks.Creating.md).
+ Migre dados do banco de dados de origem para o cluster de destino.
Você inicia uma migração do banco de dados de uma duas maneiras:
1. Você pode escolher o AWS DMS console e executar cada etapa lá.
1. Você pode usar o AWS Command Line Interface (AWS CLI). [Para obter mais informações sobre como usar a CLI com AWS DMS, consulte AWS CLI . AWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)
**Como localizar o nome DNS e o número da porta do cluster**
+ Use o AWS CLI comando a seguir para `replication-group-id` fornecer o nome do seu grupo de replicação.
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Aqui, a saída mostra o nome DNS no atributo `Address` e o número da porta no atributo `Port` do nó primário no cluster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Se estiver utilizando o MemoryDB como destino, utilize o comando da AWS CLI a seguir para fornecer um endereço de endpoint ao cluster do Redis OSS.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Baixe um pacote de certificado a ser utilizado para verificar as conexões SSL.**
+ Insira o comando `wget` na linha de comando. O Wget é uma ferramenta utilitária de linha de comando GNU gratuita utilizada para baixar arquivos na internet.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Aqui, `aws-api-domain` preenche o domínio do Amazon S3 em AWS sua região necessário para acessar o bucket do S3 especificado e rds-combined-ca-bundle o arquivo.pem que ele fornece.
**Para criar um endpoint de destino usando o console AWS DMS**
Esse endpoint é para o destino do Redis OSS que já está em execução.
+ No console, escolha **Endpoints** no painel de navegação e escolha **Criar endpoint**. A tabela a seguir descreve as configurações.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Redis.html)
Depois de você concluir o fornecimento de todas as informações do endpoint, o AWS DMS cria o endpoint de destino do Redis OSS para utilização durante a migração do banco de dados.
Para obter informações sobre como criar uma tarefa de migração e iniciar a migração do banco de dados, consulte [Criar uma tarefa](CHAP_Tasks.Creating.md).
## Especificar as configurações de endpoint para o Redis OSS como destino
Para criar ou modificar um endpoint de destino, é possível usar o console `CreateEndpoint` ou as operações de API `ModifyEndpoint`.
**Para um destino do Redis OSS no AWS DMS console, especifique as **configurações específicas do endpoint na página Criar endpoint** **ou Modificar o console do endpoint**.**
Ao utilizar as operações da API `CreateEndpoint` e `ModifyEndpoint`, especifique os parâmetros de solicitação para a opção `RedisSettings`. O exemplo a seguir mostra como fazer isso utilizando a 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"
}
}
}
```
Os parâmetros `--redis-settings` são os seguintes:
+ `ServerName`: (obrigatório) do tipo `string`, especifica o cluster do Redis OSS para o qual os dados serão migrados e está na sua mesma VPC.
+ `Port`: (obrigatório) do tipo `number`, o valor da porta utilizada para acessar o endpoint.
+ `SslSecurityProtocol`: (opcional) os valores válidos incluem `plaintext` e `ssl-encryption`. O padrão é `ssl-encryption`.
A opção `plaintext` não fornece a criptografia Transport Layer Security (TLS) para o tráfego entre o endpoint e o banco de dados.
Utilize `ssl-encryption` para fazer uma conexão criptografada. `ssl-encryption` não exige o ARN de uma Autoridade de Certificação (CA) SSL para verificar o certificado de um servidor, mas um pode ser identificado opcionalmente utilizando a configuração `SslCaCertificateArn`. Se o ARN de autoridade de certificação não for fornecido, o DMS utilizará a CA raiz da Amazon.
Ao utilizar um destino do Redis OSS on-premises, é possível utilizar `SslCaCertificateArn` para importar a Autoridade de Certificação (CA) pública ou privada para o DMS e fornecer esse ARN para autenticação do servidor. Não há suporte para uma CA privada ao usar ElastiCache (Redis OSS) como destino.
+ `AuthType`: (obrigatório) indica o tipo de autenticação a ser executada ao conectar-se ao Redis OSS. Os valores válidos são `none`, `auth-token` e `auth-role`.
A `auth-token` opção exige que um "*AuthPassword*" seja fornecido, enquanto a `auth-role` opção exige que *AuthUserName* "" e *AuthPassword* "” sejam fornecidos.
# Usando o Babelfish como alvo para AWS Database Migration Service
Você pode migrar dados de um banco de dados de origem do Microsoft SQL Server para um destino do Babelfish usando o. AWS Database Migration Service
O Babelfish for Aurora PostgreSQL amplia seu banco de dados Amazon Aurora, edição compatível com PostgreSQL, com a capacidade de aceitar conexões de banco de dados provenientes de clientes Microsoft SQL Server. Fazer isso permite que aplicações originalmente criadas para o SQL Server funcionem diretamente com o Aurora PostgreSQL, com poucas alterações de código em comparação com uma migração tradicional e sem alterar drivers de bancos de dados.
Para obter informações sobre as versões do Babelfish que são AWS DMS suportadas como alvo, consulte. [Metas para AWS DMS](CHAP_Introduction.Targets.md) As versões anteriores do Babelfish no Aurora PostgreSQL exigem um upgrade antes de utilizar o endpoint do Babelfish.
**nota**
O endpoint de destino do Aurora PostgreSQL é a forma preferida de migrar dados para o Babelfish. Para obter mais informações, consulte [Utilizar o Babelfish para Aurora PostgreSQL como destino](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
Para obter informações sobre como utilizar o Babelfish como um endpoint de banco de dados, consulte [Babelfish para Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) no *Guia do usuário do Amazon Aurora para Aurora*
## Pré-requisitos para usar o Babelfish como alvo para AWS DMS
Você deve criar suas tabelas antes de migrar dados para garantir que AWS DMS usa os tipos de dados e metadados de tabela corretos. Se você não criar suas tabelas no destino antes de executar a migração, AWS DMS poderá criar as tabelas com tipos de dados e permissões incorretos. Por exemplo, em vez disso, AWS DMS cria uma coluna de carimbo de data/hora como binária (8) e não fornece a funcionalidade esperada timestamp/rowversion .
**Como preparar e criar as tabelas antes da migração**
1. Execute as instruções DDL de criação de tabela que incluam quaisquer restrições exclusivas, chaves primárias ou restrições padrão.
Não inclua restrições de chave estrangeira nem instruções DDL para objetos, como visualizações, procedimentos armazenados, perfis ou acionadores. É possível aplicá-las depois de migrar o banco de dados de origem.
1. Identifique quaisquer colunas de identidade, colunas computadas ou colunas contendo tipos de dados rowversion ou timestamp nas tabelas. Crie as regras de transformação necessárias para lidar com problemas conhecidos ao executar a tarefa de migração. Para ter mais informações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifique colunas com tipos de dados não compatíveis com o Babelfish. Altere as colunas afetadas na tabela de destino para utilizar os tipos de dados compatíveis ou crie uma regra de transformação que os remova durante a tarefa de migração. Para ter mais informações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
A tabela a seguir lista os tipos de dados de origem não compatíveis com o Babelfish e o tipo de dados de destino recomendado correspondente a ser utilizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Babelfish.html)
**Para definir o nível de unidades de capacidade do Aurora (ACUs) para seu banco de dados de origem do Aurora PostgreSQL Serverless V2**
Você pode melhorar o desempenho da sua tarefa de AWS DMS migração antes de executá-la definindo o valor mínimo de ACU.
+ Na janela de **configurações de capacidade do Severless v2**, ACUs defina **Mínimo** **2** ou um nível razoável para seu cluster de banco de dados Aurora.
Para obter mais informações sobre as unidades de capacidade do Aurora, consulte [Escolher o intervalo de capacidade do Aurora Sem Servidor v2 para um cluster do Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html) no *Guia do usuário do Amazon Aurora*.
Depois de executar sua tarefa de AWS DMS migração, você pode redefinir o valor mínimo ACUs para um nível razoável para seu banco de dados de origem do Aurora PostgreSQL Serverless V2.
## Requisitos de segurança ao usar o Babelfish como alvo para AWS Database Migration Service
O seguinte descreve os requisitos de segurança para uso AWS DMS com um alvo Babelfish:
+ O nome de usuário do administrador (o usuário administrador) utilizado para criar o banco de dados.
+ Login e usuário do PSQL com permissões suficientes para SELECT, INSERT, UPDATE, DELETE e REFERENCES.
## Permissões de usuário para usar o Babelfish como alvo para AWS DMS
**Importante**
Para fins de segurança, a conta de usuário utilizada para a migração de dados deve ser um usuário registrado em qualquer banco de dados Babelfish que você utilize como destino.
O endpoint de destino do Babelfish requer permissões mínimas de usuário para executar uma migração do AWS DMS .
**Como criar um login e um usuário do Transact-SQL (T-SQL) com poucos privilégios**
1. Crie um login e uma senha a serem utilizados ao se conectar ao servidor.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Crie o banco de dados virtual para o cluster do Babelfish.
```
CREATE DATABASE my_database;
GO
```
1. Crie o usuário T-SQL para o banco de dados de destino.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Para cada tabela no banco de dados Babelfish, permissões de GRANT para as tabelas.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Limitações no uso do Babelfish como alvo para AWS Database Migration Service
As seguintes limitações se aplicam à utilização de um banco de dados Babelfish como destino do AWS DMS:
+ Somente o modo de preparação de tabela “**Não executar nenhuma ação**” é compatível.
+ O tipo de dados ROWVERSION exige uma regra de mapeamento de tabela que remove o nome da coluna da tabela durante a tarefa de migração.
+ O tipo de dados sql\$1variant não é compatível.
+ O modo LOB completo é compatível. Usar o SQL Server como um endpoint de origem exige que a configuração `ForceFullLob=True` do Atributo de Conexão do Endpoint do SQL Server seja definida para LOBs ser migrada para o endpoint de destino.
+ As configurações da tarefa de replicação têm as seguintes limitações:
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Os tipos de dados TIME DATETIME2 (7), (7) e DATETIMEOFFSET (7) no Babelfish limitam o valor de precisão da parte de segundos do tempo a 6 dígitos. Considere utilizar um valor de precisão de seis para a tabela de destino ao utilizar esses tipos de dados. Para as versões 2.2.0 e superiores do Babelfish, ao usar TIME (7) e DATETIME2 (7), o sétimo dígito de precisão é sempre zero.
+ No modo DO\$1NOTHING, o DMS verifica se a tabela já existe. Se a tabela não existir no esquema de destino, o DMS criará a tabela com base na definição da tabela de origem e mapeará todos os tipos de dados definidos pelo usuário para o tipo de dados base.
+ Uma tarefa de AWS DMS migração para um destino do Babelfish não suporta tabelas que tenham colunas usando os tipos de dados ROWVERSION ou TIMESTAMP. É possível utilizar uma regra de mapeamento de tabela que remove o nome da coluna da tabela durante o processo de transferência. No exemplo de regra de transformação a seguir, uma tabela nomeada `Actor` na origem é transformada para remover todas as colunas que começam com os caracteres `Actor` da tabela `col` no destino.
```
{
"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%"
}
}]
}
```
+ Para tabelas com colunas de identidade ou computadas, em que as tabelas de destino utilizam nomes com maiúsculas e minúsculas, como Categorias, crie uma ação de regra de transformação que converta os nomes das tabelas em minúsculas para a tarefa do DMS. O exemplo a seguir mostra como criar a ação da regra de transformação, **Make lowercase**, usando o AWS DMS console. Para obter mais informações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Regra de transformação do Babelfish\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Antes da versão 2.2.0 do Babelfish, o DMS limitava o número de colunas que você podia replicar para um endpoint de destino do Babelfish a vinte colunas. Com o Babelfish 2.2.0, o limite aumentou para cem colunas. Mas com as versões 2.4.0 e superiores do Babelfish, o número de colunas que é possível replicar aumenta novamente. É possível executar o exemplo de código a seguir no banco de dados SQL Server para determinar quais tabelas são muito longas.
```
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
;
```
## Tipos de dados de destino do Babelfish
A tabela a seguir mostra os tipos de dados de destino do Babelfish que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados.
Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS DMS tipo de dados | Tipo de dados do Babelfish |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY(tamanho) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC(p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | Se a coluna for de data ou hora, faça o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Babelfish.html) Se a coluna não é uma data ou hora, use VARCHAR (tamanho). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(tamanho) |
| BLOB | VARBINARY(máximo) Para usar esse tipo de dados com o DMS, você deve habilitar o uso de BLOBs para uma tarefa específica. O DMS é compatível com os tipos de dados BLOB somente em tabelas que possuem uma chave primária. |
| CLOB | VARCHAR(máximo) Para usar esse tipo de dados com o DMS, você deve habilitar o uso de CLOBs para uma tarefa específica. |
| NCLOB | NVARCHAR(máximo) Para usar esse tipo de dados com o DMS, você deve habilitar o uso de NCLOBs para uma tarefa específica. Durante a CDC, o DMS é compatível com os tipos de dados NCLOB somente em tabelas que incluem uma chave primária. |
# Usando o Amazon Timestream como alvo para AWS Database Migration Service
Você pode usar AWS Database Migration Service para migrar dados do seu banco de dados de origem para um endpoint de destino do Amazon Timestream, com suporte para migrações de dados Full Load e CDC.
O Amazon Timestream é um serviço de banco de dados de séries temporais rápido, escalável e sem servidor criado para ingestão de dados de alto volume. Dados de séries temporais são uma sequência de pontos de dados coletados em um intervalo de tempo; eles são usados para medir eventos que mudam com o tempo. Ele é usado para coletar, armazenar e analisar métricas de aplicativos, DevOps aplicativos e aplicativos de análise de IoT. Assim que seus dados estiverem no Timestream, você poderá visualizar e identificar tendências e padrões nesses dados quase em tempo real. Para obter mais informações sobre o Amazon Timestream, consulte [What is Amazon Timestream?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) no *Guia do desenvolvedor do Amazon Timestream*.
**Topics**
+ [Pré-requisitos para usar o Amazon Timestream como alvo para AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Configurações da tarefa de carga máxima com vários threads](#CHAP_Target.Timestream.FLTaskSettings)
+ [Configurações da tarefa de carga de CDC multithread](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Configurações de endpoint ao usar o Timestream como destino para AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Criar e modificar um endpoint de destino do Amazon Timestream](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Utilizar o mapeamento de objetos para migrar dados para um tópico do Timestream](#CHAP_Target.Timestream.ObjectMapping)
+ [Limitações ao usar o Amazon Timestream como alvo para AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Pré-requisitos para usar o Amazon Timestream como alvo para AWS Database Migration Service
Antes de configurar o Amazon Timestream como destino AWS DMS para, certifique-se de criar uma função do IAM. Essa função deve permitir AWS DMS o acesso aos dados que estão sendo migrados para o Amazon Timestream. O conjunto mínimo de permissões de acesso para o perfil que você usa para migrar para o Timestream é mostrado na política do IAM a seguir.
------
#### [ 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 você pretende migrar todas as tabelas, use `*` for *TABLE\$1NAME* no exemplo acima.
Observe o seguinte sobre o uso do Timestream como destino:
+ Se você pretende ingerir dados históricos com carimbos de data e hora superiores a um ano, recomendamos usar o AWS DMS para gravar os dados no Amazon S3 em um formato de valor separado por vírgula (csv). Em seguida, use o carregamento em lote do Timestream para ingerir os dados no Timestream. Para obter mais informações, consulte [Using batch load in Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) no [Guia do desenvolvedor do Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Para migrações de carga máxima de dados com menos de um ano, recomendamos definir o período de retenção do armazenamento de memória da tabela do Timestream com um valor superior ou igual ao carimbo de data e hora mais antigo. Depois que a migração for concluída, mude a retenção do armazenamento de memória da tabela para o valor desejado. Por exemplo, para migrar dados quando o carimbo de data e hora mais antigo é de dois meses, faça o seguinte:
+ Defina a retenção do armazenamento de memória da tabela de destino do Timestream para dois meses.
+ Inicie a migração de dados usando AWS DMS o.
+ Quando a migração de dados for concluída, altere o período de retenção da tabela do Timestream de destino para o valor desejado.
Recomendamos estimar o custo do armazenamento de memória antes da migração, usando as informações nas seguintes páginas:
+ [Amazon Timestream pricing](https://aws.amazon.com/timestream/pricing)
+ [AWS calculadora de preços](https://calculator.aws/#/addService)
+ Para migrações de dados de CDC, recomendamos definir o período de retenção do armazenamento de memória da tabela de destino de forma que os dados ingeridos estejam dentro dos limites de retenção do armazenamento de memória. Para obter mais informações, consulte [Best Practices: Writes](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) no [Guia do desenvolvedor do Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Configurações da tarefa de carga máxima com vários threads
Para ajudar a aumentar a velocidade da transferência de dados, AWS DMS oferece suporte a uma tarefa de migração de carga total multiencadeada para um endpoint de destino do Timestream com estas configurações de tarefa:
+ `MaxFullLoadSubTasks`: utilize esta opção para indicar o número máximo de tabelas de origem a serem carregadas em paralelo. O DMS carrega cada tabela na tabela de destino correspondente do Amazon Timestream usando uma subtarefa dedicada. O padrão é 8; o valor máximo é 49.
+ `ParallelLoadThreads`— Use essa opção para especificar o número de threads AWS DMS usados para carregar cada tabela em sua tabela de destino do Amazon Timestream. O valor máximo de um destino do Timestream é 32. Você pode solicitar o aumento desse limite máximo.
+ `ParallelLoadBufferSize`: utilize esta opção para especificar o número máximo de registros a serem armazenados no buffer utilizado pelos threads de carregamento paralelo para carregar dados no destino do Amazon Timestream. O valor padrão é 50. Valor máximo de 1.000. Use essa configuração com `ParallelLoadThreads`; `ParallelLoadBufferSize` é válido somente quando há mais de um thread.
+ `ParallelLoadQueuesPerThread`: utilize esta opção para especificar o número de filas que cada thread simultâneo acessa para extrair registros de dados das filas e gerar uma carga em lote para o destino. O padrão é um. No entanto, para destinos do Amazon Timestream de vários tamanhos de carga útil, o intervalo válido é de 5 a 512 filas por thread.
## Configurações da tarefa de carga de CDC multithread
Para promover o desempenho do CDC, AWS DMS oferece suporte a estas configurações de tarefas:
+ `ParallelApplyThreads`— Especifica o número de threads simultâneos AWS DMS usados durante o carregamento do CDC para enviar registros de dados para um endpoint de destino do Timestream. O valor padrão é 0 e o valor máximo é 32.
+ `ParallelApplyBufferSize`: especifica o número máximo de registros a serem armazenados em cada fila de buffer para os threads simultâneos enviarem a um endpoint de destino do Timestream durante uma carga de CDC. O valor padrão é 100 e o valor máximo é 1.000. Use essa opção quando `ParallelApplyThreads` especificar mais de um thread.
+ `ParallelApplyQueuesPerThread`: especifica o número de filas que cada thread acessa para extrair registros de dados das filas e gerar um carregamento em lote para um endpoint do Timestream durante a CDC. O valor padrão é 1 e o valor máximo é 512.
## Configurações de endpoint ao usar o Timestream como destino para AWS DMS
É possível utilizar as configurações de endpoint para configurar o banco de dados de destino do Timestream de forma semelhante à utilização de atributos de conexão adicional. Você especifica as configurações ao criar o endpoint de destino usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--timestream-settings '{"EndpointSetting": "value", ...}'` JSON.
A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o Timestream como destino.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Target.Timestream.html)
## Criar e modificar um endpoint de destino do Amazon Timestream
Depois de criar uma função do IAM e estabelecer o conjunto mínimo de permissões de acesso, você pode criar um endpoint de destino do Amazon Timestream usando AWS DMS o console ou usando o comando no, com `create-endpoint` a sintaxe [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
Os exemplos a seguir mostram como criar e modificar um endpoint de destino do Timestream usando a AWS CLI.
**Criar comando do endpoint de destino do 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,
}
```
**Modificar comando do endpoint de destino do 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,
}
```
## Utilizar o mapeamento de objetos para migrar dados para um tópico do Timestream
AWS DMS usa regras de mapeamento de tabela para mapear dados da fonte para o tópico do Timestream de destino. Para mapear dados para um tópico de destino, utilize um tipo de regra de mapeamento de tabelas chamado mapeamento de objetos. Utilize o mapeamento de objetos para definir como os registros de dados na origem são correlacionados com os registros de dados publicados em um tópico do Timestream.
Os tópicos do Timestream não têm uma estrutura predefinida, exceto uma chave de partição.
**nota**
Não é necessário utilizar o mapeamento de objetos. É possível utilizar o mapeamento de tabela normal para várias transformações. No entanto, o tipo de chave de partição seguirá estes comportamentos padrão:
A chave primária é utilizada como uma chave de partição para a carga máxima.
Se nenhuma configuração de tarefas de aplicação paralela for utilizada, `schema.table` será usada como uma chave de partição para a CDC.
Se as configurações de tarefas de aplicação paralela forem utilizadas, a chave primária será utilizada como uma chave de partição para a CDC.
Para criar uma regra de mapeamento de objetos, especifique `rule-type` como `object-mapping`. Essa regra especifica o tipo de mapeamento de objeto que você deseja usar. A estrutura da regra é a seguinte:
```
{
"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 atualmente suporta `map-record-to-record` e `map-record-to-document` como os únicos valores válidos para o `rule-action` parâmetro. Os `map-record-to-document` valores `map-record-to-record` e especificam o que AWS DMS acontece por padrão com registros que não são excluídos como parte da lista de `exclude-columns` atributos. Esses valores não afetam os mapeamentos de atributos de forma alguma.
Utilize `map-record-to-record` ao migrar de um banco de dados relacional para um tópico do Timestream. Esse tipo de regra utiliza o valor `taskResourceId.schemaName.tableName` encontrado no banco de dados relacional como a chave de partição no tópico do Timestream e cria um atributo para cada coluna no banco de dados de origem. Ao usar`map-record-to-record`, para qualquer coluna na tabela de origem não listada na lista de `exclude-columns` atributos, AWS DMS cria um atributo correspondente no tópico de destino. Este atributo correspondente é criado, independentemente de a coluna de origem ser usada ou não em um mapeamento de atributos.
Uma maneira de compreender o `map-record-to-record` é vê-lo em ação. Para este exemplo, suponha que você está começando com uma linha de tabela do banco de dados relacional com a seguinte estrutura de dados:
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 29/02/1988 |
Para migrar essas informações de um esquema chamado `Test` para um tópico do Timestream, crie regras para correlacionar os dados com o tópico de destino. A regra a seguir ilustra o mapeamento.
```
{
"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"
}
}
]
}
```
Com um tópico do Timestream e uma chave de partição determinados (neste caso, `taskResourceId.schemaName.tableName`), o seguinte ilustra o formato do registro resultante utilizando os nossos exemplos de dados no tópico de destino do Timestream:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Limitações ao usar o Amazon Timestream como alvo para AWS Database Migration Service
As seguintes limitações se aplicam ao utilizar o Amazon Timestream como destino:
+ **Dimensões e carimbos de data e hora**: o Timestream usa as dimensões e os carimbos de data e hora nos dados de origem como uma chave primária composta e também não permite que você altere esses valores. Isso significa que, se você alterar o carimbo de data e hora ou as dimensões de um registro no banco de dados de origem, o banco de dados do Timestream tentará criar um registro. Portanto, é possível que, se você alterar a dimensão ou o timestamp de um registro de forma que correspondam aos de outro registro existente, AWS DMS atualize os valores do outro registro em vez de criar um novo registro ou atualizar o registro correspondente anterior.
+ **Comandos DDL:** A versão atual AWS DMS só suporta `CREATE TABLE` e comandos `DROP TABLE` DDL.
+ **Limitações de registro**: o Timestream tem limitações para registros, como tamanho do registro e tamanho da medida. Para obter mais informações, consulte [Cotas](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) no [Guia do desenvolvedor do Amazon Timestream](https://docs.aws.amazon.com/).
+ **Exclusão de registros e valores nulos**: o Timestream não comporta exclusão de registros. Para oferecer suporte à migração de registros excluídos da fonte, AWS DMS limpa os campos correspondentes nos registros no banco de dados de destino do Timestream. AWS DMS altera os valores nos campos do registro de destino correspondente com **0** para campos numéricos, **nulo** para campos de texto e **falso** para campos booleanos.
+ O Timestream como destino não aceita origens que não sejam bancos de dados relacionais (RDBMS).
+ AWS DMS só oferece suporte ao Timestream como destino nas seguintes regiões:
+ Leste dos EUA (Norte da Virgínia)
+ Leste dos EUA (Ohio)
+ Oeste dos EUA (Oregon)
+ Europa (Irlanda)
+ Europa (Frankfurt)
+ Ásia-Pacífico (Sydney)
+ Ásia-Pacífico (Tóquio)
+ O Timestream como destino não aceita que a configuração de `TargetTablePrepMode` como `TRUNCATE_BEFORE_LOAD`. É recomendável não usar essa configuração.
# Usando o Amazon RDS para Db2 e o IBM Db2 LUW como destino para AWS DMS
Você pode migrar dados para um Amazon RDS for Db2 ou um banco de dados Db2 local de um banco de dados Db2 LUW usando (). AWS Database Migration Service AWS DMS
Para obter informações sobre as versões do Db2 LUW que oferecem AWS DMS suporte como destino, consulte. [Metas para AWS DMS](CHAP_Introduction.Targets.md)
É possível utilizar SSL para criptografar conexões entre o endpoint do Db2 LUW e a instância de replicação. Para obter mais informações sobre a utilização de SSL com um endpoint do Db2 LUW, consulte [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md).
## Limitações ao usar o Db2 LUW como destino para AWS DMS
As limitações a seguir se aplicam ao usar o banco de dados Db2 LUW como destino para. AWS DMS Para conhecer as limitações de uso do Db2 LUW como origem, consulte [Limitações ao usar o Db2 LUW como fonte para AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations).
+ AWS DMS só oferece suporte ao Db2 LUW como destino quando a origem é Db2 LUW ou Db2 for z/OS.
+ Quando usado como destino, o Db2 LUW não comporta replicações com o modo LOB completo.
+ Ele também não comporta o tipo de dados XML na fase de carregamento completo. Essa é uma limitação do utilitário dbload da IBM. Para obter mais informações, consulte [IBM ](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) na documentação *IBM Informix Servers*.
+ AWS DMS trunca campos BLOB com valores correspondentes ao caractere de aspas duplas (“). Essa é uma limitação do utilitário dbload da IBM.
+ AWS DMS não suporta a opção parallel full load ao migrar para um destino Db2 LUW no DMS versão 3.5.3. Essa opção está disponível no DMS versão 3.5.4 ou posterior.
## Configurações de endpoint ao usar o Db2 LUW como destino para AWS DMS
É possível utilizar as configurações de endpoint para configurar o destino do Db2 LUW de maneira semelhante à utilização de atributos de conexão adicional. Você especifica as configurações ao criar o endpoint de destino usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--ibm-db2-settings '{"EndpointSetting": "value", ...}'` JSON.
A tabela a seguir mostra as configurações de endpoints que é possível utilizar com o Db2 LUX como destino.
| Name (Nome) | Description |
| --- | --- |
| `KeepCsvFiles` | Se verdadeiro, AWS DMS salva todos os arquivos.csv no destino Db2 LUW que foram usados para replicar dados. O DMS usa esses arquivos para análise e solução de problemas. |
| `LoadTimeout` | A quantidade de tempo (em milissegundos) antes do AWS DMS tempo limite das operações executadas pelo DMS no destino do Db2. O valor padrão é 1.200 (20 minutos). |
| `MaxFileSize` | Especifica o tamanho máximo (em KB) dos arquivos .csv usados para transferir dados para o Db2 LUW. |
| `WriteBufferSize` | O tamanho (em KB) do buffer de gravação de arquivo na memória usado ao gerar arquivos .csv no disco local na instância de replicação do DMS. O valor padrão é 1.024 (1 MB). |