Uso de una base de datos de PostgreSQL como destino para AWS Database Migration Service

Puede migrar datos a bases de datos de PostgreSQL utilizandoAWS DMS, ya sea desde otra base de datos de PostgreSQL o desde una de las otras bases de datos compatibles. AWS DMSadmite una base de datos PostgreSQL de las versiones 9.4 y posteriores (para las versiones 9.x), 10.x, 11.x, 12.x, 13.x y 14.x como destino para estos tipos de bases de datos:

• Bases de datos locales

• Bases de datos en una instancia EC2

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

• Bases de datos en una instancia de base de datos de Amazon Aurora con compatibilidad con PostgreSQL

nota

• PostgreSQL 14.x requiere la versiónAWS DMS 3.4.7 y versiones posteriores.

• Amazon Aurora Serverless está disponible como destino para Amazon Aurora Serverless está disponible como destino para Amazon Aurora Serverless. Para obtener más información sobre Amazon Aurora Serverless, consulte la Guía del usuario de Amazon Aurora.

• Los clústeres de base de datos de Aurora Serverless son accesibles desde una Amazon VPC y no pueden usar una dirección IP pública. Por lo tanto, si tiene la intención de tener una instancia de replicación en una región diferente a la de Aurora PostgreSQL Serverless, debe configurar el emparejamiento de vpc. De lo contrario, compruebe la disponibilidad de las regiones de Aurora PostgreSQL Serverless y decida utilizar una de esas regiones tanto para Aurora PostgreSQL Serverless como para su instancia de replicación.

• La funcionalidad de Babelfish está integrada en Amazon Aurora y no tiene ningún coste adicional. Para obtener más información, consulte uso de Babelfish para Aurora PostgreSQLAWS Database Migration Service.

AWS DMSadopta un table-by-table enfoque al migrar datos del origen al destino en la fase de carga completa. No es posible garantizar el orden de la tabla durante la fase de carga completa. Las tablas no estarán sincronizadas durante la fase de carga completa y mientras se estén aplicando transacciones almacenadas en la caché para tablas individuales. Como resultado, las limitaciones de integridad referencial activas puede derivar en errores de tareas durante la fase de carga completa.

En PostgreSQL, se implementan claves externas (límites de integridad referencial) mediante disparadores. Durante la fase de carga completa, AWS DMS carga cada tabla de una en una. Recomendamos encarecidamente que deshabilite las restricciones de clave externa durante una carga completa, utilizando uno de los siguientes métodos:

• Deshabilite temporalmente todos los disparadores de la instancia y finalice la carga completa.

• Utilice el parámetro session_replication_role en PostgreSQL.

En cualquier momento, un disparador puede estar en uno de los siguientes estados: origin, replica, always o bien disabled. Cuando se establece el parámetro session_replication_role en replica, solo los disparadores con el estado replica estarán activos y se disparan cuando se llaman. De lo contrario, los disparadores permanecen inactivos.

PostgreSQL tiene un mecanismo a prueba de errores para evitar que se trunque una tabla, incluso cuando se ha establecido session_replication_role. Puede utilizar esto como una alternativa a la inhabilitación de disparadores para ayudar a que la carga completa se ejecute hasta su finalización. Para ello, establezca el modo de preparación de la tabla de destino en DO_NOTHING. De lo contrario, las operaciones DROP y TRUNCATE fallan cuando hay limitaciones de clave externa.

En Amazon RDS, puede controlar la configuración de este parámetro mediante un grupo de parámetros. Para una instancia de PostgreSQL que se ejecuta en Amazon EC2, puede configurar el parámetro directamente.

Para obtener más información sobre cómo trabajar con las bases de datos de PostgreSQL como destino para AWS DMS, consulte las secciones siguientes:

Restricciones al uso de PostgreSQL como destino para AWS Database Migration Service

Cuando se utiliza una base de datos de PostgreSQL como destino para AWS DMS, se aplican las siguientes restricciones:

• Para migraciones heterogéneas, el tipo de datos JSON se convierte internamente en el tipo de datos CLOB nativo.

• En una migración de Oracle a PostgreSQL, si una columna de Oracle contiene un carácter NULL (valor hexadecimal U+0000), AWS DMS convierte dicho carácter en un espacio (valor hexadecimal U+0020). Esto se debe a una restricción de PostgreSQL.

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

Requisitos de seguridad al utilizar una base de datos de PostgreSQL como destino para AWS Database Migration Service

Por motivos de seguridad, la cuenta de usuario utilizada para la migración de datos debe ser un usuario registrado en cualquier base de datos de PostgreSQL que utilice como destino.

Su punto de enlace de destino de PostgreSQL requiere permisos de usuario mínimos para ejecutar unaAWS DMS migración; consulte los siguientes ejemplos.

    CREATE USER newuser WITH PASSWORD 'your-password';
    ALTER SCHEMA schema_name OWNER TO newuser;
            

O bien,

    GRANT USAGE ON SCHEMA schema_name TO myuser;
    GRANT CONNECT ON DATABASE postgres to myuser;
    GRANT CREATE ON DATABASE postgres TO myuser;
    GRANT CREATE ON SCHEMA schema_name TO myuser;
    GRANT UPDATE, INSERT, SELECT, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA schema_name TO myuser;
    GRANT TRUNCATE ON schema_name."BasicFeed" TO myuser;
            

Configuración de endpoint cuando se usa PostgreSQL como destino paraAWS DMS

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

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

Nombre	Descripción
MaxFileSize	Especifica el tamaño máximo (en KB) de cualquier archivo .csv que se utilice para transferir datos a PostgreSQL. Valor predeterminado: 32768 KB (32 MB) Valores válidos: 1 048 576 KB (hasta 1,1 GB) Ejemplo: --postgre-sql-settings '{"MaxFileSize": 512}'
ExecuteTimeout	Establece el tiempo de espera de las instrucciones del cliente para la instancia de PostgreSQL, en segundos. El valor de predeterminado es de 60 segundos. Ejemplo: --postgre-sql-settings '{"ExecuteTimeout": 100}'
AfterConnectScript: SET session_replication_role: 'replica'	Para usar solo con captura de datos de cambio (CDC), este atributo tiene claves externas de bypass de AWS DMS y desencadenadores de usuario para reducir el tiempo que se tarda en cargar los datos en masa. nota Este atributo solo es efectivo en el modo de captura de datos de cambio.
MapUnboundedNumericAsString	Este parámetro trata las columnas con tipos de datos NUMÉRICOS ilimitados como STRING para poder migrar correctamente sin perder la precisión del valor numérico. Utilice este parámetro solo para la replicación desde el origen de PostgreSQL al destino de PostgreSQL o para bases de datos compatibles con PostgreSQL. Valor predeterminado: false Valores válidos: falso/verdadero Ejemplo: --postgre-sql-settings '{"MapUnboundedNumericAsString": "true"} El uso de este parámetro puede provocar cierta degradación del rendimiento de la replicación debido a la transformación de numérico a cadena y de nuevo a numérico. La versión 3.4.4 y superior de DMS admite el uso de este parámetro nota Úselo soloMapUnboundedNumericAsString en los extremos de origen y destino de PostgreSQL juntos. MapUnboundedNumericAsStringEl uso de puntos de conexión de PostgreSQL en el código fuente restringe la precisión a 28 durante la CDC. El uso de puntos finalesMapUnboundedNumericAsString en los puntos finales de destino migra los datos con Precision 28 Scale 6. No lo utiliceMapUnboundedNumericAsString con objetivos que no sean de PostgreSQL.

Tipos de datos de destino para PostgreSQL

El punto de enlace de la base de datos de PostgreSQL para AWS DMS admite la mayoría de los tipos de datos de la base de datos de PostgreSQL. La siguiente tabla muestra los tipos de datos de destino de la base de datos de PostgreSQL que se admiten cuando se utiliza AWS DMS y la asignación predeterminada desde los tipos de datos de AWS DMS.

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

Tipos de datos de AWS DMS	Tipos de datos de PostgreSQL
BOOLEANO	BOOLEANO
BLOB	BYTEA
BYTES	BYTEA
DATE	DATE
TIME	TIME
DATETIME	Si la escala es de 0 a 6, utilice TIMESTAMP. Si la escala es de 7 a 9, utilice VARCHAR (37).
INT1	SMALLINT
INT2	SMALLINT
INT4	INTEGER
INT8	BIGINT
NUMERIC	DECIMAL (P,S)
REAL4	FLOAT4
REAL8	FLOAT8
STRING	Si la longitud es de 1 a 21 845, utilice VARCHAR (longitud en bytes). Si la longitud es de 21 846 a 2 147 483 647, utilice VARCHAR (65535).
UINT1	SMALLINT
UINT2	INTEGER
UINT4	BIGINT
UINT8	BIGINT
WSTRING	Si la longitud es de 1 a 21 845, utilice VARCHAR (longitud en bytes). Si la longitud es de 21 846 a 2 147 483 647, utilice VARCHAR (65535).
NCLOB	TEXT
CLOB	TEXT

nota

Cuando se replica desde un origen de PostgreSQL, AWS DMS crea la tabla de destino con los mismos tipos de datos para todas las columnas, además de las columnas con los tipos de datos definidos por el usuario. En estos casos, el tipo de datos se crea como de "caracteres variables" en el destino.

Uso de Babelfish para Aurora PostgreSQLAWS Database Migration Service

Puede migrar las tablas fuente de SQL Server a un destino de Babelfish para Amazon Aurora PostgreSQL medianteAWS Database Migration Service. Con Babelfish, Aurora PostgreSQL entiende T-SQL, el dialecto SQL patentado de Microsoft SQL Server, y admite el mismo protocolo de comunicaciones. Por lo tanto, las aplicaciones escritas para SQL Server ahora pueden funcionar con Aurora con menos cambios de código. La funcionalidad de Babelfish está integrada en Amazon Aurora y no tiene ningún coste adicional. Puede activar Babelfish en su clúster de Amazon Aurora desde la consola de Amazon RDS.

Al crear el endpoint deAWS DMS destino mediante los comandos deAWS DMS consola, API o CLI, especifique el motor de destino como Amazon Aurora PostgreSQL y asigne a la base de datos el nombre babelfish_db.

Añadir reglas de transformación a la tarea de migración

Al definir una tarea de migración para un destino de Babelfish, debe incluir reglas de transformación que garanticen que DMS utilice las tablas de Babelfish de T-SQL previamente creadas en la base de datos de destino.

Primero, añada una regla de transformación a la tarea de migración que ponga todos los nombres de las tablas en minúsculas. Babelfish almacena en minúsculas en elpg_class catálogo de PostgreSQL los nombres de las tablas que se crean con T-SQL. Sin embargo, cuando tiene tablas de SQL Server con nombres que combinan mayúsculas y minúsculas, DMS las crea utilizando los tipos de datos nativos de PostgreSQL en lugar de los tipos de datos compatibles con T-SQL. Por ese motivo, asegúrese de añadir una regla de transformación que ponga todos los nombres de las tablas en minúsculas.

A continuación, si utilizó el modo de migración de múltiples bases de datos al definir el clúster, añada una regla de transformación que cambie el nombre del esquema de SQL Server original. Asegúrese de cambiar el nombre del esquema de SQL Server para incluir el nombre de la base de datos T-SQL. Por ejemplo, si el nombre del esquema de SQL Server original esdbo, y el nombre de la base de datos de T-SQL esmydb, cambie el nombre del esquema para quemydb_dbo utilice una regla de transformación.

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

La siguiente regla de transformación de ejemplo convierte todos los nombres de las tablas en minúsculas y cambia el nombre del esquema de SQL Server original dedbo amydb_dbo.

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

Limitaciones al uso de un punto final de destino de PostgreSQL con tablas de Babelfish

Se aplican las siguientes limitaciones cuando se utiliza un punto de enlace de destino de PostgreSQL con tablas de Babelfish:

• Para el modo de preparación de la tabla Target, utilice únicamente los modos No hacer nada o Truncar. No utilices las tablas desplegables en el modo objetivo. En ese modo, DMS crea las tablas como tablas de PostgreSQL que es posible que T-SQL no reconozca.

• Babelfish solo admite la migraciónBINARY yIMAGE los tipos de datos con Aurora PostgreSQL versión 14.3 y versiones posteriores, utilizando el tipo deBTYEA datos.VARBINARY Para versiones anteriores de Aurora PostgreSQL, puede usar DMS para migrar estas tablas a un endpoint de destino de Babelfish. No es necesario especificar una longitud para el tipo deBYTEA datos, como se muestra en el ejemplo siguiente.

      [Picture] [VARBINARY](max) NULL

  Lo anterior pasa a ser lo siguiente.

      [Picture] BYTEA NULL

• Si crea una tarea de migración para la replicación continua de SQL Server a Babelfish mediante el punto final de PostgreSQL, debe asignar el tipo deSERIAL datos a cualquier tabla que utiliceIDENTITY columnas. Para obtener más información, consulte el uso de SERIAL en la sección Secuencias e identidad del manual de migración de SQL Server a Aurora PostgreSQL. Luego, cuando crees la tabla en Babelfish, cambia la definición de columna de la siguiente manera.

      [IDCol] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY

  Cambie lo anterior por lo siguiente.

      [IDCol] SERIAL PRIMARY KEY

  Aurora PostgreSQL, compatible con Babelfish, crea una secuencia con la configuración predeterminada y añade unaNOT NULL restricción a la columna. La secuencia recién creada se comporta como una secuencia normal (incrementada en 1) y no tiene ningunaSERIAL opción compuesta.

• Tras migrar datos con tablas que utilizanIDENTITY columnas o el tipo deSERIAL datos, restablezca el objeto de secuencia basado en PostgreSQL en función del valor máximo de la columna. Tras realizar una carga completa de tablas, utilice la siguiente consulta TSQL para iniciar el objeto de secuencia asociado.

  DECLARE @schema_prefix NVARCHAR(200) = ''
  
  IF current_setting('babelfishpg_tsql.migration_mode') = 'multi-db'
          SET @schema_prefix = db_name() + '_'
  
  SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name(tables.schema_id) + '.' + tables.name + ''', ''' + columns.name + ''')
                 ,(select max(' + columns.name + ') from ' + schema_name(tables.schema_id) + '.' + tables.name + '));'
  FROM sys.tables tables
  JOIN sys.columns columns ON tables.object_id = columns.object_id
  WHERE columns.is_identity = 1
  
  UNION ALL
  
  SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', 
  ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));'
  FROM information_schema.columns
  WHERE column_default LIKE 'nextval(%';
  

  La consulta genera una serie de instrucciones SELECT que puede ejecutar para actualizar los valores máximos de IDENTITY y SERIAL.

• En algunos casos, el modo LOB completo puede generar un error en la tabla. Si eso ocurre, cree una tarea independiente para las tablas que no se pudieron cargar. A continuación, utilice el modo LOB limitado para especificar el valor adecuado para el tamaño máximo de LOB (KB).

• Al realizar la validación de datos con tablas de Babelfish que no utilizan claves principales basadas en números enteros, se genera un mensaje de que no se ha encontrado una clave única adecuada.

• Debido a las diferencias de precisión en el número de decimales de los segundos, el DMS informa de errores de validación de datos en las tablas de Babelfish que utilizan tipos deDATETIME datos. Para eliminar esos errores, puede añadir el siguiente tipo de regla de validación paraDATETIME los tipos de datos.

  {
           "rule-type": "validation",
           "rule-id": "3",
           "rule-name": "3",
           "rule-target": "column",
           "object-locator": {
               "schema-name": "dbo",
               "table-name": "%",
               "column-name": "%",
               "data-type": "datetime"
           },
           "rule-action": "override-validation-function",
           "source-function": "case when ${column-name} is NULL then NULL else 0 end",
           "target-function": "case when ${column-name} is NULL then NULL else 0 end"
       }