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 Postgre. SQL
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 AWS DMS lee todos los datos de origen y 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, AWS DMS pg_dumpse utiliza 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, los utiliza pg_restore en la base de datos de destino para restaurar los objetos de esquema. Después AWS DMS completa 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.
Para migraciones de datos homogéneas del tipo Change data capture (CDC), AWS DMS requiere el punto de inicio nativo para iniciar la replicación. Si proporciona el punto de inicio nativo, entonces 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 AWS DMS establece el estado de la migración SQL homogénea de datos de Postgre como Detenida, Fallida o Eliminada; el editor 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 uso de migraciones de datos homogéneas en AWS DMS para migrar una SQL base de datos de Postgre a RDS Postgre SQL o Aurora Postgre. SQL
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 datos por parte del suscriptor para la FLCDC tarea, debe ajustar y.
max_logical_replication_workersmax_sync_workers_per_subscriptionEl 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_subscriptionsolo 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 superarmax_worker_processesni ser inferior o igual a.max_sync_workers_per_subscriptionmax_logical_replication_workersPara 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.
