Uso de una base de datos PostgreSQL comoAWS DMS fuente - AWS Database Migration Service
Trabajo con bases de datos PostgreSQL autoadministradasTrabajando con basesAWS de datos PostgreSQL administradas como fuentes de DMSUso de la replicación lógica para habilitar los CDC durante la migraciónUso de puntos de inicio nativos de los CDC para configurar una carga de CDCMigraciones de PostgreSQL a PostgreSQLQuitar artefactos de un origen de PostgreSQLAjustes de configuración avanzados para PostgreSQL como origenUso de la configuración de punto final de MapBooleanAsBoolean PostgreSQLConfiguración de endpointRestricciones de PostgreSQL como origenTipos de datos de origen para PostgreSQL

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.

Uso de una base de datos PostgreSQL comoAWS DMS fuente

Puede migrar datos desde una o varias bases de datos de PostgreSQL con AWS DMS. Con una base de datos de PostgreSQL como fuente, puede migrar los datos a otra base de datos de PostgreSQL o a una de las bases de datos compatibles. AWS DMSadmite una base de datos PostgreSQL de las versiones 9.4 y posteriores (para las versiones 9.x), 10.x, 11.x, 12.x, 13.x y 14.x como fuente para los siguientes tipos de bases de datos:

  • Bases de datos locales

  • Bases de datos en una instancia Amazon EC2

  • Bases de datos en una instancia de base de datos de Amazon RDS

  • Bases de datos en una instancia de base de datos basada en Amazon Aurora PostgreSQL-Compatible Edition

  • Bases de datos en una instancia de base de datos basada en Amazon Aurora PostgreSQL-Compatible Edition

nota

DMS admite Amazon Aurora PostgreSQL (Serverless V1) como fuente únicamente para carga completa. Sin embargo, puede utilizar Amazon Aurora PostgreSQL—Serverless V2 como fuente para tareas de carga completa, carga completa + CDC y solo de CDC.

Versión de origen de PostgreSQL

Versión de AWS DMS que se debe usar

9.x, 10.x, 11.x, 12.x

Utilice cualquier versión disponible de AWS DMS.

13.x

UtiliceAWS DMS la versión 3.4.3 y versiones posteriores.

14.x

UtiliceAWS DMS la versión 3.4.7 o superior.

Puede usar las capas de conexión segura (SSL) para cifrar las conexiones entre el punto de conexión de PostgreSQL y la instancia de replicación. Para obtener más información sobre el uso de SSL con un punto de enlace de PostgreSQL, consulte Uso de SSL con AWS Database Migration Service.

Como requisito de seguridad adicional cuando se utiliza PostgreSQL como fuente, la cuenta de usuario especificada debe ser un usuario registrado en la base de datos de PostgreSQL.

Para configurar una base de datos de PostgreSQL como extremo deAWS DMS origen, haga lo siguiente:

Trabajando con bases de datos PostgreSQL autogestionadas como fuente enAWS DMS

Con una base de datos PostgreSQL autogestionada como fuente, puede migrar los datos a otra base de datos de PostgreSQL o a una de las otras bases de datos de destino compatibles conAWS DMS. El origen de la base de datos puede ser una base de datos en las instalaciones o un motor autoadministrado que se ejecuta una instancia Amazon EC2. Puede utilizar una instancia de base de datos tanto para tareas de carga completa como para tareas de captura de datos de cambios (CDC).

Requisitos previos para utilizar una base de datos PostgreSQL autogestionada comoAWS DMS fuente

Antes de migrar datos de una base de datos fuente de PostgreSQL autogestionada, haga lo siguiente:

  • Asegúrese de utilizar una base de datos PostgreSQL de la versión 9.4.x o posterior.

  • Para tareas de carga completa más de CDC o tareas exclusivas de CDC, conceda permisos de superusuario para la cuenta de usuario especificada para la base de datos fuente de PostgreSQL. La cuenta de usuario necesita permisos de superusuario para acceder a las funciones específicas de la replicación en la fuente. Para las tareas de carga completa únicamente, la cuenta de usuario necesita los permisos SELECT en las tablas para migrarlas.

  • Agregue la dirección IP del servidor de replicación AWS DMS al archivo de configuración pg_hba.conf y habilite las conexiones de socket y replicación. Ejemplo:

    
            # Replication Instance
            host all all 12.3.4.56/00 md5
            # Allow replication connections from localhost, by a user with the
            # replication privilege.
            host replication dms 12.3.4.56/00 md5

    El archivo de configuración de PostgreSQL pg_hba.conf controla la autenticación del cliente. (HBA significa autenticación basada en host). El archivo se almacena tradicionalmente en el directorio de datos del clúster de bases de datos.

  • Si está configurando una base de datos como fuente para la replicación lógica,AWS DMS consulteHabilitar a los CDC utilizando una base de datos PostgreSQL autogestionada comoAWS DMS fuente

nota

AlgunasAWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el motor de DMS las vuelva a utilizar. Al utilizar el parámetroidle_in_transaction_session_timeout en las versiones 9.6 y posteriores de PostgreSQL, puede provocar que las transacciones inactivas se agoten y fallen. No finalice las transacciones inactivas cuando utilice AWS DMS.

Habilitar a los CDC utilizando una base de datos PostgreSQL autogestionada comoAWS DMS fuente

AWS DMSadmite la captura de datos de cambio (CDC) mediante replicación lógica. Para habilitar la replicación lógica de una base de datos fuente de PostgreSQL autogestionada, defina los siguientes parámetros y valores en el archivopostgresql.conf de configuración:

  • Configurar wal_level = logical.

  • Defina max_replication_slots en un valor mayor de 1.

    Defina elmax_replication_slots valor según la cantidad de tareas que desee ejecutar. Por ejemplo, para ejecutar cinco tareas, establece un mínimo de cinco espacios. Las ranuras se abrirán automáticamente en cuanto se inicie una tarea y permanecerán abiertas incluso cuando la tarea ya no se esté ejecutando. Asegúrese de eliminar manualmente las ranuras abiertas.

  • Defina max_wal_senders en un valor mayor de 1.

    El parámetro max_wal_senders establece el número de tareas simultáneas que pueden ejecutarse.

  • Elwal_sender_timeout parámetro finaliza las conexiones de replicación que permanecen inactivas durante más de la cantidad de milisegundos especificada. El valor predeterminado es 60000 milisegundos (60 segundos). Si se establece el valor en 0 (cero), se deshabilita el mecanismo de tiempo de espera y es una configuración válida para el DMS.

    Cuando se establecewal_sender_timeout en un valor distinto de cero, el DMS requiere un mínimo de 10 000 milisegundos (10 segundos) y se produce un error si el valor es inferior a 10 000. Mantenga el valor en menos de 5 minutos para evitar demoras durante una conmutación por error Multi-AZ de una instancia de replicación de DMS.

Algunos parámetros son estáticos y solo puede configurarlos al iniciar el servidor. Cualquier cambio en sus entradas en el archivo de configuración (para una base de datos autogestionada) o en el grupo de parámetros de base de datos (para una base de datos de RDS para PostgreSQL) se ignorará hasta que se reinicie el servidor. Para obtener más información, consulte la documentación de PostgreSQL.

Para obtener más información acerca de cómo activar los CDC, consulteHabilitar la captura de datos de cambio (CDC) mediante replicación lógica.

Trabajando con basesAWS de datos PostgreSQL administradas como fuentes de DMS

Puede utilizar una instanciaAWS de base de datos PostgreSQL administrada como fuente paraAWS DMS. Puede realizar tareas de carga completa y cambiar las tareas de captura de datos (CDC) mediante una fuenteAWS de PostgreSQL gestionada.

Requisitos previos para utilizar una baseAWS de datos PostgreSQL administrada como fuente de DMS

Antes de migrar los datos de una baseAWS de datos fuente de PostgreSQL administrada, haga lo siguiente:

  • Utilice la cuenta de usuarioAWS maestra de la instancia de base de datos de PostgreSQL como cuenta de usuario del punto final de origen de PostgreSQL paraAWS DMS. La cuenta de usuario principal dispone de los roles necesarios que le permiten configurar la CDC. Si usa una cuenta que no sea la cuenta de usuario maestra, la cuenta debe tener elrds_superuser rol y elrds_replication rol. Elrds_replication rol otorga permisos para administrar ranuras lógicas y para transmitir datos mediante ranuras lógicas.

    Si no usa la cuenta de usuario maestra para la instancia de base de datos, asegúrese de crear varios objetos a partir de la cuenta de usuario maestra para la cuenta que utiliza. Para obtener más información acerca de cómo crearlos, consulteMigrar una base de datos de Amazon RDS for PostgreSQL sin usar la cuenta de usuario principal.

  • Si la base de datos de origen se encuentra en una nube privada virtual (VPC), elija el grupo de seguridad de VPC que proporciona acceso a la instancia de base de datos en la que reside la base de datos. Esto es necesario para que la instancia de replicación del DMS se conecte correctamente a la instancia de base de datos de origen. Cuando la base de datos y la instancia de replicación de DMS estén en la misma VPC, añada el grupo de seguridad correspondiente a sus propias reglas de entrada.

nota

AlgunasAWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el motor de DMS las vuelva a utilizar. Al utilizar el parámetroidle_in_transaction_session_timeout en las versiones 9.6 y posteriores de PostgreSQL, puede provocar que las transacciones inactivas se agoten y fallen. No finalice las transacciones inactivas cuando utilice AWS DMS.

Habilitar los CDC con una instanciaAWS de base de datos PostgreSQL administrada conAWS DMS

AWS DMSadmite CDC en las bases de datos PostgreSQL de Amazon RDS cuando la instancia de base de datos está configurada para usar la replicación lógica. La siguiente tabla resume la compatibilidad de replicación lógica de cada versiónAWS de PostgreSQL administrada.

No puede usar réplicas de lectura de PostgreSQL de RDS para la CDC (replicación continua).

Versión de PostgreSQL

AWS DMSsoporte de carga completa

AWS DMSSoporte de los CDC

Aurora PostgreSQL versión 2.1 con compatibilidad con PostgreSQL 10.5 (o versiones anteriores)

Sí

No

Aurora PostgreSQL versión 2.2 con compatibilidad con PostgreSQL 10.6 (o versiones posteriores)

Sí

Sí

Compatibilidad con RDS para PostgreSQL con PostgreSQL 10.21 (o superior)

Sí

Sí
Para habilitar la replicación lógica en una instancia de base de datos de RDS para PostgreSQL

  1. Utilice la cuenta de usuarioAWS maestra de la instancia de base de datos de PostgreSQL como cuenta de usuario para el extremo de origen de PostgreSQL. La cuenta de usuario principal dispone de los roles necesarios que le permiten configurar la CDC.

    Si usa una cuenta que no sea la cuenta de usuario maestra, asegúrese de crear varios objetos a partir de la cuenta maestra para la cuenta que usa. Para obtener más información, consulte Migrar una base de datos de Amazon RDS for PostgreSQL sin usar la cuenta de usuario principal.

  2. Defina elrds.logical_replication parámetro de su grupo de parámetros DB CLUSTER en 1. Para que este parámetro estático surta efecto, es necesario reiniciar la instancia de base de datos. Como parte de la aplicación de este parámetro, AWS DMS establece los parámetros wal_level, max_wal_senders, max_replication_slots y max_connections. Estos cambios de parámetros pueden aumentar la generación de registros de escritura anticipada (WAL), así que solo debe establecer rds.logical_replication cuando utilice ranuras de replicación lógica.

  3. Elwal_sender_timeout parámetro finaliza las conexiones de replicación que permanecen inactivas durante más de la cantidad de milisegundos especificada. El valor predeterminado es 60000 milisegundos (60 segundos). Si se establece el valor en 0 (cero), se deshabilita el mecanismo de tiempo de espera y es una configuración válida para el DMS.

    Cuando se establecewal_sender_timeout en un valor distinto de cero, el DMS requiere un mínimo de 10 000 milisegundos (10 segundos) y se produce un error si el valor está entre 0 y 10 000. Mantenga el valor en menos de 5 minutos para evitar demoras durante una conmutación por error Multi-AZ de una instancia de replicación de DMS.

  4. Asegúrese de que el valor delmax_worker_processes parámetro de su grupo de parámetros de clúster de base de datos sea igual o superior a los valores combinados totales demax_logical_replication_workersautovacuum_max_workers, ymax_parallel_workers. Un gran número de procesos de trabajo en segundo plano podría afectar a las cargas de trabajo de las aplicaciones en instancias pequeñas. Por lo tanto, supervise el rendimiento de la base de datos si establece un valormax_worker_processes superior al predeterminado.

Migrar una base de datos de Amazon RDS for PostgreSQL sin usar la cuenta de usuario principal

En algunos casos, es posible que no utilice la cuenta de usuario maestra de la instancia de base de datos PostgreSQL de Amazon RDS que está utilizando como fuente. En estos casos, se crean varios objetos para capturar eventos del lenguaje de definición de datos (DDL). Puede crear estos objetos en una cuenta que no sea la cuenta principal y, a continuación, crear un activador en la cuenta de usuario principal.

nota

Si establece el atributo de conexión adicional captureDDLs en N en el punto de enlace de origen, no tiene que crear la siguiente tabla en la base de datos de origen.

Utilice el siguiente procedimiento para crear estos objetos.

Para crear objetos

  1. Elija el esquema donde deben crearse los objetos. El esquema predeterminado es public. Asegúrese de que el esquema exista y que la cuenta NoPriv pueda obtener acceso a él.

  2. Inicie sesión en la instancia de base de datos de PostgreSQL con la cuenta de usuario que no sea la cuenta maestra; en este caso, laNoPriv cuenta.

  3. Cree la tablaawsdms_ddl_audit ejecutando el siguiente comando y sustituyendoobjects_schema el código siguiente por el nombre del esquema que se va a utilizar.

    
create table objects_schema.awsdms_ddl_audit
(
  c_key    bigserial primary key,
  c_time   timestamp,    -- Informational
  c_user   varchar(64),  -- Informational: current_user
  c_txn    varchar(16),  -- Informational: current transaction
  c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
  c_oid    integer,      -- For future use - TG_OBJECTID
  c_name   varchar(64),  -- For future use - TG_OBJECTNAME
  c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
  c_ddlqry  text         -- The DDL query associated with the current DDL event
)

  4. Cree la función awsdms_intercept_ddl. Para ello, ejecute el siguiente comando y sustituya objects_schema en el código siguiente por el nombre del esquema que se va a utilizar.

    
CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
  RETURNS event_trigger
LANGUAGE plpgsql
SECURITY DEFINER
  AS $$
  declare _qry text;
BEGIN
  if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE') then
         SELECT current_query() into _qry;
         insert into objects_schema.awsdms_ddl_audit
         values
         (
         default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
         );
         delete from objects_schema.awsdms_ddl_audit;
end if;
END;
$$;

  5. Cierre sesión en la cuenta NoPriv e inicie sesión con una cuenta que tenga el rol rds_superuser asignado.

  6. Cree el activador de eventos awsdms_intercept_ddl; para ello, ejecute el siguiente comando.

    
CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();

Cuando haya completado el procedimiento anterior, puede crear el punto de enlace de origen de AWS DMS utilizando la cuenta NoPriv.

nota

Estos eventos se desencadenan medianteCREATE TABLEALTER TABLE, yDROP TABLE declaraciones.

Asegúrese de que todos los usuarios y roles que accedan a estos eventos tengan los permisos de DDL necesarios. Por ejemplo:

grant all on public.awsdms_ddl_audit to public;
grant all on public.awsdms_ddl_audit_c_key_seq to public;

Habilitar la captura de datos de cambio (CDC) mediante replicación lógica

Puede utilizar la función de replicación lógica nativa de PostgreSQL para habilitar la captura de datos de cambios (CDC) durante la migración de bases de datos para fuentes de PostgreSQL. Puede utilizar esta función con una instancia de base de datos SQL de PostgreSQL autogestionada y también con una instancia de base de datos SQL de Amazon RDS for PostgreSQL. Este enfoque reduce el tiempo de inactividad y ayuda a garantizar que la base de datos de destino esté sincronizada con la base de datos de PostgreSQL de origen.

AWS DMSadmite CDC para tablas de PostgreSQL con claves principales. Si una tabla no tiene una clave principal, los registros de escritura anticipada (WAL) no incluyen la imagen anterior de la fila de la base de datos. En este caso, el DMS no puede actualizar la tabla. Aquí puede utilizar ajustes de configuración adicionales y utilizar la identidad de réplica de la tabla como solución alternativa. Sin embargo, este enfoque puede generar registros adicionales. Le recomendamos que utilice la identidad de réplica de tablas como solución alternativa solo después de realizar pruebas exhaustivas. Para obtener más información, consulte Ajustes de configuración adicionales cuando se utiliza una base de datos de PostgreSQL como fuente de DMS.

nota

REPLICA IDENTITY FULL es compatible con un complemento de decodificación lógica, pero no con un complemento pglogical. Para obtener más información, consulte la documentación pglogical documentación pglogical.

Para tareas de carga completa y exclusivas de CDC y CDC,AWS DMS utiliza ranuras de replicación lógica para conservar los registros de WAL con fines de replicación hasta que se decodifiquen los registros. Al reiniciar (no reanudar) una carga completa y una tarea de CDC o una tarea de CDC, se vuelve a crear la ranura de replicación.

nota

Para la decodificación lógica, DMS utiliza el complemento test_decoding o pglogical. Si el complemento pglogical está disponible en una base de datos PostgreSQL de origen, DMS crea una ranura de replicación mediante pglogical; de lo contrario, se utiliza el complemento test_decoding. Para obtener más información acerca del complemento test_decoding, consulte la documentación de PostgreSQL.

Si el parámetro de la base de datosmax_slot_wal_keep_size se establece en un valor no predeterminado y elrestart_lsn de una ranura de replicación supera en más de este tamaño al LSN actual, la tarea de DMS fallará debido a la eliminación de los archivos WAL necesarios.

Configuración del complemento pglogical

Implementado como una extensión de PostgreSQL, el complemento pglogical es un sistema de replicación lógica y un modelo para la replicación selectiva de datos. La siguiente tabla identifica las versiones de la base de datos PostgreSQL de origen que admiten el complemento pglogical.

Fuente de PostgreSQL

Apoyos filosóficos

PostgreSQL 9.4 o superior autogestionado

Sí

Amazon RDS PostgreSQL 9.5 o versiones anteriores

No

Amazon RDS PostgreSQL 9.6 o versiones posteriores

Sí

Aurora PostgreSQL 1.x a 2.5.x

No

Aurora PostgreSQL 2.6.x o superior

Sí

Aurora PostgreSQL 3.3.x o superior

Sí

Antes de configurar pglogical para su uso conAWS DMS, habilite primero la replicación lógica para la captura de datos de cambio (CDC) en su base de datos de origen de PostgreSQL.

Una vez habilitada la replicación lógica en la base de datos fuente de PostgreSQL, siga los siguientes pasos para configurar pglogical para su uso con DMS.

Para utilizar el complemento pglogical para la replicación lógica en una base de datos fuente de PostgreSQL conAWS DMS

  1. Cree una extensión pglogica en su base de datos PostgreSQL de origen:

    1. Establezca el parámetro correcto:

      • Para las bases de datos PostgreSQL autogestionadas, defina el parámetro de base de datosshared_preload_libraries= 'pglogical'.

      • Para PostgreSQL en las bases de datos de Amazon RDS y Amazon Aurora PostgreSQL,shared_preload_libraries defina el parámetropglogical en el mismo grupo de parámetros de RDS.

    2. Reinicie la base de datos de origen de PostgreSQL.

    3. En la base de datos de PostgreSQL, ejecute el comandocreate extension pglogical;

  2. Ejecute el siguiente comando para comprobar que pglogical se ha instalado correctamente:

    select * FROM pg_catalog.pg_extension

Ahora puede crear unaAWS DMS tarea que realice la captura de datos de cambios para el extremo de la base de datos fuente de PostgreSQL.

nota

Si no habilitas pglogical en tu base de datos fuente de PostgreSQL,AWS DMS usa eltest_decoding complemento de forma predeterminada. Cuando pglogical está habilitado para la decodificación lógica,AWS DMS usa pglogical de forma predeterminada. Pero puede configurar el atributo de conexión adicionalPluginName para usar eltest_decoding complemento en su lugar.

Uso de puntos de inicio de CDC nativos para configurar una carga de CDC de una fuente de PostgreSQL

Para habilitar los puntos de inicio de CDC nativos con PostgreSQL como fuente, defina el atributo de conexiónslotName adicional en el nombre de una ranura de replicación lógica existente al crear el punto final. Esta ranura de replicación lógica guarda los cambios continuos desde el momento en que se creó el punto de enlace, por lo que permite replicar desde un punto anterior.

PostgreSQL escribe los cambios de la base de datos en archivos WAL que solamente se descartan cuando AWS DMS lee correctamente los cambios de la ranura de replicación lógica. El uso de ranuras de replicación lógica puede evitar que los cambios registrados se eliminen antes de que el motor de replicación los consuma.

Sin embargo, en función de la tasa de cambio y consumo, los cambios que contiene una ranura de replicación lógica pueden provocar un uso elevado del disco. Se recomienda configurar alarmas de uso del espacio en la instancia de PostgreSQL de origen cuando utilice ranuras de replicación lógica. Para obtener más información acerca de cómo establecer el atributo slotName de conexión adicional, consulte Configuración de endpoint cuando se utiliza PostgreSQL como fuente de DMS.

En el siguiente procedimiento, se explica este enfoque paso a paso con más detalle.

Para utilizar un punto de inicio de CDC nativo con el fin de configurar una carga de CDC de un punto de enlace de origen de PostgreSQL

  1. Identifique una ranura de replicación lógica que se haya empleado en una tarea de replicación anterior (una tarea principal) para utilizarla como punto de inicio. A continuación, consulte la vista pg_replication_slots de la base de datos de origen para asegurarse de que esta ranura no tiene ninguna conexión activa. Si es así, resuélvalas y ciérrelas antes de continuar.

    En los siguientes pasos, vamos a suponer que la ranura de replicación lógica es abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef.

  2. Cree un nuevo punto de enlace de origen que incluya la siguiente configuración adicional de atributos de conexión:

    slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;

  3. Cree una nueva tarea exclusiva de los CDC mediante laAWS DMS APIAWS CLI or. Por ejemplo, con la CLI podría ejecutar el siguientecreate-replication-task comando.

    Actualmente, AWS DMS no permite crear una tarea de CDC con un punto de inicio nativo a través de la consola.

    aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test 
--source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 
--target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 
--replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE 
--migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" 
--replication-task-settings "file://task-pg.json"

    En el comando anterior, se establecen las siguientes opciones:

    • Lasource-endpoint-arn opción se establece en el nuevo valor que creó en el paso 2.

    • Lareplication-instance-arn opción se establece en el mismo valor que para la tarea principal del paso 1.

    • Lasreplication-task-settings opcionestable-mappings y se configuran en los mismos valores que para la tarea principal del paso 1.

    • Lacdc-start-position opción se establece en un valor de posición inicial. Para encontrar esta posición inicial, consulte la vista pg_replication_slots de la base de datos de origen o vea los detalles de la consola de la tarea principal en el paso 1. Para obtener más información, consulte Determinar un punto de inicio de CDC nativo.

    Cuando se ejecuta esta tarea de CDC, seAWS DMS genera un error si la ranura de replicación lógica especificada no existe. También genera un error si la tarea no se crea con una configuración válida paracdc-start-position.

Si utiliza puntos de inicio de CDC nativos con el complemento pglogical y desea utilizar una nueva ranura de replicación, complete los pasos de configuración que se indican a continuación antes de crear una tarea de CDC.

Para utilizar una nueva ranura de replicación que no se haya creado anteriormente como parte de otra tarea de DMS

  1. Cree una ranura de replicación, como se muestra a continuación:

    SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');

  2. Una vez que la base de datos haya creado la ranura de replicación, obtenga y anote los valores restart_lsn y confirmed_flush_lsn de la ranura:

    select * from pg_replication_slots where slot_name like 'replication_slot_name';

    Tenga en cuenta que la posición inicial nativa de los CDC para una tarea de CDC creada después del intervalo de replicación no puede ser anterior al valor confirmed_flush_lsn.

    Para obtener información sobre los valores restart_lsn y confirmed_flush_lsn, consulte pg_replication_slots

  3. Cree un nodo pglogical.

    SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');

  4. Cree dos conjuntos de replicación mediante lapglogical.create_replication_set función. El primer conjunto de replicación realiza un seguimiento de las actualizaciones y eliminaciones de las tablas que tienen claves principales. El segundo conjunto de replicación solo rastrea las inserciones y tiene el mismo nombre que el primer conjunto de replicación, con el prefijo «i» agregado.

    SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false);
SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true);

  5. Agregue una tabla al conjunto de replicación.

    SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true);
SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true);

  6. Defina el atributo de conexión adicional (ECA) a continuación al crear su punto de enlace de origen.

    PluginName=PGLOGICAL;slotName=slot_name;

Ahora puede crear una tarea exclusiva de CDC con un punto de inicio nativo de PostgreSQL utilizando la nueva ranura de replicación. Para obtener más información acerca del complemento pglogical, consulte la documentación de pglogical 3.7

Migración de PostgreSQL a PostgreSQL con AWS DMS

Cuando se migra de un motor de base de datos que no sea PostgreSQL a una base de datos de PostgreSQL, casi siempreAWS DMS es la mejor herramienta de migración que se puede utilizar. Sin embargo, cuando se migra de una base de datos de PostgreSQL a una base de datos de PostgreSQL, las herramientas de PostgreSQL pueden ser más eficaces.

Uso de herramientas nativas de PostgreSQL para migrar datos

Es recomendable usar las herramientas de migración de bases de datos de PostgreSQL, por ejemplo, sipg_dump se dan las condiciones siguientes:

  • Se trata de una migración homogénea, en la que se migra desde una base de datos de PostgreSQL de origen a una base de datos de PostgreSQL de destino.

  • Se va a migrar una base de datos completa.

  • Las herramientas nativas le permiten migrar sus datos con un tiempo de inactividad mínimo.

La utilidad pg_dump usa el comando COPY para crear un esquema y un volcado de datos de una base de datos de PostgreSQL. El script de volcado generado por pg_dump carga los datos en una base de datos con el mismo nombre y vuelve a crear las tablas, los índices y las claves externas. Para restaurar los datos en una base de datos con un nombre diferente, utilice elpg_restore comando y el-d parámetro.

Si está migrando datos de una base de datos fuente de PostgreSQL que se ejecuta en EC2 a un destino de Amazon RDS for PostgreSQL, puede utilizar el complemento pglogical.

Para obtener más información acerca de cómo importar una base de datos de PostgreSQL Amazon Aurora la Edición compatible Edition, consultehttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html.

Uso de DMS para migrar datos de PostgreSQL a PostgreSQL

AWS DMSpuede migrar datos, por ejemplo, de una base de datos de PostgreSQL de origen que se encuentra en las instalaciones a una instancia de Amazon RDS for PostgreSQL o Aurora PostgreSQL de destino. Los tipos de datos de PostgreSQL básicos se migran normalmente sin problemas.

nota

Al replicar tablas particionadas de una fuente de PostgreSQL a un destino de PostgreSQL, no es necesario mencionar la tabla principal como parte de los criterios de selección de la tarea de DMS. Al mencionar la tabla principal, los datos se duplican en las tablas secundarias del destino, lo que podría provocar una infracción de PK. Al seleccionar solo las tablas secundarias en los criterios de selección del mapeo de tablas, la tabla principal se rellena automáticamente.

Sin embargo, es posible que aquellos tipos de datos que se admitan en la base de datos de origen, pero no en el destino, no se migren correctamente. AWS DMS transmite en streaming algunos tipos de datos como cadenas si el tipo de datos es desconocido. Algunos tipos de datos, como XML y JSON, se pueden migrar correctamente como archivos pequeños, pero se puede producir un error si los documentos son grandes.

Cuando se realiza la migración de tipos de datos, tenga en cuenta lo siguiente:

  • En algunos casos, el tipo de datos NUMÉRICOS (p, s) de PostgreSQL no especifica ninguna precisión ni escala. Para las versiones 3.4.2 y anteriores del DMS, el DMS utiliza una precisión de 28 y una escala de 6 de forma predeterminada, NUMÉRICA (28,6). Por ejemplo, el valor 0.611111104488373 del origen se convierte a 0.611111 en el destino de PostgreSQL.

  • Una tabla con un tipo de datos ARRAY debe contar con una clave principal. Una tabla con un tipo de datos ARRAY a la que le falta una clave principal se suspende durante la carga completa.

En la siguiente tabla se muestran los tipos de datos de PostgreSQL de origen y se indica si pueden migrarse correctamente:

Tipo de datos Se migra correctamente Se migra parcialmente No se migra Comentarios
INTEGER X
SMALLINT X
BIGINT X
NUMERIC/DECIMAL(p,s) X Donde 0<p<39 y 0<s
NUMERIC/DECIMAL X Donde p>38 o p=s=0
REAL X
DOUBLE X
SMALLSERIAL X
SERIAL X
BIGSERIAL X
MONEY X
CHAR X Sin precisión especificada
CHAR(n) X
VARCHAR X Sin precisión especificada
VARCHAR (n) X
TEXT X
BYTEA X
TIMESTAMP X Los valores infinitos positivos y negativos se truncan a «9999-12-31 23:59:59» y «4713-01-01 00:00:00 BC», respectivamente.
TIMESTAMP(Z) X
DATE X
TIME X
TIME (z) X
INTERVAL X
BOOLEANO X
ENUM X
CIDR X
INET X
MACADDR X
TSVECTOR X
TSQUERY X
XML X
POINT X Tipo de datos espaciales PostGIS
LINE X
LSEG X
BOX X
PATH X
POLYGON X Tipo de datos espaciales PostGIS
CIRCLE X
JSON X
ARRAY X Requiere clave principal
COMPOSITE X
RANGE X
LINESTRING X Tipo de datos espaciales PostGIS
MULTIPOINT X Tipo de datos espaciales PostGIS
MULTILINESTRING X Tipo de datos espaciales PostGIS
MULTIPOLYGON X Tipo de datos espaciales PostGIS
GEOMETRYCOLLECTION X Tipo de datos espaciales PostGIS

Migración de tipos de datos espaciales PostGIS

Los datos espaciales identifican la información de geometría de un objeto o ubicación en el espacio. Las bases de datos relacionales de objetos de PostgreSQL admiten los tipos de datos espaciales PostGIS.

Antes de migrar objetos de datos espaciales de PostgreSQL, asegúrese de que el complemento de PostGIS esté habilitado a nivel global. Esto garantiza que se creen lasAWS DMS columnas de datos espaciales de origen exactas para la instancia de base de datos de destino de PostgreSQL.

Para las migraciones homogéneas de PostgreSQL a PostgreSQL, AWS DMS admite la migración de tipos y subtipos de objetos de datos geométricos y geográficos (coordenadas geodésicas) de PostGIS, como los siguientes:

  • POINT

  • LINESTRING

  • POLYGON

  • MULTIPOINT

  • MULTILINESTRING

  • MULTIPOLYGON

  • GEOMETRYCOLLECTION

Quitar artefactos de AWS DMS de una base de datos de origen de PostgreSQL

Para capturar eventos DDL, AWS DMS crea varios artefactos en la base de datos de PostgreSQL cuando comienza una tarea de migración. Cuando se complete la tarea, es posible que quiera eliminar estos artefactos.

Para eliminar los artefactos, emita las siguientes instrucciones (en el orden en que aparecen), donde{AmazonRDSMigration} se muestra el esquema en el que se crearon los artefactos. Eliminar un esquema debe hacerse con extrema precaución. No ingrese nunca un esquema operativo, especialmente si es público.

drop event trigger awsdms_intercept_ddl;

El disparador de eventos no pertenece a un esquema específico.

drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}

Ajustes de configuración adicionales cuando se utiliza una base de datos de PostgreSQL como fuente de DMS

Puede añadir parámetros de configuración adicionales cuando migre datos desde una base de datos de PostgreSQL de dos maneras:

  • Puede añadir valores al atributo extra connection para capturar eventos DDL y especificar el esquema en el que se crean los artefactos de la base de datos DDL. Para obtener más información, consulte Configuración de endpoint cuando se utiliza PostgreSQL como fuente de DMS.

  • Puede anular parámetros de cadenas de conexión. Elija esta opción para realizar una de estas dos operaciones:

    • Especifique parámetros de AWS DMS internos. Estos parámetros rara vez se requieren, por lo que no se exponen en la interfaz de usuario.

    • Especificar los valores de paso (passthru) para el cliente de base de datos específico. AWS DMS contiene parámetros de paso a través en la cadena de conexión que se pasa al cliente de base de datos.

  • Al utilizar el parámetro de nivel de tablaREPLICATE IDENTITY de las versiones 9.4 y posteriores de PostgreSQL, puede controlar la información escrita en los registros de escritura anticipada (WALL). En particular, lo hace para las WALL que identifican las filas que se actualizan o eliminan. REPLICATE IDENTITY FULLregistra los valores antiguos de todas las columnas de la fila. REPLICATE IDENTITY FULLÚselo con cuidado para cada tabla, ya queFULL genera una cantidad adicional de WALL que podrían no ser necesarias. Para obtener más información, consulte ALTER TABLE-REPLICA IDENTITY.

Uso de la configuración de punto final de MapBooleanAsBoolean PostgreSQL

Puede usar la configuración de endpoint de PostgreSQL para asignar un booleano como un booleano desde su fuente de PostgreSQL a un destino de Amazon Redshift. De forma predeterminada, un tipo BOOLEANO se migra como varchar (5). Puede especificarMapBooleanAsBoolean que PostgreSQL migre el tipo booleano como booleano, como se muestra en el siguiente ejemplo.

--postgre-sql-settings '{"MapBooleanAsBoolean": true}'

Configuración de endpoint cuando se utiliza PostgreSQL como fuente de DMS

Puede usar la configuración de endpoint para configurar la base de datos fuente de PostgreSQL de forma similar a usar atributos de conexión adicionales. La configuración se especifica al crear el extremo de origen mediante laAWS DMS consola o mediante elcreate-endpoint comando de AWS CLI, con la sintaxis--postgre-sql-settings '{"EndpointSetting": "value", ...}' JSON.

La siguiente tabla muestra la configuración de punto final que puede usar con PostgreSQL como fuente.

Nombre de atributo Descripción

CaptureDDLs

Para capturar eventos DDL, AWS DMS crea varios artefactos en la base de datos de PostgreSQL al iniciar la tarea. Más adelante podrá quitar estos artefactos según se describe en Quitar artefactos de AWS DMS de una base de datos de origen de PostgreSQL.

Si este valor se ha establecido en N, no es necesario crear tablas ni disparadores en la base de datos de origen.

Se capturan los eventos DDL transmitidos.

Valor predeterminado: Y

Valores válidos: Y/N

Ejemplo: --postgre-sql-settings '{"CaptureDDLs": Y}'

DdlArtifactsSchema

Establece el esquema en el que se crearon los artefactos de la base de datos DDL operativa.

Valor predeterminado: público

Valores válidos: String

Ejemplo: --postgre-sql-settings '{"DdlArtifactsSchema": "xyzddlschema"}'

FailTasksOnLobTruncation

Cuando se establece en true, este valor provoca un error en una tarea si el tamaño real de una columna de LOB es mayor que el LobMaxSize especificado.

Si una tarea está establecida en el modo LOB limitado y esta opción está establecida en true, la tarea genera un error en vez de truncar los datos de LOB.

Valor predeterminado: false

Valores válidos: booleano

Ejemplo: --postgre-sql-settings '{"FailTasksOnLobTruncation": true}'

ExecuteTimeout

Establece el tiempo de espera de las instrucciones del cliente para la instancia de PostgreSQL, en segundos. El valor de predeterminado es de 60 segundos.

Ejemplo: --postgre-sql-settings '{"ExecuteTimeout": 100}'

PluginName

Especifica el complemento que se va a utilizar para crear una ranura de replicación.

Valores válidos: pglogical, test_decoding

Ejemplo: --postgre-sql-settings '{"PluginName": "test_decoding"}'

SlotName

Establece el nombre de una ranura de replicación lógica creada anteriormente para una carga de CDC de la instancia de origen de PostgreSQL.

Cuando se utiliza con el parámetro de solicitud CdcStartPosition de la API de AWS DMS, este atributo también permite usar puntos de inicio de CDC nativos. DMS comprueba que existe la ranura de replicación lógica especificada antes de iniciar la tarea de carga de CDC. También verifica que la tarea se creó con una configuración de CdcStartPosition válida. Si la ranura especificada no existe o la tarea no tiene una configuración de CdcStartPosition válida, DMS genera un error.

Para obtener más información sobre la configuración del parámetro de solicitud CdcStartPosition, consulte Determinar un punto de inicio de CDC nativo. Para obtener más información sobre el usoCdcStartPosition, consulte la documentación de las operaciones de laModifyReplicationTask APICreateReplicationTaskStartReplicationTask, y en la referencia de laAWS Database Migration Service API.

Valores válidos: String

Ejemplo: --postgre-sql-settings '{"SlotName": "abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef"}'

HeartbeatEnable

La función WAL Heartbeat imita una transacción ficticia, de modo que las ranuras de replicación lógica inactivas no se mantengan en el origen. Este latido mantiene en movimiento a restart_lsn y evita que el almacenamiento se llene.

Valor predeterminado: false

Valores válidos: true/false

Ejemplo: --postgre-sql-settings '{"HeartbeatEnable": true}'

HeartbeatFrequency

Establece la frecuencia del latido de WAL (en minutos).

Valor predeterminado: 5

Valores válidos: Number

Ejemplo: --postgre-sql-settings '{"HeartbeatFrequency": 1}'

HeartbeatSchema

Establece el esquema en el que se crearon los artefactos de latido.

Valor predeterminado: public

Valores válidos: String

Ejemplo: --postgre-sql-settings '{"HeartbeatSchema": "xyzheartbeatschema"}'

ConsumeMonotonicEvents

Se usa para controlar cómo se replican las transacciones monolíticas con números de secuencia de registro (LSN) duplicados. Cuando este parámetro esfalse, los eventos con LSN duplicados se consumen y se replican en el destino. Cuando este parámetro estrue, solo se replica el primer evento, mientras que los eventos con LSN duplicados no se consumen ni se replican en el destino.

Valor predeterminado: false

Valores válidos: falso/verdadero

Ejemplo: --postgre-sql-settings '{"ConsumeMonotonicEvents": true}'

MapUnboundedNumericAsString

Este parámetro trata las columnas con tipos de datos NUMÉRICOS ilimitados como STRING para poder migrar correctamente sin perder la precisión del valor numérico. Utilice este parámetro solo para la replicación desde el origen de PostgreSQL al destino de PostgreSQL o para bases de datos compatibles con PostgreSQL.

Valor predeterminado: false

Valores válidos: false/true

Ejemplo: --postgre-sql-settings '{"MapUnboundedNumericAsString": true}'

El uso de este parámetro puede provocar cierta degradación del rendimiento de la replicación debido a la transformación de numérico a cadena y de nuevo a numérico. La versión 3.4.4 y superior de DMS admite el uso de este parámetro

nota

Úselo soloMapUnboundedNumericAsString en los extremos de origen y destino de PostgreSQL juntos.

MapUnboundedNumericAsStringEl uso de puntos de conexión de PostgreSQL en el código fuente restringe la precisión a 28 durante la CDC. El uso de puntos finalesMapUnboundedNumericAsString en los puntos finales de destino migra los datos con Precision 28 Scale 6.

No lo utiliceMapUnboundedNumericAsString con objetivos que no sean de PostgreSQL.

fetchCacheSize

Este atributo de conexión adicional (ECA) establece el número de filas que obtendrá el cursor durante la operación de carga completa. En función de los recursos disponibles en la instancia de replicación, puede ajustar el valor hacia arriba o hacia abajo.

Valor predeterminado: 10000

Valores válidos: Number

Ejemplo de ECA:fetchCacheSize=10000;

Limitaciones del uso de una base de datos PostgreSQL como fuente de DMS

Al utilizar PostgreSQL como origen para AWS DMS se aplican las siguientes restricciones:

  • AWS DMSno funciona con Amazon RDS for PostgreSQL 10.4 ni Amazon Aurora PostgreSQL 10.4 ni como origen ni como destino.

  • Las tablas de captura deben contar con una clave principal. Si una tabla no dispone de clave principal, AWS DMS omite las operaciones de registro DELETE y UPDATE para dicha tabla. Como solución alternativa, consulte Habilitar la captura de datos de cambios (CDC) mediante la replicación lógica.

    Nota: No recomendamos migrar sin una clave principal o un índice único; de lo contrario, se aplicarán limitaciones adicionales, como la capacidad de aplicación Batch «NO», la capacidad de LOB completa, la validación de datos y la incapacidad de replicar al objetivo de Redshift de manera eficiente.

  • AWS DMS omite un intento de actualizar un segmento de clave principal. En estos casos, el destino identifica la actualización como una que no ha actualizado ninguna fila. Sin embargo, dado que los resultados de actualizar una clave primaria en PostgreSQL son imprevisibles, no se escriben registros en la tabla de excepciones.

  • AWS DMS no admite la opción de ejecución Start Process Changes from Timestamp (Iniciar procesamiento de cambios a partir de una hora de inicio).

  • AWS DMSno replica los cambios que resultan de las operaciones de partición o subpartición (ADDDROP, oTRUNCATE).

  • La replicación de varias tablas que tengan el mismo nombre donde cada nombre está escrito con un uso de las mayúsculas y minúsculas diferente (por ejemplo, tabla1, TABLA1 y Tabla1) puede provocar un comportamiento imprevisible. Debido a este problema, AWS DMS no admite este tipo de replicación.

  • En la mayoría de los casos AWS DMS admite cambiar el procesamiento de las instrucciones DDL de CREATE, ALTER y DROP para las tablas. AWS DMS no admite este cambio si las tablas se conserven en un bloque de contenido de una función o procedimiento internos o en otros constructos anidados.

    Por ejemplo, no se captura el siguiente cambio.

    CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
create table attu.distributors1(did serial PRIMARY KEY,name
varchar(40) NOT NULL);
END;
$$;

  • Actualmente,boolean los tipos de datos de una fuente de PostgreSQL se migran a un destino de SQL Server como tipos debit datos con valores inconsistentes. Como solución alternativa, cree previamente la tabla con un tipo deVARCHAR(1) datos para la columna (o pida aAWS DMS que cree la tabla). A continuación, haga que el procesamiento descendente trate la "F" como falso y la "T" como verdadero.

  • AWS DMS no admite cambiar el procesamiento de las operaciones TRUNCATE.

  • El tipo de datos de LOB OID no se migra al destino.

  • AWS DMSadmite el tipo de datos PostGIS solo para migraciones homogéneas.

  • Si su fuente es una base de datos de PostgreSQL local o en una instancia de Amazon EC2, asegúrese de que el complemento de salida test_decoding esté instalado en el extremo de origen. Puede encontrar este complemento en el paquete de contrib de PostgreSQL. Para obtener más información acerca del complemento test-decoding consulte la documentación de PostgreSQL.

  • AWS DMS no admite cambiar el procesamiento para establecer o anular valores predeterminados de columnas (con la cláusula ALTER COLUMN SET DEFAULT en instrucciones ALTER TABLE).

  • AWS DMS no admite cambiar el procesamiento para establecer la nulabilidad de columnas (con la cláusula ALTER COLUMN [SET|DROP] NOT NULL en instrucciones ALTER TABLE).

  • Cuando la replicación lógica está habilitada, la cantidad máxima de cambios guardados en la memoria por transacción es de 4 MB. Después de eso, los cambios se transfieren al disco. Como resultado,ReplicationSlotDiskUsage aumenta yrestart_lsn no avanza hasta que la transacción se complete o se detenga y finalice la reversión. Dado que se trata de una transacción larga, puede tardar mucho tiempo en revisarse. Por lo tanto, evite las transacciones de larga ejecución cuando la replicación lógica esté habilitada. En su lugar, divide la transacción en varias transacciones más pequeñas.

  • Una tabla con un tipo de datos ARRAY debe contar con una clave principal. Una tabla con un tipo de datos ARRAY a la que le falta una clave principal se suspende durante la carga completa.

  • AWS DMS no admite la replicación de las tablas con particiones. Cuando se detecta una tabla con particiones, sucede lo siguiente:

    • El punto de enlace notifica una lista de las tablas principales y secundarias.

    • AWS DMS crea la tabla en el destino como una tabla normal con las mismas propiedades que las tablas seleccionadas.

    • Si la tabla principal en la base de datos de origen tiene el mismo valor de clave principal que las tablas secundarias, se genera un error de "clave duplicada".

  • Para replicar tablas particionadas de una fuente de PostgreSQL a un destino de PostgreSQL, primero cree manualmente las tablas principal y secundaria en el destino. A continuación, defina una tarea independiente para replicarla en esas tablas. En tal caso, defina la configuración de la tarea en Truncar antes de cargarla.

  • El tipo de datos NUMERIC de PostgreSQL no tiene un tamaño fijo. Cuando se transfieren datos que tienen el tipo de datos NUMERIC pero sin precisión ni escala, DMS utiliza NUMERIC(28,6) (con una precisión de 28 y una escala de 6) de forma predeterminada. Por ejemplo, el valor 0,611111104488373 del origen se convierte a 0,611111 en el destino de PostgreSQL.

  • AWS DMSadmite Aurora PostgreSQL Serverless V1 como fuente únicamente para tareas de carga completa. AWS DMSadmite Aurora PostgreSQL Serverless V2 como fuente para tareas de carga completa, carga completa y CDC y solo de CDC.

  • AWS DMSno admite la replicación de una tabla con un índice único creado con una función de fusión.

  • Cuando se utiliza el modo LOB, tanto la tabla de origen como la tabla de destino correspondiente deben tener una clave principal idéntica. Si una de las tablas no tiene una clave principal, el resultado de las operaciones de eliminación y actualización de registros será impredecible.

  • Cuando se utiliza la función Carga en paralelo, no se admite la segmentación de tablas según particiones o subparticiones. Para obtener más información acerca de Parallel Load, consulte.Uso de la carga parallel para las tablas, vistas y colecciones seleccionadas

  • AWS DMSno admite restricciones diferidas.

  • AWS DMSla versión 3.4.7 admite PostgreSQL 14.x como fuente con las siguientes limitaciones:

    • AWS DMSno admite el procesamiento de cambios de las confirmaciones en dos fases.

    • AWS DMSno admite la replicación lógica para transmitir transacciones en curso de larga duración.

  • AWS DMSno admite CDC para Amazon RDS Proxy para PostgreSQL como fuente.

  • Al utilizar filtros de origen que no contengan una columna de clave principal, no se capturaránDELETE las operaciones.

  • Si la base de datos de origen también es el destino de otro sistema de replicación de terceros, es posible que los cambios de DDL no se migren durante la CDC. Porque esa situación puede impedir que se active el desencadenador delawsdms_intercept_ddl evento. Para evitar esta situación, modifique ese disparador en la base de datos de origen de la siguiente manera:

    alter event trigger awsdms_intercept_ddl enable always;

Tipos de datos de origen para PostgreSQL

En la siguiente tabla se muestran los tipos de datos de origen de PostgreSQL compatibles cuando se utiliza AWS DMS y el mapeo predeterminado de los tipos de datos de AWS DMS.

Para obtener más información sobre cómo ver el tipo de datos que se asigna en el destino, consulte la sección del punto de enlace de destino que esté utilizando.

Para obtener más información sobre los tipos de datos de AWS DMS, consulte Tipos de datos para elAWS Database Migration Service.

Tipos de datos de PostgreSQL

Tipos de datos de DMS

INTEGER

INT4

SMALLINT

INT2

BIGINT

INT8

NUMERIC (p,s)

Si la precisión es de 0 a 38, utilice NUMERIC.

Si la precisión es 39 o superior, utilice STRING.

DECIMAL(P,S)

Si la precisión es de 0 a 38, utilice NUMERIC.

Si la precisión es 39 o superior, utilice STRING.

REAL

REAL4

DOUBLE

REAL8

SMALLSERIAL

INT2

SERIAL

INT4

BIGSERIAL

INT8

MONEY

NUMERIC(38,4)

El tipo de datos MONEY se asigna a FLOAT en SQL Server.

CHAR

WSTRING (1)

CHAR(N)

WSTRING (n)

VARCHAR(N)

WSTRING (n)

TEXT

NCLOB

BYTEA

BLOB

TIMESTAMP

DATETIME

TIMESTAMP (z)

DATETIME

TIMESTAMP WITH TIME ZONE

DATETIME

DATE

DATE

TIME

TIME

TIME (z)

TIME

INTERVAL

STRING (128) —1 AÑO, 2 MESES, 3 DÍAS, 4 HORAS, 5 MINUTOS, 6 SEGUNDOS

BOOLEANO

CHAR (5) false o true

ENUM

STRING (64)

CIDR

STRING (50)

INET

STRING (50)

MACADDR

STRING (18)

BIT (n)

STRING (n)

BIT VARYING (n)

STRING (n)

UUID (Identificador único universal)

STRING

TSVECTOR

CLOB

TSQUERY

CLOB

XML

CLOB

POINT

STRING (255) "(x,y)"

LINE

STRING (255) "(x,y,z)"

LSEG

STRING (255) "((x1,y1),(x2,y2))"

BOX

STRING (255) "((x1,y1),(x2,y2))"

PATH

CLOB "((x1,y1),(xn,yn))"

POLYGON

CLOB "((x1,y1),(xn,yn))"

CIRCLE

STRING (255) "(x,y),r"

JSON

NCLOB

JSONB

NCLOB

ARRAY

NCLOB

COMPOSITE

NCLOB

HSTORE

NCLOB

INT4RANGE

STRING (255)

INT8RANGE

STRING (255)

NUMRANGE

STRING (255)

STRRANGE

STRING (255)

Trabajando con tipos de datos fuente LOB para PostgreSQL

Los tamaños de columna de PostgreSQL afectan a la conversión de tipos de datos LOB de PostgreSQL a tipos de datos de AWS DMS. Para trabajar con esto, siga los pasos que se indican a continuación para los tipos de AWS DMS datos siguientes:

  • BLOB: establece el tamaño límite del LOB en el valor del tamaño de LOB máximo (KB) al crear la tarea.

  • CLOB: la replicación trata cada carácter como un carácter UTF8. Por lo tanto, busque la longitud del texto de caracteres más largo de la columna, que se muestra aquí comomax_num_chars_text. Utilice esta longitud para especificar el valor de Limitar el tamaño del LOB a. Si los datos incluyen caracteres de 4 bytes, multiplique por 2 para especificar el valor Limit LOB size to (Limitar tamaño de LOB a), que está en bytes. En este caso, Limit LOB size to (Limitar tamaño de LOB a) es igual a max_num_chars_text multiplicado por 2.

  • NCLOB: la replicación trata cada carácter como un carácter de doble byte. Por lo tanto, busque la longitud del texto de caracteres más largo de la columna (max_num_chars_text) y multiplíquelo por 2. Esto se hace para especificar el valor de Limitar el tamaño del LOB a. En este caso, Limit LOB size to (Limitar tamaño de LOB a) es igual a max_num_chars_text multiplicado por 2. Si los datos incluyen caracteres de 4 bytes, multiplíquelos por 2 de nuevo. En este caso, Limit LOB size to (Limitar tamaño de LOB a) es igual a max_num_chars_text multiplicado por 4.