Migre datos entre instancias de ApsaraDB RDS for PostgreSQL con Data Transmission Service (DTS). DTS admite la migración de esquemas, la migración completa de datos y la migración incremental de datos. La ejecución conjunta de estos tres tipos permite que su aplicación permanezca en línea durante todo el proceso con un tiempo de inactividad mínimo.
Requisitos previos
Antes de empezar, asegúrese de que:
Las instancias de origen y destino de ApsaraDB RDS for PostgreSQL ya están creadas. Consulte Crear una instancia
La versión de la base de datos de destino es igual o superior a la de la base de datos de origen. Una versión de destino inferior puede causar problemas de compatibilidad
La instancia de destino cuenta con más espacio de almacenamiento disponible que el tamaño total de los datos en la instancia de origen
Para consultar las versiones de bases de datos de origen y destino compatibles, consulte Descripción general de los escenarios de migración de datos .
Tipos de migración
DTS admite tres tipos de migración que puede combinar según sus necesidades.
|
Tipo de migración |
Función |
|
Migración de esquemas |
Copia los esquemas de los objetos seleccionados (tablas, vistas, índices, etc.) del origen al destino |
|
Migración completa de datos |
Copia todos los datos existentes del origen al destino |
|
Migración incremental de datos |
Replica continuamente los cambios de datos del origen al destino después de completar la migración completa, lo que mantiene el destino sincronizado mientras la aplicación se ejecuta |
Elija una estrategia de migración:
Solo migración completa (con tiempo de inactividad): Seleccione Schema Migration y Full Data Migration. Detenga las escrituras en el origen antes de iniciar la migración para garantizar la consistencia de los datos.
Migración en línea (tiempo de inactividad mínimo): Seleccione Schema Migration, Full Data Migration e Incremental Data Migration. Su aplicación permanece en línea durante la migración. Detenga las escrituras en el origen únicamente durante el cambio final.
Objetos compatibles
Se pueden migrar los siguientes tipos de objetos:
SCHEMA y TABLE — incluye PRIMARY KEY, UNIQUE KEY, FOREIGN KEY, tipos de datos integrados y restricciones DEFAULT
VIEW
PROCEDURE — solo PostgreSQL V11 o posterior
FUNCTION, RULE, SEQUENCE, EXTENSION, TRIGGER, AGGREGATE, INDEX, OPERATOR, DOMAIN
Operaciones SQL admitidas para la migración incremental
|
Tipo de operación |
Sentencias admitidas |
|
DML |
INSERT, UPDATE, DELETE |
|
DDL |
Consulte los detalles a continuación |
Detalles de la migración DDL:
La migración DDL solo está disponible para tareas creadas después del 1 de octubre de 2020.
Para migrar operaciones DDL en tareas creadas antes del 12 de mayo de 2023, primero debe crear un disparador y una función en la base de datos de origen. Consulte Uso de disparadores y funciones para implementar la migración DDL incremental en bases de datos PostgreSQL.
Si la base de datos de origen utiliza una cuenta con privilegios y la versión menor del motor es 20210228 o posterior, se admiten las siguientes sentencias DDL:
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 — el origen debe ser PostgreSQL V11 o posterior
CREATE INDEX ON TABLE
Limitaciones de la migración DDL:
Los datos de tipo BIT no se pueden migrar durante la migración incremental.
Los modificadores CASCADE y RESTRICT en sentencias DDL no se pueden migrar.
No se pueden migrar las sentencias DDL ejecutadas en una sesión donde se haya ejecutado
SET session_replication_role = replica.No se pueden migrar las sentencias DDL invocadas mediante funciones.
Si un envío por lotes contiene sentencias DML y DDL, se omiten las sentencias DDL.
Si un envío por lotes contiene sentencias DDL no admitidas para la migración, dichas sentencias se omiten.
Permisos obligatorios
Otorgue los siguientes permisos a las cuentas de base de datos que utiliza DTS. Siga el principio de menor privilegio: evite usar una cuenta de superusuario a menos que no sea posible otorgar los permisos necesarios por separado.
|
Base de datos |
Migración de esquemas |
Migración completa de datos |
Migración incremental de datos |
|
ApsaraDB RDS for PostgreSQL de origen |
USAGE en el esquema |
SELECT en los objetos que se van a migrar |
Cuenta con privilegios que sea propietaria de la base de datos. Para PostgreSQL 9.4 con migración exclusiva de DML, solo se requiere el permiso REPLICATION. |
|
ApsaraDB RDS for PostgreSQL de destino |
CREATE y USAGE en los objetos que se van a migrar |
Permisos de propietario del esquema |
— |
Para crear cuentas y otorgar permisos, consulte Crear una cuenta y Crear una base de datos.
Límites
Revise estos límites antes de configurar una tarea de migración. Ignorarlos puede provocar fallos en la tarea o inconsistencia en los datos.
Límites de la base de datos de origen
|
Límite |
Detalles |
Impacto si se incumple |
|
Clave primaria o restricción única obligatoria |
Las tablas deben tener restricciones PRIMARY KEY o UNIQUE con todos los campos únicos. Si una tabla en el destino se creó sin la migración de esquemas de DTS, asegúrese de que su restricción PRIMARY KEY o NOT NULL UNIQUE coincida con la tabla de origen. Las tablas que se van a migrar también deben tener restricciones PRIMARY KEY, FOREIGN KEY, UNIQUE o CHECK. |
El destino podría contener registros duplicados |
|
Sin guiones en el nombre de la base de datos |
El nombre de la base de datos de origen no puede contener guiones ( |
La tarea de migración no se inicia |
|
Límite de 1,000 tablas por tarea al editar nombres de tablas |
Si selecciona tablas como objetos de migración y necesita cambiar el nombre de tablas o columnas en el destino, una sola tarea puede migrar hasta 1,000 tablas. Para más de 1,000 tablas, cree varias tareas o migre toda la base de datos. |
Se produce un error de solicitud |
|
Sin tablas temporales ni procedimientos internos en lenguaje C |
DTS no puede migrar tablas temporales, disparadores internos ni procedimientos y funciones internos escritos en C. |
Estos objetos se omiten silenciosamente |
|
Compatibilidad con tipos personalizados |
DTS puede migrar parámetros personalizados de los tipos COMPOSITE, ENUM y RANGE. |
Otros tipos personalizados no se migran |
|
|
Establezca |
La migración incremental no puede iniciarse |
|
Retención de registros WAL |
Para migración solo incremental: conserve los registros de escritura anticipada (WAL) durante más de 24 horas. Para migración completa + incremental: conserve los registros WAL durante al menos 7 días. Una vez completada la migración completa, puede reducir la retención a más de 24 horas. |
Una retención insuficiente provoca fallos en la tarea, inconsistencia de datos o pérdida de datos |
|
Sin DDL durante la migración de esquemas o la migración completa |
No ejecute operaciones DDL que modifiquen esquemas de bases de datos o tablas mientras se ejecuta la migración de esquemas o la migración completa de datos. |
La tarea de migración falla |
|
Sin escrituras en el origen durante la migración solo completa |
Si ejecuta únicamente la migración completa de datos (sin incremental), no escriba en la base de datos de origen durante la migración. Para evitar esta restricción, seleccione la migración completa + incremental. |
Las escrituras simultáneas causan inconsistencia en los datos |
|
Límite de 256 MB por registro individual para la migración incremental |
Si un cambio incremental individual supera los 256 MB, la tarea falla y no se puede recuperar. Debe reconfigurar la tarea. |
La tarea falla sin opción de recuperación |
|
Las transacciones de larga duración acumulan registros WAL |
Las transacciones de larga duración en la base de datos de origen impiden la limpieza de registros WAL. Confirme o finalice las transacciones de larga duración antes de la migración. |
El espacio en disco del origen podría agotarse durante la migración incremental |
|
Las actualizaciones de versión principal interrumpen las tareas en ejecución |
Una actualización de versión principal en la base de datos de origen mientras se ejecuta una tarea de migración provoca que la tarea falle sin posibilidad de recuperación. Reconfigure la tarea después de la actualización. |
La tarea falla sin opción de recuperación |
Otros límites
|
Límite |
Detalles |
|
El cambio de primario/secundario requiere Logical Replication Slot Failover |
Antes de realizar un cambio de primario/secundario en la instancia de origen, habilite la función Logical Replication Slot Failover. Esto evita que se interrumpan las suscripciones lógicas. Consulte Logical Replication Slot Failover. |
|
Una base de datos por tarea |
Una sola tarea migra datos de una única base de datos. Cree tareas separadas para cada base de datos. |
|
Sin tablas heredadas entre esquemas |
No se pueden migrar las tablas heredadas a través de esquemas. |
|
El campo SERIAL requiere la migración de secuencias |
Si una tabla tiene un campo SERIAL y selecciona Schema Migration, seleccione también Sequence o migre todo el esquema. De lo contrario, la tarea fallará. |
|
Nuevas tablas creadas durante la migración incremental |
Si agrega una nueva tabla a un esquema o cambia el nombre de una tabla mediante RENAME durante la migración incremental, ejecute |
|
No se valida la validez de los metadatos |
DTS no valida metadatos como las secuencias. Verifique los metadatos manualmente después de la migración. |
|
Las secuencias en el destino no comienzan desde el valor máximo del origen |
Después de trasladar las cargas de trabajo al destino, las nuevas secuencias comienzan desde sus valores iniciales, no desde el valor máximo del origen. Actualice los valores iniciales de las secuencias en el destino antes del cambio final. |
|
Tablas temporales creadas por DTS |
DTS crea las siguientes tablas temporales en la base de datos de origen para respaldar la migración incremental. No las elimine durante la migración, ya que se quitan automáticamente después de liberar la instancia de DTS: |
|
|
Si la cuenta de destino es una cuenta con privilegios o tiene el rol de superusuario, DTS establece |
|
Tabla de latido creada en el origen |
DTS crea una tabla de latido llamada |
|
Ranura de replicación creada en el origen |
DTS crea una ranura de replicación con el prefijo |
|
La migración completa causa fragmentación de tablas |
Las operaciones INSERT simultáneas durante la migración completa provocan fragmentación de tablas en el destino. El tablespace de destino será mayor que el del origen una vez completada la migración completa. |
|
Precisión FLOAT y DOUBLE |
DTS utiliza |
|
Las tareas con errores pueden reanudarse y sobrescribir datos en el destino |
DTS reintenta una tarea con errores durante un máximo de 7 días. Antes de trasladar las cargas de trabajo al destino, detenga o libere las tareas con errores, o ejecute |
|
El soporte técnico de DTS puede modificar parámetros de la tarea |
Si una tarea falla, el soporte técnico de DTS intenta restaurarla en un plazo de 8 horas. Es posible que la tarea se reinicie y que se modifiquen los parámetros de la tarea (no los parámetros de la base de datos). |
Casos especiales
No modifique el endpoint ni la zona de la instancia de origen de ApsaraDB RDS for PostgreSQL mientras se ejecuta una tarea de migración. Esto provoca que la tarea falle.
Configurar una tarea de migración
Paso 1: Ir a la página Data Migration
Utilice la consola de DTS o la consola de DMS.
Consola de DTS:
Inicie sesión en la consola de DTS.
En el panel de navegación izquierdo, haga clic en Data Migration.
En la esquina superior izquierda, seleccione la región donde residirá la instancia de migración.
Consola de DMS:
Los pasos reales pueden variar según el modo y el diseño de su consola de DMS. Consulte Modo simple para referencia sobre el diseño, o consulte cómo personalizar el diseño de la consola de DMS .
Inicie sesión en la consola de DMS.
En la barra de navegación superior, pase el puntero sobre Data + AI > DTS (DTS) > Data Migration.
En la lista desplegable a la derecha de Data Migration Tasks, seleccione la región donde residirá la instancia de migración.
Paso 2: Crear una tarea
Haga clic en Create Task para abrir la página de configuración de la tarea.
Paso 3: Configurar las bases de datos de origen y destino
Después de configurar las bases de datos de origen y destino, lea los Limits que se muestran en la parte superior de la página. Omitir este paso puede provocar fallos en la tarea o inconsistencia en los datos.
Configure los siguientes parámetros tanto para la base de datos de origen como para la de destino.
|
Sección |
Parámetro |
Descripción |
|
N/A |
Task Name |
Nombre para la tarea de DTS. DTS genera un nombre automáticamente. Especifique un nombre descriptivo para identificar fácilmente la tarea. El nombre no necesita ser único. |
|
Source Database |
Select Existing Connection |
Si la instancia ya está registrada en DTS, selecciónela de la lista desplegable. DTS completa automáticamente los parámetros restantes. De lo contrario, configure los parámetros siguientes. En la consola de DMS, seleccione la instancia de la lista desplegable Select a DMS database instance. |
|
Database Type |
Seleccione PostgreSQL. |
|
|
Access Method |
Seleccione Alibaba Cloud Instance. |
|
|
Instance Region |
Región de la instancia de origen. |
|
|
Instance ID |
ID de la instancia de origen. |
|
|
Database Name |
Nombre de la base de datos que contiene los objetos a migrar. |
|
|
Database Account |
Cuenta de la instancia de origen. Consulte Permisos obligatorios. |
|
|
Database Password |
Contraseña de la cuenta de la base de datos. |
|
|
Encryption |
Seleccione Non-encrypted (predeterminado) o SSL-encrypted. Para el cifrado SSL, cargue el CA Certificate y, opcionalmente, el Client Certificate, Private Key of Client Certificate y Private Key Password of Client Certificate. Consulte Cifrado SSL para obtener instrucciones de configuración. |
|
|
Destination Database |
Select Existing Connection |
Igual que en el origen. |
|
Database Type |
Seleccione PostgreSQL. |
|
|
Access Method |
Seleccione Alibaba Cloud Instance. |
|
|
Instance Region |
Región de la instancia de destino. |
|
|
Instance ID |
ID de la instancia de destino. |
|
|
Database Name |
Nombre de la base de datos de destino. |
|
|
Database Account |
Cuenta de la instancia de destino. Consulte Permisos obligatorios. |
|
|
Database Password |
Contraseña de la cuenta de la base de datos. |
|
|
Encryption |
Mismas opciones que en el origen. |
Paso 4: Probar la conectividad
Haga clic en Test Connectivity and Proceed en la parte inferior de la página.
Los bloques CIDR de los servidores de DTS deben agregarse a la configuración de seguridad tanto de la base de datos de origen como de la de destino. Para obtener instrucciones, consulte Agregar los bloques CIDR de los servidores de DTS . Si el origen o el destino utiliza un método de acceso distinto a Alibaba Cloud Instance , haga clic en Test Connectivity en el cuadro de diálogo CIDR Blocks of DTS Servers .
Paso 5: Configurar los objetos a migrar
En la página Configure Objects, configure los ajustes de migración.
Tipos de migración:
|
Objetivo |
Seleccionar |
|
Migración completa (con tiempo de inactividad) |
Schema Migration y Full Data Migration |
|
Migración en línea (tiempo de inactividad mínimo) |
Schema Migration, Full Data Migration e Incremental Data Migration |
Si no selecciona Incremental Data Migration , no escriba datos en el origen durante la migración para garantizar la consistencia de los datos. La migración de esquemas copia las claves externas al destino.
Modo de procesamiento de tablas en conflicto:
|
Modo |
Comportamiento |
|
Precheck and Report Errors |
Comprueba si existen tablas con nombres idénticos en el origen y el destino antes de la migración. Si hay conflictos, la comprobación previa falla y la tarea no se inicia. Para resolver conflictos sin eliminar tablas del destino, utilice la asignación de nombres de objetos para cambiar el nombre de las tablas migradas. Consulte Asignar nombres de objetos. |
|
Ignore Errors and Proceed |
Omite la comprobación de conflictos. Durante la migración completa, los registros en conflicto no se migran (se conservan los registros existentes en el destino). Durante la migración incremental, los registros en conflicto sobrescriben los registros existentes en el destino. Utilice este modo con precaución, ya que puede exponer sus datos a riesgos de inconsistencia. |
Source Objects:
Seleccione uno o varios esquemas o tablas en Source Objects y haga clic en 
para agregarlos a Selected Objects.
Si selecciona tablas (en lugar de esquemas), DTS no migra otros objetos como vistas, disparadores y procedimientos almacenados. Si una tabla tiene un tipo de datos SERIAL y se selecciona Schema Migration, seleccione también Sequence o migre el esquema completo.
Selected Objects:
Para cambiar el nombre de un solo objeto en el destino, haga clic derecho sobre él en Selected Objects. Consulte Asignar el nombre de un solo objeto.
Para cambiar el nombre de varios objetos a la vez, haga clic en Batch Edit. Consulte Asignar varios nombres de objetos a la vez.
Para filtrar filas por condición, haga clic derecho en una tabla y especifique una condición WHERE. Consulte Especificar condiciones de filtro.
Para seleccionar operaciones SQL específicas a migrar para una tabla, haga clic derecho en la tabla y elija las operaciones. Consulte Operaciones SQL admitidas para la migración incremental.
Cambiar el nombre de un objeto mediante la asignación de nombres de objetos puede provocar que los objetos dependientes fallen en la migración.
Haga clic en Next: Advanced Settings.
Configuración avanzada:
| Parámetro | Descripción |
|---|---|
| Dedicated Cluster for Task Scheduling | De forma predeterminada, DTS utiliza el clúster compartido. Para mayor estabilidad, adquiera un clúster dedicado. Consulte ¿Qué es un clúster dedicado de DTS?. |
| Retry Time for Failed Connections | Tiempo durante el cual DTS reintenta tras un fallo de conexión. Rango: 10–1,440 minutos. Valor predeterminado: 720. Establezca este valor en 30 como mínimo. Si DTS se reconecta dentro de la ventana de reintentos, la tarea se reanuda; de lo contrario, falla. Nota
Si varias tareas comparten el mismo origen o destino, el tiempo de reintento establecido más recientemente se aplica a todas. Los cargos de DTS continúan durante los reintentos. |
| Retry Time for Other Issues | Tiempo durante el cual DTS reintenta tras fallos en operaciones DDL o DML. Rango: 1–1,440 minutos. Valor predeterminado: 10. Establezca este valor en más de 10. Este valor debe ser menor que Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Limita el throughput de la migración para reducir la carga en el origen y el destino. Configure QPS to the source database, RPS of Full Data Migration y Data migration speed for full migration (MB/s). Disponible solo cuando se selecciona Full Data Migration. |
| Enable Throttling for Incremental Data Migration | Limita el throughput de la migración incremental. Configure RPS of Incremental Data Migration y Data migration speed for incremental migration (MB/s). Disponible solo cuando se selecciona Incremental Data Migration. |
| Environment Tag | Etiqueta opcional para identificar la instancia de DTS por entorno. |
| Configure ETL | Habilite la extracción, transformación y carga (ETL) para procesar datos durante la migración. Seleccione Yes para introducir sentencias de procesamiento de datos. Consulte Configurar ETL en una tarea de migración o sincronización de datos. |
| Monitoring and Alerting | Configure alertas para fallos de tareas o alta latencia de migración. Seleccione Yes y configure el umbral de alerta y los ajustes de notificación. Consulte Configurar monitoreo y alertas al crear una tarea de DTS. |
Haga clic en Next Step: Data Verification para configurar la verificación de datos. Consulte Configurar una tarea de verificación de datos.
Paso 6: Ejecutar la comprobación previa
Haga clic en Next: Save Task Settings and Precheck.
Para obtener una vista previa de los parámetros de API para esta configuración de tarea, pase el cursor sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters antes de continuar.
DTS ejecuta una comprobación previa antes de iniciar la tarea. La tarea no puede iniciarse hasta que la comprobación previa sea exitosa.
Si algún elemento de la comprobación previa falla, haga clic en View Details para ver la causa. Corrija el problema y haga clic en Precheck Again.
-
Si un elemento genera una alerta:
Si la alerta no se puede ignorar, corrija el problema y vuelva a ejecutar la comprobación previa.
Si la alerta se puede ignorar, haga clic en Confirm Alert Details, luego haga clic en Ignore > OK > Precheck Again. Ignorar una alerta puede causar inconsistencia en los datos.
Paso 7: Adquirir una instancia e iniciar la tarea
Espere hasta que Success Rate alcance 100%, luego haga clic en Next: Purchase Instance.
-
En la página Purchase Instance, configure la instancia:
Sección
Parámetro
Descripción
New Instance Class
Resource Group
Grupo de recursos para la instancia de migración. Valor predeterminado: default resource group. Consulte ¿Qué es Resource Management?.
Instance Class
Controla la velocidad de migración. Seleccione según el volumen de datos y los requisitos de tiempo. Consulte Clases de instancia de migración de datos.
Lea y acepte los Data Transmission Service (Pay-as-you-go) Service Terms seleccionando la casilla de verificación.
Haga clic en Buy and Start, luego haga clic en OK en el cuadro de diálogo de confirmación.
La tarea aparece en la página Data Migration.
Si la tarea no incluye migración incremental, se detiene automáticamente al completarse. El estado muestra Completed.
Si la tarea incluye migración incremental, se ejecuta continuamente. El estado muestra Running.
Cambio final a la base de datos de destino
Para migraciones en línea que utilizan migración incremental de datos, siga estos pasos para realizar el cambio final con una pérdida mínima de datos.
Monitoree la latencia de la migración. En la página Data Migration, compruebe la latencia de la tarea de migración incremental. Espere hasta que la latencia baje a 0 o cerca de 0, lo que indica que el destino está casi completamente sincronizado con el origen.
Detenga las escrituras en el origen. Una vez que la latencia esté cerca de 0, detenga las escrituras de su aplicación en la base de datos de origen.
Confirme que la latencia llega a 0. Después de detener las escrituras, confirme que la latencia de la migración incremental llega a 0. Esto garantiza que todos los cambios se han replicado en el destino.
Actualice las secuencias en el destino. Las nuevas secuencias en el destino no se incrementan desde el valor máximo de las secuencias en el origen. Antes de cambiar el tráfico, actualice los valores iniciales de todas las secuencias en el destino para evitar conflictos de ID.
Verifique los datos. Si configuró la verificación de datos, revise los resultados para confirmar la consistencia de los datos entre el origen y el destino.
Cambie su aplicación. Actualice la cadena de conexión de su aplicación para que apunte a la instancia de destino.
Libere la tarea de DTS. Después de confirmar que la aplicación se ejecuta correctamente en el destino, detenga y libere la tarea de migración de DTS. DTS elimina automáticamente las tablas temporales y la ranura de replicación del origen después de liberar la tarea.
DTS reintenta una tarea con errores durante un máximo de 7 días. Antes de trasladar las cargas de trabajo al destino, detenga o libere cualquier tarea con errores, o ejecute REVOKE para quitar los permisos de escritura de la cuenta de DTS en la base de datos de destino. De lo contrario, una tarea con errores que se reanude podría sobrescribir datos en el destino.
Pasos siguientes
Logical Replication Slot Failover — habilite esta función antes de realizar un cambio de primario/secundario en la instancia de origen
Asignar nombres de objetos — cambie el nombre de los objetos en el destino durante la migración
Configurar una tarea de verificación de datos — verifique la consistencia de los datos después de la migración
Clases de instancia de migración de datos — elija la clase de instancia adecuada según sus requisitos de velocidad de migración