¿Cuáles son las prácticas recomendadas que se deben utilizar al migrar bases de datos de PostgreSQL a una base de datos de RDS para PostgreSQL de destino mediante AWS DMS?

Descripción corta

Cuando migre bases de datos homogéneas con AWS DMS, copie los datos iniciales con las herramientas nativas del motor, como pg_dump. A continuación, ejecute pg_restore en el destino. También puede usar la replicación lógica y el comando COPY. Para obtener más información, consulte Best practices for migrating PostgreSQL databases to Amazon RDS and Amazon Aurora (Prácticas recomendadas para migrar bases de datos de PostgreSQL a Amazon RDS y Amazon Aurora).

Para migrar desde una base de datos de RDS para PostgreSQL a otra base de datos de RDS para PostgreSQL, tome una instantánea y, a continuación, restaure la instantánea como destino. Para obtener más información, consulte Migrating a snapshot of an RDS for PostgreSQL DB instance to an Aurora PostgreSQL DB cluster (Migración de una instantánea de una instancia de base de datos de RDS para PostgreSQL a un clúster de base de datos Aurora PostgreSQL).

Tenga en cuenta que la migración de todos sus datos desde una base de datos de origen a una base de datos de destino mediante la carga completa de AWS DMS puede llevar mucho tiempo. Es posible que experimente retrasos debido a los siguientes factores:

• Ancho de banda
• Capacidad de origen para enviar grandes cantidades de datos
• Capacidad del motor de replicación para almacenar, procesar y reenviar cargas de manera masiva
• Capacidad del destino para consumir datos del origen

En comparación, la replicación de cambios solo contiene cambios del origen al destino, por lo que las cargas de trabajo como esta pueden ser muy ligeras.

Crear y determinar el número de secuencia de registro (log sequence number, LSN) actual

Antes de realizar una copia de seguridad, debe obtener un marcador que indique a la tarea de AWS DMS desde dónde empezar a migrar los cambios.

En la base de datos de PostgreSQL de origen, ejecute estas consultas para crear y determinar el LSN actual.

Cree la ranura de replicación:

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

Obtenga el LSN actual:

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

El comando restart_LSN indica a la tarea de AWS DMS dónde empezar a migrar los cambios desde el origen al destino.

Resolución

Utilice estas prácticas recomendadas para migrar datos de PostgreSQL a PostgreSQL mediante tareas de AWS DMS.

No usar claves externas y desencadenadores durante la carga completa

Cuando se esté realizando la carga completa, asegúrese de que las claves externas y los desencadenadores no estén incluidos para la migración. AWS DMS migra las tablas en orden alfabético, pero no sabe qué tablas son tablas principales y cuáles secundarias. Por lo tanto, es posible que AWS DMS intente migrar primero las tablas secundarias. A continuación, AWS DMS detiene la migración de las tablas debido a una infracción de clave externa. Por lo tanto, suprima o no incluya claves externas en el destino durante la migración.

Los desencadenadores nunca deben estar presentes en un destino durante la migración porque realizan varios procesos que podrían dañar los datos del destino. Agregue cualquier disparador a la transición.

Activar el modo LOB completo al migrar datos JSON

Al migrar LOB en forma de JSON, active el modo LOB completo para que el formato JSON no se trunque. Si usa el modo LOB limitado, es posible que se produzca un truncamiento de datos. A continuación, AWS DMS se asegura de que se produzca un error en la tabla porque el formato JSON es incorrecto.

Asegurarse de que el campo de clave principal no sea del tipo de datos TEXT

Compruebe que el campo de clave principal no sea TEXT, especialmente si el modo LOB completo está activado. Es posible que experimente DUPLICATES de NULL porque AWS DMS trata el tipo de datos TEXT como LOB. Por lo tanto, durante la carga completa, AWS DMS intenta hacer que la clave principal sea NULL y, a continuación, informa de un duplicado porque hay muchas columnas de texto con el mismo valor. El error nunca se trata como “NULL not allowed on Primary Key” (No se permite NULL en la clave principal), sino como duplicados. Este puede ser un problema difícil de descubrir y resolver, así que confirme siempre que el campo de la clave principal no sea TEXT para evitar el problema.

Permitir que AWS DMS cree tablas de destino

Si se está realizando una carga completa, permita que AWS DMS cree tablas en el destino. Cuando AWS DMS crea tablas, también crea los campos coincidentes sin valores DEFAULT para las columnas. Los valores predeterminados de las columnas pueden provocar un comportamiento inesperado en AWS DMS. Por ejemplo, SERIAL hace que la migración de AWS DMS falle porque este campo quiere crear un valor automáticamente. Consulte este ejemplo:

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

Si el destino está estructurado como en este ejemplo, los componentes internos de PostgreSQL quieren generar el valor de la columna ID. Sin embargo, el origen también contiene un valor para INSERT que provoca un problema. Por lo tanto, asegúrese de que DEFAULTS no forme parte del destino durante la migración.

Definir particiones como tablas de origen en las asignaciones de tablas de tareas

Al migrar tablas particionadas, asegúrese de definir las particiones como tablas de origen en las asignaciones de tablas de tareas, no en las tablas principales. Esto se debe a que los registros WAL conservan la información de la tabla particionada. Las tablas principales solo se deben usar durante la carga completa, así que no use tablas principales para la fase de CDC. Si define tablas principales durante los CDC, es posible que encuentre errores duplicados que afecten a la migración.

Además, cuando asigne las tablas de destino, asegúrese de que todas las particiones se reasignen al elemento principal. Esto significa que el elemento principal se utiliza para distribuir automáticamente a sus particiones.

Definir todas las facetas del destino al utilizar PGLOGICAL

Cuando utilice PGLOGICAL para la migración, asegúrese de definir todas las facetas que se requieren en el origen. Si omite un área, observará un comportamiento inesperado. Los problemas que se producen como resultado de esto son muy difíciles de solucionar, así que compruebe que ha definido estas áreas antes de comenzar la migración con PGLOGICAL.

Para Amazon RDS, defina estos elementos:

Grupo de parámetros:

shared_preload_libraries = pglocical

Nivel de base de datos:

create extension pglogical;

Para local, defina estos elementos:

postgresql.conf:

shared_preload_libraries = pglogical

Nivel de base de datos:

create extension pglogical;

Asegurarse de que todos los complementos de PG que se definen en el origen estén definidos en el destino

Asegúrese de que todos los complementos de PG que defina en el origen también estén definidos en el destino. Esto contribuye a la compatibilidad y al procesamiento fluido de los datos.

Asegurarse de que las tareas no permanezcan en el estado Stop/Error (Detener/Error)

Cuando las tareas tardan mucho en los estados Stop (Detener) o Error, el almacenamiento se llena en la ranura de replicación.

Eliminar las ranuras de replicación creadas manualmente del origen

Si creó cualquier ranura de replicación de forma manual, elimínelas del origen cuando se complete la migración. Si las ranuras de replicación permanecen en el origen, se acumulan en tamaño y el almacenamiento se llena.

Migrar tablas con una clave principal/índice único

Se recomienda asegurarse de que las tablas que va a migrar tengan una clave principal/índice único. Si una tabla no tiene una clave principal, es posible que las instrucciones UPDATE y DELETE no se apliquen a la tabla porque no están registradas en los registros de WAL. Para las tablas sin una clave principal, utilice REPLICATE IDENTITY FULL, pero tenga en cuenta que esto genera mucha información en los registros.

---

Información relacionada

Using a PostgreSQL database as an AWS DMS source (Uso de una base de datos de PostgreSQL como origen de AWS DMS)

Destinos para la migración de datos