}
```
En el siguiente ejemplo se destacan las secciones que se utilizan para la expresión de condición.
![\[Comience con AWS DMS\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Uso del mapeo de atributos con el mapeo de objetos
El mapeo de atributos le permite especificar una cadena de ejemplo utilizando nombres de columna del origen para reestructurar los datos en el destino. El formato se modifica en función de lo que especifique el usuario en la plantilla.
El siguiente ejemplo muestra la estructura de la base de datos de origen y la estructura deseada de destino en DynamoDB. En primer lugar se muestra la estructura de origen, en este caso, una base de datos de Oracle y, a continuación, la estructura deseada de los datos en DynamoDB. El ejemplo concluye con la estructura JSON utilizada para crear la estructura de destino deseada.
La estructura de los datos de Oracle es la siguiente:
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Clave principal | N/A | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
La estructura de los datos de DynamoDB es la siguiente:
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Clave de partición | Clave de ordenación | N/A |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
La siguiente estructura JSON muestra el mapeo de objetos y de columnas que se utiliza para conseguir la estructura de 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}\"}}"
}
]
}
}
]
}
```
Otro modo de utilizar el mapeo de columnas es utilizar el formato DynamoDB como su tipo de documento. El siguiente ejemplo de código utiliza *dynamodb-map* como el `attribute-sub-type` para el mapeo de atributos.
```
{
"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`, puede utilizarla `dynamodb-list` como mapeo attribute-sub-type de atributos, como se muestra en el siguiente ejemplo.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Ejemplo 1: Uso del mapeo de atributos con el mapeo de objetos
El siguiente ejemplo migra datos de dos tablas de bases de datos MySQL, *nfl\$1data y *sport\$1team**, a dos tablas de DynamoDB denominadas y. *NFLTeams*SportTeams** A continuación se muestra la estructura de las tablas y la estructura JSON que se utilizan para mapear los datos de las tablas de la base de datos MySQL en las tablas de DynamoDB.
A continuación se muestra la estructura de la tabla de base de datos MySQL *nfl\$1data*:
```
mysql> desc nfl_data;
+---------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| Position | varchar(5) | YES | | NULL | |
| player_number | smallint(6) | YES | | NULL | |
| Name | varchar(40) | YES | | NULL | |
| status | varchar(10) | YES | | NULL | |
| stat1 | varchar(10) | YES | | NULL | |
| stat1_val | varchar(10) | YES | | NULL | |
| stat2 | varchar(10) | YES | | NULL | |
| stat2_val | varchar(10) | YES | | NULL | |
| stat3 | varchar(10) | YES | | NULL | |
| stat3_val | varchar(10) | YES | | NULL | |
| stat4 | varchar(10) | YES | | NULL | |
| stat4_val | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
+---------------+-------------+------+-----+---------+-------+
```
A continuación se muestra la estructura de la tabla de la base de datos MySQL *sport\$1team*:
```
mysql> desc sport_team;
+---------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| name | varchar(30) | NO | | NULL | |
| abbreviated_name | varchar(10) | YES | | NULL | |
| home_field_id | smallint(6) | YES | MUL | NULL | |
| sport_type_name | varchar(15) | NO | MUL | NULL | |
| sport_league_short_name | varchar(10) | NO | | NULL | |
| sport_division_short_name | varchar(10) | YES | | NULL | |
```
A continuación, se muestran las reglas de mapeo de tablas que se utilizan para asignar las dos tablas a las dos tablas de DynamoDB:
```
{
"rules":[
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "nfl_data"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "sport_team"
},
"rule-action": "include"
},
{
"rule-type":"object-mapping",
"rule-id":"3",
"rule-name":"MapNFLData",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"nfl_data"
},
"target-table-name":"NFLTeams",
"mapping-parameters":{
"partition-key-name":"Team",
"sort-key-name":"PlayerName",
"exclude-columns": [
"player_number", "team", "name"
],
"attribute-mappings":[
{
"target-attribute-name":"Team",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${team}"
},
{
"target-attribute-name":"PlayerName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"PlayerInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${
stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}"
}
]
}
},
{
"rule-type":"object-mapping",
"rule-id":"4",
"rule-name":"MapSportTeam",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"sport_team"
},
"target-table-name":"SportTeams",
"mapping-parameters":{
"partition-key-name":"TeamName",
"exclude-columns": [
"name", "id"
],
"attribute-mappings":[
{
"target-attribute-name":"TeamName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"TeamInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}"
}
]
}
}
]
}
```
El ejemplo de salida de la tabla de *NFLTeams*DynamoDB se muestra a continuación:
```
"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"
}
```
El ejemplo de salida de la tabla de SportsTeams *DynamoDB* se muestra a continuación:
```
{
"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 datos de destino para DynamoDB
El punto de conexión de DynamoDB es AWS DMS compatible con la mayoría de los tipos de datos de DynamoDB. La siguiente tabla muestra los tipos de datos de AWS DMS destino de Amazon que se admiten cuando se utilizan AWS DMS y el mapeo predeterminado a partir de AWS DMS los tipos de datos.
Para obtener información adicional sobre AWS DMS los tipos de datos, consulte[Tipos de datos de AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Al AWS DMS migrar datos de bases de datos heterogéneas, asignamos los tipos de datos de la base de datos de origen a tipos de datos intermedios denominados tipos de AWS DMS datos. A continuación, se mapean los tipos de datos intermedios en los tipos de datos de destino. La siguiente tabla muestra cada tipo de AWS DMS datos y el tipo de datos al que se asigna en DynamoDB:
| AWS DMS tipo de datos | Tipo de dato de DynamoDB |
| --- | --- |
| Cadena | Cadena |
| WString | Cadena |
| Booleano | Booleano |
| Fecha | Cadena |
| DateTime | Cadena |
| 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 | Cadena |
# Uso de Amazon Kinesis Data Streams como objetivo para AWS Database Migration Service
Puede utilizarlos AWS DMS para migrar datos a una transmisión de datos de Amazon Kinesis. Amazon Kinesis Data Streams forma parte del servicio de Amazon Kinesis Data Streams. Puede utilizar Kinesis Data Streams para recopilar y procesar grandes secuencias de registros de datos en tiempo real.
Un flujo de datos de Kinesis se compone de particiones. Las *particiones* son secuencias de registros de datos identificados inequívocamente en una secuencia. Para obtener más información sobre las particiones en Amazon Kinesis Data Streams, consulte [Partición](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) en la *Guía para desarrolladores de Amazon Kinesis Data Streams*.
AWS Database Migration Service publica registros en una transmisión de datos de Kinesis mediante JSON. Durante la conversión, AWS DMS serializa cada registro de la base de datos de origen en un par de atributo-valor en formato JSON o en un formato de mensaje JSON\$1UNFORMATTED. Un formato de mensaje JSON\$1UNFORMATTED es una cadena JSON de una sola línea con un delimitador de nueva línea. Permite a Amazon Data Firehose enviar datos de Kinesis a un destino de Amazon S3 y consultar después estos datos mediante distintos motores de consulta, incluido Amazon Athena.
Puede utilizar el mapeo de objetos para migrar sus datos desde cualquier origen de datos admitido a una secuencia de destino. Con el mapeo de datos, se determina cómo se estructuran los registros de datos de la secuencia. También debe definir una clave de partición para cada tabla, que Kinesis Data Streams utiliza para agrupar los datos en particiones.
AWS DMS también establece varios valores de parámetros de Kinesis Data Streams. El costo de la creación de la tabla depende de la cantidad de datos y del número de tablas que hay que migrar.
**nota**
La opción de **modo SSL** de la AWS DMS consola o la API no se aplica a algunos servicios NoSQL y de streaming de datos, como Kinesis y DynamoDB. **Son seguros de forma predeterminada, por lo que AWS DMS indica que la configuración del modo SSL es cero (Modo SSL=Ninguno).** No necesita proporcionar ninguna configuración adicional para que el punto de conexión utilice SSL. Por ejemplo, cuando se utiliza Kinesis como punto de conexión de destino, es seguro de forma predeterminada. Todas las llamadas de API a Kinesis utilizan SSL, por lo que no es necesaria una opción de SSL adicional en el AWS DMS punto final. Puede colocar y recuperar datos de forma segura a través de puntos de conexión SSL mediante el protocolo HTTPS, que AWS DMS utiliza de forma predeterminada al conectarse a un flujo de datos de Kinesis.
**Configuración del punto de conexión de Kinesis Data Streams**
Cuando utiliza los puntos de enlace de destino de Kinesis Data Streams, puede obtener los detalles de las transacciones y el control mediante `KinesisSettings` la opción de la API. AWS DMS
Puede configurar ajustes de conexión de las siguientes formas:
+ En la AWS DMS consola, mediante la configuración de los puntos finales.
+ En la CLI, mediante la `kinesis-settings` opción del [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)comando.
En la CLI, utilice los siguientes parámetros de solicitud de la opción de `kinesis-settings`:
**nota**
La compatibilidad con la configuración del punto de conexión de `IncludeNullAndEmpty` está disponible en la versión de AWS DMS 3.4.1 y superiores. Sin embargo, la compatibilidad con las siguientes configuraciones de punto final para los destinos de Kinesis Data Streams está disponible en AWS DMS.
+ `MessageFormat`: el formato del resultado de los registros creados en el punto de conexión. El formato del mensaje es `JSON` (predeterminado) o `JSON_UNFORMATTED` (una sola línea sin tabulación).
+ `IncludeControlDetails`: muestra información detallada de control para la definición de tablas, la definición de columnas y los cambios de tablas y columnas en la salida del mensaje de Kinesis. El valor predeterminado es `false`.
+ `IncludeNullAndEmpty`: incluya columnas NULL y vacías en el objetivo. El valor predeterminado es `false`.
+ `IncludePartitionValue`: muestra el valor de partición dentro de la salida del mensaje de Kinesis, a menos que el tipo de partición sea `schema-table-type`. El valor predeterminado es `false`.
+ `IncludeTableAlterOperations`: incluye todas las operaciones de lenguaje de definición de datos (DDL) que cambien la tabla en los datos de control, como `rename-table`, `drop-table`, `add-column`, `drop-column` y `rename-column`. El valor predeterminado es `false`.
+ `IncludeTransactionDetails`: proporciona información detallada sobre transacciones de la base de datos de origen. Esta información incluye una marca temporal de confirmación, una posición de registro y valores para `transaction_id`, `previous_transaction_id` y `transaction_record_id ` (el desplazamiento del registro dentro de una transacción). El valor predeterminado es `false`.
+ `PartitionIncludeSchemaTable`: agrega los nombres de los esquemas y de las tablas como prefijo a los valores de partición, cuando el tipo de partición es `primary-key-type`. Al hacerlo, aumenta la distribución de datos entre las particiones de Kinesis. Por ejemplo, supongamos que un esquema `SysBench` tiene miles de tablas y cada tabla tiene un rango limitado para una clave principal. En este caso, la misma clave principal se envía desde miles de tablas a la misma partición, lo que provoca la limitación controlada. El valor predeterminado es `false`.
+ `UseLargeIntegerValue`— Utilice un int de hasta 18 dígitos en lugar de convertir los int como dobles, disponible en la AWS DMS versión 3.5.4. El valor predeterminado es false.
En el siguiente ejemplo, se muestra la opción `kinesis-settings` en uso con un comando `create-endpoint` de ejemplo emitido mediante la AWS CLI.
```
aws dms \
create-endpoint \
--region \
--endpoint-identifier \
--endpoint-type target \
--engine-name kinesis \
--kinesis-settings ServiceAccessRoleArn=arn:aws:iam:::role/,StreamArn=arn:aws:kinesis:::stream/,MessageFormat=json-unformatted,
IncludeControlDetails=true,IncludeTransactionDetails=true,IncludePartitionValue=true,PartitionIncludeSchemaTable=true,
IncludeTableAlterOperations=true
```
**Configuración de tareas de carga completa con varios subprocesos**
Para ayudar a aumentar la velocidad de la transferencia, AWS DMS admite una carga completa de subprocesos múltiples a una instancia de destino de Kinesis Data Streams. DMS admite este multriproceso con configuración de tareas que incluyen lo siguiente:
+ `MaxFullLoadSubTasks`: utilice esta opción para indicar el número máximo de tablas de origen que se pueden cargar en paralelo. DMS carga cada tabla en su tabla de destino de Kinesis correspondiente mediante una tarea secundaria dedicada. El valor predeterminado es 8, el valor máximo es 49.
+ `ParallelLoadThreads`— Utilice esta opción para especificar el número de subprocesos que se AWS DMS utilizan para cargar cada tabla en su tabla de destino de Kinesis. El valor máximo para un objetivo de Kinesis Data Streams es 32. Puede pedir que se incremente este límite máximo.
+ `ParallelLoadBufferSize`: utilice esta opción para especificar el número máximo de registros para almacenar en el búfer que los subprocesos de carga en paralelo utilizan para cargar datos en el destino de Kinesis. El valor predeterminado es 50. El valor máximo es 1000. Utilice este parámetro con `ParallelLoadThreads`. `ParallelLoadBufferSize` es válido solo cuando hay más de un subproceso.
+ `ParallelLoadQueuesPerThread`: utilice esta opción para especificar el número de colas que acceden a cada subproceso simultáneo para eliminar los registros de datos de las colas y generar una carga por lotes para el destino. El valor predeterminado de es 1. Sin embargo, para los destinos de Kinesis de varios tamaños de carga, el intervalo válido es de 5-512 colas por subproceso.
**Configuración de tareas de carga de CDC con varios subprocesos**
Puede mejorar el rendimiento de la captura de datos de cambios (CDC) para los puntos de conexión de destino de flujo de datos en tiempo real como Kinesis mediante la configuración de tareas para modificar el comportamiento de la llamada a la API `PutRecords`. Para ello, puede especificar el número de subprocesos simultáneos, las colas por subproceso y el número de registros que se van a almacenar en un búfer mediante la configuración de tareas `ParallelApply*`. Suponga, por ejemplo, que desea realizar una carga de CDC y aplicar 128 subprocesos en paralelo. También desea acceder a 64 colas por subproceso, con 50 registros almacenados por búfer.
Para promover el desempeño de los CDC, AWS DMS admite las siguientes configuraciones de tareas:
+ `ParallelApplyThreads`— Especifica el número de subprocesos simultáneos que se AWS DMS utilizan durante una carga de CDC para enviar registros de datos a un punto final de Kinesis de destino. El valor predeterminado es cero (0) y el valor máximo es 32.
+ `ParallelApplyBufferSize`: especifica el número máximo de registros que se almacenan en cada cola del búfer para los subprocesos simultáneos que insertan datos en un punto de conexión de destino de Kinesis durante una carga de CDC. El valor predeterminado es 100 y el máximo es 1000. Utilice esta opción cuando `ParallelApplyThreads` especifique más de un subproceso.
+ `ParallelApplyQueuesPerThread`: especifica el número de colas a las que accede cada subproceso para sacar registros de datos de las colas y generar una carga por lotes para un punto de conexión de Kinesis durante el proceso de CDC. El valor predeterminado es 1 y el máximo es 512.
Cuando se utiliza la configuración de tareas `ParallelApply*`, el valor predeterminado de `partition-key-type` es el valor de `primary-key` de la tabla, no el valor de `schema-name.table-name`.
## Uso de una imagen anterior para consultar los valores originales de las filas de CDC de un flujo de datos de Kinesis como destino
Al escribir actualizaciones de CDC en un destino de flujo de datos como Kinesis, puede ver los valores originales de una fila de base de datos de origen antes de cambiar mediante una actualización. Para que esto sea posible, AWS DMS rellena una *imagen anterior* de los eventos de actualización en función de los datos proporcionados por el motor de base de datos de origen.
Los diferentes motores de base de datos de origen proporcionan diferentes cantidades de información para una imagen anterior:
+ Oracle proporciona actualizaciones a las columnas solo si cambian.
+ PostgreSQL proporciona datos solo para las columnas que forman parte de la clave principal (cambiadas o no). Para proporcionar datos para todas las columnas (cambiadas o no), debe establecer `REPLICA_IDENTITY` en `FULL` en lugar de `DEFAULT`. Tenga en cuenta que debe elegir cuidadosamente la configuración de `REPLICA_IDENTITY` para cada tabla. Si establece `REPLICA_IDENTITY` en `FULL`, todos los valores de las columnas se escriben en el registro antes de la escritura (WAL) de forma continua. Esto puede provocar problemas de rendimiento o de recursos en las tablas que se actualizan con frecuencia.
+ MySQL generalmente proporciona datos para todas las columnas excepto para los tipos de datos BLOB y CLOB (cambiadas o no).
Para habilitar imágenes anteriores para agregar valores originales de la base de datos de origen a la salida AWS DMS , utilice la configuración de tarea `BeforeImageSettings` o el parámetro `add-before-image-columns`. Este parámetro aplica una regla de transformación de columna.
`BeforeImageSettings` agrega un nuevo atributo JSON a cada operación de actualización con valores recopilados desde el sistema de base de datos de origen, como se muestra a continuación.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**nota**
Solo se aplica `BeforeImageSettings` a AWS DMS las tareas que contienen un componente de los CDC, como la carga completa más las tareas de los CDC (que migran los datos existentes y reproducen los cambios en curso), o a las tareas exclusivas de los CDC (que solo replican los cambios en los datos). No se aplica `BeforeImageSettings` a tareas que son solo de carga completa.
Para las opciones de `BeforeImageSettings`, se aplica lo siguiente:
+ Establezca la opción `EnableBeforeImage` para habilitar `true` antes de crear imágenes. El valor predeterminado es `false`.
+ Utilice la opción `FieldName` para asignar un nombre al nuevo atributo JSON. Cuando `EnableBeforeImage` es `true`, `FieldName` es necesario y no puede estar vacío.
+ La opción `ColumnFilter` especifica una columna para agregar mediante el uso de las imágenes anteriores. Para agregar solo columnas que forman parte de las claves principales de la tabla, utilice el valor predeterminado, `pk-only`. Para agregar cualquier columna que tenga un valor de imagen anterior, utilice `all`. Tenga en cuenta que la imagen anterior no contiene columnas con tipos de datos de LOB, como CLOB o BLOB.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**nota**
Los objetivos de Amazon S3 no admiten `BeforeImageSettings`. Para los destinos de S3, utilice solo la regla de transformación `add-before-image-columns` que debe realizarse antes de crear imágenes durante el CDC.
### Uso de una regla de transformación de imagen anterior
Como alternativa a la configuración de tareas, puede utilizar el parámetro `add-before-image-columns`, que aplica una regla de transformación de columnas. Con este parámetro, puede habilitar imágenes anteriores durante CDC en destinos de flujo de datos como Kinesis.
Al utilizar `add-before-image-columns` en una regla de transformación, puede aplicar un control más detallado de los resultados de la imagen anterior. Las reglas de transformación permiten utilizar un localizador de objetos que le da control sobre las tablas seleccionadas para la regla. Además, puede encadenar reglas de transformación, lo que permite aplicar diferentes reglas a diferentes tablas. A continuación, puede manipular las columnas producidas utilizando otras reglas.
**nota**
No utilice el parámetro `add-before-image-columns` junto con la configuración de tarea `BeforeImageSettings` dentro de la misma tarea. En su lugar, utilice el parámetro o la configuración, pero no ambos, para una sola tarea.
Un tipo de regla `transformation` con el parámetro `add-before-image-columns` de una columna debe proporcionar una sección `before-image-def`. A continuación se muestra un ejemplo.
```
{
"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,
}
}
```
El valor de `column-prefix` se antepone a un nombre de columna y el valor predeterminado de `column-prefix` es `BI_`. El valor de `column-suffix` se añade al nombre de la columna y el valor predeterminado está vacío. No configure ambas cadenas `column-prefix` y `column-suffix` como cadenas vacías.
Elija un valor para `column-filter`. Para agregar solo columnas que forman parte de las claves principales de la tabla, elija `pk-only`. Elija `non-lob` para agregar solo columnas que no sean de tipo LOB. O elija `all` para agregar cualquier columna que tenga un valor de imagen anterior.
### Ejemplo de una regla de transformación de imagen anterior
La regla de transformación del siguiente ejemplo agrega una nueva columna llamada `BI_emp_no` en el destino. Entonces, una instrucción como `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` rellena el campo `BI_emp_no` con 1. Cuando escribe actualizaciones de CDC en destinos de Amazon S3, la columna `BI_emp_no` permite indicar qué fila original se actualizó.
```
{
"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 obtener información sobre el uso de la acción de regla `add-before-image-columns`, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Requisitos previos para utilizar una transmisión de datos de Kinesis como destino para AWS Database Migration Service
### Función de IAM para utilizar una transmisión de datos de Kinesis como objetivo para AWS Database Migration Service
Antes de configurar una transmisión de datos de Kinesis como destino AWS DMS, asegúrese de crear una función de IAM. Esta función debe permitir asumir y conceder acceso AWS DMS a las transmisiones de datos de Kinesis a las que se están migrando. El conjunto mínimo de permisos de acceso se muestra en la siguiente política de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
El rol que utilice para la migración a un flujo de datos de Kinesis debe tener los siguientes permisos.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Acceder a una transmisión de datos de Kinesis como destino para AWS Database Migration Service
En AWS DMS la versión 3.4.7 y versiones posteriores, para conectarse a un endpoint de Kinesis, debe realizar una de las siguientes acciones:
+ Configure DMS para que utilice puntos de conexión de VPC. Para obtener más información sobre la configuración de DMS para utilizar puntos de conexión de VPC, consulte [Configuración de puntos finales de VPC para AWS DMS](CHAP_VPC_Endpoints.md).
+ Configure DMS para que utilice rutas públicas, es decir, haga pública su instancia de replicación. Para obtener información sobre las instancias de replicación públicas, consulte [Instancias de replicación pública y privada](CHAP_ReplicationInstance.PublicPrivate.md).
## Limitaciones al utilizar Kinesis Data Streams como objetivo para AWS Database Migration Service
Al utilizar Kinesis Data Streams como destino se aplican las siguientes restricciones:
+ AWS DMS publica cada actualización en un único registro de la base de datos de origen como un registro de datos en un flujo de datos de Kinesis determinado, independientemente de las transacciones. Sin embargo, puede incluir detalles de transacción para cada registro de datos utilizando los parámetros pertinentes de la API `KinesisSettings`.
+ No se admite el modo LOB completo.
+ El tamaño de LOB máximo admitido es 1 MB.
+ Kinesis Data Streams no admite la desduplicación. Las aplicaciones que consumen datos de una secuencia necesitan ocuparse de los registros duplicados. Para obtener más información, consulte [Gestión de registros duplicados](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) en la *Guía para desarrolladores de Amazon Kinesis Data Streams*.
+ AWS DMS admite las siguientes cuatro formas de claves de partición:
+ `SchemaName.TableName` una combinación del nombre de esquema y de tabla.
+ `${AttributeName}`: el valor de uno de los campos del archivo JSON o la clave principal de la tabla de la base de datos de origen.
+ `transaction-id`: El identificador de transacción de los CDC. Todos los registros de la misma transacción van a la misma partición.
+ `constant`: un valor literal fijo para cada registro, independientemente de la tabla o los datos. Todos los registros se envían al mismo valor de clave de partición «constante», lo que proporciona un orden global estricto en todas las tablas.
```
{
"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 obtener información sobre el cifrado de los datos en reposo en Kinesis Data Streams, consulte [Protección de datos en Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html) en la *Guía para desarrolladores de AWS Key Management Service *.
+ La configuración del `IncludeTransactionDetails` punto final solo se admite cuando el punto final de origen es Oracle, SQL Server, PostgreSQL o MySQL. En el caso de otros tipos de puntos finales de origen, no se incluirán los detalles de la transacción.
+ `BatchApply` no es compatible con un punto de conexión de Kinesis. Es posible que el uso de la aplicación por lotes (por ejemplo, la configuración de tareas de metadatos de destino `BatchApplyEnabled`) para un destino de Kinesis provoque la pérdida de datos y el fallo de la tarea. No active `BatchApply` cuando utilice Kinesis como punto de conexión de destino.
+ Los destinos de Kinesis solo se admiten para una transmisión de datos de Kinesis en la misma AWS cuenta y en la Región de AWS misma instancia de replicación.
+ Al migrar desde una fuente de MySQL, los BeforeImage datos no incluyen los tipos de datos CLOB y BLOB. Para obtener más información, consulte [Uso de una imagen anterior para consultar los valores originales de las filas de CDC de un flujo de datos de Kinesis como destino](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS no admite la migración de valores de tipos de `BigInt` datos con más de 16 dígitos. Para evitar esta limitación, puede usar la siguiente regla de transformación para convertir la columna `BigInt` en una cadena. Para obtener más información sobre las reglas de transformación, consulte [Reglas y acciones de transformación](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
}
}
```
+ Cuando varias operaciones de DML dentro de una sola transacción modifican una columna de objetos grandes (LOB) de la base de datos de origen, la base de datos de destino solo conserva el valor final de LOB de la última operación de esa transacción. Los valores de LOB intermedios establecidos por las operaciones anteriores de la misma transacción se sobrescriben, lo que puede provocar la pérdida de datos o la aparición de incoherencias. Este comportamiento se debe a la forma en que se procesan los datos de LOB durante la replicación.
+ AWS DMS no admite datos de origen que contengan `'\0'` caracteres incrustados cuando se utiliza Kinesis como punto final de destino. Los datos que contengan `'\0'` caracteres incrustados se truncarán en el primer carácter. `'\0'`
## Uso de la asignación de objetos para migrar datos a un flujo de datos de Kinesis
AWS DMS utiliza reglas de mapeo de tablas para mapear los datos del flujo de datos de Kinesis de origen al de destino. Para asignar datos a una secuencia de destino, se utiliza un tipo de regla de mapeo de tablas denominada "object mapping". Puede utilizar la asignación de objetos para definir cómo los registros de datos del origen asignan a los registros de datos publicados en el flujo de datos de Kinesis.
Kinesis Data Streams no tiene una estructura predeterminada distinta de una clave de partición. En una regla de asignación de objetos, los valores posibles de `partition-key-type` para los registros de datos son `schema-table`, `transaction-id`, `primary-key`, `constant` y `attribute-name`.
Para crear una regla de mapeo de objetos, especifique `rule-type` como `object-mapping`. Esta regla indica el tipo de mapeo de objetos que desea utilizar.
La estructura de la regla es la siguiente.
```
{
"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 actualmente admite `map-record-to-record` y es `map-record-to-document` el único valor válido para el parámetro. `rule-action` Esta configuración afecta a los valores que no están excluidos como parte de la lista de atributos `exclude-columns`. Los `map-record-to-document` valores `map-record-to-record` y especifican cómo se AWS DMS gestionan estos registros de forma predeterminada. Estos valores no afectan a los mapeos de atributos en modo alguno.
Utilice `map-record-to-record` al migrar desde una base de datos relacional a un flujo de datos de Kinesis. Este tipo de regla utiliza el valor `taskResourceId.schemaName.tableName` de la base de datos relacional como la clave de partición en el flujo de datos de Kinesis y crea un atributo para cada columna de la base de datos de origen.
Cuando utilice `map-record-to-record`, tenga en cuenta lo siguiente:
+ Esta configuración solo afecta a las columnas excluidas de la lista `exclude-columns`.
+ Para cada columna de este tipo, AWS DMS crea un atributo correspondiente en el tema de destino.
+ AWS DMS crea el atributo correspondiente independientemente de si la columna de origen se utiliza en una asignación de atributos.
Se utiliza `map-record-to-document` para colocar las columnas de origen en un único documento plano en la secuencia de destino correspondiente utilizando el nombre de atributo “\$1doc”. AWS DMS coloca los datos en un único mapa plano del origen denominado “`_doc`”. Esta colocación se aplica a cada columna de la tabla de origen que no se enumera en la lista de atributos `exclude-columns`.
Una forma de entender `map-record-to-record` es verlo en acción. En este ejemplo, imagine que empieza con una fila de una tabla de base de datos relacional con la estructura y los datos siguientes.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Para migrar esta información desde un esquema denominado `Test` a un flujo de datos de Kinesis, debe crear reglas para asignar los datos a la secuencia de destino. La siguiente regla ilustra la operación de asignación.
```
{
"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"
}
}
]
}
```
A continuación, se ilustra el formato de registro resultante en el flujo de datos de Kinesis:
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaname.tableName
+ Datos: //El siguiente mensaje JSON
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
Sin embargo, supongamos que utiliza las mismas reglas pero cambia el parámetro `rule-action` a `map-record-to-document` y excluye determinadas columnas. La siguiente regla ilustra la operación de asignación.
```
{
"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"
]
}
}
]
}
```
En este caso, las columnas que no aparecen en el parámetro `exclude-columns`, `FirstName`, `LastName`, `StoreId` y `DateOfBirth`, se asignan a `_doc`. A continuación, se ilustra el formato de registro resultante.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Reestructuración de datos con el mapeo de atributos
Puede reestructurar los datos mientras los migra a un flujo de datos de Kinesis mediante un mapa de atributos. Por ejemplo, es posible que desee combinar varios campos del origen en un único campo en el destino. El mapa de atributos siguiente ilustra cómo reestructurar los datos.
```
{
"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 establecer un valor constante para, especifique`partition-key`, esto establece el valor de la partición en. `"partition-key-type: "constant"` `constant` Tal vez desee hacer esto, por ejemplo, para obligar a que todos los datos se almacenen en una única partición. El siguiente mapeo ilustra este enfoque.
```
{
"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**
El valor `partition-key` de un registro de control para una tabla específica es `TaskId.SchemaName.TableName`. El valor `partition-key` de un registro de control para una tabla específica es el `TaskId` de ese registro. La especificación de un valor `partition-key` en el mapeo de objetos no tiene ningún efecto en el elemento `partition-key` de un registro de control.
Si `partition-key-type` se establece `attribute-name` en una regla de mapeo de tablas, debe especificarse`partition-key-name`, que debe hacer referencia a una columna de la tabla de origen o a una columna personalizada definida en la asignación. Además, `attribute-mappings` debe proporcionarse para definir cómo se asignan las columnas de origen a la transmisión de Kinesis de destino.
### Formato de mensaje para Kinesis Data Streams
La salida JSON es simplemente una lista de pares de clave-valor. Un formato de mensaje JSON\$1UNFORMATTED es una cadena JSON de una sola línea con un delimitador de nueva línea.
AWS DMS proporciona los siguientes campos reservados para facilitar el consumo de los datos de Kinesis Data Streams:
**RecordType**
El tipo de registro puede ser de datos o de control. Los *registros de datos *representan las filas reales en el origen. Los *registros de control* son para eventos importantes de la secuencia como, por ejemplo, el reinicio de una tarea.
**Operación**
Para los registros de datos, la operación puede ser `load`, `insert`, `update` o `delete`.
Para los registros de control, la operación puede ser `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` o `column-type-change`.
**SchemaName**
El esquema de origen del registro. Este campo puede estar vacío para un registro de control.
**TableName**
La tabla de origen del registro. Este campo puede estar vacío para un registro de control.
**Timestamp**
La marca temporal que indica cuándo se creó el mensaje JSON. El campo está formateado con el formato ISO 8601.
# Uso de Apache Kafka como objetivo para AWS Database Migration Service
Puede usarlo AWS DMS para migrar datos a un clúster de Apache Kafka. Apache Kafka es una plataforma de streaming distribuida. Puede utilizar Apache Kafka para ingerir y procesar datos de streaming en tiempo real.
AWS también ofrece Amazon Managed Streaming para que Apache Kafka (Amazon MSK) lo utilice como objetivo. AWS DMS Amazon MSK es un servicio de streaming de Apache Kafka completamente administrado que simplifica la implementación y gestión de instancias de Apache Kafka. Funciona con versiones de código abierto de Apache Kafka y puede acceder a las instancias de Amazon MSK como AWS DMS destinos exactamente igual que a cualquier instancia de Apache Kafka. Para obtener más información, consulte [¿Qué es Amazon MSK?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) en la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka.*.
Un clúster de Kafka almacena flujos de registros en categorías denominadas temas que se dividen en particiones. Las *particiones* son secuencias de registros de datos (mensajes) identificados de forma única en un tema. Las particiones se pueden distribuir entre varios agentes de un clúster para permitir el procesamiento paralelo de los registros de un tema. Para obtener más información sobre temas y particiones y su distribución en Apache Kafka, consulte [Temas y registros](https://kafka.apache.org/documentation/#intro_topics) y [Distribución](https://kafka.apache.org/documentation/#intro_distribution).
El clúster de Kafka puede ser una instancia de Amazon MSK, un clúster que se ejecute en una instancia de Amazon EC2 o un clúster en las instalaciones. Una instancia de Amazon MSK o un clúster en una instancia de Amazon EC2 se pueden encontrar en la misma VPC o en una diferente. Si el clúster está en las instalaciones, puede usar su propio servidor de nombres en las instalaciones para la instancia de replicación a fin de resolver el nombre de host del clúster. Para obtener información acerca de cómo configurar un servidor de nombres para la instancia de replicación, consulte [Uso de su propio servidor de nombres en las instalaciones](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Para obtener más información sobre cómo configurar una red, consulte [Configuración de una red para una instancia de replicación](CHAP_ReplicationInstance.VPC.md).
Cuando utilice un clúster de Amazon MSK, asegúrese de que su grupo de seguridad permita el acceso desde la instancia de replicación. Para obtener información sobre cómo cambiar el grupo de seguridad de un clúster de Amazon MSK, consulte [Cambio del grupo de seguridad de un clúster de Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service publica los registros de un tema de Kafka mediante JSON. Durante la conversión, AWS DMS serializa cada registro de la base de datos de origen en un par de atributo-valor en formato JSON.
Para migrar los datos desde cualquier origen de datos admitido a un clúster de Kafka de destino, se usa la asignación de objetos. Con la asignación de objetos, se determina cómo se estructuran los registros de datos en el tema de destino. También debe definir una clave de partición para cada tabla, que Apache Kafka utiliza para agrupar los datos en particiones.
Actualmente, AWS DMS admite un solo tema por tarea. En el caso de una sola tarea con varias tablas, todos los mensajes van a un solo tema. Cada mensaje incluye una sección de metadatos que identifica el esquema y la tabla de destino. AWS DMS las versiones 3.4.6 y superiores admiten la replicación multitema mediante el mapeo de objetos. Para obtener más información, consulte [Replicación multitemática mediante asignación de objetos](#CHAP_Target.Kafka.MultiTopic).
**Configuración de punto de enlace de Apache Kafka**
Puede especificar los detalles de la conexión mediante la configuración del punto final en la AWS DMS consola o mediante la `--kafka-settings` opción en la CLI. A continuación se indican los requisitos para cada ajuste:
+ `Broker`: especifique las ubicaciones de uno o más agentes en el clúster de Kafka en forma de una lista separada por comas de cada `broker-hostname:port`. Un ejemplo es `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Esta configuración puede especificar las ubicaciones de algunos o todos los agentes del clúster. Todos los agentes de clúster se comunican para gestionar la partición de los registros de datos migrados al tema.
+ `Topic`: (opcional) especifique el nombre del tema con una longitud máxima de 255 letras y símbolos. Puede usar el punto (.), el guion bajo (\$1) y el signo menos (-). Los nombres de temas con un punto (.) o guion bajo (\$1) pueden colisionar en las estructuras de datos internas. Puede usar uno de estos símbolos, pero no ambos, en el nombre del tema. Si no especifica un nombre para el tema, `"kafka-default-topic"` lo AWS DMS utiliza como tema de migración.
**nota**
Para AWS DMS crear un tema de migración que especifique o el tema predeterminado, `auto.create.topics.enable = true` configúrelo como parte de la configuración del clúster de Kafka. Para obtener más información, consulte [Limitaciones a la hora de utilizar Apache Kafka como destino para AWS Database Migration Service](#CHAP_Target.Kafka.Limitations)
+ `MessageFormat`: el formato del resultado de los registros creados en el punto de conexión. El formato del mensaje es `JSON` (predeterminado) o `JSON_UNFORMATTED` (una sola línea sin tabulación).
+ `MessageMaxBytes`: el tamaño máximo en bytes de los registros creados en el punto de conexión. El valor predeterminado es 1 000 000.
**nota**
Solo puede usar la AWS CLI/SDK para cambiar a un valor que no sea `MessageMaxBytes` el predeterminado. Por ejemplo, para modificar el punto de conexión de Kafka existente y cambiar `MessageMaxBytes`, utilice el siguiente comando.
```
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`: proporciona información detallada sobre transacciones de la base de datos de origen. Esta información incluye una marca temporal de confirmación, una posición de registro y valores para `transaction_id`, `previous_transaction_id` y `transaction_record_id` (el desplazamiento del registro dentro de una transacción). El valor predeterminado es `false`.
+ `IncludePartitionValue`: muestra el valor de partición dentro de la salida del mensaje de Kafka, a menos que el tipo de partición sea `schema-table-type`. El valor predeterminado es `false`.
+ `PartitionIncludeSchemaTable`: agrega los nombres de los esquemas y de las tablas como prefijo a los valores de partición, cuando el tipo de partición es `primary-key-type`. Al hacerlo, aumenta la distribución de datos entre las particiones de Kafka. Por ejemplo, supongamos que un esquema `SysBench` tiene miles de tablas y cada tabla tiene un rango limitado para una clave principal. En este caso, la misma clave principal se envía desde miles de tablas a la misma partición, lo que provoca limitación. El valor predeterminado es `false`.
+ `IncludeTableAlterOperations`: incluye todas las operaciones de lenguaje de definición de datos (DDL) que cambien la tabla en los datos de control, como `rename-table`, `drop-table`, `add-column`, `drop-column` y `rename-column`. El valor predeterminado es `false`.
+ `IncludeControlDetails`: muestra información detallada de control para la definición de tablas, la definición de columnas y los cambios de tablas y columnas en la salida del mensaje de Kafka. El valor predeterminado es `false`.
+ `IncludeNullAndEmpty`: incluya columnas NULL y vacías en el objetivo. El valor predeterminado es `false`.
+ `SecurityProtocol`: establece una conexión segura a un punto de conexión de destino de Kafka utilizando la seguridad de la capa de transporte (TLS). Las opciones incluyen `ssl-authentication`, `ssl-encryption` y `sasl-ssl`. El uso de `sasl-ssl` requiere `SaslUsername` y `SaslPassword`.
+ `SslEndpointIdentificationAlgorithm`: establece la verificación del nombre de host para el certificado. Esta configuración se admite en AWS DMS versión 3.5.1 y posteriores. Estas son las opciones disponibles:
+ `NONE`: deshabilita la verificación del nombre de host del agente en la conexión del cliente.
+ `HTTPS`: habilita la verificación del nombre de host del agente en la conexión del cliente.
+ `useLargeIntegerValue`— Utilice un int de hasta 18 dígitos en lugar de convertir los int como dobles, disponible a partir AWS DMS de la versión 3.5.4. El valor predeterminado es false.
Puede usar la configuración para ayudar a aumentar la velocidad de la transferencia. Para ello, AWS DMS admite la carga completa con varios subprocesos en un clúster de destino de Apache Kafka. AWS DMS admite esta operación con varios subprocesos con las configuraciones de tareas que incluyen lo siguiente:
+ `MaxFullLoadSubTasks`— Utilice esta opción para indicar el número máximo de tablas de origen que se van a cargar en paralelo. AWS DMS carga cada tabla en su tabla de destino de Kafka correspondiente mediante una subtarea dedicada. El valor predeterminado es 8, el valor máximo es 49.
+ `ParallelLoadThreads`— Utilice esta opción para especificar el número de subprocesos que se AWS DMS utilizan para cargar cada tabla en su tabla de destino de Kafka. El valor máximo para un destino de Apache Kafka es 32. Puede pedir que se incremente este límite máximo.
+ `ParallelLoadBufferSize`: utilice esta opción para especificar el número máximo de registros para almacenar en el búfer que los subprocesos de carga en paralelo utilizan para cargar datos en el destino de Kafka. El valor predeterminado es 50. El valor máximo es 1000. Utilice este parámetro con `ParallelLoadThreads`. `ParallelLoadBufferSize` es válido solo cuando hay más de un subproceso.
+ `ParallelLoadQueuesPerThread`: utilice esta opción para especificar el número de colas que acceden a cada subproceso simultáneo para eliminar los registros de datos de las colas y generar una carga por lotes para el destino. El valor predeterminado de es 1. El máximo es 512.
Puede mejorar el rendimiento de la captura de datos de cambios (CDC) para los puntos de conexión de Kafka ajustando la configuración de las tareas para los subprocesos paralelos y las operaciones masivas. Para ello, puede especificar el número de subprocesos simultáneos, las colas por subproceso y el número de registros que se van a almacenar en un búfer mediante la configuración de tareas `ParallelApply*`. Suponga, por ejemplo, que desea realizar una carga de CDC y aplicar 128 subprocesos en paralelo. También desea acceder a 64 colas por subproceso, con 50 registros almacenados por búfer.
Para promover el desempeño de los CDC, AWS DMS admite las siguientes configuraciones de tareas:
+ `ParallelApplyThreads`— Especifica la cantidad de subprocesos simultáneos que se AWS DMS utilizan durante una carga de CDC para enviar los registros de datos a un punto final de Kafka. El valor predeterminado es cero (0) y el valor máximo es 32.
+ `ParallelApplyBufferSize`: especifica el número máximo de registros que se almacenan en cada cola del búfer para los subprocesos simultáneos que insertan datos en un punto de conexión de destino de Kafka durante una carga de CDC. El valor predeterminado es 100 y el máximo es 1000. Utilice esta opción cuando `ParallelApplyThreads` especifique más de un subproceso.
+ `ParallelApplyQueuesPerThread`: especifica el número de colas a las que accede cada subproceso para sacar registros de datos de las colas y generar una carga por lotes para un punto de conexión de Kafka durante el proceso de CDC. El valor predeterminado de es 1. El máximo es 512.
Cuando se utiliza la configuración de tareas `ParallelApply*`, el valor predeterminado de `partition-key-type` es el valor de `primary-key` de la tabla, no el valor de `schema-name.table-name`.
## Conexión a Kafka mediante seguridad de la capa de transporte (TLS)
Un clúster de Kafka acepta conexiones seguras mediante seguridad de la capa de transporte (TLS). Con DMS, puede utilizar cualquiera de las siguientes tres opciones de protocolos de seguridad para proteger una conexión de punto de conexión de Kafka.
**Cifrado SSL (`server-encryption`)**
Los clientes validan la identidad del servidor mediante el certificado del servidor. A continuación, se establece una conexión cifrada entre el servidor y el cliente.
**Autenticación SSL (`mutual-authentication`)**
El servidor y el cliente validan la identidad entre sí mediante sus propios certificados. A continuación, se establece una conexión cifrada entre el servidor y el cliente.
**SASL-SSL (`mutual-authentication`)**
El método de capa de seguridad y autenticación simple (SASL) reemplaza el certificado del cliente por un nombre de usuario y una contraseña para validar la identidad del cliente. En concreto, debe proporcionar un nombre de usuario y una contraseña que el servidor haya registrado para que el servidor pueda validar la identidad de un cliente. A continuación, se establece una conexión cifrada entre el servidor y el cliente.
**importante**
Apache Kafka y Amazon MSK aceptan certificados resueltos. Se trata de una limitación conocida que deben abordar Kafka y Amazon MSK. Para obtener más información, consulte [Problemas de Apache Kafka, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Si utiliza Amazon MSK, considere la posibilidad de utilizar listas de control de acceso (ACLs) como solución alternativa a esta limitación conocida. Para obtener más información sobre su uso ACLs, consulte la ACLs sección [Apache Kafka](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) de la Guía para desarrolladores de *Amazon Managed Streaming for Apache Kafka*.
Si utiliza un clúster de Kafka autoadministrado, consulte [Comentario del 21 de octubre de 2018](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376) para obtener información sobre la configuración del clúster.
### Uso del cifrado SSL con Amazon MSK o un clúster de Kafka autoadministrado
Puede utilizar el cifrado SSL para proteger una conexión de punto de conexión con Amazon MSK o con un clúster de Kafka autoadministrado. Cuando utiliza el método de autenticación de cifrado SSL, los clientes validan la identidad de un servidor mediante el certificado del servidor. A continuación, se establece una conexión cifrada entre el servidor y el cliente.
**Uso del cifrado SSL para conectarse a Amazon MSK**
+ Establezca la configuración del punto de conexión del protocolo de seguridad (`SecurityProtocol`) mediante la opción `ssl-encryption` al crear el punto de conexión de Kafka de destino.
En el siguiente ejemplo de JSON se establece el protocolo de seguridad como cifrado SSL.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**Uso del cifrado SSL en un clúster de Kafka autoadministrado**
1. Si utiliza una entidad de certificación (CA) privada en el clúster de Kafka en las instalaciones, cargue el certificado de la entidad de certificación privado y obtenga un nombre de recurso de Amazon (ARN).
1. Establezca la configuración del punto de conexión del protocolo de seguridad (`SecurityProtocol`) mediante la opción `ssl-encryption` al crear el punto de conexión de Kafka de destino. En el siguiente ejemplo de JSON se establece el protocolo de seguridad como `ssl-encryption`.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Si utiliza una entidad de certificación privada, establezca `SslCaCertificateArn` en el ARN que obtuvo en el primer paso anterior.
### Uso de la autenticación SSL
Puede utilizar la autenticación SSL para proteger una conexión de punto de conexión con Amazon MSK o con un clúster de Kafka autoadministrado.
Para habilitar la autenticación y el cifrado del cliente mediante la autenticación SSL para conectarse a Amazon MSK, haga lo siguiente:
+ Prepare una clave privada y un certificado público para Kafka.
+ Cargue certificados en el mánager de certificados de DMS.
+ Cree un punto final de destino de Kafka con el certificado correspondiente ARNs especificado en la configuración del punto final de Kafka.
**Preparación de una clave privada y un certificado público para Amazon MSK**
1. Cree una instancia EC2 y configure un cliente para que utilice la autenticación tal y como se describe en los pasos 1 a 9 de la sección [Autenticación de clientes](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) de la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka*.
Tras completar estos pasos, dispondrá de un ARN de certificado (el ARN del certificado público guardado en ACM) y de una clave privada en un archivo `kafka.client.keystore.jks`.
1. Obtenga el certificado público y cópielo en el archivo `signed-certificate-from-acm.pem` mediante el siguiente comando:
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
El comando devuelve información similar al siguiente ejemplo:
```
{"Certificate": "123", "CertificateChain": "456"}
```
A continuación, copie el equivalente de `"123"` al archivo `signed-certificate-from-acm.pem`.
1. Obtenga la clave privada importando la clave `msk-rsa` desde `kafka.client.keystore.jks to keystore.p12`, como se muestra en el siguiente ejemplo.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Utilice el siguiente comando para exportar `keystore.p12` a un formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
Aparece el mensaje **Ingrese la frase de contraseña PEM** e identifica la clave que se aplica para cifrar el certificado.
1. Elimine los atributos de bolsa y los atributos de clave del archivo `.pem` para asegurarse de que la primera línea comience con la siguiente cadena.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**Carga de un certificado público y una clave privada en el mánager de certificados de DMS y prueba de la conexión a Amazon MSK**
1. Cargue en el mánager de certificados de DMS mediante el siguiente comando.
```
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. Cree un punto de conexión de destino de Amazon MSK y pruebe la conexión para asegurarse de que la autenticación TLS funciona.
```
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**
Puede utilizar la autenticación SSL para proteger una conexión a un clúster de Kafka autoadministrado. En algunos casos, es posible que use una entidad de certificación (CA) privada en el clúster de Kafka en las instalaciones. Si es así, cargue la cadena de la entidad de certificación, el certificado público y la clave privada en el mánager de certificados de DMS. A continuación, utilice el nombre de recurso de Amazon (ARN) correspondiente en la configuración del punto de conexión cuando cree el punto de conexión de destino Kafka en las instalaciones.
**Preparación de una clave privada y un certificado firmado para un clúster de Kafka autoadministrado**
1. Genere un par de claves como se muestra en el siguiente ejemplo.
```
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. Genere una solicitud de firma 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. Utilice la entidad de certificación del almacén de confianza del clúster para firmar la CSR. Si no tiene una entidad de certificación, puede crear su propia entidad de certificación privada.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Importe `ca-cert` en el almacén de confianza y al almacén de claves del servidor. Si no dispone de un almacén de confianza, utilice el siguiente comando para crear el almacén de confianza e importar `ca-cert ` en él.
```
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. Firme el 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 el certificado firmado al almacén de claves.
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. Utilice el siguiente comando para importar la clave `on-premise-rsa` de `kafka.server.keystore.jks` a `keystore.p12`.
```
keytool -importkeystore \
-srckeystore kafka.server.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias on-premise-rsa \
-deststorepass your-truststore-password \
-destkeypass your-key-password
```
1. Utilice el siguiente comando para exportar `keystore.p12` a un formato `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Cargue `encrypted-private-server-key.pem`, `signed-certificate.pem` y `ca-cert` en el mánager de certificados de DMS.
1. Cree un punto final utilizando el devuelto. 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
```
### Uso de la autenticación SASL-SSL para conectarse a Amazon MSK
El método de capa de seguridad y autenticación simple (SASL) utiliza un nombre de usuario y una contraseña para validar la identidad del cliente y establece una conexión cifrada entre el servidor y el cliente.
Para usar SASL, primero debe crear un nombre de usuario y una contraseña seguros al configurar el clúster de Amazon MSK. Para obtener una descripción de cómo configurar un nombre de usuario y una contraseña seguros para un clúster de Amazon MSK, consulte [Configuración de la SASL/SCRAM autenticación para un clúster de Amazon MSK en la Guía para desarrolladores](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) de *Amazon Managed Streaming for Apache Kafka*.
A continuación, cuando cree el punto de conexión de destino de Kafka, establezca la configuración del punto de conexión del protocolo de seguridad (`SecurityProtocol`) mediante la opción `sasl-ssl`. Establezca también las opciones `SaslUsername` y `SaslPassword`. Asegúrese de que coincidan con el nombre de usuario y la contraseña seguros que creó cuando configuró por primera vez el clúster de Amazon MSK, como se muestra en el siguiente ejemplo de JSON.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**nota**
Actualmente, solo AWS DMS admite el SASL-SSL público respaldado por una CA. DMS no admite el SASL-SSL para usarlo con Kafka autoadministrado y respaldado por una entidad de certificación privada.
Para la autenticación SASL-SSL, AWS DMS es compatible con el mecanismo SCRAM-SHA-512 de forma predeterminada. AWS DMS las versiones 3.5.0 y superiores también admiten el mecanismo Plain. Para admitir el mecanismo Plain, defina el parámetro `SaslMechanism` del tipo de datos de la API `KafkaSettings` en `PLAIN`. El tipo de datos `PLAIN` es compatible con Kafka, pero no con Amazon Kafka (MSK).
## Uso de una imagen anterior para consultar los valores originales de las filas de CDC para Apache Kafka como destino
Al escribir actualizaciones de CDC en un destino de transmisión de datos como Kafka, puede ver los valores originales de una fila de base de datos de origen antes de cambiar mediante una actualización. Para que esto sea posible, AWS DMS rellena una *imagen anterior* de los eventos de actualización en función de los datos proporcionados por el motor de base de datos de origen.
Los diferentes motores de base de datos de origen proporcionan diferentes cantidades de información para una imagen anterior:
+ Oracle proporciona actualizaciones a las columnas solo si cambian.
+ PostgreSQL proporciona datos solo para las columnas que forman parte de la clave principal (cambiadas o no). Si se utiliza la replicación lógica y se ha configurado REPLICA IDENTITY FULL para la tabla de origen, puede escribir toda la información de antes y después de la fila WALs y verla aquí.
+ MySQL generalmente proporciona datos para todas las columnas (cambiadas o no).
Para habilitar imágenes anteriores para agregar valores originales de la base de datos de origen a la salida AWS DMS , utilice la configuración de tarea `BeforeImageSettings` o el parámetro `add-before-image-columns`. Este parámetro aplica una regla de transformación de columna.
`BeforeImageSettings` agrega un nuevo atributo JSON a cada operación de actualización con valores recopilados desde el sistema de base de datos de origen, como se muestra a continuación.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**nota**
Aplicar `BeforeImageSettings` a tareas de carga completa más CDC (que migran datos existentes y replican cambios en curso) o a tareas de solo CDC (que replican cambios de datos solamente). No se aplica `BeforeImageSettings` a tareas que son solo de carga completa.
Para las opciones de `BeforeImageSettings`, se aplica lo siguiente:
+ Establezca la opción `EnableBeforeImage` para habilitar `true` antes de crear imágenes. El valor predeterminado es `false`.
+ Utilice la opción `FieldName` para asignar un nombre al nuevo atributo JSON. Cuando `EnableBeforeImage` es `true`, `FieldName` es necesario y no puede estar vacío.
+ La opción `ColumnFilter` especifica una columna para agregar mediante el uso de las imágenes anteriores. Para agregar solo columnas que forman parte de las claves principales de la tabla, utilice el valor predeterminado, `pk-only`. Para agregar solo columnas que no son del tipo LOB, utilice `non-lob`. Para agregar cualquier columna que tenga un valor de imagen anterior, utilice `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Uso de una regla de transformación de imagen anterior
Como alternativa a la configuración de tareas, puede utilizar el parámetro `add-before-image-columns`, que aplica una regla de transformación de columnas. Con este parámetro, puede habilitar las imágenes anteriores durante CDC en destinos de transmisión de datos como Kafka.
Al utilizar `add-before-image-columns` en una regla de transformación, puede aplicar un control más detallado de los resultados de la imagen anterior. Las reglas de transformación permiten utilizar un localizador de objetos que le da control sobre las tablas seleccionadas para la regla. Además, puede encadenar reglas de transformación, lo que permite aplicar diferentes reglas a diferentes tablas. A continuación, puede manipular las columnas producidas utilizando otras reglas.
**nota**
No utilice el parámetro `add-before-image-columns` junto con la configuración de tarea `BeforeImageSettings` dentro de la misma tarea. En su lugar, utilice el parámetro o la configuración, pero no ambos, para una sola tarea.
Un tipo de regla `transformation` con el parámetro `add-before-image-columns` de una columna debe proporcionar una sección `before-image-def`. A continuación se muestra un ejemplo.
```
{
"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,
}
}
```
El valor de `column-prefix` se antepone a un nombre de columna y el valor predeterminado de `column-prefix` es `BI_`. El valor de `column-suffix` se añade al nombre de la columna y el valor predeterminado está vacío. No configure ambas cadenas `column-prefix` y `column-suffix` como cadenas vacías.
Elija un valor para `column-filter`. Para agregar solo columnas que forman parte de las claves principales de la tabla, elija `pk-only`. Elija `non-lob` para agregar solo columnas que no sean de tipo LOB. O elija `all` para agregar cualquier columna que tenga un valor de imagen anterior.
### Ejemplo de una regla de transformación de imagen anterior
La regla de transformación del siguiente ejemplo agrega una nueva columna llamada `BI_emp_no` en el destino. Entonces, una instrucción como `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` rellena el campo `BI_emp_no` con 1. Cuando escribe actualizaciones de CDC en destinos de Amazon S3, la columna `BI_emp_no` permite indicar qué fila original se actualizó.
```
{
"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 obtener información sobre el uso de la acción de regla `add-before-image-columns`, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Limitaciones a la hora de utilizar Apache Kafka como destino para AWS Database Migration Service
Al utilizar Apache Kafka como destino, se aplican las siguientes restricciones:
+ AWS DMS Los puntos de enlace de destino de Kafka no admiten el control de acceso de IAM para Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ No se admite el modo LOB completo.
+ Especifique un archivo de configuración de Kafka para su clúster con propiedades que permitan AWS DMS crear nuevos temas automáticamente. Incluya el valor `auto.create.topics.enable = true`. Si utiliza Amazon MSK, puede especificar la configuración predeterminada al crear el clúster de Kafka y, a continuación, cambiar la configuración de `auto.create.topics.enable` a `true`. Para obtener más información acerca de los valores de configuración predeterminados, consulte [La configuración predeterminada de Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) en la *Guía para desarrolladores de Amazon Managed Streaming para Apache Kafka*. Si necesita modificar un clúster de Kafka existente creado con Amazon MSK, ejecute el AWS CLI comando `aws kafka create-configuration` para actualizar la configuración de Kafka, como en el siguiente ejemplo:
```
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"
}
```
Aquí, `//~/kafka_configuration` es el archivo de configuración que ha creado con los valores de propiedades necesarios.
Si utiliza su propia instancia de Kafka instalada en Amazon EC2, modifique la configuración del clúster de Kafka con `auto.create.topics.enable = true` la configuración AWS DMS que permita la creación automática de nuevos temas mediante las opciones que se proporcionan con la instancia.
+ AWS DMS publica cada actualización en un único registro de la base de datos de origen como un registro de datos (mensaje) de un tema de Kafka determinado, independientemente de las transacciones.
+ AWS DMS admite las siguientes cuatro formas de claves de partición:
+ `SchemaName.TableName` una combinación del nombre de esquema y de tabla.
+ `${AttributeName}`: el valor de uno de los campos del archivo JSON o la clave principal de la tabla de la base de datos de origen.
+ `transaction-id`: El identificador de transacción de los CDC. Todos los registros de la misma transacción van a la misma partición.
+ `constant`: un valor literal fijo para cada registro, independientemente de la tabla o los datos. Todos los registros se envían al mismo valor de clave de partición «constante», lo que proporciona un orden global estricto en todas las tablas.
```
{
"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"
}
}
```
+ La configuración del `IncludeTransactionDetails` punto final solo se admite cuando el punto final de origen es Oracle, SQL Server, PostgreSQL o MySQL. En el caso de otros tipos de puntos finales de origen, no se incluirán los detalles de la transacción.
+ `BatchApply` no es compatible con un punto de conexión de Kafka. Es posible que el uso de la aplicación por lotes (por ejemplo, la configuración de tareas de metadatos de destino `BatchApplyEnabled`) para un objetivo de Kafka provoque la pérdida de datos.
+ AWS DMS no admite la migración de valores de tipos de `BigInt` datos con más de 16 dígitos. Para evitar esta limitación, puede usar la siguiente regla de transformación para convertir la columna `BigInt` en una cadena. Para obtener más información sobre las reglas de transformación, consulte [Reglas y acciones de transformación](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 Los puntos de enlace de destino de Kafka no son compatibles con Amazon MSK servless.
+ Al definir las reglas de asignación, no se admite disponer de una regla de asignación de objetos y una regla de transformación. Debe establecer solo una regla.
+ AWS DMS admite la autenticación SASL para las versiones de Apache Kafka hasta la 3.8. Si utiliza Kafka 4.0 o una versión superior, solo puede conectarse sin la autenticación SASL.
+ AWS DMS no admite datos de origen que contengan `'\0'` caracteres incrustados cuando se utiliza Kafka como punto final de destino. Los datos que contengan `'\0'` caracteres incrustados se truncarán en el primer carácter. `'\0'`
## Uso de la asignación de objetos para migrar datos a un tema de Kafka
AWS DMS utiliza reglas de mapeo de tablas para mapear los datos del tema de Kafka de origen al tema de Kafka de destino. Para asignar datos a un tema de destino, se utiliza un tipo de regla de asignación de tablas denominado asignación de objetos. Puede utilizar el mapeo de objetos para definir cómo los registros de datos del origen se asignan a los registros de datos publicados en un tema de Kafka.
Los temas de Kafka no tienen una estructura predeterminada distinta de una clave de partición.
**nota**
No tiene que utilizar la asignación de objetos. Puede utilizar la asignación de tablas normal para varias transformaciones. Sin embargo, el tipo de clave de partición seguirá estos comportamientos predeterminados:
La clave principal se usa como clave de partición para la carga completa.
Si no se utiliza ninguna configuración de tareas de aplicación paralela, `schema.table` se utiliza como clave de partición para CDC.
Si se utiliza la configuración de tareas de aplicación paralela, la clave principal se utiliza como clave de partición para CDC.
Para crear una regla de mapeo de objetos, se especifica `rule-type` como `object-mapping`. Esta regla indica el tipo de mapeo de objetos que desea utilizar.
La estructura de la regla es la siguiente.
```
{
"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 actualmente admite `map-record-to-record` y es `map-record-to-document` el único valor válido para el parámetro. `rule-action` Esta configuración afecta a los valores que no están excluidos como parte de la lista de atributos `exclude-columns`. Los `map-record-to-document` valores `map-record-to-record` y especifican cómo se AWS DMS gestionan estos registros de forma predeterminada. Estos valores no afectan a los mapeos de atributos en modo alguno.
Utilice `map-record-to-record` al migrar desde una base de datos relacional a un tema de Kafka. Este tipo de regla utiliza el valor `taskResourceId.schemaName.tableName` de la base de datos relacional como la clave de partición en el tema de Kafka y crea un atributo para cada columna de la base de datos de origen.
Cuando utilice `map-record-to-record`, tenga en cuenta lo siguiente:
+ Esta configuración solo afecta a las columnas excluidas de la lista `exclude-columns`.
+ Para cada columna de este tipo, AWS DMS crea un atributo correspondiente en el tema de destino.
+ AWS DMS crea el atributo correspondiente independientemente de si la columna de origen se utiliza en una asignación de atributos.
Una forma de entender `map-record-to-record` es verlo en acción. En este ejemplo, imagine que empieza con una fila de una tabla de base de datos relacional con la estructura y los datos siguientes.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Para migrar esta información desde un esquema denominado `Test` a un tema de Kafka, cree reglas para mapear los datos al tema. La siguiente regla ilustra la operación de asignación.
```
{
"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"
}
}
]
}
```
Dados un tema de Kafka y una clave de partición (en este caso, `taskResourceId.schemaName.tableName`), a continuación se ilustra el formato de registro resultante al usar nuestros datos de ejemplo en el tema de destino de 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**
+ [Reestructuración de datos con el mapeo de atributos](#CHAP_Target.Kafka.AttributeMapping)
+ [Replicación multitemática mediante asignación de objetos](#CHAP_Target.Kafka.MultiTopic)
+ [Formato de mensajes para Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Reestructuración de datos con el mapeo de atributos
Puede reestructurar los datos mientras los migra a un tema de Kafka utilizando un mapa de atributos. Por ejemplo, es posible que desee combinar varios campos del origen en un único campo en el destino. El mapa de atributos siguiente ilustra cómo reestructurar los datos.
```
{
"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 establecer un valor constante para`partition-key`, especifique`"partition-key-type: "constant"`, esto establece el valor de la partición en`constant`. Tal vez desee hacer esto, por ejemplo, para obligar a que todos los datos se almacenen en una única partición. El siguiente mapeo ilustra este enfoque.
```
{
"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**
El valor `partition-key` de un registro de control para una tabla específica es `TaskId.SchemaName.TableName`. El valor `partition-key` de un registro de control para una tabla específica es el `TaskId` de ese registro. La especificación de un valor `partition-key` en el mapeo de objetos no tiene ningún efecto en el elemento `partition-key` de un registro de control.
Si `partition-key-type` se establece `attribute-name` en una regla de mapeo de tablas, debe especificarse`partition-key-name`, que debe hacer referencia a una columna de la tabla de origen o a una columna personalizada definida en la asignación. Además, `attribute-mappings` debe proporcionarse para definir cómo se asignan las columnas de origen al tema de Kafka de destino.
### Replicación multitemática mediante asignación de objetos
De forma predeterminada, AWS DMS las tareas migran todos los datos de origen a uno de los siguientes temas de Kafka:
+ Como se especifica en el campo **Tema** del punto final de AWS DMS destino.
+ Como especifica `kafka-default-topic` si el campo **Tema** del punto de conexión de destino no está rellenado y la configuración `auto.create.topics.enable` de Kafka está establecida en `true`.
Con las versiones 3.4.6 y posteriores AWS DMS del motor, puede usar el `kafka-target-topic` atributo para asignar cada tabla fuente migrada a un tema diferente. Por ejemplo, las siguientes reglas de asignación de objetos migran las tablas de origen `Customer` y `Address` a los temas de Kafka `customer_topic` y `address_topic`, respectivamente. Al mismo tiempo, AWS DMS migra todas las demás tablas de origen, incluida la `Bills` tabla del `Test` esquema, al tema especificado en el punto final 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"
}
}
]
}
```
Al utilizar la replicación multitema de Kafka, puede agrupar y migrar las tablas de origen para separar los temas de Kafka mediante una única tarea de replicación.
### Formato de mensajes para Apache Kafka
La salida JSON es simplemente una lista de pares de clave-valor.
**RecordType**
El tipo de registro puede ser de datos o de control. Los *registros de datos *representan las filas reales en el origen. Los *registros de control* son para eventos importantes de la secuencia como, por ejemplo, el reinicio de una tarea.
**Operación**
Para los registros de datos, la operación puede ser `load`, `insert`, `update` o `delete`.
Para los registros de control, la operación puede ser `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` o `column-type-change`.
**SchemaName**
El esquema de origen del registro. Este campo puede estar vacío para un registro de control.
**TableName**
La tabla de origen del registro. Este campo puede estar vacío para un registro de control.
**Timestamp**
La marca temporal que indica cuándo se creó el mensaje JSON. El campo está formateado con el formato ISO 8601.
El siguiente ejemplo de mensaje JSON ilustra un mensaje de tipo de datos con todos los metadatos adicionales.
```
{
"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"
}
}
```
El siguiente ejemplo de mensaje JSON ilustra un mensaje de tipo control.
```
{
"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"
}
}
```
# Utilizar un clúster OpenSearch de Amazon Service como objetivo para AWS Database Migration Service
Se puede utilizar AWS DMS para migrar datos a Amazon OpenSearch Service (OpenSearch Servicio). OpenSearch El servicio es un servicio gestionado que facilita la implementación, el funcionamiento y el escalado de un clúster OpenSearch de servicios.
En OpenSearch Service, se trabaja con índices y documentos. Un *índice* es una colección de documentos y un *documento* es un objeto JSON que contiene valores escalares, matrices y otros objetos. OpenSearch proporciona un lenguaje de consulta basado en JSON para que pueda consultar los datos de un índice y recuperar los documentos correspondientes.
Cuando AWS DMS crea índices para un punto final de destino para OpenSearch Service, crea un índice para cada tabla desde el punto final de origen. El coste de crear un índice OpenSearch de servicios depende de varios factores. Estos son el número de índices creados, la cantidad total de datos que contienen y la pequeña cantidad de metadatos que se OpenSearch almacenan para cada documento.
Configure su clúster de OpenSearch servicios con los recursos de procesamiento y almacenamiento adecuados para el alcance de la migración. Le recomendamos que tenga en cuenta los factores siguientes, en función de la tarea de replicación que desee utilizar:
+ Para una carga de datos completa, considere la cantidad total de datos que va a migrar, así como la velocidad de la transferencia.
+ Para replicar los cambios en curso, tenga en cuenta la frecuencia de las actualizaciones y sus requisitos de end-to-end latencia.
Además, configure los ajustes del índice en su OpenSearch clúster, prestando especial atención al recuento de documentos.
**Configuración de tareas de carga completa con varios subprocesos**
Para ayudar a aumentar la velocidad de la transferencia, AWS DMS admite una carga completa de subprocesos múltiples a un clúster de destino del OpenSearch servicio. AWS DMS admite este subprocesamiento múltiple con una configuración de tareas que incluye lo siguiente:
+ `MaxFullLoadSubTasks`: utilice esta opción para indicar el número máximo de tablas de origen que se pueden cargar en paralelo. DMS carga cada tabla en su índice de objetivos de OpenSearch servicio correspondiente mediante una subtarea dedicada. El valor predeterminado es 8, el valor máximo es 49.
+ `ParallelLoadThreads`— Utilice esta opción para especificar el número de subprocesos que se AWS DMS utilizan para cargar cada tabla en su índice de destino OpenSearch de servicio. El valor máximo para un objetivo OpenSearch de servicio es 32. Puede pedir que se incremente este límite máximo.
**nota**
Si no cambia `ParallelLoadThreads` desde su valor predeterminado (0), AWS DMS transfiere un solo registro a la vez. Este enfoque supone una carga excesiva para el clúster OpenSearch de servicios. Asegúrese de que configura esta opción en 1 o más.
+ `ParallelLoadBufferSize`— Utilice esta opción para especificar el número máximo de registros que se almacenarán en el búfer que utilizan los subprocesos de carga paralela para cargar datos en el destino del OpenSearch servicio. El valor predeterminado es 50. El valor máximo es 1000. Utilice este parámetro con `ParallelLoadThreads`. `ParallelLoadBufferSize` es válido solo cuando hay más de un subproceso.
Para obtener más información sobre cómo DMS carga un clúster de OpenSearch servicios mediante subprocesos múltiples, consulte la AWS entrada del blog Scale [Amazon OpenSearch Service](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) for migrations. AWS Database Migration Service
**Configuración de tareas de carga de CDC con varios subprocesos**
Puede mejorar el rendimiento de la captura de datos de cambios (CDC) para un clúster de destino de un OpenSearch servicio mediante la configuración de tareas para modificar el comportamiento de la llamada a la API. `PutRecords` Para ello, puede especificar el número de subprocesos simultáneos, las colas por subproceso y el número de registros que se van a almacenar en un búfer mediante la configuración de tareas `ParallelApply*`. Suponga, por ejemplo, que desea realizar una carga de CDC y aplicar 32 subprocesos en paralelo. También desea acceder a 64 colas por subproceso, con 50 registros almacenados por búfer.
**nota**
El soporte para el uso de la configuración de `ParallelApply*` tareas durante los puntos finales de destino de CDC a Amazon OpenSearch Service está disponible en AWS DMS las versiones 3.4.0 y posteriores.
Para promover el desempeño de los CDC, AWS DMS apoya las siguientes configuraciones de tareas:
+ `ParallelApplyThreads`— Especifica la cantidad de subprocesos simultáneos que se AWS DMS utilizan durante una carga de CDC para enviar los registros de datos a un punto final de destino del OpenSearch servicio. El valor predeterminado es cero (0) y el valor máximo es 32.
+ `ParallelApplyBufferSize`— Especifica el número máximo de registros que se deben almacenar en cada cola de búfer para que los subprocesos simultáneos se envíen a un punto final de destino del OpenSearch servicio durante una carga de CDC. El valor predeterminado es 100 y el máximo es 1000. Utilice esta opción cuando `ParallelApplyThreads` especifique más de un subproceso.
+ `ParallelApplyQueuesPerThread`— Especifica el número de colas a las que accede cada subproceso para extraer los registros de datos de las colas y generar una carga por lotes para un punto final del servicio durante la CDC. OpenSearch
Cuando se utiliza la configuración de tareas `ParallelApply*`, el valor predeterminado de `partition-key-type` es el valor de `primary-key` de la tabla, no el valor de `schema-name.table-name`.
## Migración de una tabla de base de datos relacional a un índice de servicios OpenSearch
AWS DMS admite la migración de datos a los tipos de datos escalares del OpenSearch Servicio. Al migrar de una base de datos relacional como Oracle o MySQL a OpenSearch Service, es posible que desee reestructurar la forma en que almacena estos datos.
AWS DMS admite los siguientes tipos de datos escalares OpenSearch de servicio:
+ Booleano
+ Date
+ Flotante
+ Int
+ Cadena
AWS DMS convierte los datos de tipo Date en tipo String. Puede especificar la asignación personalizada para interpretar estas fechas.
AWS DMS no admite la migración de tipos de datos LOB.
## Requisitos previos para utilizar Amazon OpenSearch Service como objetivo para AWS Database Migration Service
Antes de empezar a trabajar con una base de datos de OpenSearch servicios como destino AWS DMS, asegúrese de crear un rol AWS Identity and Access Management (de IAM). Esta función debería permitir el AWS DMS acceso a los índices del OpenSearch servicio en el punto final de destino. El conjunto mínimo de permisos de acceso se muestra en la siguiente política de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
El rol que utilice para la migración al OpenSearch Servicio debe tener los siguientes permisos.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
En el ejemplo anterior, `region` sustitúyalo por el identificador de AWS región, *`account-id`* por el ID de tu AWS cuenta y `domain-name` por el nombre de tu dominio de Amazon OpenSearch Service. Un ejemplo es `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`.
## Configuración del punto final cuando se utiliza el OpenSearch Servicio como destino para AWS DMS
Puede utilizar los ajustes de punto final para configurar la base de datos de destino del OpenSearch Servicio de forma similar a como se utilizan atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el `create-endpoint` comando del [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintaxis `--elasticsearch-settings '{"EndpointSetting": "value", ...}'` JSON.
En la siguiente tabla se muestran los ajustes de punto final que puede utilizar con OpenSearch Service como destino.
| Nombre de atributo | Valores válidos | Valor predeterminado y descripción |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Un número entero positivo mayor que 0, pero menor que 100. | 10: para una tarea de carga completa, este atributo determina el umbral de errores permitidos antes de producirse un error en la tarea. Por ejemplo, suponga que hay 1 500 filas en el punto de enlace de origen y que este parámetro está establecido en 10. Entonces, la tarea falla si AWS DMS encuentra más de 150 errores (el 10 por ciento del recuento de filas) al escribir en el punto final de destino. |
| `ErrorRetryDuration` | Un número entero positivo mayor que 0. | 300: si se produce un error en el punto final de destino, AWS DMS vuelve a intentarlo durante ese número de segundos. De lo contrario, la tarea produce un error. |
| `UseNewMappingType` | true o false | `false`, pero para trabajar con opensearch v2.x, debe configurarse en `true`. |
## Limitaciones al utilizar Amazon OpenSearch Service como objetivo para AWS Database Migration Service
Cuando se utiliza Amazon OpenSearch Service como objetivo, se aplican las siguientes limitaciones:
+ OpenSearch El servicio utiliza el mapeo dinámico (estimación automática) para determinar los tipos de datos que se utilizarán para los datos migrados.
+ OpenSearch El servicio almacena cada documento con un identificador único. A continuación, se muestra un ID de ejemplo.
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Cada ID de documento tiene una longitud de 64 bytes, por lo que debe prever este requisito de almacenamiento. Por ejemplo, si migra 100 000 filas de una AWS DMS fuente, el índice de OpenSearch servicios resultante requiere almacenamiento de 6 400 000 bytes adicionales.
+ Con OpenSearch Service, no puede actualizar los atributos clave principales. Esta restricción es importante cuando se utiliza la replicación continua con captura de datos de cambio (CDC), ya que puede resultar en la presencia de datos no deseados en el destino. En el modo CDC, las claves principales se asignan a SHA256 valores, que tienen una longitud de 32 bytes. Se convierten en cadenas de 64 bytes legibles por humanos y se utilizan como documento de servicio. OpenSearch IDs
+ Si AWS DMS encuentra algún elemento que no se pueda migrar, escribe mensajes de error en Amazon CloudWatch Logs. Este comportamiento difiere del de otros puntos finales de AWS DMS destino, que escriben los errores en una tabla de excepciones.
+ AWS DMS no admite la conexión a un clúster de Amazon ES que tenga habilitado el control de acceso detallado con un usuario maestro y una contraseña.
+ AWS DMS no es compatible con el servicio sin servidor OpenSearch .
+ OpenSearch El servicio no admite la escritura de datos en índices preexistentes.
+ La configuración de tareas de replicación no `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` se admite para su uso con un punto final de OpenSearch destino.
+ Al migrar datos a Amazon Elasticsearch mediante AWS DMS, los datos de origen deben tener una clave principal o una columna de identificador único. Si los datos de origen no tienen una clave principal o un identificador único, debe definir uno mediante la define-primary-key regla de transformación.
## Tipos de datos de destino para Amazon OpenSearch Service
Cuando AWS DMS migra datos de bases de datos heterogéneas, el servicio mapea los tipos de datos de la base de datos de origen a tipos de datos intermedios, denominados tipos de AWS DMS datos. A continuación, el servicio asigna los tipos de datos intermedios a los tipos de datos de destino. La siguiente tabla muestra cada tipo de AWS DMS datos y el tipo de datos al que se asigna en OpenSearch Service.
| AWS DMS tipo de datos | OpenSearch tipo de datos de servicio |
| --- | --- |
| Booleano | booleano |
| Fecha | cadena |
| Tiempo | date |
| Marca temporal | date |
| INT4 | entero |
| Real4 | float |
| UINT4 | entero |
Para obtener información adicional sobre AWS DMS los tipos de datos, consulte[Tipos de datos de AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Uso de Amazon DocumentDB como destino para AWS Database Migration Service
Para obtener información sobre las versiones de Amazon DocumentDB (compatibles con MongoDB) compatibles, consulte. AWS DMS [Objetivos para AWS DMS](CHAP_Introduction.Targets.md) Puede usar AWS DMS para migrar datos a Amazon DocumentDB (con compatibilidad con MongoDB) desde cualquiera de los motores de datos de origen compatibles con AWS DMS . El motor de origen puede estar en un servicio AWS gestionado como Amazon RDS, Aurora o Amazon S3. O el motor puede estar en una base de datos autoadministrada, como MongoDB ejecutándose en Amazon EC2 o en las instalaciones.
Puede utilizarlos AWS DMS para replicar los datos de origen en bases de datos, colecciones o documentos de Amazon DocumentDB.
**nota**
Si el punto de conexión de origen es MongoDB o Amazon DocumentDB, ejecute la migración en **modo documento**.
MongoDB almacena los datos en un formato JSON binario (BSON). AWS DMS admite todos los tipos de datos BSON compatibles con Amazon DocumentDB. Para obtener una lista de estos tipos de datos, consulte [ APIsMongoDB, operaciones y tipos de datos compatibles en la Guía](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) para desarrolladores de *Amazon DocumentDB.*
Si el punto final de origen es una base de datos relacional, AWS DMS asigna los objetos de la base de datos a Amazon DocumentDB de la siguiente manera:
+ Una base de datos relacional o un esquema de base de datos, se asigna una *base de datos* de Amazon DocumentDB.
+ Las tablas de una base de datos relacional se corresponden con *recopilaciones* en Amazon DocumentDB.
+ Los registros de una tabla relacional se asignan a *documentos* en Amazon DocumentDB. Cada documento se crea a partir de los datos del registro de origen.
Si el punto de conexión de origen es Amazon S3, los objetos de Amazon DocumentDB resultantes se corresponden con reglas de asignación de AWS DMS para Amazon S3. Considere, por ejemplo, el siguiente URI.
```
s3://amzn-s3-demo-bucket/hr/employee
```
En este caso, AWS DMS asigne los objetos `amzn-s3-demo-bucket` a Amazon DocumentDB de la siguiente manera:
+ La parte del URI del nivel superior (`hr`) se asigna a una base de datos de Amazon DocumentDB.
+ La parte del URI siguiente (`employee`) se asigna a una recopilación de Amazon DocumentDB.
+ Cada objeto en `employee` asigna un documento de Amazon DocumentDB.
Para obtener más información sobre las reglas de asignación de Amazon S3, consulte [Uso de Amazon S3 como fuente de AWS DMS](CHAP_Source.S3.md).
**Configuración del punto de conexión de Amazon DocumentDB**
En AWS DMS las versiones 3.5.0 y posteriores, puede mejorar el rendimiento de la captura de datos de cambios (CDC) para los puntos de enlace de Amazon DocumentDB ajustando la configuración de las tareas para los subprocesos paralelos y las operaciones masivas. Para ello, puede especificar el número de subprocesos simultáneos, las colas por subproceso y el número de registros que se van a almacenar en un búfer mediante la configuración de tareas `ParallelApply*`. Suponga, por ejemplo, que desea realizar una carga de CDC y aplicar 128 subprocesos en paralelo. También desea acceder a 64 colas por subproceso, con 50 registros almacenados por búfer.
Para promover el desempeño de los CDC, AWS DMS es compatible con las siguientes configuraciones de tareas:
+ `ParallelApplyThreads`— Especifica el número de subprocesos simultáneos que se AWS DMS utilizan durante una carga de CDC para enviar registros de datos a un punto final de destino de Amazon DocumentDB. El valor predeterminado es cero (0) y el valor máximo es 32.
+ `ParallelApplyBufferSize`: especifica el número máximo de registros que se almacenan en cada cola del búfer para los subprocesos simultáneos que insertan datos en un punto de conexión de destino de Amazon DocumentDB durante una carga de CDC. El valor predeterminado es 100 y el máximo es 1000. Utilice esta opción cuando `ParallelApplyThreads` especifique más de un subproceso.
+ `ParallelApplyQueuesPerThread`: especifica el número de colas a las que accede cada subproceso para sacar registros de datos de las colas y generar una carga por lotes para un punto de conexión de Amazon DocumentDB durante el proceso de CDC. El valor predeterminado de es 1. El máximo es 512.
**nota**
En el caso de los objetivos de Amazon DocumentDB, la solicitud paralela de los CDC puede provocar errores clave duplicados o el estancamiento de la solicitud de los CDC para las cargas de trabajo que utilizan índices únicos secundarios o que requieren un orden estricto de los cambios. Utilice la configuración de aplicación CDC de subproceso único predeterminada para estas cargas de trabajo.
Para obtener información adicional sobre cómo trabajar con Amazon DocumentDB como destino AWS DMS, consulte las siguientes secciones:
**Topics**
+ [Asignación de datos desde un origen a un destino de Amazon DocumentDB](#CHAP_Target.DocumentDB.data-mapping)
+ [Conexión a los clústeres elásticos de Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Replicación continua con Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Limitaciones para usar Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.limitations)
+ [Uso de la configuración de puntos de conexión con Amazon DocumentDB como destino](#CHAP_Target.DocumentDB.ECAs)
+ [Tipos de datos de destino de Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**nota**
Para obtener información step-by-step detallada sobre el proceso de migración, consulte [Migración de MongoDB a Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html) en la Guía de migración. AWS Database Migration Service Step-by-Step
## Asignación de datos desde un origen a un destino de Amazon DocumentDB
AWS DMS lee los registros del punto final de origen y crea documentos JSON en función de los datos que lee. Para cada documento JSON, AWS DMS debe determinar un `_id` campo que actúe como identificador único. A continuación, escribe el documento JSON en una recopilación de Amazon DocumentDB, con el campo `_id` como clave principal.
### Datos de origen que están en una sola columna
Si los datos de origen constan de una única columna, deben ser del tipo cadena. (Según el motor de origen, el tipo de datos real puede ser VARCHAR, NVARCHAR, TEXT, LOB, CLOB o similar). AWS DMS asume que los datos son un documento JSON válido y los replica en Amazon DocumentDB tal cual.
Si el documento JSON resultante contiene un campo llamado `_id`, entonces se utiliza ese campo como el `_id` único en Amazon DocumentDB.
Si JSON no contiene un campo `_id`, Amazon DocumentDB genera un valor de `_id` automáticamente.
### Datos de origen que están en varias columnas
Si los datos de origen constan de varias columnas, crea un documento JSON a partir de todas estas columnas. AWS DMS Para determinar el `_id` campo del documento, AWS DMS proceda de la siguiente manera:
+ Si una de las columnas se llama `_id`, los datos de esa columna se utilizan como el `_id` de destino.
+ Si no hay ninguna `_id` columna, pero los datos de origen tienen una clave principal o un índice único, AWS DMS utiliza esa clave o valor de índice como `_id` valor. Los datos de la clave principal o el índice único también aparecen como campos explícitos en el documento JSON.
+ Si no hay ninguna columna `_id` y tampoco hay una clave principal o un índice único, Amazon DocumentDB genera un valor de `_id` automáticamente.
### Forzar un tipo de datos en el punto de enlace de destino
AWS DMS puede modificar las estructuras de datos cuando escribe en un punto final de destino de Amazon DocumentDB. Puede solicitar estos cambios modificando los nombres de las columnas y las tablas en el punto de enlace de origen o proporcionando reglas de transformación que se apliquen cuando se ejecute una tarea.
#### Uso de un documento JSON anidado (json\$1 prefix)
Para forzar un tipo de datos, puede incluir el prefijo `json_` en el nombre de la columna de origen (por ejemplo, `json_columnName`) manualmente o mediante una transformación. En este caso, la columna se crea como un documento JSON anidado dentro del documento de destino, en lugar de como un campo de cadena.
Suponga, por ejemplo, que desea migrar el siguiente documento desde un punto de enlace de origen de MongoDB.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Si no fuerza ningún tipo de datos de origen, el documento `ContactDetails` incrustado se migra como una cadena.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
Sin embargo, puede añadir una regla de transformación para obligar a que `ContactDetails` sea un objeto JSON. Suponga, por ejemplo, que el nombre original de la columna de origen es `ContactDetails`. Para utilizar el tipo de datos como JSON anidado, es necesario cambiar el nombre de la columna situada en el punto final de origen a «json\$1ContactDetails», ya sea añadiendo el prefijo «\$1json\$1\$1» a la fuente de forma manual o mediante reglas de transformación. Por ejemplo, puede usar la siguiente regla de transformación:
```
{
"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 el campo como JSON anidado, de la siguiente manera. ContactDetails
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Uso de una matriz JSON (array\$1 prefix)
Para forzar un tipo de datos, puede incluir el prefijo `array_` en el nombre de la columna (por ejemplo, `array_columnName`) manualmente o mediante una transformación. En este caso, AWS DMS considera la columna como una matriz JSON y la crea como tal en el documento de destino.
Suponga que desea migrar el siguiente documento desde un punto de enlace de origen de MongoDB.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Si no fuerza ningún tipo de datos de origen, el documento `ContactDetails` incrustado se migra como una cadena.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
Sin embargo, puede añadir reglas de transformación para imponer el tipo de datos de matriz JSON a `ContactAddress` y `ContactPhoneNumbers`, tal y como se muestra en la siguiente tabla.
****
| Nombre original de la columna de origen | Nuevo nombre de la columna de origen |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS se replica `ContactAddress` y de la `ContactPhoneNumbers` siguiente manera.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Conexión a Amazon DocumentDB mediante TLS
De forma predeterminada, un clúster de Amazon DocumentDB recién creado solo acepta conexiones seguras mediante la seguridad de la capa de transporte (TLS). Cuando TLS está habilitado, cada conexión a Amazon DocumentDB requiere una clave pública.
Puede recuperar la clave pública de Amazon DocumentDB descargando el archivo desde un bucket de Amazon S3 AWS alojado. `rds-combined-ca-bundle.pem` Para obtener más información acerca de la descarga de este archivo, consulte [Cifrado de conexiones mediante TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) en la *Guía para desarrolladores de Amazon DocumentDB*
Tras descargar este archivo.pem, puede importar la clave pública que contiene tal y AWS DMS como se describe a continuación.
#### Consola de administración de AWS
**Para importar el archivo de clave pública (.pem)**
1. [Abra la AWS DMS consola en /dms. https://console.aws.amazon.com](https://console.aws.amazon.com/dms)
1. En el panel de navegación, elija **Certificates**.
1. Elija **Import certificate (Importar certificado)** y haga lo siguiente:
+ En **Certificate identifier (Identificador del certificado)**, escriba un nombre único para el certificado (por ejemplo `docdb-cert`).
+ En **Import file (Archivo de importación)**, desplácese hasta la ubicación en la que guardó el archivo .pem.
Cuando los ajustes sean los deseados, elija **Add new CA certificate (Añadir nuevo certificado de CA)**.
#### AWS CLI
Utilice el comando `aws dms import-certificate`, tal y como se muestra en el ejemplo siguiente.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Al crear un punto final de AWS DMS destino, proporcione el identificador del certificado (por ejemplo,`docdb-cert`). A continuación, establezca el parámetro de modo de SSL en `verify-full`.
## Conexión a los clústeres elásticos de Amazon DocumentDB como destino
En AWS DMS las versiones 3.4.7 y posteriores, puede crear un punto final de destino de Amazon DocumentDB como un clúster elástico. Si crea el punto de conexión de destino como un clúster elástico, debe adjuntar un certificado SSL nuevo al punto de conexión del clúster elástico de Amazon DocumentDB, ya que el certificado SSL existente no funcionará.
**Asociación de un certificado SSL nuevo al punto de conexión del clúster elástico de Amazon DocumentDB**
1. En un navegador, abra [ https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) y guarde el contenido en un `.pem` archivo con un nombre de archivo único, por ejemplo. `SFSRootCAG2.pem` Este es el archivo de certificado que debe importar en los pasos siguientes.
1. Cree el punto de conexión del clúster elástico y establezca las siguientes opciones:
1. En **Configuración del punto de conexión**, elija **Agregar un nuevo certificado de entidad de certificación**.
1. En **Identificador del certificado**, escriba **SFSRootCAG2.pem**.
1. Para **Importar archivo de certificado**, elija **Elegir archivo**, después acceda al archivo `SFSRootCAG2.pem` que descargó anteriormente.
1. Seleccione y abra el archivo `SFSRootCAG2.pem` descargado.
1. Seleccione **Importar certificado**.
1. **En el menú desplegable **Elegir un certificado**, elija SFSRoot CAG2 .pem.**
El nuevo certificado SSL del archivo `SFSRootCAG2.pem` descargado ahora está adjunto al punto de conexión del clúster elástico de Amazon DocumentDB.
## Replicación continua con Amazon DocumentDB como destino
Si la replicación continua (captura de datos de cambios, CDC) está habilitada para Amazon DocumentDB como objetivo, las versiones 3.5.0 y superiores de AWS DMS proporcionan una mejora del rendimiento veinte veces mayor que las versiones anteriores. En versiones anteriores, en AWS DMS las que se gestionaban hasta 250 registros por segundo, AWS DMS ahora se procesan de forma eficiente más de 5000 registros por segundo. AWS DMS también garantiza que los documentos de Amazon DocumentDB permanezcan sincronizados con la fuente. Cuando se crea o actualiza un registro fuente, primero AWS DMS debe determinar qué registro de Amazon DocumentDB se ve afectado de la siguiente manera:
+ Si el registro de origen tiene una columna denominada `_id`, el valor de esa columna determina el `_id` correspondiente en la recopilación de Amazon DocumentDB.
+ Si no hay ninguna `_id` columna, pero los datos de origen tienen una clave principal o un índice único, AWS DMS utiliza esa clave o valor de índice como el de la `_id` colección Amazon DocumentDB.
+ Si el registro de origen no tiene una `_id` columna, una clave principal o un índice único, hace AWS DMS coincidir todas las columnas de origen con los campos correspondientes de la colección Amazon DocumentDB.
Cuando se crea un registro de origen nuevo, AWS DMS escribe el documento correspondiente en Amazon DocumentDB. Si se actualiza un registro de origen existente, AWS DMS actualiza los campos correspondientes del documento de destino en Amazon DocumentDB. Los campos que existen en el documento de destino pero no en el registro de origen se mantienen tal cual están.
Cuando se elimina un registro de origen, AWS DMS elimina el documento correspondiente de Amazon DocumentDB.
### Cambios estructurales (DDL) en el origen
Con la replicación continua, todos los cambios realizados en las estructuras de datos de origen (como tablas, columnas, etc.) se propagan a los elementos correspondientes en Amazon DocumentDB. En las bases de datos relacionales, estos cambios se inician con instrucciones del lenguaje de definición de datos (DDL). Puede ver cómo AWS DMS se propagan estos cambios a Amazon DocumentDB en la siguiente tabla.
****
| DDL en el origen | Efecto en el objetivo de Amazon DocumentDB |
| --- | --- |
| CREATE TABLE | Crea una colección vacía. |
| Instrucción que cambia el nombre de una tabla (RENAME TABLE, ALTER TABLE...RENAME y similar) | Cambia el nombre de la colección. |
| TRUNCATE TABLE | Elimina todos los documentos de la colección, pero solo si HandleSourceTableTruncated es true. Para obtener más información, consulte [Configuración de tareas para la administración de DDL del procesamiento de cambios](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Elimina la colección, pero solo si HandleSourceTableDropped es true. Para obtener más información, consulte [Configuración de tareas para la administración de DDL del procesamiento de cambios](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Instrucción que añade una columna a una tabla (ALTER TABLE...ADD y similar) | La instrucción DDL se omite y se envía una advertencia. Cuando se ejecuta la primera instrucción INSERT en el origen, se añade el nuevo campo al documento de destino. |
| ALTER TABLE...RENAME COLUMN | La instrucción DDL se omite y se envía una advertencia. Cuando se ejecuta la primera instrucción INSERT en el origen, el campo con el nuevo nombre se añade al documento de destino. |
| ALTER TABLE...DROP COLUMN | La instrucción DDL se omite y se envía una advertencia. |
| Instrucción que cambia el tipo de datos de las columnas (ALTER COLUMN...MODIFY y similar) | La instrucción DDL se omite y se envía una advertencia. Cuando se ejecuta la primera instrucción INSERT en el origen con el nuevo tipo de datos, se crea el documento de destino con un campo de ese nuevo tipo de datos. |
## Limitaciones para usar Amazon DocumentDB como destino
Se aplican las siguientes limitaciones cuando se utiliza Amazon DocumentDB como destino para: AWS DMS
+ En Amazon DocumentDB, los nombres de las recopilaciones no pueden incluir el símbolo del dólar (\$1). Además, los nombres de las bases de datos no pueden contener caracteres Unicode.
+ AWS DMS no admite la fusión de varias tablas de origen en una única colección de Amazon DocumentDB.
+ Cuando AWS DMS los procesos cambian desde una tabla de origen que no tiene una clave principal, se ignoran todas las columnas LOB de esa tabla.
+ Si la opción **Tabla de cambios** está habilitada y AWS DMS encuentra una columna de origen llamada “*\$1id*”, esa columna aparece como “*\$1\$1id*” (con dos guiones bajos) en la tabla de cambios.
+ Si elige Oracle como punto de enlace de origen, el origen de Oracle debe tener el registro suplementario completo habilitado. De lo contrario, si hay columnas en el origen que no han cambiado, los datos se cargan en Amazon DocumentDB como valores nulos.
+ La configuración de tareas de replicación, `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` no se admite para su uso con un punto de conexión de destino de DocumentDB.
+ Amazon DocumentDB no admite las colecciones limitadas de MongoDB. Sin embargo, AWS DMS migra automáticamente dichos objetos como colecciones ilimitadas en la DocumentDB de destino.
+ La solicitud paralela de los CDC a los objetivos de Amazon DocumentDB puede provocar errores clave duplicados o el estancamiento de la solicitud de los CDC para cargas de trabajo que utilizan índices únicos secundarios o que requieren un orden estricto de los cambios. Para este tipo de cargas de trabajo, utilice la configuración de aplicación CDC predeterminada de un solo subproceso.
## Uso de la configuración de puntos de conexión con Amazon DocumentDB como destino
Puede utilizar la configuración de punto de conexión para configurar la base de datos de destino de Amazon DocumentDB de forma similar al uso de atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el `create-endpoint` comando del [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la `--doc-db-settings '{"EndpointSetting": "value", ...}'` sintaxis JSON.
La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con Amazon DocumentDB como destino.
| Nombre de atributo | Valores válidos | Valor predeterminado y descripción |
| --- | --- | --- |
| `replicateShardCollections` | booleano `true` `false` | Cuando se establece en `true`, esta configuración de punto de conexión tiene los siguientes efectos e impone las siguientes limitaciones: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Tipos de datos de destino de Amazon DocumentDB
En la siguiente tabla, puede encontrar los tipos de datos de destino de Amazon DocumentDB que se admiten cuando se utiliza AWS DMS y el mapeo predeterminado a partir de los tipos de datos de AWS DMS. Para obtener más información sobre los tipos de datos de AWS DMS, consulte. [Tipos de datos de AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS Tipo de datos DMS | Tipo de datos de Amazon DocumentDB |
| --- | --- |
| BOOLEAN | Booleano |
| BYTES | Datos binarios |
| DATE | Date |
| TIME | Cadena () UTF8 |
| DATETIME | Date |
| INT1 | Entero de 32 bits |
| INT2 | Entero de 32 bits |
| INT4 | Entero de 32 bits |
| INT8 | Entero de 64 bits |
| NUMERIC | Cadena (UTF8) |
| REAL4 | Double |
| REAL8 | Double |
| STRING | Si los datos se reconocen como JSON, AWS DMS los migra a Amazon DocumentDB como un documento. De lo contrario, los datos se asignan a String (). UTF8 |
| UINT1 | Entero de 32 bits |
| UINT2 | Entero de 32 bits |
| UINT4 | Entero de 64 bits |
| UINT8 | Cadena () UTF8 |
| WSTRING | Si los datos se reconocen como JSON, AWS DMS los migra a Amazon DocumentDB como un documento. De lo contrario, los datos se asignan a String (). UTF8 |
| BLOB | Binario |
| CLOB | Si los datos se reconocen como JSON, AWS DMS los migra a Amazon DocumentDB como un documento. De lo contrario, los datos se asignan a String (). UTF8 |
| NCLOB | Si los datos se reconocen como JSON, AWS DMS los migra a Amazon DocumentDB como un documento. De lo contrario, los datos se asignan a String (). UTF8 |
# Uso de Amazon Neptune como objetivo para AWS Database Migration Service
Amazon Neptune es un servicio de base de datos de gráficos rápido, fiable y completamente administrado que le permite crear y ejecutar fácilmente aplicaciones que funcionen con conjuntos de datos altamente conectados. El componente principal de Neptune es un motor de base de datos de gráficos de alto rendimiento y personalizado. Este motor está optimizado para almacenar miles de millones de relaciones y consultar el gráfico con una latencia de milisegundos. Neptune es compatible con los populares lenguajes de consulta gráfica Apache TinkerPop Gremlin y SPARQL del W3C. Para obtener más información sobre Amazon Neptune, consulte [¿Qué es Amazon Neptune?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) en la *Guía del usuario de Amazon Neptune*.
Sin una base de datos de gráficos como Neptune, probablemente modele datos altamente conectados en una base de datos relacional. Como los datos tienen conexiones potencialmente dinámicas, las aplicaciones que usan dichos orígenes de datos deben modelar consultas de datos conectados en SQL. Este enfoque requiere que escriba una capa adicional para convertir consultas de gráficos a SQL. Además, las bases de datos relacionales vienen con rigidez de esquema. Cualquier cambio en el esquema para modelar las conexiones cambiantes requiere tiempo de inactividad y mantenimiento adicional de la conversión de la consulta para admitir el nuevo esquema. El rendimiento de la consulta es otra gran restricción a tener en cuenta al diseñar sus aplicaciones.
Las bases de datos de gráficos pueden simplificar en gran medida dichas situaciones. Sin ningún esquema, las capas (Gremlin o SPARQL) de consulta de gráficos enriquecidos y los índices optimizados para la consulta de gráficos aumentan la flexibilidad y el rendimiento. La base de datos de gráficos de Amazon Neptune también tiene características empresariales como el cifrado en reposo, una capa de autorización con seguridad, copias de seguridad por defecto, compatibilidad Multi-AZ, compatibilidad con réplicas de lectura, etc.
Con él AWS DMS, puede migrar datos relacionales que modelan un gráfico altamente conectado a un punto final de destino de Neptune desde un punto final de origen de DMS para cualquier base de datos SQL compatible.
Para obtener más detalles, consulte lo siguiente.
**Topics**
+ [Información general sobre la migración a Amazon Neptune como destino](#CHAP_Target.Neptune.MigrationOverview)
+ [Especificación de la configuración del punto de conexión de Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings)
+ [Creación de un rol de servicio de IAM para acceder a Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole)
+ [Especificación de reglas de asignación de gráficos mediante Gremlin y R2RML para Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping)
+ [Tipos de datos para la migración de Gremlin y R2RML a Amazon Neptune como destino](#CHAP_Target.Neptune.DataTypes)
+ [Restricciones del uso de Amazon Neptune como destino](#CHAP_Target.Neptune.Limitations)
## Información general sobre la migración a Amazon Neptune como destino
Antes de iniciar una migración a un objetivo de Neptune, cree los siguientes recursos en su AWS cuenta:
+ Un clúster de Neptune para el punto de conexión de destino.
+ Una base de datos relacional SQL compatible con el punto AWS DMS final de origen.
+ Un bucket de Amazon S3 para el punto de conexión de destino. Cree este depósito S3 en la misma AWS región que su clúster de Neptune. AWS DMS utiliza este depósito S3 como almacenamiento de archivos intermedio para los datos de destino que carga de forma masiva en la base de datos de Neptune. Para obtener más información sobre la creación de un bucket de S3, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service.*
+ Un punto de conexión de nube privada virtual (VPC) de S3 en la misma VPC que el clúster de Neptune.
+ Un rol AWS Identity and Access Management (de IAM) que incluye una política de IAM. Esta política especifica los permisos `GetObject`, `PutObject`, `DeleteObject` y `ListObject` del bucket de S3 de su punto de enlace de destino. Tanto AWS DMS Neptune como Neptune asumen esta función con acceso de IAM tanto al bucket S3 de destino como a la base de datos de Neptune. Para obtener más información, consulte [Creación de un rol de servicio de IAM para acceder a Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole).
Después de obtener estos recursos, la configuración y el inicio de una migración a un destino de Neptune es similar a cualquier migración de carga completa mediante la consola o la API de DMS. Sin embargo, una migración a un destino de Neptune requiere algunos pasos únicos.
**Para migrar una base de datos AWS DMS relacional a Neptune**
1. Cree una instancia de replicación como se describe en [Creación de una instancia de replicación](CHAP_ReplicationInstance.Creating.md).
1. Cree y pruebe una base de datos relacional SQL compatible con el punto final AWS DMS de origen.
1. Cree y pruebe el punto de conexión de destino de la base de datos de Neptune.
Para conectar el punto de conexión de destino con la base de datos de Neptune, especifique el nombre del servidor para el punto de conexión del clúster de Neptune o para el punto de conexión de la instancia de escritor de Neptune. Además, especifique la carpeta del bucket S3 para almacenar sus archivos intermedios AWS DMS para cargarlos de forma masiva en la base de datos de Neptune.
Durante la migración, AWS DMS almacena todos los datos de destino migrados en esta carpeta de bucket de S3 hasta el tamaño máximo de archivo que especifique. Cuando el almacenamiento de este archivo alcanza este tamaño máximo, carga de AWS DMS forma masiva los datos de S3 almacenados en la base de datos de destino. Luego elimina la carpeta para permitir el almacenamiento de cualquier dato de destino adicional para su carga posterior en la base de datos de destino. Para obtener más información sobre cómo especificar esta configuración, consulte [Especificación de la configuración del punto de conexión de Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings).
1. Cree una tarea de replicación de carga completa con los recursos que ha creado en los pasos 1-3 y haga lo siguiente:
1. Use la asignación de la tabla de tareas como de costumbre para identificar esquemas, tablas y vistas de origen concreto para migrar de su base de datos relacional mediante las reglas de transformación y selección adecuadas. Para obtener más información, consulte [Uso del mapeo de tablas para especificar la configuración de tareas](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Especifique las asignaciones de destino eligiendo una de las siguientes para especificar las reglas de asignación de las tablas y vistas de origen al gráfico de base de datos de destino de Neptune:
+ Gremlin JSON: para obtener información sobre el uso de JSON de Gremlin para cargar una base de datos de Neptune, consulte el [formato de datos de carga Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) en la *Guía del usuario de Amazon Neptune*.
+ Lenguaje de asignación del RDB al marco de descripción de recursos (R2RML) de SPARQL: para obtener información sobre el uso de R2RML de SPARQL, consulte la especificación de W3C [R2RML: lenguaje de asignación de RDB a RDF](https://www.w3.org/TR/r2rml/).
1. Realice una de las siguientes acciones:
+ Con la AWS DMS consola, especifique las opciones de mapeo de gráficos mediante las **reglas de mapeo de gráficos** en la página de **tareas Crear una base de datos para migrar**.
+ Con la AWS DMS API, especifique estas opciones mediante el parámetro de `TaskData` solicitud de la llamada a la `CreateReplicationTask` API.
Para obtener más información y ejemplos de uso de JSON de Gremlin y R2RML de SPARQL para especificar reglas de asignación de gráficos, consulte [Especificación de reglas de asignación de gráficos mediante Gremlin y R2RML para Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping).
1. Inicie la replicación de la tarea de migración.
## Especificación de la configuración del punto de conexión de Amazon Neptune como destino
Para crear o modificar un punto de enlace de destino, puede usar la consola o las operaciones de la API `CreateEndpoint` o `ModifyEndpoint`.
**Para un destino de Neptune en la AWS DMS consola, especifique la **configuración específica del punto final en la página Crear punto** **final o Modificar punto final** de la consola.** En `CreateEndpoint` y `ModifyEndpoint`, especifique los parámetros de solicitud de la opción `NeptuneSettings`. El siguiente ejemplo muestra cómo hacer esto usando la CLI.
```
dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com
--port 8192
--neptune-settings
'{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
"S3BucketName":"amzn-s3-demo-bucket",
"S3BucketFolder":"amzn-s3-demo-bucket-folder",
"ErrorRetryDuration":57,
"MaxFileSize":100,
"MaxRetryCount": 10,
"IAMAuthEnabled":false}‘
```
Aquí, la opción `--server-name` de la CLI especifica el nombre del servidor del punto de conexión del escritor del clúster de Neptune. O puede especificar el nombre del servidor para un punto de conexión de instancia del escritor de Neptune.
Los parámetros de la solicitud de la opción `--neptune-settings` son los siguientes:
+ `ServiceAccessRoleArn`: (requerido) el nombre de recurso de Amazon (ARN) del rol de servicio que ha creado para el punto de conexión de destino de Neptune. Para obtener más información, consulte [Creación de un rol de servicio de IAM para acceder a Amazon Neptune como destino](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName`: (requerido) el nombre del bucket de S3 en el que DMS puede almacenar temporalmente datos de gráficos migrados en archivos .csv antes de cargarlos en masa en la base de datos de destino de Neptune. DMS asigna los datos de origen SQL a datos gráficos antes de almacenarlos en estos archivos.csv.
+ `S3BucketFolder`: (requerido) una ruta de carpeta en la que desea que DMS almacene datos de gráficos migrados en el bucket de S3 especificado por `S3BucketName`.
+ `ErrorRetryDuration`: (opcional) el número de milisegundos para DMS que espera para volver a intentar una carga en masa de datos de gráficos migrados a la base de datos de destino de Neptune antes de generar un error. El valor predeterminado es 250.
+ `MaxFileSize`: (opcional) el tamaño máximo en KB de datos de gráficos migrados almacenados en un archivo .csv antes de que DMS cargue en masa los datos en la base de datos de destino de Neptune. El valor predeterminado es 1.048.576 KB (1 GB). Si se realiza correctamente, DMS borra el bucket y está listo para almacenar el siguiente lote de datos de gráficos migrados.
+ `MaxRetryCount`: (opcional) el número de veces que DMS vuelve a intentar una carga en masa de datos de gráficos migrados a la base de datos de destino de Neptune antes de generar un error. El valor predeterminado es 5.
+ `IAMAuthEnabled`: (opcional) si desea habilitar la autorización de IAM para este punto de conexión, establezca este parámetro en `true` y adjunte el documento de política de IAM correspondiente al rol de servicio especificado por `ServiceAccessRoleArn`. El valor predeterminado es `false`.
## Creación de un rol de servicio de IAM para acceder a Amazon Neptune como destino
Para acceder a Neptune como destino, cree un rol de servicio mediante IAM. En función de la configuración del punto de conexión de Neptune, adjunte a este rol alguna o todas las políticas de IAM y documentos de confianza. Cuando crea el punto de conexión de Neptune, proporciona el ARN de este rol de servicio. De este modo, AWS DMS Amazon Neptune podrá obtener permisos para acceder tanto a Neptune como a su bucket de Amazon S3 asociado.
Si establece el parámetro `IAMAuthEnabled` de `NeptuneSettings` en `true` en la configuración del punto de conexión de Neptune, adjunte una política de IAM como la siguiente al rol de servicio. Si establece `IAMAuthEnabled` como `false`, puede 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/*"
}
]
}
```
La política de IAM anterior permite acceso completo al clúster de destino de Neptune especificado por `Resource`.
Adjunte una política de IAM como la siguiente a su rol de servicio. Esta política permite a DMS almacenar de forma temporal datos de gráficos migrados en el bucket de S3 que ha creado para cargarlos por lotes a la base de datos de destino de Neptune.
```
//Policy to access S3 bucket
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ListObjectsInBucket0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": ["s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
},
{
"Sid": "ListObjectsInBucket1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
}
]
}
```
La política de IAM anterior permite a la cuenta consultar el contenido del bucket de S3 (`arn:aws:s3:::amzn-s3-demo-bucket`) creado para el destino de Neptune. También permite que su cuenta funcione completamente con el contenido de todos los archivos y carpetas del bucket (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Edite la relación de confianza y asocie la siguiente función de IAM a su función de servicio para permitir que AWS DMS tanto el servicio de base de datos Amazon Neptune asuman la función.
------
#### [ 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 obtener información sobre cómo especificar este rol de servicio para el punto de conexión de destino de Neptune, consulte [Especificación de la configuración del punto de conexión de Amazon Neptune como destino](#CHAP_Target.Neptune.EndpointSettings).
## Especificación de reglas de asignación de gráficos mediante Gremlin y R2RML para Amazon Neptune como destino
Las reglas de asignación de gráficos que cree especifican cómo se cargan los datos extraídos de un origen de base de datos relacional SQL en un destino de clúster Neptune de base de datos. El formato de estas reglas de mapeo varía en función de si se utilizan para cargar datos de gráficos de propiedades con Apache TinkerPop Gremlin o datos del Resource Description Framework (RDF) con R2RML. A continuación, puede encontrar información sobre estos formatos y dónde obtener más información.
Puede especificar estas reglas de asignación al crear la tarea de migración mediante la consola o la API de DMS.
Mediante la consola, especifique estas reglas de asignación mediante **Graph mapping rules (Reglas de asignación de gráficos)** en la página **Create database migration task (Crear migración de base de datos)**. En **Graph mapping rules (Reglas de asignación de gráficos)**, puede introducir y editar las reglas de asignación directamente mediante el editor proporcionado. También puede buscar un archivo que contenga las reglas de asignación en el formato de asignación de gráficos adecuado.
Mediante la API, especifique estas opciones mediante el parámetro de solicitud `TaskData` de la llamada a la API `CreateReplicationTask`. Establezca `TaskData` en la ruta de un archivo que contiene las reglas de asignación en el formato de asignación de gráficos adecuado.
### Reglas de mapeo de gráficos para generar datos de gráficos de propiedades mediante Gremlin
Usando Gremlin para generar los datos de gráficos de propiedades, especifique un objeto JSON con una regla de asignación para cada entidad de gráfico que se generará a partir de los datos de origen. El formato de este JSON se define específicamente para la carga por lotes de Amazon Neptune. La plantilla siguiente muestra el aspecto de cada regla en este 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)"
}
]
}
]
}
]
}
```
La presencia de una etiqueta de vértice implica que el vértice se está creando aquí. Su ausencia implica que el vértice es creado por una fuente diferente, y esta definición solo añade propiedades de vértice. Especifique tantas definiciones de borde y vértice como sea necesario para especificar las asignaciones de su origen de base de datos relacional entero.
A continuación se muestra una regla de ejemplo para una tabla de `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"
}
]
}
]
}
]
}
```
Aquí, las definiciones de vértice y borde asignan una relación de informe de un nodo `employee` con el ID de empleado (`EmpID`) y un nodo `employee` con un ID de empleado (`managerId`).
Para obtener más información acerca de la creación de reglas de asignación de gráficos mediante el JSON de Gremlin, consulte [Formato de datos de carga Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) en la *Guía del usuario de Amazon Neptune*.
### Reglas de RDF/SPARQL mapeo gráfico para generar datos
Si está cargando datos de RDF para realizar consultas mediante SPARQL, escriba las reglas de asignación de gráficos en R2RML. R2RML es un lenguaje W3C estándar para asignar datos relacionales a RDF. En un archivo R2RML, una *asignación de triples* (por ejemplo, el `<#TriplesMap1>` a continuación) especifica una regla para traducir cada fila de una tabla lógica a cero o más triples de RDF. Una *asignación de asunto* (por ejemplo, cualquier `rr:subjectMap` a continuación) especifica una regla para generar los sujetos de los triples de RDF generados por las asignaciones de triples. Una *asignación de predicación-objeto* (por ejemplo, cualquier `rr:predicateObjectMap` a continuación) es una función que crea uno o más pares de predicación-objeto para cada fila de tabla lógica de una tabla lógica.
A continuación se muestra un sencillo ejemplo 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" ];
]
```
En el ejemplo anterior, la asignación define los nodos de gráficos asignados a partir de una tabla de empleados.
A continuación se muestra otro sencillo ejemplo de una tabla de `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" ]
].
```
En el ejemplo anterior, el mapeo define los nodos gráficos que mapean friend-of-a-friend las relaciones entre las personas de una `Student` tabla.
Para obtener más información acerca de la creación de reglas de mapeo de gráficos mediante SPARQL R2RML, consulte la especificación de W3C [R2RML: RDB to RDF mapping language](https://www.w3.org/TR/r2rml/).
## Tipos de datos para la migración de Gremlin y R2RML a Amazon Neptune como destino
AWS DMS realiza la asignación de tipos de datos desde el punto final de origen de SQL al destino de Neptune de dos maneras. La forma en que los utilice depende del formato de asignación de gráficos que utilice para cargar la base de datos de Neptune:
+ Apache TinkerPop Gremlin, mediante una representación en JSON de los datos de migración.
+ SPARQL de W3C, mediante una representación R2RML de los datos de migración.
Para obtener más información sobre estos dos formatos de asignación de gráficos, consulte [Especificación de reglas de asignación de gráficos mediante Gremlin y R2RML para Amazon Neptune como destino](#CHAP_Target.Neptune.GraphMapping).
A continuación, puede encontrar descripciones de las asignaciones de tipos de datos para cada formato.
### Mapeo de tipos de datos de origen de SQL a destino de Gremlin
En la siguiente tabla se muestran las asignaciones de tipos de datos de un origen SQL a un destino con formato Gremlin.
AWS DMS asigna cualquier tipo de datos fuente SQL que no figure en la lista a un Gremlin. `String`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Neptune.html)
Para obtener más información sobre los tipos de datos de Gremlin para cargar Neptune, consulte [Tipos de datos de Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) en la *Guía del usuario de Neptune.*
### Mapeo de tipos de datos de origen de SQL a destino de R2RML (RDF)
En la tabla siguiente se muestran las asignaciones de tipos de datos de un origen SQL a un destino con formato R2RML.
Todos los tipos de datos RDF listados distinguen mayúsculas de minúsculas, excepto el RDF literal. AWS DMS asigna cualquier tipo de datos de origen SQL que no figure en la lista a un literal RDF.
Un *RDF literal* es uno de entre una variedad de formas léxicas literales y tipos de datos. Para obtener más información, consulte [RDF literals](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) en la especificación de W3C *Marco de descripción de recursos (RDF): Conceptos y sintaxis abstracta*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Neptune.html)
Para obtener más información sobre los tipos de datos RDF para cargar Neptune y las asignaciones a tipos de datos de origen de SQL, consulte [Conversiones de tipos de datos](https://www.w3.org/TR/r2rml/#datatype-conversions) en la especificación de W3C *R2RML: Lenguaje de asignación RBD a RDF*.
## Restricciones del uso de Amazon Neptune como destino
Al utilizar Neptune como destino se aplican las siguientes restricciones:
+ AWS DMS actualmente solo admite tareas de carga completa para la migración a un objetivo de Neptune. No se admite la migración de captura de datos (CDC) a un destino de Neptune.
+ Asegúrese de que elimina todos los datos de la base de datos de Neptune de destino antes de empezar la tarea de migración, como en los siguientes ejemplos.
Para borrar todos los datos (vértices y bordes) que hay en el gráfico, ejecute el siguiente comando Gremlin.
```
gremlin> g.V().drop().iterate()
```
Para borrar los vértices que tienen la etiqueta `'customer'`, ejecute el siguiente comando Gremlin.
```
gremlin> g.V().hasLabel('customer').drop()
```
**nota**
Puede llevar algún tiempo eliminar un conjunto de datos grande. Es posible que desee iterar `drop()` con un límite, por ejemplo, `limit(1000)`.
Para borrar las aristas que tienen la etiqueta `'rated'`, ejecute el siguiente comando Gremlin.
```
gremlin> g.E().hasLabel('rated').drop()
```
**nota**
Puede llevar algún tiempo eliminar un conjunto de datos grande. Es posible que desee iterar `drop()` con un límite, por ejemplo `limit(1000)`.
+ La operación `DescribeTableStatistics` de la API de DMS puede devolver resultados inexactos sobre una tabla dada debido a la naturaleza de las estructuras de datos de gráficos de Neptune.
Durante la migración, AWS DMS escanea cada tabla de origen y utiliza el mapeo de gráficos para convertir los datos de origen en un gráfico de Neptune. Los datos convertidos se almacenan primero en la carpeta del bucket de S3 en el punto de enlace de destino. Si se analiza el origen y estos datos de S3 intermedios se generan correctamente, `DescribeTableStatistics` asume que los datos se han cargado correctamente en la base de datos de destino de Neptune. Pero esto no siempre es cierto. Para verificar que los datos se han cargado correctamente en una tabla, compare los valores de retorno de `count()` en ambos extremos de la migración de esa tabla.
En el siguiente ejemplo, AWS DMS ha cargado una `customer` tabla de la base de datos de origen, a la que se le asigna la etiqueta `'customer'` en el gráfico de la base de datos de Neptune de destino. Puede asegurarse de que esta etiqueta se escribe en la base de datos de destino. Para ello, compare la cantidad de filas `customer` disponibles en la base de datos de origen con la cantidad de filas etiquetadas con `'customer'` cargadas en la base de datos de destino de Neptune después de la finalización de la tarea.
Para obtener la cantidad de filas de cliente disponibles en la base de datos de origen mediante SQL, ejecute lo siguiente.
```
select count(*) from customer;
```
Para obtener la cantidad de filas etiquetadas como `'customer'` cargadas en el gráfico de la base de datos de destino mediante Gremlin, ejecute lo siguiente.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Actualmente, si una sola tabla no se carga, se produce un error en toda la tarea. A diferencia de un destino de base de datos relacional, los datos de Neptune están altamente conectados, lo que hace que en muchos casos sea imposible realizar una tarea. Si no se puede reanudar una tarea correctamente debido a esta clase de error de carga de datos, cree una nueva tarea para cargar la tabla que no se ha podido cargar. Antes de ejecutar esta nueva tarea, borre manualmente la tabla parciamente cargada del destino de Neptune.
**nota**
Puede reanudar una tarea con un error de migración a un destino de Neptune si el error se puede recuperar (por ejemplo, un error de tránsito de red).
+ AWS DMS es compatible con la mayoría de los estándares de R2RML. Sin embargo, AWS DMS no es compatible con ciertos estándares de R2RML, incluidas las expresiones inversas, las uniones y las vistas. Una solución alternativa para una vista R2RML consiste en crear una vista SQL personalizada correspondiente en la base de datos de origen. En la tarea de migración, utilice la asignación de tablas para elegir la vista como entrada. A continuación, asigne la vista a una tabla que R2RML consume para generar datos de gráficos.
+ Al migrar datos de origen con tipos de datos SQL no admitidos, puede haber una pérdida de precisión en los datos de destino resultantes. Para obtener más información, consulte [Tipos de datos para la migración de Gremlin y R2RML a Amazon Neptune como destino](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS no admite la migración de datos LOB a un objetivo de Neptune.
# Uso de Redis OSS como objetivo para AWS Database Migration Service
Redis OSS es un almacén de estructura de datos en memoria de código abierto que se utiliza como base de datos, caché y agente de mensajes. La administración de datos en memoria puede provocar que las operaciones de lectura o escritura tarden menos de un milisegundo y que se realicen cientos de millones de operaciones por segundo. Como almacén de datos en memoria, Redis OSS potencia las aplicaciones más exigentes que requieren tiempos de respuesta inferiores a un milisegundo.
Con él AWS DMS, puede migrar datos de cualquier base de datos de origen compatible a un almacén de datos de Redis OSS de destino con un tiempo de inactividad mínimo. Para obtener información adicional sobre Redis OSS, consulte la [Documentación de Redis OSS](https://redis.io/documentation).
Además del OSS de Redis local, es AWS Database Migration Service compatible con lo siguiente:
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) como almacén de datos de destino. ElastiCache (Redis OSS) funciona con sus clientes de Redis OSS y utiliza el formato de datos abierto de Redis OSS para almacenar sus datos.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) como almacén de datos de destino. MemoryDB es compatible con Redis OSS y le permite crear aplicaciones utilizando todas las estructuras de datos y comandos de Redis OSS que se utilizan en la actualidad. APIs
Para obtener información adicional sobre cómo trabajar con Redis OSS como objetivo AWS DMS, consulte las siguientes secciones:
**Topics**
+ [Requisitos previos para utilizar un clúster de Redis OSS como destino para AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Limitaciones a la hora de utilizar Redis como objetivo para AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migración de datos de una base de datos relacional o no relacional a un destino de Redis OSS](#CHAP_Target.Redis.Migrating)
+ [Especificación de la configuración del punto de conexión para Redis OSS como destino](#CHAP_Target.Redis.EndpointSettings)
## Requisitos previos para utilizar un clúster de Redis OSS como destino para AWS DMS
DMS admite un destino de Redis OSS en las instalaciones en una configuración independiente o como clúster de Redis OSS en el que los datos se *particionan* de forma automática en varios nodos. La fragmentación es el proceso de separar los datos en partes más pequeñas, denominados particiones, que se distribuyen en varios servidores o nodos. En efecto, una partición es una partición de datos que contiene un subconjunto del conjunto total de datos y sirve para cubrir una parte de la carga de trabajo total.
Dado que Redis OSS es un almacén de datos NoSQL de clave-valor, la convención de nomenclatura de claves de Redis OSS que se debe utilizar cuando el origen es una base de datos relacional es **schema-name.table-name.primary-key**. En Redis OSS, la clave y el valor no deben contener el carácter especial %. De lo contrario, DMS omite el registro.
**nota**
Si utiliza ElastiCache (Redis OSS) como destino, el DMS solo admite configuraciones habilitadas en *modo clúster*. Para obtener más información sobre el uso de la versión 6.x o superior ElastiCache (Redis OSS) para crear un almacén de datos de destino habilitado para el modo de clúster, consulte [Introducción](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) en la Guía del usuario de *Amazon ElastiCache (Redis OSS)*.
Antes de iniciar la migración de una base de datos, lance el clúster de Redis OSS con los siguientes criterios.
+ El clúster tiene una o varias particiones.
+ Si utiliza un destino ElastiCache (Redis OSS), asegúrese de que su clúster no utilice un control de acceso basado en roles de IAM. En su lugar, utilice la autenticación de Redis OSS para autenticar a los usuarios.
+ Habilite Multi-AZ (zonas de disponibilidad).
+ Asegúrese de que el clúster tenga suficiente memoria disponible para ajustar los datos a migrar desde la base de datos.
+ Asegúrese de que el clúster de Redis OSS de destino esté libre de todos los datos antes de empezar la tarea de migración inicial.
Debe determinar los requisitos de seguridad para la migración de datos antes de crear la configuración del clúster. DMS admite la migración a los grupos de replicación de destino, independientemente de la configuración de cifrado. Sin embargo, solo puede habilitar o desactivar el cifrado al crear la configuración del clúster.
## Limitaciones a la hora de utilizar Redis como objetivo para AWS Database Migration Service
Las siguientes restricciones se aplican cuando se usa Redis OSS como destino:
+ Dado que Redis OSS es un almacén de datos de clave-valor NoSQL, la convención de nomenclatura de claves de Redis OSS que se debe utilizar cuando el origen es una base de datos relacional es `schema-name.table-name.primary-key`.
+ En Redis OSS, la clave y el valor no pueden contener el carácter especial `%`. De lo contrario, DMS omite el registro.
+ DMS no migrará las filas que contengan el carácter `%`.
+ DMS no migrará los campos que contengan el carácter `%` en el nombre del campo.
+ No se admite el modo LOB completo.
+ No se admite una autoridad de certificación (CA) privada cuando se utiliza ElastiCache (Redis OSS) como destino.
+ AWS DMS no admite datos de origen que contengan `'\0'` caracteres incrustados cuando se utiliza Redis como punto final de destino. Los datos que contengan `'\0'` caracteres incrustados se truncarán en el primer carácter. `'\0'`
## Migración de datos de una base de datos relacional o no relacional a un destino de Redis OSS
Puede migrar datos de cualquier almacén de datos SQL o NoSQL de origen directamente a un destino de Redis OSS. La configuración y el inicio de una migración a un destino de Redis OSS es similar a cualquier migración de carga completa y captura de datos de cambios mediante la API o la consola de DMS. Para realizar una migración de base de datos a un destino de Redis OSS, haga lo siguiente.
+ Cree una instancia de replicación que efectúe todos los procesos para la migración. Para obtener más información, consulte [Creación de una instancia de replicación](CHAP_ReplicationInstance.Creating.md).
+ Especifique un punto de conexión de origen. Para obtener más información, consulte [Creación de puntos de enlace de origen y destino](CHAP_Endpoints.Creating.md).
+ Busque el nombre de DNS y el número de puerto del clúster.
+ Descargue un paquete de certificados que pueda usar para verificar las conexiones SSL.
+ Especifique un punto de conexión de destino, tal y como se describe a continuación.
+ Crear una tarea o conjunto de tareas para definir qué tablas y procesos de replicación desea utilizar. Para obtener más información, consulte [Creación de una tarea](CHAP_Tasks.Creating.md).
+ Migre los datos de la base de datos de origen al clúster de destino.
Puede iniciar una migración de base de datos de una de las dos formas:
1. Puede elegir la AWS DMS consola y realizar allí cada paso.
1. Puede usar el AWS Command Line Interface (AWS CLI). [Para obtener más información sobre el uso de la CLI con AWS DMS, consulte AWS CLIAWS DMS.](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)
**Búsqueda del nombre de DNS y el número de puerto del clúster**
+ Utilice el siguiente AWS CLI comando para `replication-group-id` proporcionarle el nombre de su grupo de replicación.
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Aquí, el resultado muestra el nombre de DNS en el atributo `Address` y el número de puerto en el atributo `Port` del nodo principal del clúster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Si utiliza MemoryDB como destino, utilice el comando de la AWS CLI siguiente para proporcionar una dirección de punto de conexión al clúster de Redis OSS.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Descarga de un paquete de certificados para usar para verificar las conexiones SSL**
+ Ingrese el siguiente comando `wget` en la línea de comandos. Wget es una herramienta de utilidad gratuita de línea de comandos de GNU que se utiliza para descargar archivos de Internet.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Aquí, `aws-api-domain` complete el dominio de Amazon S3 de su AWS región necesario para acceder al bucket de S3 especificado y al rds-combined-ca-bundle archivo.pem que proporciona.
**Para crear un punto final de destino mediante la consola AWS DMS**
Este punto de conexión es para el destino de Redis OSS que ya está en ejecución.
+ En la consola, elija **Puntos de conexión** del panel de navegación y, a continuación, elija **Crear punto de conexión**. La tabla siguiente describe la configuración.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Redis.html)
Cuando haya terminado de proporcionar toda la información para el punto de conexión, AWS DMS crea el punto de conexión de destino de Redis OSS para usarlo durante la migración de la base de datos.
Para obtener información sobre cómo crear una tarea de migración e iniciar la migración de la base de datos, consulte [Creación de una tarea](CHAP_Tasks.Creating.md).
## Especificación de la configuración del punto de conexión para Redis OSS como destino
Para crear o modificar un punto de enlace de destino, puede usar la consola o las operaciones de la API `CreateEndpoint` o `ModifyEndpoint`.
**Para un destino de Redis OSS en la AWS DMS consola, especifique la **configuración específica del punto final en la página Crear punto** **final o Modificar dispositivo final** de la consola.**
Cuando utilice las operaciones de API `CreateEndpoint` y `ModifyEndpoint`, especifique los parámetros de solicitud de la opción `RedisSettings`. El siguiente ejemplo muestra cómo hacer esto mediante la AWS CLI.
```
aws dms create-endpoint --endpoint-identifier my-redis-target
--endpoint-type target --engine-name redis --redis-settings
'{"ServerName":"sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com","Port":6379,"AuthType":"auth-token",
"SslSecurityProtocol":"ssl-encryption", "AuthPassword":"notanactualpassword"}'
{
"Endpoint": {
"EndpointIdentifier": "my-redis-target",
"EndpointType": "TARGET",
"EngineName": "redis",
"EngineDisplayName": "Redis",
"TransferFiles": false,
"ReceiveTransferredFiles": false,
"Status": "active",
"KmsKeyId": "arn:aws:kms:us-east-1:999999999999:key/x-b188188x",
"EndpointArn": "arn:aws:dms:us-east-1:555555555555:endpoint:ABCDEFGHIJKLMONOPQRSTUVWXYZ",
"SslMode": "none",
"RedisSettings": {
"ServerName": "sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com",
"Port": 6379,
"SslSecurityProtocol": "ssl-encryption",
"AuthType": "auth-token"
}
}
}
```
Los parámetros `--redis-settings` son:
+ `ServerName`: (obligatorio) de tipo `string`, especifica el clúster de Redis OSS al que se migrarán los datos y se encuentra en la misma VPC.
+ `Port`: (obligatorio) de tipo `number`, el valor del puerto utilizado para acceder al punto de conexión.
+ `SslSecurityProtocol`: (opcional) los valores válidos son `plaintext` y `ssl-encryption`. El valor predeterminado es `ssl-encryption`.
La opción de `plaintext` no ofrece cifrado de seguridad de la capa de transporte (TLS) para el tráfico entre el punto de conexión y la base de datos.
Se utiliza `ssl-encryption` para establecer una conexión cifrada. `ssl-encryption` no requiere un ARN de una entidad de certificación (CA) SSL para verificar el certificado de un servidor, pero se puede identificar uno opcionalmente mediante la configuración `SslCaCertificateArn`. Si no se proporciona un ARN de entidad de certificación, DMS utiliza la entidad de certificación raíz de Amazon.
Cuando se utiliza un destino de Redis OSS en las instalaciones, se puede utilizar `SslCaCertificateArn` para importar una autoridad de certificación (CA) pública o privada a DMS y proporcionar ese ARN para la autenticación del servidor. No se admite una CA privada cuando se utiliza ElastiCache (Redis OSS) como destino.
+ `AuthType`: (obligatorio) indica el tipo de autenticación que se realiza cuando se conecta a Redis OSS. Los valores válidos son `none`, `auth-token` y `auth-role`.
La `auth-token` opción requiere que se proporcione un *AuthPassword* «», mientras que la `auth-role` opción requiere que se proporcionen *AuthUserName* «» y *AuthPassword* «».
# Uso de Babelfish como objetivo para AWS Database Migration Service
Puede migrar datos de una base de datos fuente de Microsoft SQL Server a un destino de Babelfish utilizando. AWS Database Migration Service
Babelfish for Aurora PostgreSQL amplía la base de datos de edición compatible con Amazon Aurora PostgreSQL con la capacidad de aceptar conexiones de bases de datos de clientes de Microsoft SQL Server. Esto permite que las aplicaciones creadas originalmente para SQL Server funcionen directamente con Aurora PostgreSQL con pocos cambios de código en comparación con una migración tradicional y sin cambiar los controladores de base de datos.
Para obtener información sobre las versiones de Babelfish AWS DMS compatibles como destino, consulte. [Objetivos para AWS DMS](CHAP_Introduction.Targets.md) Las versiones anteriores de Babelfish en Aurora PostgreSQL requieren una actualización antes de utilizar el punto de conexión de Babelfish.
**nota**
El punto de conexión de destino de Aurora PostgreSQL es la forma preferida de migrar datos a Babelfish. Para obtener más información, consulte [Uso de Babelfish para Aurora PostgreSQL como destino](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
Para obtener información sobre el uso de Babelfish como punto de conexión de la base de datos, consulte [Babelfish para Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) en la *Guía del usuario de Amazon Aurora para Aurora*
## Requisitos previos para utilizar Babelfish como objetivo para AWS DMS
Debe crear sus tablas antes de migrar los datos para asegurarse de que AWS DMS utiliza los tipos de datos y los metadatos de las tablas correctos. Si no crea las tablas en el destino antes de ejecutar la migración, es AWS DMS posible que cree las tablas con permisos y tipos de datos incorrectos. Por ejemplo, AWS DMS crea una columna de fecha y hora como binaria (8) y no proporciona la funcionalidad esperada timestamp/rowversion .
**Preparación y creación de las tablas antes de la migración**
1. Ejecute las instrucciones DDL de creación de tablas que incluyan cualquier restricción única, claves principales o restricciones predeterminadas.
No incluya restricciones de clave externa ni instrucciones DDL para objetos como vistas, procedimientos almacenados, funciones o desencadenadores. Puede aplicarlos después de migrar la base de datos de origen.
1. Identifique las columnas de identidad, columnas calculadas o columnas que contengan tipos de datos de versión de fila o marca temporal para las tablas. A continuación, cree las reglas de transformación necesarias para gestionar los problemas conocidos al ejecutar la tarea de migración. Para obtener más información, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifique las columnas con tipos de datos que Babelfish no admite. A continuación, cambie las columnas afectadas de la tabla de destino para utilizar los tipos de datos compatibles o cree una regla de transformación que las elimine durante la tarea de migración. Para obtener más información, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
En la siguiente tabla se muestran los tipos de datos de origen que Babelfish no admite y el correspondiente tipo de datos de destino que se recomienda utilizar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Babelfish.html)
**Para establecer el nivel de unidades de capacidad (ACUs) de Aurora para la base de datos de origen Aurora PostgreSQL Serverless V2**
Puede mejorar el rendimiento de la tarea de AWS DMS migración antes de ejecutarla estableciendo el valor mínimo de la ACU.
+ En la ventana de **configuración de capacidad de Severless v2**, establezca un nivel **mínimo ACUs** o razonable para su clúster de base de datos Aurora. **2**
Para obtener información adicional sobre cómo establecer unidades de capacidad de Aurora, consulte [Elección del rango de capacidad máxima de Aurora sin servidor v2 para un clúster de Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html) en la *Guía del usuario de Amazon Aurora*
Tras ejecutar AWS DMS la tarea de migración, puede restablecer el valor mínimo de su base de datos de origen Aurora PostgreSQL Serverless V2 ACUs a un nivel razonable.
## Requisitos de seguridad al utilizar Babelfish como destino para AWS Database Migration Service
A continuación se describen los requisitos de seguridad para su uso AWS DMS con un objetivo Babelfish:
+ El nombre de usuario del administrador (el usuario administrador) utilizado para crear la base de datos.
+ Inicio de sesión y usuario de PSQL con los permisos SELECT, INSERT, UPDATE, DELETE y REFERENCES suficientes.
## Permisos de usuario para usar Babelfish como objetivo para AWS DMS
**importante**
Por motivos de seguridad, la cuenta de usuario utilizada para la migración de datos debe ser un usuario registrado en cualquier base de datos de Babelfish que utilice como destino.
El punto de conexión de destino de Babelfish requiere permisos de usuario mínimos para ejecutar una migración de AWS DMS .
**Creación de un inicio de sesión y un usuario Transact-SQL (T-SQL) con pocos privilegios**
1. Cree un nombre de usuario y una contraseña para utilizarlos cuando se conecte al servidor.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Cree la base de datos virtual para el clúster de Babelfish.
```
CREATE DATABASE my_database;
GO
```
1. Cree el usuario de T-SQL para la base de datos de destino.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. CONCEDA permisos a las tablas para cada tabla de la base de datos de Babelfish.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Limitaciones en el uso de Babelfish como objetivo para AWS Database Migration Service
Cuando se utiliza una base de datos de Babelfish como destino para AWS DMS, se aplican las siguientes restricciones:
+ Solo se admite el modo de preparación de tablas “**No hacer nada**”.
+ El tipo de datos ROWVERSION requiere una regla de asignación de tablas que elimine el nombre de la columna de la tabla durante la tarea de migración.
+ No se admite el tipo de datos sql\$1variant.
+ Se admite el modo de LOB completo. El uso de SQL Server como punto final de origen requiere que se establezca la configuración `ForceFullLob=True` del atributo de conexión del punto final de SQL Server para poder migrarlo LOBs al punto final de destino.
+ La configuración de las tareas de replicación presenta las siguientes limitaciones:
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Los tipos de datos TIME DATETIME2 (7), (7) y DATETIMEOFFSET (7) de Babelfish limitan el valor de precisión de la parte de segundos del tiempo a 6 dígitos. Considere la posibilidad de utilizar un valor de precisión de 6 para la tabla de destino cuando utilice estos tipos de datos. En las versiones 2.2.0 y posteriores de Babelfish, cuando se utilizan TIME (7) y DATETIME2 (7), el séptimo dígito de precisión es siempre cero.
+ En el modo DO\$1NOTHING, DMS comprueba si la tabla ya existe. Si la tabla no existe en el esquema de destino, DMS la crea en función de la definición de la tabla de origen y asigna cualquier tipo de datos definido por el usuario al tipo de datos base.
+ Una tarea de AWS DMS migración a un destino de Babelfish no admite tablas que tengan columnas con los tipos de datos ROWVERSION o TIMESTAMP. Puede usar una regla de asignación de tablas que elimine el nombre de la columna de la tabla durante el proceso de transferencia. En el siguiente ejemplo de regla de transformación, se transforma una tabla denominada `Actor` en el origen para eliminar todas las columnas que empiecen por los caracteres `col` de la tabla de `Actor` en el 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 las tablas con columnas de identidad o calculadas, en las que las tablas de destino utilizan nombres en mayúsculas y minúsculas, como Categorías, debe crear una acción de regla de transformación que convierta los nombres de las tablas a minúsculas para la tarea de DMS. En el siguiente ejemplo, se muestra cómo crear la acción de la regla de transformación, **Convertir** en minúsculas, mediante la consola. AWS DMS Para obtener más información, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Regla de transformación de Babelfish\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Antes de la versión 2.2.0 de Babelfish, DMS limitó el número de columnas que se podían replicar en un punto de conexión de destino de Babelfish a veinte (20) columnas. Con Babelfish 2.2.0, el límite aumentó a 100 columnas. Sin embargo, con las versiones 2.4.0 y superiores de Babelfish, el número de columnas que puede replicar vuelve a aumentar. Puede ejecutar el siguiente ejemplo de código en la base de datos de SQL Server para determinar qué tablas son demasiado largas.
```
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 datos de destino para Babelfish
La siguiente tabla muestra los tipos de datos objetivo de Babelfish que se admiten cuando se utiliza AWS DMS y el mapeo predeterminado a partir de los tipos de datos. AWS DMS
Para obtener información adicional sobre AWS DMS los tipos de datos, consulte. [Tipos de datos de AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS DMS tipo de datos | Tipo de datos de Babelfish |
| --- | --- |
| BOOLEANO | TINYINT |
| BYTES | VARBINARY (longitud) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC(p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | Si la columna es una columna de fecha u hora, haga lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Babelfish.html) Si la columna no es una columna de fecha o de hora, utilice VARCHAR (longitud). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(length) |
| BLOB | VARBINARY (máx.) Para usar este tipo de datos con DMS, debe habilitar el uso de BLOBs para una tarea específica. DMS solo es compatible con tipos de datos BLOB en las tablas que incluyen una clave principal. |
| CLOB | VARCHAR (máx.) Para utilizar este tipo de datos con el DMS, debe habilitar el uso de CLOBs para una tarea específica. |
| NCLOB | NVARCHAR (máx.) Para utilizar este tipo de datos con el DMS, debe habilitar el uso de NCLOBs para una tarea específica. En la CDC, DMS admite tipos de datos NCLOB solo en las tablas que incluyan una clave principal. |
# Uso de Amazon Timestream como objetivo para AWS Database Migration Service
Puede utilizarlos AWS Database Migration Service para migrar datos de su base de datos de origen a un punto final de destino de Amazon Timestream, con soporte para migraciones de datos de Full Load y CDC.
Amazon Timestream es un servicio de base de datos de series temporales rápido, escalable y sin servidor creado para la ingesta de datos de gran volumen. Los datos de series temporales son una secuencia de puntos de datos recopilados durante un intervalo de tiempo y se utilizan para medir eventos que cambian con el tiempo. Se utiliza para recopilar, almacenar y analizar métricas de aplicaciones de IoT, DevOps aplicaciones y aplicaciones de análisis. Una vez que tenga los datos en Timestream, podrá visualizar e identificar las tendencias y los patrones de los datos prácticamente en tiempo real. Para obtener más información sobre Amazon Timestream, consulte [¿Qué es Amazon Timestream?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) en la *Guía para desarrolladores de Amazon Timestream*.
**Topics**
+ [Requisitos previos para usar Amazon Timestream como objetivo para AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Configuración de tareas de carga completa con varios subprocesos](#CHAP_Target.Timestream.FLTaskSettings)
+ [Configuración de tareas de carga de CDC con varios subprocesos](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Configuración del punto final cuando se utiliza Timestream como objetivo para AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Creación y modificación de un punto de conexión de destino de Amazon Timestream](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Uso de la asignación de objetos para migrar datos a un tema de Timestream](#CHAP_Target.Timestream.ObjectMapping)
+ [Limitaciones al usar Amazon Timestream como objetivo para AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Requisitos previos para usar Amazon Timestream como objetivo para AWS Database Migration Service
Antes de configurar Amazon Timestream como objetivo, asegúrese AWS DMS de crear un rol de IAM. Esta función debe permitir acceder AWS DMS a los datos que se migran a Amazon Timestream. En la siguiente política de IAM se muestra el conjunto mínimo de permisos de acceso para el rol que utilice para migrar a Timestream.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDescribeEndpoints",
"Effect": "Allow",
"Action": [
"timestream:DescribeEndpoints"
],
"Resource": "*"
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"timestream:ListTables",
"timestream:DescribeDatabase"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"timestream:DeleteTable",
"timestream:WriteRecords",
"timestream:UpdateTable",
"timestream:CreateTable"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME/table/TABLE_NAME"
}
]
}
```
------
Si tiene intención de migrar todas las tablas, úselo `*` *TABLE\$1NAME* en el ejemplo anterior.
Tenga en cuenta lo siguiente acerca del uso de Timestream como destino:
+ Si tiene intención de ingerir datos históricos con marcas de tiempo de más de 1 año, le recomendamos que utilice AWS DMS para escribir los datos en Amazon S3 en un formato de valores separados por comas (csv). A continuación, utilice la carga por lotes de Timestream para ingerir los datos a Timestream. Para obtener más información, consulte [Uso de la carga por lotes en Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) en la [Guía para desarrolladores de Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Para migraciones de datos de carga completa de datos con menos de 1 año de antigüedad, recomendamos establecer el período de retención en el almacén en memoria de la tabla de Timestream superior o igual a la marca de tiempo más antigua. A continuación, una vez finalizada la migración, edite la retención del almacén en memoria de la tabla con el valor deseado. Por ejemplo, para migrar datos cuya marca de tiempo más antigua tenga 2 meses de antigüedad, haga lo siguiente:
+ Establezca la retención del almacén en memoria de la tabla de destino de Timestream en 2 meses.
+ Inicie la migración de datos utilizando AWS DMS.
+ Una vez que se complete la migración de datos, cambie el período de retención de la tabla de Timestream de destino al valor deseado.
Recomendamos estimar el costo del almacén en memoria antes de la migración utilizando la información de las siguientes páginas:
+ [Precios de Amazon Timestream](https://aws.amazon.com/timestream/pricing)
+ [AWS calculadora de precios](https://calculator.aws/#/addService)
+ Para las migraciones de datos de CDC, recomendamos configurar el período de retención en el almacén en memoria de la tabla de destino de manera que los datos ingeridos se encuentren dentro de los límites de retención del almacén en memoria. Para obtener más información, consulte [Prácticas recomendadas de escritura](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) en la [Guía para desarrolladores de Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Configuración de tareas de carga completa con varios subprocesos
Para ayudar a aumentar la velocidad de transferencia de datos, AWS DMS admite una tarea de migración a carga completa y multiproceso a un punto final de destino de Timestream con la siguiente configuración de tareas:
+ `MaxFullLoadSubTasks`: utilice esta opción para indicar el número máximo de tablas de origen que se pueden cargar en paralelo. DMS carga cada tabla en su tabla de destino de Amazon Timestream correspondiente mediante una tarea secundaria dedicada. El valor predeterminado es 8, el valor máximo es 49.
+ `ParallelLoadThreads`— Utilice esta opción para especificar el número de subprocesos que se AWS DMS utilizan para cargar cada tabla en su tabla de destino de Amazon Timestream. El valor máximo para un destino de Amazon Timestream es de 32. Puede pedir que se incremente este límite máximo.
+ `ParallelLoadBufferSize`: utilice esta opción para especificar el número máximo de registros para almacenar en el búfer que los subprocesos de carga en paralelo utilizan para cargar datos en el destino de Amazon Timestream. El valor predeterminado es 50. El valor máximo es 1000. Utilice este parámetro con `ParallelLoadThreads`. `ParallelLoadBufferSize` es válido solo cuando hay más de un subproceso.
+ `ParallelLoadQueuesPerThread`: utilice esta opción para especificar el número de colas que acceden a cada subproceso simultáneo para eliminar los registros de datos de las colas y generar una carga por lotes para el destino. El valor predeterminado de es 1. Sin embargo, para los destinos de Amazon Timestream de varios tamaños de carga, el intervalo válido es de 5-512 colas por subproceso.
## Configuración de tareas de carga de CDC con varios subprocesos
Para promover el desempeño de los CDC, AWS DMS es compatible con las siguientes configuraciones de tareas:
+ `ParallelApplyThreads`— Especifica la cantidad de subprocesos simultáneos que se AWS DMS utilizan durante una carga de los CDC para enviar los registros de datos a un punto final de destino de Timestream. El valor predeterminado es 1 y el máximo es 32.
+ `ParallelApplyBufferSize`: especifica el número máximo de registros que se almacenan en cada cola del búfer para los subprocesos simultáneos que insertan datos en un punto de conexión de destino de Timestream durante una carga de CDC. El valor predeterminado es 100 y el máximo es 1000. Utilice esta opción cuando `ParallelApplyThreads` especifique más de un subproceso.
+ `ParallelApplyQueuesPerThread`: especifica el número de colas a las que accede cada subproceso para sacar registros de datos de las colas y generar una carga por lotes para un punto de conexión de Timestream durante el proceso de CDC. El valor predeterminado es 1 y el máximo es 512.
## Configuración del punto final cuando se utiliza Timestream como objetivo para AWS DMS
Puede utilizar la configuración de punto de conexión para configurar la base de datos de destino de Timestream de forma similar al uso de atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el `create-endpoint` comando del [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintaxis `--timestream-settings '{"EndpointSetting": "value", ...}'` JSON.
La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con Timestream como destino.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Target.Timestream.html)
## Creación y modificación de un punto de conexión de destino de Amazon Timestream
Una vez que haya creado un rol de IAM y establecido el conjunto mínimo de permisos de acceso, podrá crear un punto final de destino de Amazon Timestream AWS DMS mediante la consola o `create-endpoint` mediante el comando de, con la sintaxis [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
En los siguientes ejemplos se muestra cómo crear y modificar un punto de conexión de destino de Timestream con la AWS CLI.
**Crear comando de punto de conexión de destino de 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 el comando de punto de conexión de destino de 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,
}
```
## Uso de la asignación de objetos para migrar datos a un tema de Timestream
AWS DMS utiliza reglas de mapeo de tablas para mapear los datos del tema de Timestream de origen al tema de Timestream de destino. Para asignar datos a un tema de destino, se utiliza un tipo de regla de asignación de tablas denominado asignación de objetos. Puede utilizar el mapeo de objetos para definir cómo los registros de datos del origen se asignan a los registros de datos publicados en un tema de Timestream.
Los temas de Timestream no tienen una estructura predeterminada distinta de una clave de partición.
**nota**
No tiene que utilizar la asignación de objetos. Puede utilizar la asignación de tablas normal para varias transformaciones. Sin embargo, el tipo de clave de partición seguirá estos comportamientos predeterminados:
La clave principal se usa como clave de partición para la carga completa.
Si no se utiliza ninguna configuración de tareas de aplicación paralela, `schema.table` se utiliza como clave de partición para CDC.
Si se utiliza la configuración de tareas de aplicación paralela, la clave principal se utiliza como clave de partición para CDC.
Para crear una regla de mapeo de objetos, se especifica `rule-type` como `object-mapping`. Esta regla indica el tipo de mapeo de objetos que desea utilizar. La estructura de la regla es la siguiente.
```
{
"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 actualmente admite `map-record-to-record` y `map-record-to-document` es el único valor válido para el parámetro. `rule-action` `map-record-to-document`Los valores `map-record-to-record` y especifican lo que AWS DMS ocurre de forma predeterminada con los registros que no se excluyen como parte de la lista de `exclude-columns` atributos. Estos valores no afectan a los mapeos de atributos en modo alguno.
Utilice `map-record-to-record` al migrar desde una base de datos relacional a un tema de Timestream. Este tipo de regla utiliza el valor `taskResourceId.schemaName.tableName` de la base de datos relacional como la clave de partición en el tema de Timestream y crea un atributo para cada columna de la base de datos de origen. Cuando se utiliza`map-record-to-record`, para cualquier columna de la tabla de origen que no aparezca en la lista de `exclude-columns` atributos, AWS DMS crea el atributo correspondiente en el tema de destino. Este atributo se crea independientemente de si dicha columna de origen se utiliza en un mapeo de atributos.
Una forma de entender `map-record-to-record` es verlo en acción. En este ejemplo, imagine que empieza con una fila de una tabla de base de datos relacional con la estructura y los datos siguientes.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Para migrar esta información desde un esquema denominado `Test` a un tema de Timestream, cree reglas para mapear los datos al tema. La siguiente regla ilustra la operación de asignación.
```
{
"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"
}
}
]
}
```
Dados un tema de Timestream y una clave de partición (en este caso, `taskResourceId.schemaName.tableName`), a continuación se ilustra el formato de registro resultante al usar nuestros datos de ejemplo en el tema de destino de Timestream:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Limitaciones al usar Amazon Timestream como objetivo para AWS Database Migration Service
Al utilizar Amazon Timestream como destino se aplican las siguientes restricciones:
+ **Dimensiones y marcas de tiempo:** Timestream utiliza las dimensiones y las marcas de tiempo de los datos de origen como una clave primaria compuesta, y no permite actualizar estos valores. Esto significa que si cambia la marca de tiempo o las dimensiones de un registro en la base de datos de origen, la base de datos de Timestream intentará crear un registro nuevo. Por lo tanto, si cambia la dimensión o la marca de tiempo de un registro para que coincidan con las de otro registro existente, AWS DMS actualice los valores del otro registro en lugar de crear un registro nuevo o actualizar el registro anterior correspondiente.
+ **Comandos DDL:** la versión actual AWS DMS solo admite `CREATE TABLE` comandos DDL. `DROP TABLE`
+ **Limitaciones de registro:** Timestream tiene limitaciones para los registros, como el tamaño del registro y el tamaño de la medida. Para obtener más información, consulte [Cuotas](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) en la [Guía para desarrolladores de Amazon Timestream](https://docs.aws.amazon.com/).
+ **Eliminar registros y valores nulos:** Timestream no admite la eliminación de registros. Para permitir la migración de registros eliminados del origen, AWS DMS borra los campos correspondientes de los registros de la base de datos de destino de Timestream. AWS DMS cambia los valores de los campos del registro de destino correspondiente con **0** para los campos numéricos, **nulo** para los campos de texto y **falso** para los campos booleanos.
+ Timestream como destino no admite orígenes que no sean bases de datos relacionales (RDBMS).
+ AWS DMS solo admite Timestream como destino en las siguientes regiones:
+ Este de EE. UU. (Norte de Virginia)
+ Este de EE. UU. (Ohio)
+ Oeste de EE. UU. (Oregón)
+ Europa (Irlanda)
+ Europa (Fráncfort)
+ Asia-Pacífico (Sídney)
+ Asia-Pacífico (Tokio)
+ Timestream como destino no admite la configuración de `TargetTablePrepMode` para `TRUNCATE_BEFORE_LOAD`. Le recomendamos que utilice `DROP_AND_CREATE` para esta configuración.
# Uso de Amazon RDS para Db2 e IBM Db2 LUW como destino para AWS DMS
Puede migrar datos a una base de datos Amazon RDS para Db2 o a una base de datos Db2 local desde una base de datos LUW de Db2 mediante (). AWS Database Migration Service AWS DMS
Para obtener información sobre las versiones de Db2 LUW compatibles como destino, consulte. AWS DMS [Objetivos para AWS DMS](CHAP_Introduction.Targets.md)
Puede utilizar la Capa de conexión segura (SSL) para cifrar las conexiones entre el punto de enlace de Db2 LUW y la instancia de replicación. Para obtener más información sobre cómo utilizar SSL con un punto de conexión de Db2 LUW, consulte [Uso de SSL con AWS Database Migration Service](CHAP_Security.SSL.md).
## Limitaciones al utilizar Db2 LUW como destino para AWS DMS
Las siguientes limitaciones se aplican al utilizar la base de datos LUW de Db2 como destino para. AWS DMS Para restricciones al usar Db2 LUW como origen, consulte [Limitaciones al utilizar Db2 LUW como fuente de AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations).
+ AWS DMS solo admite Db2 LUW como destino cuando el origen es Db2 LUW o Db2 for z/OS.
+ El uso de Db2 LUW como destino no admite replicaciones con el modo de LOB completo.
+ El uso de Db2 LUW como destino no admite el tipo de datos XML en la fase de carga completa. Se trata de una limitación de la utilidad dbload de IBM. Para obtener más información, consulte [La utilidad dbload](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) en la documentación de *IBM Informix Servers*.
+ AWS DMS trunca los campos BLOB con valores correspondientes al carácter de comillas dobles («). Se trata de una limitación de la utilidad dbload de IBM.
+ AWS DMS no admite la opción de carga completa en paralelo al migrar a un destino LUW de Db2 en la versión 3.5.3 del DMS. Esta opción está disponible a partir de la versión 3.5.4 o posteriores de DMS.
## Configuración del punto final cuando se utiliza Db2 LUW como destino para AWS DMS
Puede utilizar la configuración de punto de conexión para configurar la base de datos de destino de Db2 LUW de forma similar al uso de atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el `create-endpoint` comando del [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintaxis `--ibm-db2-settings '{"EndpointSetting": "value", ...}'` JSON.
La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con Db2 LUW como destino.
| Name | Description (Descripción) |
| --- | --- |
| `KeepCsvFiles` | Si es verdadero, AWS DMS guarda todos los archivos.csv en el destino LUW de Db2 que se hayan utilizado para replicar datos. DMS utiliza estos archivos para el análisis y la solución de problemas. |
| `LoadTimeout` | El tiempo (en milisegundos) antes de que se agote el AWS DMS tiempo de espera de las operaciones realizadas por el DMS en el destino de Db2. El valor predeterminado es 1200 (20 minutos). |
| `MaxFileSize` | Especifica el tamaño máximo (en KB) de los archivos .csv que se utilizan para transferir datos a Db2 LUW. |
| `WriteBufferSize` | El tamaño (en KB) del búfer de escritura de archivos en memoria que se utiliza al generar archivos .csv en el disco local de la instancia de replicación DMS. El valor predeterminado es 1024 (1 MB). |