Configuración de las tareas de los metadatos de destino

La configuración de los metadatos de destino incluye lo siguiente. Para obtener información sobre cómo utilizar un archivo de configuración de tareas para establecer la configuración de tareas, consulteEjemplo de configuración de tarea.

• TargetSchema— El nombre del esquema de la tabla de destino. Si esta opción de metadatos está en blanco, se utiliza el esquema de la tabla de origen. Si no hay un esquema de origen definido, AWS DMS agrega automáticamente el prefijo del propietario de la base de datos de destino a todas las tablas. Esta opción debe estar en blanco para los puntos de enlace de destino de tipo MySQL.

• Configuración de LOB: configuración que determina cómo se administran los objetos grandes (LOB). Si establece SupportLobs=true, debe establecer una de las siguientes opciones en true:

  • FullLobMode— Si establece esta opción entrue, debe introducir un valor para laLobChunkSize opción. Indique el tamaño, en kilobytes, de los fragmentos del LOB que se van a utilizar cuando se repliquen los datos en el destino. La opción FullLobMode es más adecuada para los LOB de gran tamaño, pero suele ralentizar la carga. El valor recomendado paraLobChunkSize es de 64 kilobytes. Aumentar el valor porLobChunkSize encima de 64 kilobytes puede provocar errores en las tareas.

  • InlineLobMaxSize— Este valor determina qué LOB seAWS DMS transfieren en línea durante una carga completa. La transferencia de LOB pequeños es más eficaz que buscarlos de una tabla de origen. Durante una carga completa, AWS DMS comprueba todos los LOB y realiza una transferencia en línea para los LOB de tamaño inferior a InlineLobMaxSize. AWS DMS transfiere todos los LOB de tamaño superior a InlineLobMaxSize en FullLobMode. El valor predeterminado paraInlineLobMaxSize es 0 y el intervalo es de 1 a 102400 kilobytes (100 MB). Establezca un valor para InlineLobMaxSize solo si sabe que la mayor parte de los LOB tienen un tamaño inferior al valor especificado en InlineLobMaxSize.

  • LimitedSizeLobMode— Si establece esta opción entrue, debe introducir un valor para laLobMaxSize opción. Indique el tamaño máximo, en kilobytes, para un LOB específico. El valor máximo recomendadoLobMaxSize es de 102400 kilobytes (100 MB).

  Para obtener más información sobre los criterios para el uso de la configuración de LOB de tarea, consulteConfiguración de la compatibilidad de LOB con bases de datos de origen en una tarea de AWS DMS. También puede controlar la administración de LOB para tablas individuales. Para obtener más información, consulte Configuración, reglas y operaciones de tablas y colecciones.

• LoadMaxFileSize— Una opción para terminales de destino basados en CSV, como MySQL, PostgreSQL y Amazon Redshift, que admiten el uso de archivos de valores separados por comas (.csv) para cargar datos. LoadMaxFileSizedefine el tamaño máximo en disco de los datos almacenados y descargados, como los archivos.csv. Esta opción anula el atributo de conexión del punto final de destino,maxFileSize. Puede especificar valores a partir de 0, que indica que esta opción no anula el atributo de conexión, hasta 100 000 KB.

• BatchApplyEnabled— Determina si cada transacción se aplica de forma individual o si los cambios se confirman en lotes. El valor predeterminado es false.

  CuandoBatchApplyEnabled se establece entrue, el DMS requiere una clave principal (PK) o una clave única (UK) en las tablas de origen. Sin un PK o UK en las tablas de origen, solo se aplican las inserciones por lotes, pero no las actualizaciones ni eliminaciones por lotes.

  CuandoBatchApplyEnabled se establece entrue,AWS DMS genera un mensaje de error si la tabla de destino tiene una restricción única y una clave principal. Las tablas de destino con una restricción única y una clave principal no se admiten cuandoBatchApplyEnabled se establece entrue.

  CuandoBatchApplyEnabled se establece en true yAWS DMS encuentra un error de datos en una tabla con la política de gestión de errores predeterminada, laAWS DMS tarea cambia del modo por lotes al one-by-one modo para el resto de las tablas. Para modificar este comportamiento, puede establecer la"SUSPEND_TABLE" acción en las siguientes políticas en la propiedad de"ErrorBehavior" grupo del archivo JSON de configuración de tareas:

  • DataErrorPolicy

  • ApplyErrorDeletePolicy

  • ApplyErrorInsertPolicy

  • ApplyErrorUpdatePolicy

  Para obtener más información sobre esta propiedad de"ErrorBehavior" grupo, consulte el ejemplo del archivo JSON de configuración de tareas enEspecificar la configuración de tareas para las tareas delAWS Database Migration Service. Tras establecer estas políticas en"SUSPEND_TABLE", laAWS DMS tarea suspende los errores de datos en cualquier tabla que los genere y continúa en modo por lotes para todas las tablas.

  Puede utilizar elBatchApplyEnabled parámetro con elBatchApplyPreserveTransaction parámetro. Si BatchApplyEnabled está establecido en true, el parámetro BatchApplyPreserveTransaction determina la integridad de las transacciones.

  Si BatchApplyPreserveTransaction está establecido en true, se mantiene la integridad de las transacciones y se garantiza que un lote contendrá todos los cambios en una transacción desde el origen.

  Si BatchApplyPreserveTransaction está establecido en false, pueden producirse interrupciones temporales en la integridad de las transacciones para mejorar el desempeño.

  El parámetro BatchApplyPreserveTransaction se aplica únicamente a los puntos de enlace de destino de Oracle y solo es pertinente cuando el parámetro BatchApplyEnabled está establecido en true.

  Cuando se incluyen columnas de LOB en la replicación, BatchApplyEnabled solo se puede utilizar en modo de LOB limitado.

  Para obtener más información sobre el uso de esta configuración para una carga de captura de datos de cambio (CDC), consulteConfiguración de ajuste del procesamiento de cambios.

• ParallelLoadThreads— Especifica el número de subprocesos que seAWS DMS utilizan para cargar cada tabla en la base de datos de destino. Este parámetro tiene valores máximos para los destinos que no son de RDBMS. El valor máximo para un objetivo de DynamoDB es 200. El valor máximo para un destino de Amazon Kinesis Data Streams, Apache Kafka o Amazon OpenSearch Service es 32. Puede pedir que se incremente este límite máximo. Para obtener información acerca de la configuración de la carga paralela de las tablas individuales, consulte Configuración, reglas y operaciones de tablas y colecciones.

  Este ajuste se aplica a los siguientes tipos de motor de punto de conexión:

  • DynamoDB

  • Amazon Kinesis Data Streams

  • Amazon MSK

  • OpenSearch Servicio Amazon

  • Amazon Redshift

• ParallelLoadBufferSize— Especifica el número máximo de registros que se almacenarán en el búfer que los subprocesos de carga en parallel utilizan para cargar datos en el destino. El valor predeterminado es 50. El valor máximo es 1000. Actualmente, esta configuración solo es válida cuando el destino OpenSearch es DynamoDB, Kinesis, Apache Kafka o. Utilice este parámetro con ParallelLoadThreads. ParallelLoadBufferSize solo es válido cuando hay más de un subproceso. Para obtener información acerca de la configuración de la carga paralela de las tablas individuales, consulte Configuración, reglas y operaciones de tablas y colecciones.

• ParallelLoadQueuesPerThread— Especifica el número de colas a las que accede cada subproceso simultáneo para sacar los registros de datos de las colas y generar una carga por lotes para el destino. El valor predeterminado es 1. Actualmente, esta configuración solo es válida cuando el objetivo es Kinesis o Apache Kafka.

• ParallelApplyThreads— Especifica la cantidad de subprocesos simultáneos que seAWS DMS utilizan durante una carga de CDC para enviar registros de datos a un punto final de destino de Kinesis OpenSearch, Apache Kafka o Amazon Redshift. El rol predeterminado es cero (0).

  Este ajuste se aplica a los siguientes tipos de motor de punto de conexión:

  • Amazon Kinesis Data Streams

  • Amazon MSK

  • OpenSearch Servicio Amazon

  • Amazon Redshift

• ParallelApplyBufferSize— Especifica la cantidad máxima 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 de Kinesis OpenSearch, Apache Kafka o Amazon Redshift durante una carga de CDC. El valor predeterminado es 100. 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 los registros de datos de las colas y generar una carga por lotes para un Kinesis, Apache Kafka o un OpenSearch endpoint durante la CDC. El valor predeterminado es 1.