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

Puede migrar datos a bases AWS DMS de datos PostgreSQL desde otra base de datos PostgreSQL o desde una de las otras bases de datos compatibles.

Para obtener información sobre las versiones de PostgreSQL AWS DMS compatibles como destino, consulte. Objetivos para AWS DMS

nota

• Amazon Aurora sin servidor está disponible como destino para Amazon Aurora con compatibilidad de PostgreSQL. Para obtener más información sobre Amazon Aurora sin servidor, consulte Uso de Aurora Serverless v2 en la Guía del usuario de Amazon Aurora.

• Los clústeres de base de datos de Aurora sin servidor solo son accesibles desde una Amazon VPC y no pueden usar una dirección IP pública. Por lo tanto, si pretende tener una instancia de replicación en una región diferente a la de Aurora PostgreSQL sin servidor, debe configurar la interconexión con VPC. De lo contrario, compruebe la disponibilidad de las regiones de Aurora PostgreSQL sin servidor y decida usar una de esas regiones para Aurora PostgreSQL sin servidor y para la instancia de replicación.

• La capacidad de Babelfish está integrada en Amazon Aurora y no tiene costo adicional. Para obtener más información, consulte Uso de Babelfish para Aurora PostgreSQL como destino para AWS Database Migration Service.

AWS DMS adopta un table-by-table enfoque al migrar los 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 establecer este parámetro mediante un grupo de parámetros. Para una instancia de PostgreSQL que se ejecute en EC2 Amazon, puede configurar el parámetro directamente.

Para obtener información adicional sobre cómo trabajar con una base de datos PostgreSQL como destino, consulte AWS DMS las siguientes secciones:

Limitaciones en el uso de PostgreSQL como objetivo 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 las migraciones heterogéneas, el tipo de datos JSON se convierte internamente al tipo de datos Native CLOB.

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

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

• Si las tablas utilizan secuencias, actualice el valor de cada secuencia NEXTVAL de la base de datos de destino después de detener la replicación desde la base de datos de origen. AWS DMS copia los datos de la base de datos de origen, pero no migra las secuencias al destino durante la replicación en curso.

Limitaciones del uso de Amazon Aurora PostgreSQL Limitless como objetivo para AWS Database Migration Service

Se aplican las siguientes limitaciones cuando se utiliza Amazon Aurora PostgreSQL Limitless como destino para: AWS DMS

• AWS DMS La validación de datos no es compatible con Amazon Aurora PostgreSQL Limitless.

• AWS DMS migra las tablas de origen como tablas estándar, que no están distribuidas. Tras la migración, puede convertir estas tablas estándar en tablas ilimitadas siguiendo la guía de conversión oficial.

Requisitos de seguridad al utilizar una base de datos 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 terminal de destino de PostgreSQL requiere permisos de usuario mínimos para ejecutar AWS DMS una 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 punto final y atributos de conexión adicionales (ECAs) cuando se utiliza PostgreSQL como destino para AWS DMS

Puede utilizar la configuración del punto final y los atributos de conexión adicionales (ECAs) para configurar la base de datos de destino de PostgreSQL.

Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el create-endpoint comando del AWS CLI, con la sintaxis --postgre-sql-settings '{"EndpointSetting": "value", ...}' JSON.

Se especifica ECAs mediante el ExtraConnectionAttributes parámetro de su punto final.

La siguiente tabla muestra la configuración de punto de conexión 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–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	Este atributo AWS DMS omite las claves externas y los activadores de usuario para reducir el tiempo que se tarda en cargar datos de forma masiva.
MapUnboundedNumericAsString	Este parámetro trata las columnas con tipos de datos NUMÉRICOS ilimitados como CADENA 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"} 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 superiores de DMS nota Use MapUnboundedNumericAsString solo en los puntos de conexión de origen y destino de PostgreSQL juntos. El uso de MapUnboundedNumericAsString en puntos de conexión de PostgreSQL de origen restringe la precisión a 28 durante 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 use MapUnboundedNumericAsString con destinos que no sean de PostgreSQL.
loadUsingCSV	Use este atributo de conexión adicional para transferir los datos de las operaciones de carga completa con el comando \COPY. Valor predeterminado: true Valores válidos: true/false Ejemplo de ECA: loadUsingCSV=true; Nota: Si se establece este ECA en falso, es posible que se reduzca en cierta medida el rendimiento de la replicación debido a INSERTs que se ejecuta directamente.
DatabaseMode	Utilice este atributo para cambiar el comportamiento predeterminado de la gestión de la replicación de los puntos de conexión compatibles con PostgreSQL que requieren alguna configuración adicional, como los puntos de conexión de Babelfish. Valor predeterminado: DEFAULT Valores válidos: DEFAULT, BABELFISH Ejemplo: DatabaseMode=default;
BabelfishDatabaseName	Utilice este atributo para especificar el nombre de la base de datos T-SQL Babelfish de destino a la que se va a migrar. Esto es obligatorio si DatabaseMode se establece en Babelfish. Esta no es la base de datos de babelfish_db reservada. Ejemplo: BabelfishDatabaseName=TargetDb;

Tipos de datos de destino para PostgreSQL

El punto final de la base de datos PostgreSQL AWS DMS es compatible con la mayoría de los tipos de datos de bases de datos PostgreSQL. La siguiente tabla muestra los tipos de datos de destino de las bases de datos PostgreSQL que se admiten cuando se AWS DMS utilizan y el mapeo AWS DMS predeterminado a partir de los tipos de datos.

Para obtener información adicional sobre AWS DMS los tipos de datos, consulte. Tipos de datos de AWS Database Migration Service

AWS DMS tipo de datos	Tipos de datos de PostgreSQL
BOOLEAN	BOOLEAN
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

Al replicar desde una fuente de PostgreSQL AWS DMS , crea la tabla de destino con los mismos tipos de datos para todas las columnas, excepto las columnas con 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 PostgreSQL como objetivo para AWS Database Migration Service

Puede migrar las tablas de origen de SQL Server a un destino de Babelfish para Amazon Aurora PostgreSQL mediante AWS Database Migration Service. Con Babelfish, Aurora PostgreSQL entiende T-SQL, el dialecto SQL patentado por 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 capacidad de Babelfish está integrada en Amazon Aurora y no tiene costo adicional. Puede activar Babelfish en el clúster de Amazon Aurora desde la consola de Amazon RDS.

Al crear el punto final de AWS DMS destino mediante los comandos de AWS 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. En la sección Configuración de punto de conexión, agregue ajustes para establecer DatabaseMode en Babelfish y BabelfishDatabaseName en el nombre de la base de datos de Babelfish T-SQL de destino.

Agregar 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 Babelfish de T-SQL creadas previamente en la base de datos de destino.

En primer lugar, agregue una regla de transformación a la tarea de migración que ponga todos los nombres de las tablas en minúsculas. Babelfish guarda en minúsculas en el catálogo pg_class de PostgreSQL los nombres de las tablas que se crean con T-SQL. Sin embargo, cuando tiene tablas de SQL Server con nombres en mayúsculas y minúsculas, DMS crea las tablas con los tipos de datos nativos de PostgreSQL en lugar de los tipos de datos compatibles con T-SQL. Por ese motivo, asegúrese de agregar una regla de transformación que ponga todos los nombres de las tablas en minúsculas. Tenga en cuenta que los nombres de las columnas no deben transformarse a minúsculas.

A continuación, si utilizó el modo de migración de bases de datos múltiples al definir el clúster, agregue una regla de transformación que cambie el nombre del esquema original de SQL Server. 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 es dbo y el nombre de la base de datos de T-SQL es mydb, cambie el nombre del esquema a mydb_dbo mediante una regla de transformación.

Si utiliza 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.

El siguiente ejemplo de regla de transformación pone todos los nombres de las tablas en minúsculas y cambia el nombre del esquema original de SQL Server de dbo a mydb_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": []
   }
]
}          
            

Restricciones al uso de un punto de conexión de destino de PostgreSQL con tablas de Babelfish

Las siguientes restricciones se aplican al usar un punto de conexión de destino de PostgreSQL con tablas de Babelfish:

• Para el modo de Preparación de tablas de destino, utilice solo los modos No hacer nada o Truncar. No utilice el modo Borrar tablas en el destino. En ese modo, DMS crea las tablas como tablas de PostgreSQL que es posible que T-SQL no reconozca.

• AWS DMS no admite el tipo de datos sql_variant.

• Babelfish no admite tipos de datos HEIRARCHYID, GEOMETRY y GEOGRAPHY. Para migrar estos tipos de datos, puede agregar reglas de transformación para convertir el tipo de datos en wstring(250).

• Babelfish solo admite la migración de los tipos de datos BINARY, VARBINARY e IMAGE con el tipo de datos BYTEA. Para las versiones anteriores de Aurora PostgreSQL, puede usar DMS para migrar estas tablas a un punto de conexión de destino de Babelfish. No es necesario especificar una longitud para el tipo de datos BYTEA, como se muestra en el ejemplo siguiente.

  [Picture] [VARBINARY](max) NULL

  Cambie el tipo de datos T-SQL anterior por el tipo de datos BYTEA compatible con T-SQL.

  [Picture] BYTEA NULL

• Para las versiones anteriores de Aurora PostgreSQL Babelfish, si crea una tarea de migración para la replicación continua de SQL Server a Babelfish mediante el punto de conexión de destino de PostgreSQL, debe asignar el tipo de datos SERIAL a cualquier tabla que utilice columnas IDENTITY. A partir de Aurora PostgreSQL (versión 15.3/14.8 y superiores) y Babelfish (versión 3.2.0 y más recientes), se admite la columna de identidad y ya no es necesaria para asignar el tipo de datos SERIAL. Para obtener más información, consulte Uso de SERIAL en la sección Secuencias e identidad del Manual de migración de SQL Server a Aurora PostgreSQL. A continuación, cuando cree la tabla en Babelfish, cambie la definición de la columna de la siguiente manera.

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

  Cambia lo anterior por lo siguiente.

      [IDCol] SERIAL PRIMARY KEY

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

• Después de migrar los datos con tablas que utilizan columnas IDENTITY o el tipo de datos SERIAL, restablezca el objeto de secuencia basado en PostgreSQL en función del valor máximo de la columna. Después de realizar una carga completa de las tablas, utilice la siguiente consulta T-SQL para generar instrucciones que inicien 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 se ejecutan para actualizar los valores máximos de IDENTITY y SERIAL.

• Para las versiones de Babelfish anteriores a la 3.2, es posible que el modo de LOB completo provoque un error de la tabla. Si eso ocurre, cree una tarea independiente para las tablas que no se pudieron cargar. A continuación, utilice el Modo de LOB limitado para especificar el valor adecuado para el Tamaño máximo de LOB (KB). Otra opción es establecer la configuración del atributo de conexión del punto de conexión de SQL Server ForceFullLob=True.

• En las versiones de Babelfish anteriores a la 3.2, 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 puede encontrar una clave única adecuada. A partir de Aurora PostgreSQL (versión 15.3/14.8 y superiores) y Babelfish (versión 3.2.0 y superiores), se admite la validación de datos para claves principales que no sean números enteros.

• Debido a las diferencias de precisión en el número de decimales por segundo, DMS informa de errores de validación de datos en las tablas de Babelfish que utilizan tipos de datos DATETIME. Para suprimir esos errores, puede agregar el siguiente tipo de regla de validación para los tipos de datos DATETIME.

  {
           "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"
       }