Uso de una SQL base de datos Postgre como fuente AWS DMS - AWS Database Migration Service
Trabajar con bases de datos Postgre autogestionadas SQLTrabajar con bases de datos Postgre administradas AWS por usted SQLUso de la replicación lógica para habilitarla CDC durante la migraciónUso de puntos de CDC inicio nativos para configurar una carga CDCMigraciones SQL de Postgre SQL a PostgreMigración desde BabelfishEliminar artefactos de una fuente de Postgre SQLParámetros de configuración avanzados para Postgre SQL como fuenteUso de la configuración de punto final de MapBooleanAsBoolean Postgre SQLPunto final y configuración ECALimitaciones de Postgre SQL como fuenteTipos de datos de origen para Postgre SQL

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 SQL base de datos Postgre como fuente AWS DMS

Puede migrar datos de una o varias bases de datos de SQL Postgre utilizando. AWS DMS Con una SQL base de datos de Postgre como fuente, puede migrar los datos a otra base de datos de Postgre o a una de las otras SQL bases de datos compatibles.

Para obtener información sobre las versiones de Postgre SQL que son AWS DMS compatibles como fuente, consulte. Fuentes de AWS DMS

AWS DMS admite Postgre SQL para estos tipos de bases de datos:

  •  Bases de datos en las instalaciones

  • Bases de datos en una EC2 instancia de Amazon

  • Bases de datos en una instancia de Amazon RDS DB

  • Bases de datos en una instancia de base de datos basada en Amazon Aurora: edición compatible con Postgre SQL

  • Bases de datos en una instancia de base de datos basada en la edición Serverless compatible con Postgre SQL de Amazon Aurora

nota

DMSadmite Amazon Aurora Postgre SQL —Serverless V1 como fuente únicamente para carga completa. Sin embargo, puede usar Amazon Aurora Postgre SQL —Serverless V2 como fuente de carga completa, carga completa + CDC y solo tareas. CDC

Versión fuente de Postgre SQL

AWS DMS versión a utilizar

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

Utilice cualquier AWS DMS versión disponible.

13.x

Utilice AWS DMS la versión 3.4.3 y superior.

14.x

Utilice AWS DMS la versión 3.4.7 y superior.

15.x

Utilice AWS DMS la versión 3.5.1 y superior.

16.x

Utilice AWS DMS la versión 3.5.3 y superior.

Puede usar Secure Socket Layers (SSL) para cifrar las conexiones entre el SQL punto final de Postgre y la instancia de replicación. Para obtener más información sobre el uso SSL con un punto final de PostgreSQL, consulte. Uso de SSL con AWS Database Migration Service

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

Para configurar una SQL base de datos de Postgre como punto final de AWS DMS origen, haga lo siguiente:

Trabajar con bases de datos Postgre SQL autogestionadas como fuente en AWS DMS

Con una base de datos Postgre autogestionada como fuente, puede migrar los datos a otra SQL base de datos de Postgre o a una de las otras SQL bases de datos de destino compatibles con ellas. AWS DMS La fuente de la base de datos puede ser una base de datos local o un motor autogestionado que se ejecute en una instancia de AmazonEC2. Puede usar una instancia de base de datos tanto para tareas de carga completa como para tareas de captura de datos () CDC de cambios.

Requisitos previos para utilizar una base de datos Postgre autogestionada SQL como fuente AWS DMS

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

  • Asegúrese de utilizar una SQL base de datos de Postgre de la versión 9.4.x o superior.

  • Para tareas de carga completa o CDC solo CDC tareas, conceda permisos de superusuario para la cuenta de usuario especificada para la base de datos de origen de Postgre. SQL La cuenta de usuario necesita permisos de superusuario para acceder a funciones específicas de replicación en el origen. Para las tareas que solo se cargan por completo, la cuenta de usuario necesita SELECT permisos en las tablas para poder migrarlas.

  • Agregue la dirección IP del servidor de AWS DMS replicación al archivo de pg_hba.conf configuración y habilite la replicación y las conexiones de socket. 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 pg_hba.conf configuración SQL de Postgre controla la autenticación de los clientes. (HBAsignifica autenticación basada en host). El archivo se almacena tradicionalmente en el directorio de datos del clúster de bases de datos.

  • Si va a configurar una base de datos como fuente de replicación lógica mediante AWS DMS Permitir CDC el uso de una base de datos Postgre autogestionada SQL como fuente AWS DMS

nota

Algunas AWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el DMS motor las vuelva a utilizar. Si utiliza el parámetro idle_in_transaction_session_timeout en las SQL versiones 9.6 y posteriores de Postgre, puede provocar que se agote el tiempo de espera de las transacciones inactivas y se produzcan errores. No finalice las transacciones inactivas cuando utilice AWS DMS.

Permitir CDC el uso de una base de datos Postgre autogestionada SQL como fuente AWS DMS

AWS DMS admite la captura de datos de cambios (CDC) mediante la replicación lógica. Para habilitar la replicación lógica de una base de datos SQL fuente de Postgre autogestionada, defina los siguientes parámetros y valores en el postgresql.conf archivo de configuración:

  • Configurar wal_level = logical.

  • Defina max_replication_slots en un valor mayor de 1.

    Establezca el valor max_replication_slots en función del número de tareas que desea ejecutar. Por ejemplo, para ejecutar cinco tareas debe establecer un mínimo de cinco ranuras. 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. Tenga en cuenta que elimina DMS automáticamente los espacios de replicación cuando se elimina la tarea, si se DMS creó el espacio.

  • 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.

  • El parámetro wal_sender_timeout termina la replicación de conexiones que están inactivas durante más tiempo de los milisegundos especificados. El valor predeterminado para una SQL base de datos Postgre local es de 60 000 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 él. DMS

    Si se establece wal_sender_timeout en un valor distinto de cero, una DMS tarea CDC requiere un mínimo de 10000 milisegundos (10 segundos) y se produce un error si el valor es inferior a 10000. Mantenga el valor en menos de 5 minutos para evitar demoras durante la conmutación por error de una instancia de replicación en zonas de disponibilidad múltiples (Multi-AZ). DMS

Algunos parámetros son estáticos y solo se pueden configurar al iniciar el servidor. Los cambios 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 (RDSpara una base de SQL datos de Postgre) se ignoran hasta que se reinicie el servidor. Para obtener más información, consulte la documentación de Postgre. SQL

Para obtener más información sobre la activaciónCDC, consulte. Habilitar la captura de datos de cambios (CDC) mediante la replicación lógica

Trabajar con SQL bases AWS de datos Postgreg administradas como fuente DMS

Puede utilizar una SQL instancia de base de datos AWS de Postgre gestionada como fuente para. AWS DMS Puede realizar tareas de carga completa y cambiar las tareas de captura de datos (CDC) utilizando una AWS fuente de Postgre gestionada por usted. SQL

Requisitos previos para utilizar como fuente una base de datos Postgre AWS gestionada SQL DMS

Antes de migrar datos de una base de datos fuente de SQL Postgre AWS gestionada por usted, haga lo siguiente:

  • Le recomendamos que utilice una cuenta de AWS usuario con los permisos mínimos necesarios para la SQL instancia de base de datos de Postgre como cuenta de usuario para el punto final de origen de Postgre. SQL AWS DMS No se recomienda el uso de la cuenta principal. La cuenta debe tener el rol rds_superuser y el rol rds_replication. El rol de rds_replication concede permisos para administrar ranuras lógicas y para transmitir datos mediante ranuras lógicas.

    Asegúrese de crear varios objetos a partir de la cuenta de usuario principal para la cuenta que utilice. Para obtener información sobre la creación de estos, consulte Migración de una SQL base de datos de Amazon RDS for Postgre sin usar la cuenta de usuario maestra.

  • Si la base de datos de origen está en una nube privada virtual (VPC), elija el grupo de VPC seguridad 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 DMS replicación se conecte correctamente a la instancia de base de datos de origen. Cuando la base de datos y la instancia de DMS replicación estén en la misma VPC posición, añada el grupo de seguridad correspondiente a sus propias reglas de entrada.

nota

Algunas AWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el DMS motor las vuelva a utilizar. Si utiliza el parámetro idle_in_transaction_session_timeout en las SQL versiones 9.6 y posteriores de Postgre, puede provocar que se agote el tiempo de espera de las transacciones inactivas y se produzcan errores. No finalice las transacciones inactivas cuando utilice AWS DMS.

Habilitar CDC con una instancia de base de AWS datos de SQL Postgre administrada con AWS DMS

AWS DMS es compatible con CDC las SQL bases de datos de Amazon RDS Postgre cuando la instancia de base de datos está configurada para utilizar la replicación lógica. En la siguiente tabla se resume la compatibilidad de la replicación lógica de cada versión de Postgre AWS administrada. SQL

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

Versión de Postgre SQL

AWS DMS soporte de carga completa

AWS DMS CDCsoporte

Aurora Postgre SQL versión 2.1 con compatibilidad con Postgre SQL 10.5 (o inferior)

Sí

No

Aurora Postgre SQL versión 2.2 con compatibilidad con Postgre SQL 10.6 (o superior)

Sí

Sí

RDSpara compatibilidad con Postgre SQL con Postgre 10.21 (o superior) SQL

Sí

Sí
Para habilitar la replicación lógica de una instancia de base de datos de Postgre RDS SQL

  1. Utilice la cuenta de usuario AWS maestra de la SQL instancia de base de datos de Postgre como cuenta de usuario para el punto final de origen de Postgre. SQL La cuenta de usuario maestra tiene las funciones necesarias que le permiten configurarse. CDC

    Si utiliza una cuenta que no sea la cuenta de usuario principal, asegúrese de crear varios objetos desde la cuenta principal para la cuenta que utilice. Para obtener más información, consulte Migración de una SQL base de datos de Amazon RDS for Postgre sin usar la cuenta de usuario maestra.

  2. Defina el rds.logical_replication parámetro del grupo de CLUSTER parámetros de base de datos 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 en los parámetros pueden aumentar la generación de registros de escritura anticipada (WAL), por lo que solo rds.logical_replication se configuran cuando se utilizan ranuras de replicación lógica.

  3. El parámetro wal_sender_timeout termina la replicación de conexiones que están inactivas durante más tiempo de los milisegundos especificados. El valor predeterminado para una SQL base AWS de datos Postgre administrada es de 30 000 milisegundos (30 segundos). Si se establece el valor en 0 (cero), se desactiva el mecanismo de tiempo de espera y es una configuración válida para él. DMS

    Si se establece wal_sender_timeout en un valor distinto de cero, una DMS tarea CDC requiere un mínimo de 10000 milisegundos (10 segundos) y se produce un error si el valor está entre 0 y 10000. Mantenga el valor en menos de 5 minutos para evitar demoras durante la conmutación por error de una instancia de replicación en zonas de disponibilidad múltiples (Multi-AZ). DMS

  4. Asegúrese de que el valor del parámetro max_worker_processes del grupo de parámetros del clúster de base de datos sea igual o superior a los valores totales combinados de max_logical_replication_workers, autovacuum_max_workers y max_parallel_workers. Un número elevado 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, monitoree el rendimiento de la base de datos si establece max_worker_processes encima del valor predeterminado.

  5. Cuando utilice Aurora Postgre SQL como fuente conCDC, synchronous_commit establézcalo en. ON

Migración de una SQL base de datos de Amazon RDS for Postgre sin usar la cuenta de usuario maestra

En algunos casos, es posible que no utilice la cuenta de usuario maestra para la SQL instancia de base de datos de Amazon RDS Postgre que está utilizando como fuente. En estos casos, debe crear 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 la configuración de punto de conexión de CaptureDdls en false en el punto de conexión de origen, no tendrá que crear la tabla y el desencadenador siguientes 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 OtherThanMaster pueda obtener acceso a él.

  2. Inicie sesión en la SQL instancia de base de datos de Postgre con una cuenta de usuario distinta de la cuenta maestra, aquí la OtherThanMaster cuenta.

  3. Cree la tabla awsdms_ddl_audit mediante la ejecución del siguiente comando, sustituyendo objects_schema en 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' or tg_tag = 'CREATE TABLE AS') 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 OtherThanMaster 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();

  7. Asegúrese de que todos los usuarios y roles que acceden a estos eventos tengan los permisos necesariosDDL. Por ejemplo:

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

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

nota

Estos eventos se desencadenan mediante instrucciones CREATE TABLE, ALTER TABLE y DROP TABLE.

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

Puede utilizar la función de replicación lógica nativa SQL de Postgre para permitir la captura de datos de cambios (CDC) durante la migración de la base de datos para las fuentes de SQL Postgre. Puede utilizar esta función con una instancia de base de datos de Postgre autogestionada SQL y también con una instancia de base de datos de Amazon RDS for SQL SQL Postgre. 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 Postgre de origen. SQL

AWS DMS admite SQL tablas CDC de Postgre con claves principales. Si una tabla no tiene una clave principal, los registros de escritura anticipada (WAL) no incluyen una imagen anterior de la fila de la base de datos. En este caso, no DMS se puede actualizar la tabla. En este caso, puede utilizar opciones 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 la tabla 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 Postgre SQL como fuente DMS.

nota

REPLICAIDENTITYFULLes 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 de pglogical.

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

nota

Para la decodificación lógica, DMS utiliza el plugin test_decoding o pglogical. Si el complemento pglogical está disponible en una SQL base de datos Postgre fuente, DMS crea un espacio de replicación con pglogical; de lo contrario, se utiliza un complemento test_decoding. Para obtener más información sobre el complemento test_decoding, consulte la documentación de Postgre. SQL

Si el parámetro de la base de datos max_slot_wal_keep_size está establecido en un valor que no es el predeterminado y la ranura restart_lsn de replicación es inferior a la actual LSN en un tamaño superior a este, la DMS tarea no se realizará correctamente debido a la eliminación de los archivos necesarios. WAL

Configuración del complemento pglogical

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

SQLFuente de Postgre

Admite pglogical

SQLPostgre 9.4 o superior autogestionado

Sí

Amazon RDS Postgrex SQL 9.5 o inferior

No

Amazon RDS Postgre SQL 9.6 o superior

Sí

Aurora Postgre SQL 1.x a 2.5.x

No

Aurora Postgre SQL 2.6.x o superior

Sí

Aurora Postgre SQL 3.3.x o superior

Sí

Antes de configurar pglogical para su uso con AWS DMS, habilite primero la replicación lógica para la captura de datos de cambios (CDC) en la base de datos de origen de Postgre. SQL

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

Para usar el complemento pglogical para la replicación lógica en una base de datos fuente de Postgre con SQL AWS DMS

  1. Cree una extensión pglogic en su base de datos Postgre fuente: SQL

    1. Establezca el parámetro correcto:

      • Para las bases de datos Postgre SQL autogestionadas, defina el parámetro de la base de datos. shared_preload_libraries= 'pglogical'

      • Para las bases de datos Postgre en SQL Amazon RDS y Amazon Aurora Postgre SQL -Compatible Edition, shared_preload_libraries defina el parámetro pglogical en el mismo grupo de parámetros. RDS

    2. Reinicie la base de datos fuente de Postgre. SQL

    3. En la SQL base de datos de Postgre, ejecute el comando create extension pglogical;

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

    select * FROM pg_catalog.pg_extension

Ahora puede crear una AWS DMS tarea que realice la captura de datos de cambios para el punto final de la base de datos fuente de Postgre. SQL

nota

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

Uso de puntos de CDC inicio nativos para configurar una CDC carga de una fuente de Postgre SQL

Para habilitar los puntos de CDC inicio nativos con Postgre SQL como fuente, defina el atributo de conexión slotName adicional con 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.

Postgre SQL escribe los cambios de la base de datos en los WAL archivos que se descartan solo después de leer AWS DMS 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 de espacio en la SQL instancia de Postgre 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 del punto final y atributos de conexión adicionales (ECAs) cuando utilice Postgre SQL como fuente DMS.

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

Utilizar un punto de CDC inicio nativo para configurar una CDC carga de un punto final de origen de Postgre SQL

  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 tiene, 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 CDC exclusiva mediante la consola, o. AWS CLI AWS DMS API Por ejemplo, si usa el, CLI puede ejecutar el siguiente create-replication-task comando. 

    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:

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

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

    • Las opciones table-mappings y replication-task-settings se establecen en los mismos valores que en la tarea principal del paso 1.

    • Se establece la opción cdc-start-position para iniciar un valor de posición. 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.

    Para habilitar el modo de CDC inicio personalizado al crear una nueva tarea CDC exclusiva mediante la AWS DMS consola, haga lo siguiente:

    • En la sección Configuración de tareas, en el modo de CDC inicio de las transacciones de origen, selecciona Habilitar el modo de CDC inicio personalizado.

    • En Punto de CDC inicio personalizado para las transacciones de origen, elija Especificar un número de secuencia de registro. Especifique el número de cambio del sistema o elija Especificar un punto de control de recuperación y proporcione un punto de control de recuperación.

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

Si utiliza puntos de CDC inicio 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 CDC tarea.

Para utilizar una nueva ranura de replicación que no se haya creado anteriormente como parte de otra tarea 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 crea 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 de CDC inicio nativa de una CDC tarea 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 la función pglogical.create_replication_set. 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 rastrea solo 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. Establezca el siguiente atributo de conexión adicional (ECA) al crear el punto final de origen.

    PluginName=PGLOGICAL;slotName=slot_name;

Ahora puede crear una CDC única tarea con un punto de inicio SQL nativo de Postgre utilizando la nueva ranura de replicación. Para obtener más información sobre el complemento de pglogical, consulte la documentación de pglogical 3.7

Migración de Postgre a SQL Postgre mediante SQL AWS DMS

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

Uso de herramientas nativas de Postgre para migrar datos SQL

Le recomendamos que utilice las herramientas de migración de SQL bases de datos de Postgre, por ejemplo, en las siguientes pg_dump condiciones:

  • Tiene una migración homogénea, en la que migra de una base de datos Postgre de origen a una SQL base de datos Postgre de destino. SQL

  • 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 COPY comando para crear un esquema y un volcado de datos de una base de datos de Postgre. SQL 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, use el comando pg_restore y el parámetro -d.

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

Para obtener más información sobre la importación de una SQL base de datos de Postgre a Amazon RDS for Postgre o Amazon SQL Aurora SQL Postgre -Compatible Edition, consulte. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html

Se utiliza para migrar datos de Postgre DMS a Postgre SQL SQL

AWS DMS puede migrar datos, por ejemplo, desde una SQL base de datos Postgre de origen que se encuentra en las instalaciones a una instancia de Amazon RDS for Postgre SQL o Aurora Postgre de destino. SQL Los tipos de datos básicos o básicos de SQL Postgre suelen migrar correctamente.

nota

Al replicar tablas particionadas de una SQL fuente de Postgre a una de SQL destino de Postgre, no es necesario que menciones la tabla principal como parte de los criterios de selección de la tarea. DMS Mencionar la tabla principal provoca que los datos se dupliquen 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 de la asignación de tablas, la tabla principal se rellena automáticamente.

Es posible que los tipos de datos que se admiten en la base de datos de origen pero que no se admiten en la de destino no se migren correctamente. AWS DMS transmite algunos tipos de datos como cadenas si se desconoce el tipo de datos. Algunos tipos de datos, como XML yJSON, pueden migrar correctamente como archivos pequeños, pero pueden fallar si se trata de documentos de gran tamaño.

Cuando realice la migración de un tipo de datos, tenga en cuenta lo siguiente:

  • En algunos casos, el tipo de datos Postgre SQL NUMERIC (p, s) no especifica precisión ni escala. Para DMS las versiones 3.4.2 y anteriores, DMS utiliza una precisión de 28 y una escala de 6 de forma predeterminada, NUMERIC (28,6). Por ejemplo, el valor 0,611111104488373 de la fuente se convierte en 0,611111 en el destino de Postgre. SQL

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

La siguiente tabla muestra los tipos de SQL datos de Postgre de origen y si se pueden migrar correctamente.

Tipo de datos Se migra correctamente Se migra parcialmente No se migra Comentarios
INTEGER X
SMALLINT X
BIGINT X
NUMERIC/DECIMAL(ps, 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 a. C.”, respectivamente.
TIMESTAMP WITH TIME ZONE X
DATE X
TIME X
TIME WITH TIME ZONE X
INTERVAL X
BOOLEAN X
ENUM X
CIDR X
INET X
MACADDR X
TSVECTOR X
TSQUERY X
XML X
POINT X Tipo de datos GIS posespaciales
LINE X
LSEG X
BOX X
PATH X
POLYGON X Tipo de datos GIS posespaciales
CIRCLE X
JSON X
ARRAY X Requiere clave principal
COMPOSITE X
RANGE X
LINESTRING X Tipo de datos GIS posespaciales
MULTIPOINT X Tipo de datos GIS posespaciales
MULTILINESTRING X Tipo de datos GIS posespaciales
MULTIPOLYGON X Tipo de datos GIS posespaciales
GEOMETRYCOLLECTION X Tipo de datos GIS posespaciales

Migración de tipos de datos GIS posespaciales

Los datos espaciales identifican la información de geometría de un objeto o ubicación en el espacio. Las bases de datos SQL relacionales de objetos de Postgre admiten tipos de datos posespaciales. GIS

Antes de migrar los objetos de datos SQL espaciales de Postgre, asegúrese de que el complemento Post GIS esté habilitado a nivel global. De este modo, se garantiza que se AWS DMS crean las columnas de datos espaciales de origen exactas para la instancia de base de datos de destino de PostgreSQL.

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

  • POINT

  • LINESTRING

  • POLYGON

  • MULTIPOINT

  • MULTILINESTRING

  • MULTIPOLYGON

  • GEOMETRYCOLLECTION

Migración de Babelfish a Amazon Aurora Postgre mediante SQL AWS DMS

Puede migrar las tablas de SQL origen de Postgre de Babelfish para Aurora a cualquier punto final de destino compatible utilizando. AWS DMS

Al crear el punto final de AWS DMS origen mediante la DMS consola o los CLI comandosAPI, establece el origen en Amazon Aurora Postgre SQL y el nombre de la base de datos en. babelfish_db En la sección Configuración del punto final, asegúrese de que DatabaseModeesté establecido en Babelfish y en el nombre de la BabelfishDatabaseNamebase de datos Babelfish T- de origen. SQL En lugar de usar el puerto Babelfish1433, usa el TCP puerto Aurora SQL TCP Postgre. 5432

Debe crear las tablas antes de migrar los datos para asegurarse de que DMS utilizan los tipos de datos y los metadatos de las tablas correctos. Si no crea las tablas en el destino antes de ejecutar la migración, es DMS posible que cree las tablas con permisos y tipos de datos incorrectos.

Agregar reglas de transformación a la tarea de migración

Al crear una tarea de migración para una fuente de Babelfish, es necesario incluir reglas de transformación que garanticen que se DMS utilizan las tablas de destino creadas previamente.

Si configuró el modo de migración de varias bases de datos al definir su SQL clúster de Babelfish para Postgre, añada una regla de transformación que cambie el nombre del esquema por el de esquema T. SQL Por ejemplo, si el nombre del esquema en T es y el nombre de tu SQL esquema de Babelfish para Postgre esdbo, cambia el nombre del SQL esquema para usar una regla de transformación. mydb_dbo dbo Para encontrar el nombre del SQL esquema de Postgre, consulte la arquitectura de Babelfish en la Guía del usuario de Amazon Aurora.

Si usa el modo de base de datos única, no necesita usar una regla de transformación para cambiar el nombre de los esquemas de base de datos. Los nombres de los SQL esquemas de Postgre tienen un one-to-one mapeo con los nombres de los esquemas de la base de datos T. SQL

El siguiente ejemplo de regla de transformación muestra cómo cambiar el nombre del esquema de mydb_dbo nuevo a: dbo

{
    "rules": [
        {
            "rule-type": "transformation",
            "rule-id": "566251737",
            "rule-name": "566251737",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "mydb_dbo"
            },
            "rule-action": "rename",
            "value": "dbo",
            "old-value": null
        },
        {
            "rule-type": "selection",
            "rule-id": "566111704",
            "rule-name": "566111704",
            "object-locator": {
                "schema-name": "mydb_dbo",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}

Limitaciones del uso de un punto final de código SQL fuente de Postgre con tablas de Babelfish

Cuando se utiliza un punto final de origen de Postgre SQL con tablas de Babelfish, se aplican las siguientes limitaciones:

  • DMSsolo admite la migración desde las versiones 16.2/15.6 y posteriores de Babelfish y desde la versión 3.5.3 y posteriores. DMS

  • DMSno replica los cambios en la definición de la tabla de Babelfish en el punto final de destino. Una solución para esta limitación consiste en aplicar primero los cambios en la definición de la tabla en el destino y, a continuación, cambiar la definición de la tabla en la fuente de Babelfish.

  • Al crear tablas de Babelfish con el tipo de BYTEA datos, las DMS convierte al tipo de varbinary(max) datos al migrar a Server como destino. SQL

  • DMSno admite el LOB modo completo para los tipos de datos binarios. En su lugar, utilice LOB el modo limitado para los tipos de datos binarios.

  • DMSno admite la validación de datos para Babelfish como fuente.

  • Para configurar las tareas del modo de preparación de la tabla de Target, utilice únicamente los modos No hacer nada o Truncar. No utilice el modo Borrar tablas en el destino. Al utilizar Drop tables on Target, es DMS posible que se creen las tablas con tipos de datos incorrectos.

  • Cuando utilice la replicación continua (CDCo carga completa yCDC), establezca el atributo de conexión PluginName adicional (ECA) enTEST_DECODING.

  • DMSno admite la replicación (CDCo carga completaCDC) de una tabla particionada para Babelfish como fuente.

Eliminar AWS DMS artefactos de una base de datos fuente de Postgre SQL

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

Para eliminar los artefactos, emita las instrucciones siguientes (en el orden en el que aparecen), donde {AmazonRDSMigration} es el esquema en el que se crearon los artefactos. La operación de ingresar un esquema se debe realizar con su sumo cuidado. 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 Postgre SQL como fuente DMS

Puede añadir ajustes de configuración adicionales al migrar datos de una base de datos de Postgre SQL de dos maneras:

  • Puede añadir valores al atributo de conexión adicional para capturar los DDL eventos y especificar el esquema en el que se crean los artefactos de la DDL base de datos operativa. Para obtener más información, consulte Configuración del punto final y atributos de conexión adicionales (ECAs) cuando utilice Postgre SQL como fuente DMS.

  • Puede anular parámetros de cadenas de conexión. Elija esta opción para hacer cualquiera de las siguientes acciones:

    • Especifique AWS DMS los parámetros internos. Estos parámetros se necesitan en contadas ocasiones, no están a la vista en la interfaz de usuario.

    • Especifique los valores de transferencia (passthru) para el cliente de base de datos específico. AWS DMS incluye los parámetros de transferencia en la cadena de conexión transferida al cliente de base de datos.

  • Al utilizar el parámetro de nivel de tabla REPLICA IDENTITY en las SQL versiones 9.4 y posteriores de Postgre, puede controlar la información que se escribe en los registros de escritura anticipada (). WALs En concreto, lo hace para identificar las filas WALs que se actualizan o eliminan. REPLICA IDENTITY FULLregistra los valores antiguos de todas las columnas de la fila. Úselo REPLICA IDENTITY FULL con cuidado para cada tabla, ya que FULL genera un número adicional WALs que puede no ser necesario. Para obtener más información, consulte ALTERTABLE- REPLICA IDENTITY

Uso de la configuración de MapBooleanAsBoolean punto final de Postgre SQL

Puede usar la configuración del SQL punto final de Postgre para mapear un booleano como booleano desde su SQL fuente de Postgre a un destino de Amazon Redshift. De forma predeterminada, un tipo se migra como varchar (5BOOLEAN). Puede especificar MapBooleanAsBoolean que Postgre migre SQL el tipo booleano como booleano, como se muestra en el siguiente ejemplo.

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

Tenga en cuenta que debe establecer esta configuración en los puntos de conexión de origen y destino para que surta efecto.

Como My SQL no tiene ningún BOOLEAN tipo, utilice una regla de transformación en lugar de esta configuración al migrar datos a My. BOOLEAN SQL

Configuración del punto final y atributos de conexión adicionales (ECAs) cuando utilice Postgre SQL como fuente DMS

Puede usar la configuración del punto final y los atributos de conexión adicionales (ECAs) para configurar su base de datos SQL fuente de Postgre. La configuración del punto final se especifica al crear el punto final de origen mediante la AWS DMS consola o mediante el create-endpoint comando del AWS CLI, con la --postgre-sql-settings '{"EndpointSetting": "value", ...}' JSON sintaxis.

En la siguiente tabla se muestran los ajustes de punto final ECAs que puede utilizar con Postgre SQL como fuente.

Nombre de atributo Descripción

CaptureDdls

Para capturar DDL eventos, AWS DMS crea varios artefactos en la SQL base de datos de Postgre cuando se inicia la tarea. Más adelante podrá quitar estos artefactos según se describe en Eliminar AWS DMS artefactos de una base de datos fuente de Postgre SQL.

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

Se capturan los DDL eventos transmitidos.

Valor predeterminado: true

Valores válidos: true/false

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

ConsumeMonotonicEvents

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

Valor predeterminado: false

Valores válidos: falso/verdadero

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

DdlArtifactsSchema

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

Valor predeterminado: público

Valores válidos: string

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

ExecuteTimeout

Establece el tiempo de espera de la sentencia del cliente para la SQL instancia de Postgre, en segundos. El valor de predeterminado es de 60 segundos.

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

FailTasksOnLobTruncation

Cuando se establece entrue, este valor hace que una tarea falle si el tamaño real de una LOB columna es mayor que el especificado. LobMaxSize

Si la tarea está configurada en LOB modo limitado y esta opción está establecida en True, la tarea fallará en lugar de truncar los LOB datos.

Valor predeterminado: false

Valores válidos: booleano

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

fetchCacheSize

Este atributo de conexión adicional (ECA) establece el número de filas que el cursor buscará durante la operación a plena carga. En función de los recursos disponibles en la instancia de replicación, puede ajustar el valor al alza o a la baja.

Valor predeterminado: 10000

Valores válidos: Number

ECAEjemplo: fetchCacheSize=10000;

HeartbeatEnable

La función de WAL latido imita una transacción ficticia, de modo que las ranuras de replicación lógica inactivas no retienen WAL los registros antiguos, lo que provoca situaciones de almacenamiento completo en la fuente. 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 de los WAL latidos del corazón (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"}'

MapJsonbAsClob

De forma predeterminada, se AWS DMS asigna JSONB aNCLOB. Puede especificar MapJsonbAsClob que Postgre SQL migre el JSONB tipo como. CLOB

Ejemplo: --postgre-sql-settings='{"MapJsonbAsClob": "true"}'

MapLongVarcharAs

De forma predeterminada, se AWS DMS asigna VARCHAR a. WSTRING Puede especificar MapLongVarcharAs que Postgre SQL migre el tipo VARCHAR (N) (donde N es mayor que 16387) a los siguientes tipos:

  • WSTRING

  • CLOB

  • NCLOB

Ejemplo: --postgre-sql-settings='{"MapLongVarcharAs": "CLOB"}'

MapUnboundedNumericAsString

Este parámetro trata las columnas con tipos de NUMERIC datos ilimitados como si se STRING migraran correctamente sin perder la precisión del valor numérico. Utilice este parámetro solo para la replicación desde el SQL origen de Postgre al SQL destino de Postgre o para bases de datos compatibles con Postgre. SQL

Valor predeterminado: false

Valores válidos: false/true

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

Es posible que el uso de este parámetro provoque una 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. Este parámetro se admite para su uso en la versión 3.4.4 y versiones posteriores DMS

nota

Úselo solo MapUnboundedNumericAsString en los puntos finales de SQL origen y destino de Postgre juntos.

El uso de SQL puntos finales MapUnboundedNumericAsString de Postgre no fuente restringe la precisión a 28 durante el proceso. CDC El uso de MapUnboundedNumericAsString en los puntos de conexión de destino migra los datos con precisión de 28 y escala de 6.

No lo use MapUnboundedNumericAsString con objetivos que no sean de Postgre. SQL

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 CDC carga de la instancia fuente de SQL Postgre.

Cuando se usa con el parámetro de AWS DMS API CdcStartPosition solicitud, este atributo también permite usar puntos de CDC inicio nativos. DMScomprueba que existe la ranura de replicación lógica especificada antes de iniciar la tarea de CDC carga. 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 CdcStartPosition configuración válida, se 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 CreateReplicationTask documentación de ModifyReplicationTask API las operaciones y en la AWS Database Migration Service APIReferencia. StartReplicationTask

Valores válidos: string

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

unboundedVarcharMaxSize

Este atributo de conexión adicional (ECA) define el tamaño máximo de una columna de datos definida como tipo VarChar sin un especificador de longitud máxima. El valor predeterminado es 8000 bytes. El valor máximo es 10485760 bytes.

Limitaciones del uso de una base de datos Postgre SQL como fuente DMS

Se aplican las siguientes limitaciones al utilizar Postgre SQL como fuente para: AWS DMS

  • AWS DMS no funciona con Amazon RDS for Postgre SQL 10.4 ni con Amazon Aurora Postgre SQL 10.4 ni como origen ni como destino.

  • Las tablas de captura deben contar con una clave principal. Si una tabla no tiene una clave principal, AWS DMS DELETE ignora y registra las operaciones de esa tabla. UPDATE 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 por lotes «NO», la LOB capacidad total, la validación de datos y la incapacidad de replicar en Redshift Target de manera eficiente.

  • AWS DMS ignora el 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 la actualización de una clave principal en Postgre SQL son impredecibles, no se escribe ningún registro en la tabla de excepciones.

  • AWS DMS no admite la opción Iniciar los cambios del proceso desde la ejecución de la marca de tiempo.

  • AWS DMS no replica los cambios que resultan de las operaciones de partición o subpartición (ADD,DROP, o). TRUNCATE

  • La replicación de varias tablas con el mismo nombre, donde cada nombre tiene mayúsculas y minúsculas diferentes (por ejemplo, tabla1 y tabla1) puede provocar un comportamiento impredecible. TABLE1 Debido a este problema, AWS DMS no admite este tipo de replicación.

  • En la mayoría de los casos, AWS DMS admite el procesamiento de CREATE cambios y DROP DDL las instrucciones de las tablas. ALTER AWS DMS no admite este procesamiento de cambios si las tablas se encuentran en un bloque interno de funciones o procedimientos o en otras estructuras anidadas.

    Por ejemplo, el siguiente cambio no se capturó.

    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 SQL fuente de Postgre se migran a un SQL servidor de destino como tipos de bit datos con valores incoherentes. Como solución alternativa, cree previamente la tabla con un tipo de VARCHAR(1) datos para la columna (o haga que AWS DMS 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 el procesamiento de cambios de las TRUNCATE operaciones.

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

  • AWS DMS admite el tipo de GIS datos Post solo para migraciones homogéneas.

  • Si tu fuente es una SQL base de datos de Postgre local o en una EC2 instancia de Amazon, asegúrate de que el complemento de salida test_decoding esté instalado en el punto final de origen. Puedes encontrar este complemento en el paquete contrib de Postgre. SQL Para obtener más información sobre el complemento test-decocoding, consulta la documentación de Postgre. SQL

  • AWS DMS no admite el procesamiento de cambios para establecer y desestablecer los valores predeterminados de las columnas (utilizando la cláusula sobre las ALTER COLUMN SET DEFAULT declaraciones). ALTER TABLE

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

  • Cuando la replicación lógica está habilitada, el número máximo 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 y restart_lsn no avanza hasta que la transacción se complete o detenga y finalice la reversión. Como se trata de una transacción larga, puede tardar mucho tiempo en restaurarse. Por lo tanto, evite las transacciones de larga duración o muchas subtransacciones cuando la replicación lógica esté habilitada. En su lugar, divida la transacción en varias transacciones más pequeñas.

    En SQL las versiones 13 y posteriores de Aurora Postgre, puede ajustar el logical_decoding_work_mem parámetro para controlar cuándo los DMS derrames cambian los datos al disco. Para obtener más información, consulte Derrame archivos en Aurora Postgre SQL.

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

  • AWS DMS no admite la replicación de tablas particionadas. 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 SQL fuente de Postgre a un SQL destino de Postgre, primero cree manualmente las tablas principal y secundaria en el destino. A continuación, defina una tarea independiente para replicar en estas tablas. En tal caso, establezca la configuración de la tarea en Truncar antes de cargar.

  • El tamaño del tipo de SQL NUMERIC datos de Postgre no es fijo. Al transferir datos que son de un tipo de NUMERIC datos pero sin precisión ni escala, DMS utiliza NUMERIC(28,6) (una precisión de 28 y una escala de 6) de forma predeterminada. Por ejemplo, el valor 0,611111104488373 de la fuente se convierte en 0,611111 en el destino de Postgre. SQL

  • AWS DMS admite Aurora Postgre SQL Serverless V1 como fuente únicamente para tareas de carga completa. AWS DMS admite Aurora Postgre SQL Serverless V2 como fuente para tareas de carga completa, carga completa y únicamente CDC tareas. CDC

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

  • Cuando se utiliza el LOB modo, 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 DELETE y las operaciones de UPDATE registro serán impredecibles.

  • Cuando se utiliza la característica de carga paralela, no se admite la segmentación de tablas en función de particiones o subparticiones. Para obtener más información acerca de la carga paralela, consulte Uso de carga paralela para tablas, vistas y recopilaciones seleccionadas

  • AWS DMS no admite restricciones diferidas.

  • AWS DMS la versión 3.4.7 admite Postgre SQL 14.x como fuente con las siguientes limitaciones:

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

    • AWS DMS no admite la replicación lógica para transmitir transacciones en curso desde hace mucho tiempo.

  • AWS DMS no es compatible con CDC Amazon RDS Proxy para Postgre SQL como fuente.

  • Si se utilizan filtros de origen que no contienen una columna de clave principal, no se capturarán las operaciones DELETE.

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

    alter event trigger awsdms_intercept_ddl enable always;

  • AWS DMS no admite el clúster de bases de datos RDS Multi-AZ de Amazon CDC para Postgre SQL como fuente, ya que RDS para Postgre los clústeres de bases de datos SQL Multi-AZ no admiten la replicación lógica.

Tipos de datos de origen para Postgre SQL

La siguiente tabla muestra los tipos de datos de SQL origen de Postgre que se admiten cuando se utiliza AWS DMS y la asignación predeterminada a los tipos de datos. 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 información adicional sobre AWS DMS los tipos de datos, consulte. Tipos de datos de AWS Database Migration Service

Tipos de datos de Postgre SQL

DMStipos de datos

INTEGER

INT4

SMALLINT

INT2

BIGINT

INT8

NUMERIC(p, s)

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

Si la precisión es 39 o superior, utiliceSTRING.

DECIMAL(P, S)

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

Si la precisión es 39 o superior, utiliceSTRING.

REAL

REAL4

DOUBLE

REAL8

SMALLSERIAL

INT2

SERIAL

INT4

BIGSERIAL

INT8

MONEY

NUMERIC(38,4)

El tipo de MONEY datos está asignado FLOAT en SQL el servidor.

CHAR

WSTRING(1)

CHAR(N)

WSTRING(n)

VARCHAR(N)

WSTRING(n)

TEXT

NCLOB

CITEXT

NCLOB

BYTEA

BLOB

TIMESTAMP

DATETIME

TIMESTAMP WITH TIME ZONE

DATETIME

DATE

DATE

TIME

TIME

TIME WITH TIME ZONE

TIME

INTERVAL

STRING(128) —1YEAR, 2MONTHS, 3DAYS, 4HOURS, 5MINUTES, 6 SECONDS

BOOLEAN

CHAR(5) falso o verdadero

ENUM

STRING(64)

CIDR

STRING(50)

INET

STRING(50)

MACADDR

STRING(18)

BIT(n)

STRING(n)

BITVARYING(n)

STRING(n)

UUID

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)

Trabajar con tipos LOB de datos fuente para Postgre SQL

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

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

  • CLOB— La replicación trata a cada personaje como si fuera un UTF8 personaje. Por lo tanto, encuentre la longitud del texto con más caracteres en la columna, que se muestra aquí como max_num_chars_text. Utilice esta longitud para especificar el valor de Limitar el LOB tamaño a. Si los datos incluyen caracteres de 4 bytes, multiplique por 2 para especificar el LOBtamaño límite del valor, que se expresa en bytes. En este caso, el LOB tamaño límite 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 con más caracteres en la columna (max_num_chars_text) y multiplíquela por 2. Esto se hace para especificar el valor de Limitar el LOB tamaño a. En este caso, el LOB tamaño límite 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, el LOB tamaño límite a es igual a max_num_chars_text multiplicado por 4.