AWS Database Migration Service es un servicio en la nube que migra bases de datos relacionales, bases de datos NoSQL, almacenes de datos y todos los demás tipos de almacenamiento de datos a la nube de AWS o entre configuraciones en la nube y locales de manera eficiente y segura. DMS admite varios tipos de bases de datos de origen y destino, como Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift y S3, etc.
Observaciones Durante la Migración de Datos
Trabajamos en el diseño y creación de un lago de datos AWS S3 y un almacén de datos en AWS Redshift con las fuentes de datos locales para Oracle, MS SQL Server, MySQL, Postgres SQL y MongoDB para bases de datos relacionales. Utilizamos AWS DMS para la carga completa inicial y la transferencia de datos incrementales diarios desde estas fuentes a AWS S3.
Con esta serie de publicaciones, quiero explicar los diversos desafíos enfrentados durante la migración real de datos con diferentes bases de datos relacionales.
1. Fecha Modificada No Poblada Correctamente en el Origen
AWS DMS se utiliza para la carga completa y la captura de datos de cambios de bases de datos de origen. AWS DMS captura registros cambiados basados en los registros de transacciones, pero una columna de fecha modificada actualizada correctamente puede ayudar a aplicar la lógica de deduplicación y extraer el último registro modificado para una fila dada en el destino en S3.
En caso de que los datos modificados no estén disponibles para una tabla o no se actualicen correctamente, AWS DMS proporciona una opción de reglas de transformación para agregar una nueva columna al extraer datos de la base de datos de origen. Aquí, el encabezado AR_H_CHANGE_SEQ ayuda a agregar una nueva columna con un valor como un número único en incremento de la base de datos de origen, que consta de una marca de tiempo y un número de incremento automático.
El siguiente ejemplo de código agrega una nueva columna como DMS_CHANGE_SEQ al destino, que tiene un número único en incremento de la base de datos de origen. Este es un número único de 35 dígitos con los primeros 16 dígitos para la marca de tiempo y los siguientes 19 dígitos para el número de identificación del registro incrementado por la base de datos.
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value": "DMS_CHANGE_SEQ",
"expression": "$AR_H_CHANGE_SEQ",
"data-type": {
"type": "string",
"length": 100
}
}
2. Habilitar el registro suplementario para Oracle como origen
Para Oracle como base de datos de origen, para capturar cambios en curso, AWS DMS necesita que se habilite el registro suplementario mínimo en la base de datos de origen. En consecuencia, esto incluirá información adicional y columnas en los registros de redo para identificar los cambios en el origen.
El registro suplementario se puede habilitar para claves primarias, únicas, conjuntos de columnas o todas las columnas. El registro suplementario para todas las columnas captura todas las columnas de las tablas en la base de datos de origen y ayuda a sobrescribir los registros completos en la capa de destino de AWS S3.
El registro suplementario de todas las columnas aumentará el tamaño de los registros de redo, ya que todas las columnas de la tabla se registran en los logs. Es necesario configurar, redo y archivar los logs de acuerdo con la información adicional que contengan.
3. Ancho de Banda de Red Entre Bases de Datos de Origen y Destino
La carga inicial completa desde las fuentes locales para Oracle, MS SQL Server, etc., funcionó bien y la captura de datos cambiados también, la mayor parte del tiempo.
Solía haber un número moderado de transacciones la mayor parte del día en un mes determinado, excepto por el proceso de cierre del día laboral, diariamente, después de la medianoche y las actividades de fin de mes. Observamos que las tareas de migración de DMS estaban desincronizadas o fallaban durante este tiempo.
Revisamos las métricas de la instancia de origen, destino y replicación en los logs y encontramos las siguientes observaciones:
- CDCLatencySource – la brecha, en segundos, entre el último evento capturado del punto final de origen y la marca de tiempo actual del sistema de la instancia de AWS DMS.
- CDCIncomingchanges – el número total de eventos de cambio en un momento dado que está esperando ser aplicado al destino. Esto aumenta de cero a miles durante las actividades de reconciliación en la madrugada.
- CDCLatencySource – la brecha, en segundos, entre el último evento capturado del punto final de origen y la marca de tiempo actual del sistema de la instancia de AWS DMS. Esto aumenta desde cero a unos pocos miles hasta 10-12 mil segundos durante las actividades diarias de reconciliación posterior a la medianoche. Este valor llegó a ser de hasta 40 mil durante las actividades de fin de mes.
Tras un análisis adicional de registros y revisión de otras métricas, observamos que:
Las métricas de AWS DMS NetworkReceiveThroughput sirven para comprender el tráfico entrante en la instancia de replicación de DMS tanto para la base de datos del cliente como para el tráfico de DMS. Estas métricas ayudan a entender los problemas relacionados con la red, si los hay, entre la base de datos de origen y la instancia de replicación de DMS.
Se observó que el rendimiento de recepción de red llegó a ser de hasta 30 MB/s, es decir, 250 Mb/s, debido a la conexión VPN entre el origen y AWS, que también se compartía con otras aplicaciones.
La conclusión final de este problema es que la conectividad entre las bases de datos de origen y destino es fundamental para una migración de datos exitosa. Debe asegurarse de que el ancho de banda suficiente entre las bases de datos de origen en las instalaciones o en otra nube y el entorno de AWS esté configurado antes de la migración real de datos.
- Un túnel VPN como AWS Site-to-Site VPN o Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS) puede proporcionar un rendimiento de hasta 1,25 Gbps. Esto sería suficiente para la migración de tablas pequeñas o tablas con menos tráfico de DML.
- Para migraciones de datos grandes con transacciones pesadas por segundo en las tablas, se debe considerar AWS Direct Connect. Proporciona la opción de crear una conexión privada dedicada con un ancho de banda de 1 Gbps, 10 Gbps, etc.
Conclusión
Esta es la Parte I de la serie de varias partes para las migraciones de bases de datos relacionales utilizando AWS DMS y las soluciones implementadas. La mayoría de los desafíos mencionados en esta serie podrían ocurrir durante el proceso de migración de la base de datos y estas soluciones pueden ser consultadas.
Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment