Prácticas recomendadas de AWS Database Migration Service - AWS Database Migration Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas de 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.

Planificación de la migración con AWS Database Migration Service

A la hora de planificar la migración de una base de datos con AWS Database Migration Service, tenga en cuenta lo siguiente:

  • Tendrá que configurar una red que conecte las bases de datos de origen y de destino con una instancia de replicación de AWS DMS. Esto puede ser tan sencillo como conectar dos recursos de AWS en la misma VPC como la instancia de replicación con configuraciones más complejas, tales como conectar una base de datos local a una instancia de base de datos de Amazon RDS a través de una VPN. Para obtener más información, consulte Configuraciones de red para migrar bases de datos

  • Puntos de enlace de origen y de destino – Necesitará saber qué información y tablas de la base de datos de origen deben migrarse a la base de datos de destino. AWS DMS admite la migración básica del esquema, incluida la creación de tablas y claves primarias. Sin embargo, AWS DMS no crea automáticamente índices secundarios, claves externas, cuentas de usuario, etc. en la base de datos de destino. Tenga en cuenta que, en función de su motor de base de datos de origen y de destino, es posible que tenga que configurar el registro complementario o modificar otra configuración para una base de datos de destino o de origen. Para obtener más información, consulte Orígenes para la migración de datos y Destinos para la migración de datos.

  • Migración de esquemas/código – AWS DMS no realiza conversiones de esquemas o de código. Puede utilizar herramientas como Oracle SQL Developer, MySQL Workbench o pgAdmin III para convertir su esquema. Si desea convertir un esquema existente en otro motor de base de datos, puede utilizar AWS Schema Conversion Tool. Puede crear un esquema de destino y también generar y crear un esquema completo: tablas, índices, vistas y así sucesivamente. También puede utilizar la herramienta para convertir PL/SQL o TSQL en PgSQL y otros formatos. Para obtener más información sobre AWS Schema Conversion Tool, consulte la sección sobre AWS Schema Conversion Tool.

  • Unsupported data types: algunos tipos de datos de origen deben convertirse en tipos de datos equivalentes para la base de datos de destino.– Para obtener más información sobre los tipos de datos admitidos, consulte la sección de origen o destino del almacén de datos.

Mejora del rendimiento de una migración de AWS DMS

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

  • Disponibilidad de recursos en el origen

  • Desempeño de la red disponible

  • Capacidad de los recursos del servidor de replicación

  • Capacidad del sistema de destino para incorporar cambios

  • El tipo y la distribución de los datos de origen

  • El número de objetos que se van a migrar

En nuestras pruebas, hemos migrado un terabyte de datos en aproximadamente 12–13 horas mediante una única tarea de AWS DMS y en condiciones ideales. Estas condiciones ideales incluían el uso de bases de datos de origen que se ejecutaban en Amazon EC2 y en Amazon RDS con bases de datos de destino en Amazon RDS, todas ellas 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.

Uso de índices, disparadores y límites de integridad referencial

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. Por tanto, no se necesitan índices durante una tarea de carga completa, y los índices incurren en sobrecarga 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 una base de datos de Amazon RDS, se recomienda deshabilitar las copias de seguridad y Multi-AZ en el destino hasta que todo esté listo para realizar el traspaso. Del mismo modo, al migrar a sistemas que no sean Amazon RDS, es buena idea deshabilitar cualquier registro en el destino hasta después del cambio.

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, es posible que pueda dividir la migración en varias tareas. La consistencia transaccional se mantiene dentro de una tarea, por lo que es importante que las tablas de tareas independientes 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. Esto le permite paralelizar las lecturas en el origen, los procesos en la instancia de replicación y las escrituras en 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. El uso de la opción de aplicación optimizada por lotes infringe casi siempre los límites de integridad referencial. Por lo tanto, le recomendamos que los deshabilite durante el proceso de migración y que los habilite de nuevo como parte del proceso de cambio.

Reducción de la carga en su base de datos de origen

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.

Uso del registro de tareas para solucionar problemas de migración

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. Con el fin de habilitar la visualización del log de tareas, configure Amazon CloudWatch como parte de la creación de tareas.

Conversión de esquemas

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 están en el mismo motor de base de datos, puede utilizar herramientas como Oracle SQL Developer, MySQL Workbench o PgAdmin4 para mover su esquema.

Migración de objetos binarios grandes (LOB)

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 LOBs 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 las tablas de destino con algún otro mecanismo, como la importación o exportación. En estos casos, asegúrese de que las columnas de LOB sean NULLABLE antes de comenzar 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.

Uso del modo LOB limitado

AWS DMS utiliza dos métodos que equilibran el desempeño 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 LOBs. 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é establecida en un valor que no haga que los datos JSON se trunquen.

El AWS DMS es totalmente compatible en cuanto al uso de tipos de datos de objetos grandes (BLOB, CLOBs y NCLOBs). 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.

La replicación continua

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, obtiene 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.

Antes de actualizar las bases de datos de origen o de destino, le recomendamos que detenga las tareas de AWS DMS que se estén ejecutando en estas bases de datos. Reanude las tareas una vez completadas las actualizaciones.

Mejora del rendimiento al migrar tablas grandes

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 reglas de transformaciones 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.

Uso de su propio servidor de nombres en las instalaciones

Normalmente, una instancia de replicación de AWS DMS utiliza el solucionador del sistema de nombres de dominio (DNS) en una instancia Amazon EC2 para resolver puntos de enlace del dominio. Sin embargo, puede utilizar su propio servidor de nombres local para resolver determinados puntos de enlace si utiliza el solucionador de Amazon Route 53. Con esta herramienta, puede realizar consultas entre las instalaciones y AWS mediante puntos de enlace de entrada y salida, reglas de reenvío y una conexión privada. Los beneficios de utilizar un servidor de nombres en las instalaciones incluyen una mayor seguridad y facilidad de uso detrás de un firewall.

Los puntos de enlace de entrada habilitan las consultas de DNS que se originan localmente para resolver dominios alojados de AWS. Para configurar los puntos de enlace, asigne direcciones IP en cada subred que desee que proporcione un solucionador. Para establecer la conectividad entre su infraestructura de DNS local y AWS, utilice AWS Direct Connect o una red privada virtual (VPN).

Los puntos de enlace de salida se conectan al servidor de nombres en las instalaciones. El servidor de nombres solo concede acceso a direcciones IP incluidas en una lista de direcciones permitidas y establecidas en un punto de enlace saliente. La dirección IP de su servidor de nombres es la dirección IP de destino. Al elegir un grupo de seguridad para un punto de enlace de salida, 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 punto de enlace de salida puede gestionar varias reglas de reenvío. El ámbito de la regla de reenvío es su nube virtual privada (VPC). Con una regla de reenvío asociada a una VPC, puede aprovisionar una sección aislada lógicamente de la nube de AWS. Desde esta sección aislada lógicamente, puede lanzar recursos de AWS en una red virtual.

Puede configurar dominios alojados en su infraestructura de DNS local como reglas de reenvío condicional que permitan las consultas de DNS salientes. Cuando se realiza una consulta a uno de esos dominios, las reglas desencadenan un intento de reenviar solicitudes de DNS a servidores configurados con las reglas. De nuevo, se requiere una conexión privada a través de AWS Direct Connect o una VPN.

El siguiente diagrama muestra la arquitectura de Route 53 Resolver.


                Arquitectura de Route 53 Resolver

Para obtener más información sobre AWS Route-53 DNS Resolver, consulte Introducción a Route 53 Resolver en la Guía para desarrolladores de Amazon Route 53.

Usar Amazon Route 53 Resolver conAWS DMS

Puede crear un servidor de nombres local para que AWS DMS resuelva puntos de enlace mediante Amazon Route 53 Resolver. A continuación se muestra una descripción del proceso.

Para crear un servidor de nombres local para DMS basado enRoute 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 la consola de Route 53, elija la región de AWS en la que desea configurar su solucionador de Route 53. El solucionador de Route 53 es específico de una región.

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

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

    1. Introduzca un nombre de punto de enlace y elija una VPC.

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

    3. Asigne direcciones IP específicas para utilizarlas como puntos de enlace, o haga que Route 53 Resolver las asigne 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 sus servidores DNS locales.

  7. Envíe la regla.

Cuando se crea todo, su VPC se asocia con sus reglas de entrada y salida y puede comenzar a dirigir el tráfico.

Para obtener más información acerca de Route 53 Resolver, consulte Introducción a Route 53 Resolver en la Guía para desarrolladores de Amazon Route 53.

Cambio del usuario y el esquema de un destino de Oracle

Con Oracle como destino, AWS DMS migra los datos al esquema propiedad del usuario del punto de enlace 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 la selección de tablas y reglas de transformaciones mediante JSON.

Cambio de espacios de tabla de tabla e índice para un destino de Oracle

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 la selección de tablas y reglas de transformaciones mediante JSON.

Cuando Oracle es origen y destino, puede conservar las asignaciones de espacio de tabla de índice o tabla existentes estableciendo 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