Migración de datos de SQL bases de datos de Postgre con migraciones de datos homogéneas en AWS DMS - 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.

Migración de datos de SQL bases de datos de Postgre con migraciones de datos homogéneas en AWS DMS

Puede utilizarla Migraciones de datos homogéneas para migrar una SQL base de datos Postgre autogestionada a Postgre o RDS Aurora Postgre. SQL SQL AWS DMS crea un entorno sin servidores para la migración de datos. Para diferentes tipos de migraciones de datos, AWS DMS utiliza diferentes herramientas de bases de datos nativas de SQL Postgre.

Para migraciones de datos homogéneas del tipo de carga completa, AWS DMS usa pg_dump para leer los datos de la base de datos de origen y almacenarlos en el disco conectado al entorno sin servidor. Después de AWS DMS leer todos los datos de origen, utiliza pg_restore en la base de datos de destino para restaurarlos.

Para migraciones de datos homogéneas del tipo Full Load and Change Data Capture (CDC), se AWS DMS utiliza pg_dump para leer objetos de esquema sin datos de tablas de la base de datos de origen y almacenarlos en el disco conectado al entorno sin servidor. A continuación, se utiliza pg_restore en la base de datos de destino para restaurar los objetos del esquema. Una vez AWS DMS finalizado el pg_restore proceso, cambia automáticamente a un modelo de publicador y suscriptor para la replicación lógica, con la Initial Data Synchronization opción de copiar los datos iniciales de la tabla directamente de la base de datos de origen a la base de datos de destino y, a continuación, inicia la replicación continua. En este modelo, uno o más suscriptores se suscriben a una o más publicaciones en un nodo publicador.

En el caso de migraciones de datos homogéneas del tipo Change data capture (CDC), se AWS DMS requiere el punto de partida nativo para iniciar la replicación. Si proporciona el punto de inicio nativo, AWS DMS captura los cambios desde ese punto. Otra opción, elija Inmediatamente en la configuración de migración de datos para capturar automáticamente el punto de inicio de la replicación cuando comience la migración de datos real.

nota

Para que una migración CDC exclusiva funcione correctamente, todos los esquemas y objetos de la base de datos de origen deben estar ya presentes en la base de datos de destino. Sin embargo, es posible que el destino tenga objetos que no estén presentes en el origen.

Puede usar el siguiente ejemplo de código para obtener el punto de inicio nativo de su base de datos de SQL Postgre.

select confirmed_flush_lsn from pg_replication_slots where slot_name=‘migrate_to_target';

Esta consulta utiliza la pg_replication_slots vista de la SQL base de datos de Postgre para capturar el valor del número de secuencia del registro (). LSN

Después de AWS DMS establecer el estado de la migración de datos SQL homogéneos de Postgre como Detenida, Fallida o Eliminada, el publicador y la replicación no se eliminan. Si no desea reanudar la migración, elimine la ranura de replicación y el publicador mediante el siguiente comando.

SELECT pg_drop_replication_slot('migration_subscriber_{ARN}'); DROP PUBLICATION publication_{ARN};

El siguiente diagrama muestra el proceso de usar migraciones de datos homogéneas para AWS DMS migrar una SQL base de datos de Postgre a RDS Postgre o Aurora PostgreSQL. SQL

Diagrama de arquitectura de la migración de datos de Postgre con migraciones de datos homogéneasSQL. DMS

Mejores prácticas para usar una base de datos de Postgre como fuente para SQL migraciones de datos homogéneas

  • Para acelerar la sincronización inicial de los datos por parte del suscriptor para la FLCDC tarea, debe ajustar y. max_logical_replication_workers max_sync_workers_per_subscription El aumento de estos valores mejora la velocidad de sincronización de la tabla.

    • max_logical_replication_workers: especifica el número máximo de trabajadores de replicación lógica. Esto incluye tanto los trabajadores de aplicación del lado del suscriptor como los trabajadores de sincronización de tablas.

    • max_sync_workers_per_subscription: el aumento max_sync_workers_per_subscription solo afecta al número de tablas que se sincronizan en paralelo, no al número de trabajadores por tabla.

    nota

    max_logical_replication_workersno debe superar max_worker_processes ni ser inferior o igual a. max_sync_workers_per_subscription max_logical_replication_workers

  • Para migrar tablas grandes, considere la posibilidad de dividirlas en tareas independientes mediante reglas de selección. Por ejemplo, puede dividir las tablas grandes en tareas individuales independientes y las tablas pequeñas en otra tarea individual.

  • Supervise el disco y el CPU uso por parte del suscriptor para mantener un rendimiento óptimo.