Data Transmission Service:Migración de datos de una base de datos PostgreSQL autogestionada a AnalyticDB for PostgreSQL

Requisitos de la base de datos de origen

• El servidor de origen debe contar con suficiente ancho de banda de salida. Un ancho de banda bajo reduce la velocidad de migración.

• Las tablas deben tener restricciones PRIMARY KEY o UNIQUE, y todos los campos deben ser únicos. Las tablas sin estas restricciones pueden generar registros duplicados en el destino.

• El nombre de la base de datos de origen no puede contener guiones (-). Por ejemplo, dts-testdata no es un nombre válido.

• Si selecciona tablas como objetos de migración y necesita cambiarles el nombre a las tablas o columnas en el destino, una sola tarea de migración admite un máximo de 1,000 tablas. Para migraciones más grandes, divídalas en varias tareas o realice la migración a nivel de base de datos.

• La migración incremental requiere que el parámetro wal_level esté establecido en logical en la base de datos de origen.

• Retención del registro de escritura anticipada (WAL):

  • Solo migración incremental de datos: conserve los registros WAL durante más de 24 horas.

  • Migración completa de datos + migración incremental de datos: conserve los registros WAL durante como mínimo 7 días.

  • Una vez que finaliza la migración completa, puede reducir el periodo de retención a más de 24 horas. Una retención insuficiente puede impedir que DTS lea los registros WAL, lo que provoca errores en la tarea o pérdida de datos.

• Durante la migración, evite las siguientes operaciones en la base de datos de origen:

  • Un cambio entre nodo principal y secundario, ya que hace que la tarea de migración termine con errores.

  • Operaciones DDL durante la migración completa de datos, porque provocan que la tarea de migración termine con errores.

  • Escribir datos en el origen durante una migración exclusivamente completa, pues genera inconsistencias en los datos. Para evitar este riesgo, incluya la migración incremental de datos en su tarea.

• Las transacciones de larga duración con registros de escritura anticipada abiertos pueden acumularse y agotar el espacio en disco del origen mientras se ejecuta la migración incremental.

Requisitos de la base de datos de destino

• Durante la migración completa e incremental de datos, DTS deshabilita temporalmente las comprobaciones de restricciones y las operaciones en cascada de claves externas a nivel de sesión. Si ejecuta operaciones de actualización o eliminación en cascada en la base de datos de origen durante la migración, pueden producirse inconsistencias en los datos.

• La tabla de destino no puede ser una tabla optimizada para anexión (AO).

• DTS no migra los siguientes tipos de objetos: DATATYPE, SEQUENCE, INDEX, PROCEDURE, FUNCTION, VIEW, OPERATOR, DEFAULT_CONSTRAINT, UK, PK, RULE, DOMAIN, AGGREGATE, EXTENSION, FK y TRIGGER.

• Si utiliza la asignación de columnas para una migración parcial de tablas, se pierden los datos de las columnas de origen que no tienen una columna de destino coincidente.

• Para tablas con clave principal: las columnas de clave principal en el destino deben coincidir con las del origen.

• Para tablas sin clave principal: la columna de clave principal y la clave de distribución en el destino deben ser iguales.

• Una clave única en el destino debe contener todas las columnas de su clave de distribución, incluidas las columnas de clave principal.

• DTS no admite la migración de tablas de extensión de TimescaleDB ni de tablas con relaciones de herencia entre esquemas.

• DTS no admite la migración de tablas particionadas, a menos que incluya tanto la tabla principal como todas las tablas secundarias como objetos de migración. La tabla principal no almacena datos; toda la información reside en las tablas secundarias.

Comportamiento de la migración incremental

REPLICA IDENTITY y replicación de UPDATE/DELETE

PostgreSQL utiliza REPLICA IDENTITY para controlar la cantidad de datos de columnas que se escriben en los registros WAL ante eventos UPDATE y DELETE. La configuración predeterminada (DEFAULT) solo incluye las columnas de clave principal en dichos registros. Cuando DTS replica operaciones UPDATE o DELETE, necesita los valores anteriores de todas las columnas para identificar y aplicar los cambios correctamente en el destino. Sin la identidad FULL, DTS no puede replicar de manera confiable los eventos UPDATE o DELETE, lo que puede generar inconsistencias en los datos.

Si su tarea de migración incluye migración incremental de datos, ejecute el siguiente comando en cada tabla que se va a migrar antes de escribir datos en ella. Esto establece REPLICA IDENTITY en FULL, lo que registra todos los valores de las columnas para los eventos UPDATE y DELETE:

ALTER TABLE schema.table REPLICA IDENTITY FULL;

Reemplace schema y table con el nombre real del esquema y de la tabla. Ejecute este comando fuera del horario de mayor actividad y evite bloquear la tabla durante su ejecución.

Ejecute este comando en las siguientes situaciones:

• Cuando la instancia de DTS inicia por primera vez.

• Cuando la granularidad del objeto de migración es Schema y usted crea una tabla nueva o reconstruye una mediante el comando RENAME dentro del esquema que se está migrando.

Si omite el elemento de comprobación previa correspondiente, DTS ejecuta automáticamente este comando durante la inicialización de la instancia.

Tablas temporales y slots de replicación

DTS crea las siguientes tablas temporales en la base de datos de origen. No las elimine durante la migración, ya que la tarea podría terminar con errores si se quitan. DTS las elimina automáticamente después de liberar la instancia.

public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, public.dts_args_session, public.aliyun_dts_instance

La tabla dts_postgres_heartbeat es una tabla de latido que DTS utiliza para garantizar la precisión de la latencia en la migración incremental.

DTS también crea un slot de replicación con el prefijo dts_sync_ y borra sus datos históricos cada 90 minutos para reducir el uso de almacenamiento. Si la tarea de migración se libera o termina con errores, DTS borra automáticamente el slot de replicación. Si se realiza un cambio entre nodo principal y secundario en una instancia de ApsaraDB RDS for PostgreSQL, inicie sesión en la base de datos secundaria y borre manualmente el slot de replicación.

Otras notas sobre la migración incremental

• Para usar una tarea de migración de datos creada antes del 12 de mayo de 2023 y migrar operaciones DDL, debe crear un trigger y una función en la base de datos de origen que capturen la información DDL antes de configurar la tarea. Para obtener más información, consulte Uso de triggers y funciones para implementar la migración incremental de DDL en bases de datos PostgreSQL.

• La migración incremental de datos no admite columnas del tipo de datos BIT.

• Cuando DTS escribe instrucciones UPDATE en la instancia de AnalyticDB for PostgreSQL de destino, las convierte automáticamente en REPLACE INTO. Si la instrucción UPDATE afecta columnas de clave principal, DTS la convierte en DELETE + INSERT.

• DTS solo admite la replicación de DDL para tareas creadas después del 1 de octubre de 2020. Para las tareas creadas antes del 12 de mayo de 2023, cree un trigger y una función en la base de datos de origen que capturen las operaciones DDL antes de configurar la tarea. Consulte Uso de triggers y funciones para implementar la migración incremental de DDL en bases de datos PostgreSQL.

• La cuenta de base de datos utilizada para la migración incremental debe tener permisos de superusuario para replicar DDL. Operaciones DDL admitidas:

  • CREATE TABLE, DROP TABLE

  • ALTER TABLE: RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, ALTER COLUMN DROP DEFAULT

  • TRUNCATE TABLE (requiere PostgreSQL V11 o posterior en el origen)

  • CREATE INDEX ON TABLE

• DTS no replica: DDL con CASCADE o RESTRICT, DDL de sesiones que ejecutan SET session_replication_role = replica, DDL ejecutado mediante llamadas a funciones, CREATE SEQUENCE ni lotes que combinan DML y DDL.

Otras notas

• Una tarea de migración abarca una sola base de datos. Cree una tarea independiente por cada base de datos adicional.

• Antes de migrar los datos, evalúe el impacto en el rendimiento de las bases de datos de origen y de destino. Se recomienda migrar los datos fuera del horario de mayor actividad. Durante la migración completa de datos, DTS utiliza los recursos de lectura y escritura de ambas bases de datos, lo que puede aumentar la carga en los servidores de base de datos.

• La migración completa de datos usa operaciones INSERT simultáneas, lo que provoca fragmentación en las tablas de destino. Después de la migración, el tablespace de destino será más grande que el de origen.

• DTS utiliza ROUND(COLUMN, PRECISION) para leer las columnas FLOAT y DOUBLE. Precisión predeterminada: 38 dígitos para FLOAT y 308 dígitos para DOUBLE. Compruebe que esto cumple sus requisitos de precisión antes de migrar.

• DTS intenta reanudar las tareas con errores durante un máximo de 7 days. Antes de trasladar las cargas de trabajo al destino, detenga o libere cualquier tarea con errores, o bien ejecute REVOKE para quitar los permisos de escritura de DTS en el destino. Si una tarea con errores se reanuda después del traslado, sobrescribirá los datos en el destino.

• DTS no valida los metadatos de las secuencias. Compruebe manualmente la validez de las secuencias.

• Después de cambiar al destino, las nuevas secuencias no comienzan desde el valor máximo del origen. Antes de realizar el cambio, consulte los valores de las secuencias de origen y establézcalos como valores iniciales en el destino:

  do language plpgsql $$
  declare
    nsp name;
    rel name;
    val int8;
  begin
    for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
    loop
      execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
      raise notice '%',
      format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
    end loop;
  end;
  $$;

  La salida contiene instrucciones setval para todas las secuencias del origen. Ejecute en el destino únicamente las instrucciones que correspondan a sus objetos de migración.

• Si una instancia de DTS presenta errores, el equipo de soporte técnico intenta recuperarla en un plazo de 8 horas. La recuperación puede incluir reiniciar la instancia o ajustar los parámetros de la instancia de DTS, pero no los parámetros de la base de datos. Para conocer los parámetros ajustables, consulte Modificar los parámetros de la instancia.

PostgreSQL 10.1 o posterior

1. Inicie sesión en el servidor donde se ejecuta la base de datos PostgreSQL autogestionada.

2. Abra postgresql.conf y actualice los siguientes parámetros: Configuración de ejemplo:

   • Establezca wal_level en logical.

   • Establezca max_wal_senders y max_replication_slots en valores mayores a la suma de: la cantidad de slots de replicación en uso actualmente en el origen, más el número de instancias de DTS que utilizan esta base de datos de origen.

   # - Settings -
   
   wal_level = logical			# minimal, replica, or logical
   					# (change requires restart)
   
   ......
   
   # - Sending Server(s) -
   
   # Set these on the master and on any standby that will send replication data.
   
   max_wal_senders = 10		# max number of walsender processes
   				# (change requires restart)
   #wal_keep_segments = 0		# in logfile segments, 16MB each; 0 disables
   #wal_sender_timeout = 60s	# in milliseconds; 0 disables
   
   max_replication_slots = 10	# max number of replication slots
   				# (change requires restart)

   Reinicie la base de datos para aplicar los cambios.

3. Agregue los bloques CIDR del servidor de DTS en pg_hba.conf. Incluya únicamente los bloques CIDR de los servidores de DTS que se encuentren en la misma región que la base de datos de destino. Para consultar la lista de bloques CIDR, vea Agregar direcciones IP de servidores de DTS a una lista de permitidos. Después de editar pg_hba.conf, ejecute SELECT pg_reload_conf(); o reinicie la base de datos para aplicar los cambios. Omita este paso si la dirección IP en pg_hba.conf ya está establecida en 0.0.0.0/0.

   

4. Cree la base de datos y el esquema correspondientes en la instancia de AnalyticDB for PostgreSQL de destino.

PostgreSQL 9.4.8 a 10.0

Las versiones de PostgreSQL anteriores a la 10.1 requieren el complemento ali_decoding para admitir la replicación lógica. Siga estos pasos para compilarlo e instalarlo.

1. Descargue el código fuente de PostgreSQL que corresponda a la versión de su base de datos desde el sitio web oficial de PostgreSQL.

2. Compile e instale PostgreSQL mediante la ejecución secuencial de los siguientes comandos:

   Importante

   • La versión del sistema operativo debe ser compatible con la versión de GNU Compiler Collection (GCC). - Si sudo ./configure falla con un error de readline, ejecute sudo ./configure --without-readline en su lugar. - Si instala PostgreSQL mediante otro método, compile el complemento ali_decoding en un entorno de prueba que tenga la misma versión del sistema operativo y de GCC.

   sudo ./configure
   sudo make
   sudo make install

3. Descargue el complemento ali_decoding.

4. Copie el directorio ali_decoding al directorio contrib de la instalación de PostgreSQL compilada.

   

5. Reemplace el contenido del archivo Makefile ubicado en el directorio ali_decoding con lo siguiente:

   # contrib/ali_decoding/Makefile
   MODULE_big = ali_decoding
   MODULES = ali_decoding
   OBJS    = ali_decoding.o
   
   DATA = ali_decoding--0.0.1.sql ali_decoding--unpackaged--0.0.1.sql
   
   EXTENSION = ali_decoding
   
   NAME = ali_decoding
   
   #subdir = contrib/ali_decoding
   #top_builddir = ../..
   #include $(top_builddir)/src/Makefile.global
   #include $(top_srcdir)/contrib/contrib-global.mk
   
   #PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
   #pgsql_lib_dir := $(shell $(PG_CONFIG) --libdir)
   #PGXS := $(shell $(PG_CONFIG) --pgxs)
   #include $(PGXS)
   
   # Run the following commands to install the ali_decoding plug-in:
   ifdef USE_PGXS
   PG_CONFIG = pg_config
   PGXS := $(shell $(PG_CONFIG) --pgxs)
   include $(PGXS)
   else
   subdir = contrib/ali_decoding
   top_builddir = ../..
   include $(top_builddir)/src/Makefile.global
   include $(top_srcdir)/contrib/contrib-global.mk
   endif

6. Desde el directorio ali_decoding, ejecute secuencialmente los siguientes comandos para compilar e instalar el complemento:

   sudo make
   sudo make install

7. Copie los archivos compilados a los directorios correspondientes.

   

8. Cree la base de datos y el esquema correspondientes en la instancia de AnalyticDB for PostgreSQL de destino.

Paso 1: Ir a la página Data Migration

Utilice la consola de DTS o la consola de DMS.

Paso 2: Configurar las bases de datos de origen y destino

Haga clic en Create Task y configure los siguientes parámetros.

Base de datos de origen

Base de datos de destino

Paso 3: Probar la conectividad

Haga clic en Test Connectivity and Proceed.

DTS necesita acceder a ambas bases de datos. Asegúrese de agregar los bloques CIDR del servidor de DTS a la configuración de seguridad tanto de la base de datos de origen como de la de destino. Consulte Agregar direcciones IP de servidores de DTS a una lista de permitidos .

Si el origen o el destino es una base de datos autogestionada a la que no se accede mediante Alibaba Cloud Instance , haga clic en Test Connectivity en el cuadro de diálogo CIDR Blocks of DTS Servers .

Paso 4: Configurar los objetos de migración

Tipos y objetos de migración

Paso 5: Configurar los ajustes avanzados

Haga clic en Next: Advanced Settings y configure los siguientes parámetros.

Paso 6: Configurar la verificación de datos (opcional)

Haga clic en Next Step: Data Verification. Para consultar las instrucciones de configuración, vea Configurar una tarea de verificación de datos.

Paso 7: Configurar la clave primaria y las columnas de distribución

Haga clic en Next: Configure Database and Table Fields para establecer la clave primaria y las columnas de distribución de las tablas migradas en la instancia de AnalyticDB for PostgreSQL de destino.

Esta página aparece únicamente cuando se selecciona Schema Migration . Para obtener más información sobre las columnas de clave primaria y las columnas de distribución, consulte Data Table Management y Table Distribution Definition .

Paso 8: Ejecutar la comprobación previa

Haga clic en Next: Save Task Settings and Precheck.

Para previsualizar los parámetros de API de esta configuración, coloque el cursor sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters .

DTS ejecuta una comprobación previa antes de iniciar la migración. Solo puede iniciar la tarea después de superar dicha comprobación.

Si la comprobación previa falla, haga clic en View Details junto a cada elemento con errores, corrija el problema y haga clic en Precheck Again.

Si aparece una alerta para algún elemento:

• Si no es posible ignorar la alerta, haga clic en View Details, corrija el problema y vuelva a ejecutar la comprobación previa.

• Si la alerta se puede ignorar, haga clic en Confirm Alert Details > Ignore > OK y, a continuación, haga clic en Precheck Again.

Paso 9: Adquirir e iniciar la instancia

1. Espere hasta que Success Rate alcance 100% y, a continuación, haga clic en Next: Purchase Instance.

2. En la página Purchase Instance, configure lo siguiente:

   Parámetro	Descripción
   Resource group	El resource group de la instancia de migración. Valor predeterminado: default resource group.
   Instance class	Seleccione una clase de instancia según la velocidad de migración necesaria. Consulte Clases de instancia de las instancias de migración de datos.

3. Lea y acepte Data Transmission Service (Pay-as-you-go) Service Terms.

4. Haga clic en Buy and Start y, a continuación, haga clic en OK en el cuadro de diálogo de confirmación.

Siga el progreso en la página Data Migration.

Las tareas de migración de esquemas y de migración completa de datos se detienen automáticamente al finalizar. El estado muestra Completed .

Las tareas de migración incremental de datos se ejecutan de forma continua. El estado muestra Running . Detenga la tarea manualmente cuando esté listo para cambiar las cargas de trabajo al destino.