Best practices for AWS Database Migration Service - AWS Database Migration Service

Si proporcionásemos una traducción de la versión en inglés de la guía, prevalecerá la versión en inglés de la guía si hubiese algún conflicto. La traducción se proporciona mediante traducción automática.

Best practices for AWS Database Migration Service

Para sacar el máximo partido de AWS Database Migration Service (AWS DMS), consulte las recomendaciones de esta sección sobre la manera más provechosa de migrar sus datos.

Improving the performance of an AWS DMS migration

Hay una serie de factores que afectan al desempeño del proceso de migración con AWS DMS:

  • Resource availability on the source

  • The available network throughput

  • The resource capacity of the replication server

  • The ability of the target to ingest changes

  • The type and distribution of source data

  • The number of objects to be migrated

En nuestras pruebas, hemos migrado un terabyte de datos en aproximadamente 12–13 horas utilizando una única AWS DMS y en condiciones ideales. Estas condiciones ideales se incluyen utilizando bases de datos de origen en Amazon EC2 y en Amazon RDS con bases de datos de destino en Amazon RDS, todas en la misma zona de disponibilidad. Las bases de datos de origen incluían una cantidad representativa de datos distribuidos de una forma relativamente uniforme y unas cuantas tablas de gran tamaño que contenían hasta 250 GB de datos. Los datos de origen no contenían tipos de datos complejos, como BLOB.

Puede mejorar el desempeño si se siguen algunas o todas las prácticas recomendadas que se mencionan a continuación. Si se puede utilizar o no una de estas prácticas depende en gran parte en su caso de uso específico. Comentaremos las limitaciones, según proceda.

Carga de varias tablas en paralelo

De forma predeterminada, AWS DMS carga ocho tablas a la vez. Podrá observar cierta mejora en el desempeño si aumenta ligeramente este valor cuando utilice un servidor de replicación muy grande, como una instancia dms.c4.xlarge o más grande. No obstante, llegará un momento en que si sigue aumentando este paralelismo, el desempeño será inferior. Si el servidor de replicación es relativamente pequeño, como dms.t2.medium, le recomendamos que reduzca el número de tablas cargadas en paralelo.

Para cambiar este número en la consola de administración de AWS, abra la consola, elija Tasks (Tareas), elija crear o modificar una tarea y, a continuación, elija Advanced Settings (Configuración avanzada). En Tuning Settings (Configuración de ajuste), cambie la opción Maximum number of tables to load in parallel (Número máximo de tablas que se pueden cargar en paralelo).

Para cambiar este número a través de la interfaz de línea de comandos (CLI) de AWS, cambie el parámetro MaxFullLoadSubTasks en TaskSettings.

Trabajar con índices, activadores y restricciones de integridad referenciales

Los índices, los disparadores y los límites de integridad referencial pueden afectar al desempeño de la migración y hacer que la migración provoque un error. La forma en que esto afecta a la migración depende de si la tarea de replicación es una tarea de carga completa o una tarea de replicación continua (CDC).

Para una tarea de carga completa, le recomendamos que elimine los índices de clave primaria, los índices secundarios, los límites de integridad referencial y los disparadores del lenguaje de manipulación de datos (DML). Si lo prefiere, puede retrasar su creación hasta que las tareas de carga completa se hayan completado. No necesita índices durante una tarea de carga completa, y los índices incurren en gastos generales de mantenimiento si están presentes. Dado que la tarea de carga completa carga grupos de tablas de una vez, se infringen los límites de integridad referencial. Del mismo modo, los disparadores INSERT, UPDATE y DELETE pueden producir errores, por ejemplo, si se activa una inserción de fila para una tabla que se haya cargado de forma masiva previamente. Otros tipos de disparadores también afectan al desempeño debido al procesamiento añadido.

Puede crear índices de clave principal y secundarios antes de una tarea de carga completa si los volúmenes de datos son relativamente pequeños y el tiempo de migración adicional no es un problema. Los límites de integridad referencial y los disparadores deben deshabilitarse siempre.

Para una tarea de carga completa + CDC, le recomendamos que añada índices secundarios antes de la fase de CDC. Dado que AWS DMS utiliza la replicación lógica, deben implementarse índices secundarios que admiten operaciones de DML para evitar los análisis de tablas completas. Puede detener la tarea de replicación antes de la fase de CDC para crear índices, disparadores y límites de integridad referencial antes de reiniciar la tarea.

Deshabilitar los backup y el registro de transacciones

Al migrar a un Amazon RDS base de datos, es buena idea desactivar las copias de seguridad y Multi-AZ en el objetivo hasta que esté listo para cortar más de. De manera similar, al migrar a sistemas distintos Amazon RDS, deshabilitar cualquier registro del objetivo hasta después de la transición suele ser una buena idea.

Usar varias tareas

En ocasiones, el uso de varias tareas para una sola migración puede mejorar el desempeño. Si tiene conjuntos de tablas que no participan en transacciones comunes, puede que pueda dividir su migración en varias tareas. La coherencia transaccional se mantiene dentro de una tarea, por lo que es importante que las tablas en tareas separadas no participen en transacciones comunes. Además, cada tarea leerá de manera independiente la secuencia de transacciones, por lo que habrá que tener la precaución de no exigir demasiado a la base de datos de origen.

Puede utilizar varias tareas para crear flujos de replicación independientes. Al hacerlo, puede paralellizar las lecturas del origen, los procesos de la instancia de replicación y los escritos a la base de datos de destino.

Optimización del procesamiento de cambios

De forma predeterminada, AWS DMS procesa los cambios en un modo transaccional, para garantizar la integridad transaccional. Si puede permitirse interrupciones temporales en la integridad de las transacciones, active la opción de aplicación optimizada por lotes. Para resultar más eficaz, esta opción agrupa las transacciones y las aplica en lotes. La utilización de la opción de aplicación optimizada por lotes casi siempre infringe las restricciones de integridad referencial. Así que le recomendamos que se deshabilite durante el proceso de migración y que vuelva a activarlos como parte del proceso de transición.

Choosing the optimum size for a replication instance

La selección de la instancia de replicación adecuada depende de varios factores del caso de uso. Para ayudar a entender cómo se utilizan los recursos de instancias de replicación, consulte la siguiente explicación. Trata la situación habitual de una tarea de carga completa + CDC.

Durante una tarea de carga completa, AWS DMS carga las tablas de manera individual. De forma predeterminada, se cargan ocho tablas cada vez. AWS DMS captura los cambios en curso al origen durante una tarea de carga completa de modo que los cambios se puedan aplicar más adelante en el punto de enlace de destino. Los cambios se almacenan en caché en la memoria y, en caso de agotarse la memoria disponible, se almacenan en la memoria caché del disco. Al completarse una tarea de carga completa para una tabla, AWS DMS aplica inmediatamente los cambios almacenados en caché a la tabla de destino.

Después de que se hayan aplicado todos los cambios en la memoria caché pendientes para una tabla, el punto de enlace de destino se encuentra en un estado coherente desde el punto de vista transaccional. En este momento, el destino está sincronizado con el punto de enlace de origen con respecto a los últimos cambios almacenados en caché. AWS DMS a continuación, comienza la replicación continua entre el origen y el destino. Para ello, AWS DMS realiza operaciones de cambio de los registros de transacciones originales y los aplica al destino de forma transaccional. (Este proceso asume que la aplicación optimizada por lotes no está seleccionada). AWS DMS transmite cambios continuos a través de la memoria en la instancia de replicación, si es posible. De lo contrario, AWS DMS escribe los cambios en el disco en la instancia de replicación hasta que pueden aplicarse al destino.

El usuario tiene cierto control sobre la forma en que la instancia de replicación gestiona el procesamiento de los cambios y sobre cómo se utiliza la memoria en dicho proceso. Para obtener más información acerca de cómo ajustar el procesamiento de cambios, consulte Configuración de ajuste del procesamiento de cambios.

Por la explicación anterior puede verse que la cantidad total de memoria disponible es una consideración fundamental. Si la instancia de replicación tiene memoria suficiente para que AWS DMS pueda transmitir los cambios en caché y en curso sin escribirlos en el disco, el rendimiento de la migración aumenta considerablemente. Del mismo modo, al configurar la instancia de replicación con suficiente espacio en disco para posibilitar el almacenamiento en caché de los cambios y el almacenamiento de logs también aumenta el desempeño. El número máximo de IOPS posible depende del tamaño de disco seleccionado.

Tenga en cuenta los siguientes son factores a la hora de elegir una clase de instancia de replicación y el almacenamiento en disco disponible:

  • Table size – Large tables take longer to load and so transactions on those tables must be cached until the table is loaded. After a table is loaded, these cached transactions are applied and are no longer held on disk.

  • Data manipulation language (DML) activity – A busy database generates more transactions. These transactions must be cached until the table is loaded. Transactions to an individual table are applied as soon as possible after the table is loaded, until all tables are loaded.

  • Transaction size – Long-running transactions can generate many changes. For best performance, if AWS DMS applies changes in transactional mode, sufficient memory must be available to stream all changes in the transaction.

  • Total size of the migration – Large migrations take longer and they generate a proportionally large number of log files.

  • Number of tasks – The more tasks, the more caching is likely to be required, and the more log files are generated.

  • Large objects – Tables with LOBs take longer to load.

Algunas pruebas demuestran que los archivos de registro consumen la mayor parte del espacio que necesita AWS DMS. Los ajustes de almacenamiento predeterminados suelen ser suficientes.

Sin embargo, las instancias de replicación que ejecutan varias tareas pueden requerir más espacio en el disco. Asimismo, si la base de datos incluye tablas grandes y activas, es posible que tenga que incrementar el espacio en disco para las transacciones que se almacenan en la caché del disco durante una tarea de carga completa. Por ejemplo, suponga que la carga tarda 24 horas y que produce 2 GB de transacciones cada hora. En este caso, puede que desee asegurarse de tener 48 GB de espacio para transacciones en caché. Además, cuanto más espacio de almacenamiento asigne a la instancia de replicación, mayor será el IOPS que obtendrá.

Las directrices anteriores no cubren todas las situaciones posibles. Es sumamente importante tener en cuenta los detalles específicos de su caso de uso particular al determinar el tamaño de la instancia de replicación. Cuando la migración se esté ejecutando, monitorice la CPU, la memoria que se puede liberar, la cantidad de almacenamiento libre y las IOPS de su instancia de replicación. En función de los datos que recopile, puede ampliar o reducir las dimensiones de la instancia de replicación según sea necesario.

Reducing the load on your source database

AWS DMS utiliza algunos recursos en la base de datos de origen. Durante una tarea de carga completa, AWS DMS analiza por completo la tabla de origen para cada una de las tablas procesadas en paralelo. Asimismo, cada tarea que se crea como parte de una migración comprueba si existen cambios en el origen como parte del proceso de CDC. Para que AWS DMS realice la CDC para algunos orígenes, como Oracle, puede que tenga que aumentar la cantidad de datos escritos en el registro de cambios de su base de datos.

Si descubre que está sobrecargando la base de datos de origen, puede reducir el número de tareas o de tablas por cada tarea de la migración. Cada tarea obtiene los cambios del origen de forma independiente, por lo que la consolidación de las tareas puede reducir la carga de trabajo de la captura de cambios.

Using the task log to troubleshoot migration issues

En algunos casos, AWS DMS puede encontrar problemas para los que los mensajes de advertencia o de error aparecen solo en el registro de tareas. En concreto, los problemas de truncamiento de datos o de rechazo de filas por infracciones en la clave externa solo están escritos en el log de tareas. Por lo tanto, asegúrese de revisar este registro al migrar una base de datos. Para habilitar la visualización del log de tareas, configure Amazon CloudWatch como parte de la creación de tareas.

Converting schema

AWS DMS no convierte ni los esquemas ni el código. Si desea convertir un esquema existente en otro motor de base de datos, puede utilizar la herramienta Schema Conversion Tool (AWS SCT) de AWS. AWS SCT convierte los objetos, tablas, índices, vistas, disparadores y otros objetos del sistema de origen en el formato de lenguaje de definición de datos (DDL) de destino. También puede utilizar AWS SCT para convertir la mayor parte del código de aplicación, como PL/SQL o TSQL, en el lenguaje de destino equivalente.

Puede obtener AWS SCT como descarga gratuita de AWS. Para obtener más información sobre la herramienta AWS SCT, consulte la Guía de usuario de AWS Schema Conversion Tool.

Si los puntos de enlace de origen y de destino se corresponden con el mismo motor de base de datos, puede utilizar herramientas como Oracle SQL Developer, MySQL Workbench o PgAdmin4 para trasladar su esquema.

Migrating large binary objects (LOBs)

En general, AWS DMS migra los datos LOB en dos fases.

  1. AWS DMS crea una nueva fila de la tabla de destino y la rellena con todos los datos, excepto el valor de LOB asociado.

  2. AWS DMS actualiza la fila en la tabla de destino con los datos de LOB.

Este proceso de migración para los LOB requiere que, durante el proceso, todas las columnas de LOB de la tabla de destino sean NULLABLE. Esto es así aunque las columnas de LOB no sean NULLABLE en la tabla de origen. Si AWS DMS crea las tablas de destino, define las columnas de LOB como NULLABLE de forma predeterminada. En algunos casos, puede crear tablas de destino utilizando otro mecanismo, como importar o exportar. En tales casos, asegúrese de que las columnas de LOB sean nulíbles antes de iniciar la tarea de migración.

Este requisito tiene una excepción. Supongamos que realiza una migración homogénea desde un origen de Oracle a un destino de Oracle y elige Limited Lob mode (Modo de LOB limitado). En este caso, la totalidad de la fila se rellena a la vez, incluido cualquier valor de LOB. En tal caso, AWS DMS puede crear las columnas de LOB de la tabla de destino con restricciones NOT NULL, en caso necesario.

Using limited LOB mode

AWS DMS utiliza dos métodos que equilibran el rendimiento y la comodidad cuando la migración contiene valores LOB.

  1. Limited LOB mode (Modo LOB limitado) migra todos los valores LOB hasta un límite de tamaño especificado por el usuario (el valor predeterminado es 32 KB). Los valores LOB que superen el límite de tamaño deben migrarse manualmente. Normalmente, el valor predeterminado de Limited LOB mode (Modo de LOB limitado) para todas las tareas de migración proporciona el mejor desempeño. Sin embargo, debe asegurarse de que la configuración del parámetro Max LOB size (Tamaño máximo de LOB) sea correcta. Este parámetro debe establecerse en el tamaño de LOB más grande para todas las tablas.

  2. Full LOB mode (Modo de LOB completo) migra todos los datos LOB de las tablas, independientemente de su tamaño. Full LOB mode (Modo de LOB completo) resulta conveniente porque traslada todos los datos LOB de las tablas, si bien el proceso puede tener un impacto significativo en el desempeño.

Para algunos motores de base de datos, como PostgreSQL, AWS DMS trata los tipos de datos JSON como LOB. Asegúrese de que si ha elegido Limited LOB mode (Modo de LOB limitado), la opción Max LOB size (Tamaño máximo de LOB) esté definida en un valor que no haga que los datos JSON se trunquen.

AWS DMS es totalmente compatible en cuanto al uso de tipos de datos de objetos grandes (BLOB, CLOB y NCLOB). Los siguientes son puntos de enlace de origen totalmente compatibles con objetos LOB:

  • Oracle

  • Microsoft SQL Server

  • ODBC

Los siguientes son puntos de enlace de destino totalmente compatibles con objetos LOB:

  • Oracle

  • Microsoft SQL Server

El siguiente punto de enlace de destino tiene compatibilidad limitada con objetos LOB. No puede utilizar un tamaño LOB ilimitado para este punto de enlace de destino.

  • Amazon Redshift

Si los puntos de enlace son totalmente compatibles con objetos LOB, también puede fijar un límite de tamaño para los tipos de datos LOB.

Ongoing replication

AWS DMS proporciona la replicación continua de los datos, a la vez que mantiene las bases de datos de origen y de destino sincronizadas. Solo se replica una cantidad limitada de lenguaje de definición de datos (DDL). AWS DMS no propaga elementos tales como índices, usuarios, privilegios, procedimientos almacenados y otros cambios de la base de datos no relacionados directamente con los datos de tabla.

Si tiene previsto utilizar la replicación continua, debe habilitar la opción Multi-AZ (Multi-AZ) al crear la instancia de replicación. Al elegir la opción Multi-AZ (Multi-AZ) consigue alta disponibilidad y soporte de conmutación por error para la instancia de replicación. Sin embargo, esta opción puede afectar al desempeño.

Changing the user and schema for an Oracle target

Cuando utiliza Oracle como destino, AWS DMS migra los datos al esquema propiedad del usuario del criterio de valoración de destino.

Por ejemplo, supongamos que va a migrar un esquema denominado PERFDATA a un punto de enlace de destino de Oracle y que el nombre de usuario del punto de enlace de destino es MASTER. AWS DMS se conectará al destino de Oracle como MASTER y rellena el esquema MASTER con objetos de base de datos de PERFDATA.

Para anular este comportamiento, debe proporcionar una transformación de esquema. Por ejemplo, si desea migrar los objetos de esquema PERFDATA a un esquema PERFDATA en el punto de enlace de destino, puede utilizar la siguiente transformación:

{ "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "PERFDATA" }, "rule-target": "schema", "rule-action": "rename", "value": "PERFDATA" }

Para obtener más información sobre transformaciones, consulte Especificación de selección de tablas y transformaciones mediante mapeo de tablas con JSON.

Changing table and index tablespaces for an Oracle target

Cuando se utiliza Oracle como destino, AWS DMS migra todas las tablas e índices a los espacios de tabla de índice y de tabla predeterminados del destino. Por ejemplo, suponga que su origen es un motor de base de datos distinto de Oracle. Todas las tablas de destino e índices se migran a los mismos espacios de tabla predeterminados.

Para anular este comportamiento, tiene que proporcionar las transformaciones de espacio de tabla correspondientes. Por ejemplo, suponga que desea migrar tablas e índices a espacios de tabla de tabla e índice en el destino de Oracle que se nombran según el esquema del origen. En este caso, puede utilizar transformaciones similares a las siguientes. Aquí, el esquema en el origen se denomina INVENTORY y los espacios de tabla de tabla e índice correspondiente en el destino se llaman INVENTORYTBL e INVENTORYIDX, respectivamente.

{ "rule-type": "transformation", "rule-id": "3", "rule-name": "3", "rule-action": "rename", "rule-target": "table-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "table-tablespace-name": "%" }, "value": "INVENTORYTBL" }, { "rule-type": "transformation", "rule-id": "4", "rule-name": "4", "rule-action": "rename", "rule-target": "index-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "index-tablespace-name": "%" }, "value": "INVENTORYIDX" }

Para obtener más información sobre transformaciones, consulte Especificación de selección de tablas y transformaciones mediante mapeo de tablas con JSON.

Cuando Oracle es la fuente y el destino, puede conservar asignaciones existentes de tablas o índices de tableros configurando el atributo de conexión adicional de origen de Oracle, enableHomogenousTablespace=true. Para obtener más información, consulte Atributos de conexión adicionales al usar Oracle como origen para AWS DMS

Improving performance when migrating large tables

Si desea mejorar el desempeño al migrar una tabla de gran tamaño, puede dividir la migración en más de una tarea. Para dividir la migración en varias tareas usando el filtrado de filas, utilice una clave o una clave de partición. Por ejemplo, si tiene un ID entero de clave principal de 1 a 8 000 000, puede crear ocho tareas y usar el filtrado de filas para migrar un millón de registros por cada una.

Para aplicar el filtrado de filas en la consola de administración de AWS, abra la consola, elija Tasks (Tareas) y cree una nueva tarea. En la sección Table mappings (Mapeos de tabla), añada un valor para Selection Rule (Regla de selección). A continuación, puede añadir un filtro de columna con una condición inferior o igual a, superior o igual a, igual a o de rango (entre dos valores). Para obtener más información acerca del filtrado de columnas, consulte Especificación de selección de tablas y transformaciones mediante mapeo de tablas desde la consola.

También puede migrar los datos en función de la fecha, si tiene una tabla grande particionada por fecha. Por ejemplo, supongamos que tiene una tabla particionada por mes y solo se actualizan los datos correspondientes al mes actual. En este caso, puede crear una tarea de carga completa para cada partición mensual estática y crear una tarea de carga completa + CDC para la partición actualizada actualmente.

Using your own on-premises name server

Normalmente, un AWS DMS la instancia de replicación utiliza el solucionador del sistema de nombres de dominio (DNS) en un Amazon EC2 instancia para resolver los criterios de valoración del dominio. Sin embargo, puede utilizar su propio servidor de nombre local para resolver determinados criterios de valoración si utiliza el Amazon Route 53 Solucionador. Con esta herramienta, puede consultar entre las instalaciones y AWS utilizando terminales de entrada y salida, reglas de reenvío y una conexión privada. Las ventajas de utilizar un servidor de nombres en las instalaciones incluyen una mayor seguridad y facilidad de uso detrás de un cortafuegos.

Los criterios de valoración entrantes permiten consultas DNS que se originan en las instalaciones para resolver dominios alojados en AWS. Para configurar los criterios de valoración, asigne direcciones IP en cada subred que desee proporcionar a un solucionador. Para establecer conectividad entre su infraestructura DNS local y AWS, utilice AWS Direct Connect o una red privada virtual (VPN).

Los terminales salientes se conectan a su servidor de nombre local. El servidor de nombres solo concede acceso a direcciones IP incluidas en una lista de permisos y se establece en un terminal saliente. La dirección IP de su servidor de nombres es la dirección IP de destino. Cuando elija un grupo de seguridad para un terminal saliente, elija el mismo grupo de seguridad utilizado por la instancia de replicación.

Para reenviar dominios seleccionados al servidor de nombres, utilice reglas de reenvío. Un terminal saliente puede gestionar varias reglas de reenvío. El alcance de la regla de reenvío es su nube privada virtual (VPC). Al utilizar una regla de reenvío asociada a un VPC, puede proporcionar una sección aislada lógicamente de AWS Cloud. Desde esta sección aislada lógicamente, puede iniciar los recursos de AWS en una red virtual.

Puede configurar dominios alojados dentro de la infraestructura DNS local como reglas de reenvío condicional que permiten consultas DNS salientes. Cuando se realiza una consulta en uno de esos dominios, las reglas activan un intento de reenviar solicitudes DNS a servidores configurados con las reglas. Otra vez, una conexión privada AWS Direct Connect o VPN es obligatorio.

El siguiente diagrama muestra el Route 53 Arquitectura de resolución.


                Arquitectura de resolución Route 53

Para obtener más información sobre el solucionador DNS Route-53 de AWS, consulte Primeros pasos con el solucionador Route 53 en el Guía para desarrolladores de Amazon Route 53.

Using Amazon Route 53 Resolver with AWS DMS

Puede crear un servidor de nombre local para AWS DMS para resolver los criterios de valoración utilizando Amazon Route 53 Resolver. Una descripción del proceso sigue.

Crear un servidor de nombres en las instalaciones para DMS basado en Route 53

  1. Inicie sesión en la Consola de administración de AWS y abra la consola de Route 53 en https://console.aws.amazon.com/route53/.

  2. En el Route 53 seleccione la región de AWS en la que desee configurar su Route 53 Solucionador. El Route 53 El solucionador es específico de una región.

  3. Seleccione la dirección de la consulta—entrante, saliente o ambos.

  4. Proporcione la configuración de la consulta entrante:

    1. Introduzca un nombre de terminal y elija un VPC.

    2. Asigne una o más subredes desde dentro de la VPC (por ejemplo, elija dos para la disponibilidad).

    3. Asignar direcciones IP específicas para usarlas como criterios de valoración o Route 53 Solucione la asignación automáticamente.

  5. Cree una regla para su dominio local para que las cargas de trabajo dentro de la VPC puedan enrutar consultas de DNS a su infraestructura de DNS.

  6. Introduzca una o más direcciones IP para los servidores DNS locales.

  7. Envíe su regla.

Cuando se crea todo, su VPC está asociado a las reglas de entrada y salida y puede iniciar el tráfico de enrutamiento.

Para obtener más información sobre Route 53 Solucionador, ver Primeros pasos con el solucionador Route 53 en el Guía para desarrolladores de Amazon Route 53.