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 como fuente AWS DMS Puede migrar datos de una o varias bases de datos PostgreSQL mediante. AWS DMS Con una base de datos de PostgreSQL como origen, podrá migrar datos a otra base de datos de PostgreSQL o a una de las bases de datos compatibles. Para obtener información sobre las versiones de PostgreSQL AWS DMS compatibles como fuente, consulte. [Fuentes de AWS DMS](CHAP_Introduction.Sources.md) AWS DMS admite PostgreSQL para estos tipos de bases de datos: +  Bases de datos en las instalaciones + Bases de datos en una instancia de Amazon EC2 + Bases de datos en una instancia de base de datos de Amazon RDS + Bases de datos de una instancia de base de datos basada en Amazon Aurora PostgreSQL-Compatible Edition + Bases de datos de una instancia de base de datos basada en Amazon Aurora PostgreSQL-Compatible Serverless Edition **nota** DMS es compatible con Amazon Aurora PostgreSQL - Serverless V1 como origen solo para carga completa. Sin embargo, puede usar Amazon Aurora PostgreSQL - Serverless V2 como origen para tareas de carga completa, carga completa \$1 CDC y solo CDC. Puede utilizar 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](CHAP_Security.SSL.md). Como requisito de seguridad adicional cuando se utiliza PostgreSQL como origen, la cuenta de usuario especificada debe ser un usuario registrado en la base de datos de PostgreSQL. Para configurar una base de datos PostgreSQL como AWS DMS punto final de origen, haga lo siguiente: + Cree un usuario de PostgreSQL con los permisos adecuados para AWS DMS proporcionar acceso a la base de datos de origen de PostgreSQL. **nota** Si la base de datos de origen de PostgreSQL es autoadministrada, consulte [Trabajar con bases de datos PostgreSQL autogestionadas como fuente en AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) para obtener más información. Si la base de datos de origen de PostgreSQL la administra Amazon RDS, consulte [Trabajar con bases AWS de datos PostgreSQL gestionadas como fuente de DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) para obtener más información. + Cree un punto de conexión de origen de PostgreSQL que se ajuste a la configuración de base de datos de PostgreSQL que haya elegido. + Cree una tarea o un conjunto de tareas para migrar las tablas. Para crear una full-load-only tarea, no es necesaria ninguna otra configuración de punto final. Antes de crear una tarea para la captura de datos de cambios (una tarea exclusiva de CDC o de carga completa de CDC y de CDC), consulte [Permitir a los CDC utilizar una base de datos PostgreSQL autogestionada como fuente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) o [Habilitar CDC con una instancia de base AWS de datos PostgreSQL administrada con AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC). **Topics** + [Trabajar con bases de datos PostgreSQL autogestionadas como fuente en AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) + [Trabajar con bases AWS de datos PostgreSQL gestionadas como fuente de DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) + [Habilitación de la captura de datos de cambios (CDC) mediante replicación lógica](#CHAP_Source.PostgreSQL.Security) + [Uso de puntos de inicio de CDC nativo para configurar una carga de CDC de un origen de PostgreSQL](#CHAP_Source.PostgreSQL.v10) + [Migración de PostgreSQL a PostgreSQL mediante AWS DMS](#CHAP_Source.PostgreSQL.Homogeneous) + [Migración de Babelfish a Amazon Aurora PostgreSQL mediante AWS DMS](#CHAP_Source.PostgreSQL.Babelfish) + [Eliminar AWS DMS artefactos de una base de datos fuente de PostgreSQL](#CHAP_Source.PostgreSQL.CleanUp) + [Ajustes de configuración adicionales al utilizar una base de datos de PostgreSQL como origen de DMS](#CHAP_Source.PostgreSQL.Advanced) + [Réplica de lectura como origen para PostgreSQL](#CHAP_Source.PostgreSQL.ReadReplica) + [Uso de la configuración del punto de conexión `MapBooleanAsBoolean` de PostgreSQL](#CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting) + [Configuración de punto final y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como fuente de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib) + [Restricciones en el uso de una base de datos de PostgreSQL como origen de DMS](#CHAP_Source.PostgreSQL.Limitations) + [Tipos de datos de origen para PostgreSQL](#CHAP_Source-PostgreSQL-DataTypes) ## Trabajar con bases de datos PostgreSQL autogestionadas como fuente en AWS 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 con. AWS DMS El origen de la base de datos puede estar en una base de datos en las instalaciones o un motor autoadministrado en ejecución en una instancia de Amazon EC2. Puede utilizar una instancia de base de datos tanto para tareas de carga completa como para la captura de datos de cambios (CDC). ### Requisitos previos para utilizar una base de datos PostgreSQL autogestionada como fuente AWS DMS Antes de migrar datos desde una base de datos de origen de PostgreSQL autoadministrada, haga lo siguiente: + Asegúrese de utilizar una base de datos de PostgreSQL versión 9.4.x o superiores. + Para las tareas de carga completa más CDC o tareas exclusivas de CDC, debe conceder permisos de superusuario para la cuenta de usuario especificada para la base de datos de origen de PostgreSQL. La cuenta de usuario necesita permisos de superusuario para acceder a funciones específicas de replicación en el origen. La cuenta de usuario de DMS necesita permisos SELECT en todas las columnas para migrar las tablas correctamente. En el caso de que falten permisos en las columnas, DMS crea la tabla de destino con las asignaciones de tipos de datos habituales de DMS, lo que genera diferencias en los metadatos y errores en las tareas. + 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 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 va a configurar una base de datos como fuente para la replicación lógica AWS DMS mediante [Permitir a los CDC utilizar una base de datos PostgreSQL autogestionada como fuente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) **nota** Algunas AWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el motor del DMS las vuelva a utilizar. Al usar el parámetro `idle_in_transaction_session_timeout` en PostgreSQL versiones 9.6 y superiores, puede provocar transacciones inactivas en el tiempo de espera y que se devuelva un error. No finalice las transacciones inactivas cuando utilice AWS DMS. ### Permitir a los CDC utilizar una base de datos PostgreSQL autogestionada 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 en una base de datos de origen de PostgreSQL autoadministrada, establezca los siguientes parámetros y valores en el archivo de configuración `postgresql.conf`: + 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 DMS elimina automáticamente las ranuras de replicación cuando se elimina la tarea, si DMS creó la ranura. + 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 base de datos de PostgreSQL en las instalaciones es 60 000 milisegundos (60 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 la DMS. Si se establece `wal_sender_timeout` en un valor distinto de cero, una tarea de DMS con CDC 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 retrasos durante una conmutación por error de Multi-AZ de una instancia de replicación de DMS. Algunos parámetros son estáticos y solo se pueden configurar al iniciar el servidor. Los cambios en las entradas en el archivo de configuración (para una base de datos autoadministrada) o en el grupo de parámetros de base de datos (para una base de datos de RDS para PostgreSQL) se ignoran hasta que se reinicie el servidor. Para obtener más información, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/intro-whatis.html). Para obtener más información acerca de la habilitación de CDC, consulte [Habilitación de la captura de datos de cambios (CDC) mediante replicación lógica](#CHAP_Source.PostgreSQL.Security). ## Trabajar con bases AWS de datos PostgreSQL gestionadas como fuente de DMS Puede utilizar una instancia de base AWS de datos PostgreSQL gestionada como fuente para. AWS DMS Puede realizar tanto tareas de carga completa como tareas de captura de datos de cambios (CDC) mediante un origen de PostgreSQL administrado por AWS. ### Requisitos previos para utilizar una base de datos AWS PostgreSQL gestionada como fuente de DMS Antes de migrar datos desde una base de datos fuente AWS de PostgreSQL gestionada, haga lo siguiente: + Le recomendamos que utilice una cuenta de AWS usuario con los permisos mínimos necesarios para la instancia de base de datos de PostgreSQL como cuenta de usuario para el punto final de origen de PostgreSQL. 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 base de datos de Amazon RDS para PostgreSQL sin usar la cuenta de usuario principal](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser). + Si la base de datos de origen está en una nube privada virtual (VPC), elija el grupo de seguridad de la VPC que proporciona acceso a la instancia de base de datos donde reside la base de datos. Esto es necesario para que la instancia de replicación de 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, agregue el grupo de seguridad adecuado a sus propias reglas de entrada. **nota** Algunas AWS DMS transacciones permanecen inactivas durante algún tiempo antes de que el motor de DMS las vuelva a utilizar. Al usar el parámetro `idle_in_transaction_session_timeout` en PostgreSQL versiones 9.6 y superiores, puede provocar transacciones inactivas en el tiempo de espera y que se devuelva un error. No finalice las transacciones inactivas cuando utilice AWS DMS. ### Habilitar CDC con una instancia de base AWS de datos PostgreSQL administrada con AWS DMS AWS DMS admite CDC en bases de datos PostgreSQL de Amazon RDS cuando la instancia de base de datos está configurada para usar la replicación lógica. En la siguiente tabla se resume la compatibilidad de la replicación lógica de cada versión de AWS PostgreSQL administrada. | Versión de PostgreSQL | AWS DMS soporte de carga completa | AWS DMS Soporte de los CDC | | --- | --- | --- | | Aurora PostgreSQL versión 2.1 con compatibilidad de PostgreSQL 10.5 (o inferior) | Sí | No | | Aurora PostgreSQL versión 2.2 con compatibilidad de PostgreSQL 10.6 (o superiores) | Sí | Sí | | RDS para PostgreSQL compatible con PostgreSQL 10.21 (o superiores) | 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 usuario AWS maestra de la instancia de base de datos de PostgreSQL como cuenta de usuario para el punto final de origen de PostgreSQL. La cuenta de usuario principal dispone de los roles necesarios que le permiten configurar la 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 base de datos de Amazon RDS para PostgreSQL sin usar la cuenta de usuario principal](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser). 1. Establezca en 1 el parámetro `rds.logical_replication` en el grupo de parámetros de CLÚSTER de la base de datos. 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. 1. 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 base AWS de datos PostgreSQL gestionada 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 la DMS. Si se establece `wal_sender_timeout` en un valor distinto de cero, una tarea de DMS con CDC 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 retrasos durante una conmutación por error de Multi-AZ de una instancia de replicación de DMS. 1. 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. 1. Cuando utilice Aurora PostgreSQL como origen con CDC, establezca `synchronous_commit` en `ON`. **Cómo utilizar la réplica de lectura del clúster de base de datos multi-AZ de PostgreSQL para la CDC (replicación continua)** 1. Establezca los parámetros `rds.logical_replication` y `sync_replication_slots` del grupo de parámetros CLUSTER de la base de datos en 1. Para que estos parámetros estáticos surtan efecto, es necesario reiniciar la instancia de base de datos. 1. Ejecute el siguiente comando para crear la tabla `awsdms_ddl_audit` en Writer y sustituirla por el `objects_schema` con 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 ); ``` 1. Ejecute el siguiente comando para crear la función `awsdms_intercept_ddl` y sustituirla por el `objects_schema` con 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; $$; ``` 1. Ejecute el siguiente comando para crear el desencadenador de eventos `awsdms_intercept_ddl`: ``` CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl(); ``` Asegúrese de que todos los usuarios y roles que acceden 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; ``` 1. Cree una ranura de replicación en Writer: ``` SELECT * FROM pg_create_logical_replication_slot('dms_read_replica_slot', 'test_decoding', false, true); ``` 1. Asegúrese de que la ranura de replicación esté disponible en Reader: ``` select * from pg_catalog.pg_replication_slots where slot_name = 'dms_read_replica_slot'; slot_name |plugin |slot_type|datoid|database|temporary|active|active_pid|xmin|catalog_xmin|restart_lsn|confirmed_flush_lsn|wal_status|safe_wal_size|two_phase|inactive_since |conflicting|invalidation_reason|failover|synced| ---------------------+-------------+---------+------+--------+---------+------+----------+----+------------+-----------+-------------------+----------+-------------+---------+-----------------------------+-----------+-------------------+--------+------+ dms_read_replica_slot|test_decoding|logical | 5|postgres|false |false | | |3559 |0/180011B8 |0/180011F0 |reserved | |true |2025-02-10 15:45:04.083 +0100|false | |false |false | ``` 1. Cree el punto de conexión de origen de DMS para la réplica de lectura y establezca el nombre de la ranura de replicación lógica mediante el atributo de conexión adicional: ``` slotName=dms_read_replica_slot; ``` 1. Cree e inicie la tarea CDC/FL\$1CDC. **nota** En el caso de las migraciones CDC/FL\$1CDC, DMS considera la hora de inicio de la tarea como la posición de inicio de la CDC. Se ignoran todas las ranuras LSNs de replicación antiguas. ### Migración de una base de datos de Amazon RDS para PostgreSQL sin usar la cuenta de usuario principal En algunos casos, es posible que no utilice la cuenta de usuario principal para la instancia de base de datos de Amazon RDS PostgreSQL que está utilizando como origen. En estos casos, se crean varios objetos para capturar los 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. 1. Inicie sesión en la instancia de base de datos de PostgreSQL con una cuenta de usuario distinta de la cuenta maestra, aquí la cuenta de `OtherThanMaster`. 1. 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 ); ``` 1. 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; $$; ``` 1. Cierre sesión en la cuenta `OtherThanMaster` e inicie sesión con una cuenta que tenga el rol `rds_superuser` asignado. 1. 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(); ``` 1. Asegúrese de que todos los usuarios y roles que acceden 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; ``` 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`. ## Habilitación de la captura de datos de cambios (CDC) mediante replicación lógica Puede utilizar la característica 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 orígenes de PostgreSQL. Puede utilizar esta característica con una instancia de base de datos SQL de PostgreSQL autoadministrada y también con una instancia de base de datos SQL de Amazon RDS para PostgreSQL. Este enfoque reduce el tiempo de inactividad y le ayuda a asegurar que la base de datos de destino esté sincronizada con la base de datos de PostgreSQL de origen. AWS DMS admite tablas CDC para PostgreSQL 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, DMS no 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 al utilizar una base de datos de PostgreSQL como origen de DMS](#CHAP_Source.PostgreSQL.Advanced). **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 de pglogical](https://github.com/2ndQuadrant/pglogical#primary-key-or-replica-identity-required). Para tareas de carga completa y solo para CDC y CDC, AWS DMS utiliza ranuras de replicación lógica para conservar los registros de WAL para la replicación hasta que se decodifiquen. Cuando se reinicia (no se reanuda) durante una tarea de carga completa y 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\$1decocoding o pglogical. Si el complemento pglogical está disponible en una base de datos de PostgreSQL de origen, DMS crea una ranura de replicación con pglogical, de lo contrario se utiliza un complemento test\$1decoding. Para obtener más información acerca del complemento test\$1decoding, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/9.4/test-decoding.html). 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 el tamaño `restart_lsn` de la ranura de replicación es inferior al LSN actual, la tarea de DMS no se realizará correctamente 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 y modelo de replicación lógica para la replicación selectiva de datos. La siguiente tabla identifica las versiones de base de datos PostgreSQL de origen que admiten el complemento pglogical. | Origen de PostgreSQL | Admite pglogical | | --- | --- | | PostgreSQL 9.4 o superiores autoadministrado | Sí | | Amazon RDS PostgreSQL 9.5 o versiones anteriores | No | | Amazon RDS PostgreSQL 9.6 o versiones superiores | Sí | | Aurora PostgreSQL 1.x hasta 2.5.x | No | | Aurora PostgreSQL 2.6.x o versiones superiores | Sí | | Aurora PostgreSQL 3.3.x o versiones superiores | Sí | Antes de configurar pglogical para su uso con AWS DMS, active primero la replicación lógica para la captura de datos de cambios (CDC) en la base de datos de origen de PostgreSQL. + Para obtener información sobre cómo habilitar la replicación lógica para CDC en bases de datos de origen PostgreSQL *autoadministradas*, consulte [Permitir a los CDC utilizar una base de datos PostgreSQL autogestionada como fuente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) + Para obtener información sobre cómo habilitar la replicación lógica para CDC en bases de datos de origen PostgreSQL *administradas por AWS*, consulte [Habilitar CDC con una instancia de base AWS de datos PostgreSQL administrada con AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC). Una vez habilitada la replicación lógica en la base de datos de origen PostgreSQL, 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 PostgreSQL con AWS DMS** 1. Cree una extensión pglogical en la base de datos PostgreSQL de origen: 1. Establezca el parámetro correcto: + Para las bases de datos PostgreSQL autoadministradas, establezca el parámetro `shared_preload_libraries= 'pglogical'` de la base de datos. + Para las bases de datos PostgreSQL en Amazon RDS y Amazon Aurora PostgreSQL-Compatible Edition, establezca el parámetro `shared_preload_libraries` en `pglogical` en el mismo grupo de parámetros de RDS. 1. Reinicie la base de datos de origen de PostgreSQL. 1. En la base de datos PostgreSQL, ejecute el comando, `create extension pglogical;` 1. 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 de origen de PostgreSQL. **nota** Si no habilita pglogical en la base de datos de origen de PostgreSQL, AWS DMS utiliza el complemento `test_decoding` de forma predeterminada. Cuando pglogical está activado para la decodificación lógica, AWS DMS utiliza pglogical de forma predeterminada. Pero puede configurar el atributo de conexión adicional `PluginName` para usar el complemento `test_decoding` en su lugar. ## Uso de puntos de inicio de CDC nativo para configurar una carga de CDC de un origen de PostgreSQL Para habilitar puntos de inicio de CDC nativos con PostgreSQL como origen, establezca el atributo de conexión adicional `slotName` en el nombre de una ranura de replicación lógica existente al crear el punto de conexión. 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 establecer alarmas de uso de espacio en la instancia de PostgreSQL de origen cuando se utilizan 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 punto final y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como fuente de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib). 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 tenga 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`. 1. 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; ``` 1. Cree una nueva tarea exclusiva para los CDC mediante la consola o la API. AWS CLI AWS DMS Por ejemplo, puede usar la CLI para ejecutar el siguiente comando `create-replication-task`. ``` 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](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint.Native). Para activar el modo de inicio personalizado de los CDC al crear una nueva tarea exclusiva para los CDC mediante la AWS DMS consola, haga lo siguiente: + En la sección **Configuración de tareas**, para el **modo de inicio de CDC para las transacciones de origen**, elija **Habilitar el modo de inicio de CDC personalizado**. + Para el **punto de inicio personalizado de CDC 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 tarea de CDC, 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 partida nativos de CDC 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. **Uso de 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'); ``` 1. Una vez que la base de datos crea la ranura de replicación, obtenga y anote los valores **restart\$1lsn** y **confirmed\$1flush\$1lsn** de la ranura: ``` select * from pg_replication_slots where slot_name like 'replication_slot_name'; ``` Tenga en cuenta que la posición de inicio nativa de CDC para una tarea de CDC creada después de la ranura de replicación no puede ser anterior al valor **confirmed\$1flush\$1lsn**. Para obtener información sobre los valores **restart\$1lsn** y **confirmed\$1flush\$1lsn**, consulte [pg\$1replication\$1slots](https://www.postgresql.org/docs/14/view-pg-replication-slots.html) 1. Cree un nodo pglogical. ``` SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name'); ``` 1. 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); ``` 1. 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); ``` 1. Establezca el atributo de conexión adicional (ECA) que se muestra a continuación al crear el punto de conexión de origen. ``` PluginName=PGLOGICAL;slotName=slot_name; ``` Ahora puede crear una tarea exclusiva de CDC con un punto de partida nativo de PostgreSQL mediante 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](https://www.enterprisedb.com/docs/pgd/3.7/pglogical/) ## Migración de PostgreSQL a PostgreSQL mediante AWS DMS Cuando se migra de un motor de base de datos distinto de PostgreSQL a una base de datos PostgreSQL AWS DMS , casi siempre es la mejor herramienta de migración que se puede utilizar. Pero cuando migre 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 como `pg_dump` si 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\$1dump 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\$1dump 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 va a migrar datos de una base de datos de origen de PostgreSQL que se ejecuta en EC2 a un destino de Amazon RDS para PostgreSQL, puede utilizar el complemento pglogical. Para obtener más información sobre la importación de una base de datos de PostgreSQL en Amazon RDS para PostgreSQL o Amazon Aurora PostgreSQL-Compatible Edition, consulte [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html). ### Uso de DMS para migrar datos de PostgreSQL a PostgreSQL AWS DMS puede migrar datos, por ejemplo, de una base de datos PostgreSQL de origen local 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 un origen de PostgreSQL a un destino de PostgreSQL, no es necesario que mencione la tabla principal como parte de los criterios de selección en la tarea de 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 y JSON, se pueden migrar correctamente como archivos pequeños, pero se puede producir un error si los documentos son grandes. Cuando realice la migración de un tipo de datos, tenga en cuenta lo siguiente: + En algunos casos, el tipo de datos NUMERIC(p,s) de PostgreSQL no especifica ninguna precisión ni escala. Para las versiones 3.4.2 y anteriores de DMS, DMS usa una precisión de 28 y una escala de 6 de forma predeterminada, NUMERIC(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 de MATRIZ debe contar con una clave principal. Una tabla con un tipo de datos de MATRIZ 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 migra | Comentarios | | --- | --- | --- | --- | --- | | INTEGER | X | | | | | SMALLINT | X | | | | | BIGINT | X | | | | | NUMERIC/DECIMAL(p,s) | | X | | Donde 038 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. | | MARCA DE TIEMPO CON ZONA HORARIA | | X | | | | DATE | X | | | | | TIME | X | | | | | HORA CON ZONA HORARIA | 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 PostGIS esté habilitado en el 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 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 ## Migración de Babelfish a Amazon Aurora PostgreSQL mediante AWS DMS Puede migrar las tablas fuente de PostgreSQL de Babelfish para Aurora a cualquier punto final de destino compatible utilizando. AWS DMS Al crear el punto de enlace de AWS DMS origen mediante la consola de DMS, la API o los comandos CLI, establece el origen en **Amazon Aurora PostgreSQL** y el nombre de la base de datos en. **babelfish\$1db** En la sección **Endpoint Settings**, asegúrese de que **DatabaseMode**esté establecido en **Babelfish** y en el nombre de la base de datos **BabelfishDatabaseName**T-SQL Babelfish de origen. En lugar de usar el puerto TCP de Babelfish **1433**, utilice el puerto TCP de Aurora PostgreSQL **5432**. Debe crear las tablas antes de migrar los datos para asegurarse de que DMS utiliza 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 posible que DNS 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 un origen de Babelfish, debe incluir reglas de transformación que garanticen que DMS utilice las tablas de destino creadas previamente. Si configuró el modo de migración de bases de datos múltiples al definir el clúster de Babelfish para PostgreSQL, agregue una regla de transformación que cambie el nombre del esquema al del esquema de T-SQL. Por ejemplo, si el nombre del esquema de T-SQL es `dbo` y el nombre del esquema de Babelfish para PostgreSQL es `mydb_dbo`, cambie el nombre del esquema a `dbo` mediante una regla de transformación. Para encontrar el nombre del esquema de PostgreSQL, consulte [Arquitectura de Babelfish](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/babelfish-architecture.html) en la *Guía del usuario de Amazon Aurora*. Si utiliza el modo de base de datos única, no necesita una regla de transformación para cambiar el nombre de los esquemas de base de datos. Los nombres de los esquemas de PostgreSQL tienen one-to-one un mapeo con los nombres de los esquemas de la base de datos de T-SQL. El siguiente ejemplo de regla de transformación muestra cómo volver a cambiar el nombre del esquema de `mydb_dbo` 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": [] } ] } ``` ### Restricciones en el uso de un punto de conexión de origen de PostgreSQL con tablas de Babelfish Las siguientes restricciones se aplican al usar un punto de conexión de origen de PostgreSQL con tablas de Babelfish: + DMS solo 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 de DMS. + DMS no replica los cambios de la definición de tabla de Babelfish en el punto de conexión de destino. Una solución para esta limitación consiste en aplicar primero los cambios de la definición de tabla en el destino y, a continuación, cambiar la definición de la tabla en el origen de Babelfish. + Al crear tablas de Babelfish con el tipo de datos BYTEA, DMS las convierte al tipo de datos `varbinary(max)` al migrar a SQL Server como destino. + DMS no admite el modo de LOB completo para los tipos de datos binarios. En su lugar, utilice el modo de LOB limitado para los tipos de datos binarios. + DMS no admite la validación de datos de Babelfish como origen. + Para la configuración de la tarea **Modo de preparación de la tabla de destino** utilice solo los modos **No hacer nada** o **Truncar**. No utilice el modo **Borrar tablas en el destino**. Al utilizar **Descartar las tablas en el destino**, DMS puede crear las tablas con tipos de datos incorrectos. + Cuando utilice la replicación continua (CDC o Carga completa y CDC), establezca el atributo de conexión adicional `PluginName` en `TEST_DECODING`. + DMS no admite la replicación (CDC o Carga completa y CDC) de tablas particionadas para Babelfish como origen. ## Eliminar AWS DMS artefactos de una base de datos fuente de PostgreSQL Para capturar eventos de DDL, AWS DMS crea varios artefactos en la base de datos de PostgreSQL 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 desencadenador 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 al utilizar una base de datos de PostgreSQL como origen 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 punto final y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como fuente de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib). + Puede anular parámetros de cadenas de conexión. Elija esta opción para hacer cualquiera de las siguientes acciones: + Especifique los parámetros internos. AWS DMS 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 en las versiones 9.4 y posteriores de `REPLICA IDENTITY` PostgreSQL, 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 FULL`registra 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 [ALTER TABLE-REPLICA IDENTITY](https://www.postgresql.org/docs/devel/sql-altertable.html) ## Réplica de lectura como origen para PostgreSQL Utilice réplicas de lectura de PostgreSQL como fuentes de CDC para reducir la carga de la base de datos AWS DMS principal. Esta función está disponible en PostgreSQL 16.x y AWS DMS requiere la versión 3.6.1 o posterior. El uso de réplicas de lectura para el procesamiento de la CDC reduce el impacto operativo en la base de datos principal. **nota** La versión 16.x de Amazon RDS para PostgreSQL presenta limitaciones para la replicación lógica de réplicas de lectura en las configuraciones de tres zonas de disponibilidad (TAZ). Para obtener compatibilidad total con la replicación lógica de réplicas de lectura en las implementaciones de TAZ, debe usar PostgreSQL 17.x o posterior. ### Requisitos previos Antes de utilizar una réplica de lectura como fuente de CDC AWS DMS, debe habilitar la replicación lógica tanto en la instancia de base de datos principal como en su réplica de lectura para crear una decodificación lógica en una réplica de lectura. Lleve a cabo las siguientes acciones: + Active la replicación lógica tanto en la instancia de base de datos principal como en su réplica de lectura, junto con cualquier otro parámetro de base de datos necesario. Para obtener más información, consulte [Trabajar con bases de datos PostgreSQL AWS administradas](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.RDSPostgreSQL) como fuente de DMS. + Para las tareas exclusivas de la CDC, cree una ranura de replicación en la instancia principal (de escritura). Para obtener más información, consulte [Uso de puntos de inicio de CDC nativa para configurar una carga de CDC de un origen de PostgreSQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10). Esta acción es necesaria, ya que las réplicas de lectura no admiten la creación de ranuras de replicación. + Para la versión 16 de PostgreSQL, la ranura debe crearse manualmente en la réplica de lectura. + Para la versión 17 y posteriores de PostgreSQL, la ranura de replicación debe crearse en la principal y se sincroniza automáticamente con la réplica de lectura. + Al utilizar tareas a plena carga o solo con CDC, AWS DMS puede gestionar automáticamente los intervalos de replicación lógica en las instancias principales, pero no en las réplicas de lectura. Para las réplicas de lectura de PostgreSQL versión 16, debe eliminar y volver a crear manualmente las ranuras de replicación antes de reiniciar una tarea (no reanudarla). Omitir este paso puede provocar errores en las tareas o posiciones de inicio de la CDC incorrectas. A partir de la versión 17 de PostgreSQL, la sincronización de ranuras lógicas desde la instancia principal automatiza este proceso. Tras cumplir los requisitos previos, puede configurar su terminal de origen replicando la AWS DMS fuente `SlotName` de lectura y réplica en la configuración del terminal y configurar su AWS DMS tarea utilizando los puntos de partida nativos de los CDC. Para obtener más información, consulte [Configuración de puntos de conexión y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como fuente de DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.ConnectionAttrib) [y Uso de puntos de inicio nativos de CDC para configurar una carga de CDC de una fuente de](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) PostgreSQL. ## Uso de la configuración del punto de conexión `MapBooleanAsBoolean` de PostgreSQL Puede usar la configuración del punto de conexión de PostgreSQL para asignar un booleano como booleano desde el origen de PostgreSQL a un destino de Amazon Redshift. De forma predeterminada, un tipo BOOLEANO se migra como varchar(5). Puede especificar `MapBooleanAsBoolean` para permitir que PostgreSQL migre 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 MySQL no tiene ningún tipo BOOLEANO, utilice una regla de transformación en lugar de esta configuración al migrar datos BOOLEANOS a MySQL. ## Configuración de punto final y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como fuente de DMS Puede utilizar la configuración del punto final y los atributos de conexión adicionales (ECAs) para configurar la base de datos fuente de PostgreSQL. Los ajustes de punto final se especifican al crear el punto final de origen mediante la AWS DMS consola o mediante el `create-endpoint` comando de [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintaxis `--postgre-sql-settings '{"EndpointSetting": "value", ...}'` JSON. En la siguiente tabla se muestran los ajustes de punto final ECAs que puede utilizar con PostgreSQL como fuente. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Source.PostgreSQL.html) ## Restricciones en el uso de una base de datos de PostgreSQL como origen de DMS Al utilizar PostgreSQL como origen para AWS DMS se aplican las siguientes restricciones: + AWS DMS no funciona con Amazon RDS para PostgreSQL 10.4 ni con 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 tiene una clave principal, AWS DMS ignora las operaciones de eliminación y actualización de registros de esa tabla. Como solución alternativa, consulte [Habilitación de la captura de datos de cambios (CDC) mediante replicación lógica](#CHAP_Source.PostgreSQL.Security). **Nota:** No recomendamos migrar sin un Key/Unique índice principal; de lo contrario, se aplicarán limitaciones adicionales, como la capacidad de aplicación por lotes «NO», la capacidad de LOB 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 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 **Iniciar los cambios del proceso desde la ejecución de la marca de tiempo**. + AWS DMS no replica los cambios que resulten 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 cambios de las instrucciones DDL CREATE, ALTER y DROP para tablas. AWS DMS no admite este procesamiento de cambios si las tablas se encuentran en un bloque interno del cuerpo de una función o procedimiento 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, los tipos de datos `boolean` de un origen de PostgreSQL se migran a un destino de SQL Server como tipo de datos `bit` 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 operaciones TRUNCATE. + El tipo de datos de LOB OID no se migra al destino. + AWS DMS admite el tipo de datos PostGIS solo para migraciones homogéneas. + Si el origen es una base de datos de PostgreSQL en las instalaciones o una instancia de Amazon EC2, asegúrese de que el complemento de salida test\$1decoding esté instalado en el punto de conexión de origen. Puede encontrar este complemento en el paquete contrib de PostgreSQL. Para obtener más información acerca del complemento test-decoding consulte la [ documentación de PostgreSQL](https://www.postgresql.org/docs/10/static/test-decoding.html). + AWS DMS no admite el procesamiento de cambios para establecer y desconfigurar los valores predeterminados de las columnas (mediante la cláusula ALTER COLUMN SET DEFAULT en las sentencias ALTER TABLE). + AWS DMS no admite el procesamiento de cambios para establecer la nulabilidad de las columnas (se utiliza la cláusula ALTER COLUMN [SET\$1DROP] NOT NULL en las sentencias ALTER TABLE). + 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 las versiones 13 y posteriores de Aurora PostgreSQL, puede ajustar el parámetro `logical_decoding_work_mem` para controlar cuándo vuelca DMS los datos de cambios en el disco. Para obtener más información, consulte [Archivos de volcado en Aurora PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill). + Una tabla con un tipo de datos de MATRIZ debe contar con una clave principal. Una tabla con un tipo de datos de MATRIZ a la que le falta una clave principal se suspende durante la carga completa. + AWS DMS [no admite la migración de metadatos de tablas relacionados con la partición o la herencia de tablas.](https://www.postgresql.org/docs/15/ddl-inherit.html) Cuando AWS DMS encuentra una tabla particionada o una tabla que utiliza la herencia, se observa el siguiente comportamiento: + AWS DMS identifica e informa de las tablas principales y secundarias que participan en la partición o la herencia en la base de datos de origen. + **Creación de tablas en la base de datos de destino**: en la base de datos de destino, AWS DMS crea la tabla como una tabla estándar (no particionada ni heredada), conservando la estructura y las propiedades de las tablas seleccionadas, pero no la lógica de partición o herencia. + **Diferenciación de registros en tablas heredadas**: en el caso de las tablas que utilizan la herencia, AWS DMS no distingue los registros que pertenecen a las tablas secundarias al rellenar la tabla principal. Como resultado, no utiliza consultas SQL con sintaxis como: `SELECT * FROM ONLY parent_table_name`. + Para replicar tablas con particiones desde un origen de PostgreSQL a un destino de PostgreSQL, primero debe crear 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 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 DMS admite Aurora PostgreSQL Serverless V1 como fuente únicamente para tareas de carga completa. AWS DMS admite Aurora PostgreSQL Serverless V2 como fuente para tareas de carga completa, carga completa, CDC y únicamente CDC. + AWS DMS no admite la replicación de una tabla con un índice único creado con una función de fusión. + Si la definición de la clave principal en el origen y el destino no coinciden, los resultados de la replicación pueden ser 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](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad) + AWS DMS no admite restricciones diferidas. + AWS DMS La versión 3.4.7 admite PostgreSQL 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 prolongadas en curso. + AWS DMS no admite CDC para Amazon RDS Proxy para PostgreSQL como fuente. + Si se utilizan [filtros de origen](CHAP_Tasks.CustomizingTasks.Filters.md) 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 cambios de DDL no se migren durante 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 la replicación de los cambios realizados en las definiciones de las claves principales de la base de datos de origen. Si la estructura de clave principal se modifica durante una tarea de replicación activa, los cambios posteriores en las tablas afectadas no se replican en la de destino. + En la replicación DDL como parte de un script, el número total máximo de comandos DDL por script es de 8192 y el número total máximo de líneas por script es de 8192 líneas. + AWS DMS no admite vistas materializadas. + Para tareas de carga completa y de CDC que utilizan una réplica de lectura como fuente, AWS DMS no se pueden crear ranuras de replicación en las réplicas de lectura. ## Tipos de datos de origen para PostgreSQL En la siguiente tabla se muestran los tipos de datos de origen de PostgreSQL que se admiten cuando se AWS DMS utiliza y la asignación AWS DMS predeterminada a los tipos de datos. 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](CHAP_Reference.DataTypes.md) | 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 | | DOBLE | 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 | | CITEXT | NCLOB | | BYTEA | BLOB | | TIMESTAMP | DATETIME | | MARCA DE TIEMPO CON ZONA HORARIA | DATETIME | | DATE | DATE | | TIME | TIME | | HORA CON ZONA HORARIA | TIME | | INTERVAL | STRING (128): 1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS | | 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 | 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 | | INT4RANGO | STRING (255) | | INT8ALCANCE | STRING (255) | | NUMRANGE | STRING (255) | | STRRANGE | STRING (255) | ### Trabajo con tipos de datos de origen de 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: establezca **Limitar tamaño de LOB a** en el valor **Tamaño máximo de LOB (KB)** al crear la tarea. + CLOB: la replicación trata a cada personaje como 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 tamaño de 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 gestiona cada carácter como carácter de dos bytes. Por lo tanto, busque la longitud del texto con más caracteres en la columna (`max_num_chars_text`) y multiplíquela por 2. Hace esto para especificar el valor de **Limitar el tamaño de 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.