PolarDB:Clone an ApsaraDB RDS for MySQL instance to PolarDB for MySQL

Notas importantes

Cuando se clonan datos a un clúster de PolarDB mediante la función de clonación con un clic, esta no sincroniza los datos incrementales de la instancia de RDS de origen al clúster de PolarDB de destino.

Descripción general

PolarDB admite la clonación con un clic de los datos de una instancia de ApsaraDB RDS for MySQL a un nuevo clúster de PolarDB for MySQL. Esta función crea un nuevo clúster de PolarDB con los mismos datos que la instancia de RDS de origen. Además, el clúster de PolarDB incluye las cuentas, las bases de datos, la lista blanca de IP y los parámetros necesarios de dicha instancia.

A continuación se describen las versiones y los tipos de almacenamiento compatibles para la instancia de ApsaraDB RDS for MySQL de origen y el clúster de PolarDB for MySQL de destino:

• Es posible clonar instancias de ApsaraDB RDS for MySQL de origen de todas las versiones y todos los tipos de almacenamiento. Las instancias de ApsaraDB RDS for MySQL 5.6, 5.7 y 8.0 que usan discos SSD locales o discos en la nube se pueden clonar a un clúster de PolarDB for MySQL.

• Una instancia de ApsaraDB RDS for MySQL se puede clonar a un clúster de PolarDB for MySQL de la misma versión o de una versión diferente. Por ejemplo, es posible clonar una instancia de ApsaraDB RDS for MySQL 5.6 a un clúster de PolarDB for MySQL 5.6 o a un clúster de PolarDB for MySQL 8.0.

Comparación entre la migración física y la lógica

La función de clonación con un clic admite dos métodos: la migración física (replicación física) y la migración lógica (sincronización de datos mediante DTS).

• Migración física (replicación física): este método utiliza la replicación física para copiar todos los datos de la instancia de ApsaraDB RDS for MySQL de origen al clúster de PolarDB for MySQL recién creado.

• Migración lógica (sincronización de datos mediante DTS): este método utiliza Data Transmission Service (DTS) para crear una tarea de sincronización de datos. Dicha tarea sincroniza el esquema y todos los datos de la instancia de ApsaraDB RDS for MySQL de origen al clúster de PolarDB for MySQL recién creado.

En la siguiente tabla se comparan los métodos de migración física y lógica.

En la siguiente tabla se describen las versiones y los tipos de almacenamiento de ApsaraDB RDS for MySQL que se pueden clonar.

Utilice la migración física únicamente cuando clone una instancia de ApsaraDB RDS for MySQL 5.6 o 5.7 de High-availability Edition que use un disco SSD local a un clúster de PolarDB for MySQL de la misma versión. Para todas las demás configuraciones, se emplea la migración lógica para clonar un clúster de ApsaraDB RDS for MySQL a un clúster de PolarDB for MySQL de la misma versión o de una versión diferente.

Beneficios

El proceso de clonación no provoca pérdida de datos.

Requisitos previos

• Para la migración física, la instancia de RDS de origen debe cumplir con los siguientes requisitos de versión secundaria. La migración lógica no tiene limitaciones de versión.

  • Para ApsaraDB RDS for MySQL 5.6, la versión secundaria debe ser 20190815 o posterior.

  • Para ApsaraDB RDS for MySQL 5.7, la versión secundaria debe ser 20200331 o posterior.

  Nota

  Ejecute el comando SHOW VARIABLES LIKE '%rds_release_date%'; para comprobar la versión secundaria de la instancia de RDS de origen. Si la versión secundaria es anterior a la requerida, actualícela a la versión más reciente. Para obtener más información, consulte Upgrade the minor engine version.

• La función de clonación con un clic solo es compatible con instancias de RDS de origen que utilizan el motor de almacenamiento InnoDB o X-Engine.

• TDE y SSL no están habilitados en la instancia de RDS de origen. Si alguna de estas funciones está habilitada, cree manualmente una tarea de migración de datos de Data Transmission Service (DTS) para migrar la instancia de RDS de origen a PolarDB. Para obtener más información, consulte Migrate RDS for MySQL to PolarDB for MySQL.

• Si su instancia de RDS se ejecuta en High-Security Mode (con Database Proxy habilitado), debe crear una cuenta con privilegios (consulte Create an account) o cambiar a High-Performance Mode (consulte Upgrade the network connection mode of an ApsaraDB RDS instance) para llevar a cabo la clonación con un clic. En la página Database Connection de la consola de ApsaraDB RDS, puede consultar el estado de Database Proxy, así como el endpoint interno (con el formato InstanceID.mysql.rds.aliyuncs.com) y el puerto del tipo de red actual, como la red clásica.

Limitaciones

• Solo es posible clonar una instancia de ApsaraDB RDS for MySQL a un clúster de PolarDB for MySQL de la misma versión o de una versión posterior. No se admite la reducción de versión.

  Por ejemplo, no se puede clonar una instancia de ApsaraDB RDS for MySQL 5.7 a un clúster de PolarDB for MySQL 5.6, ni una instancia de ApsaraDB RDS for MySQL 8.0.2 a un clúster de PolarDB for MySQL 8.0.1.

• La migración física presenta las siguientes limitaciones:

  • No se admite la migración entre regiones.

  • No se pueden modificar los parámetros de la instancia de RDS de origen durante la migración.

• La migración lógica presenta las siguientes limitaciones:

  • No se admite la migración entre regiones.

  • No se pueden modificar los parámetros de la instancia de RDS de origen durante la migración.

  • La base de datos de origen tiene las siguientes limitaciones:

    Tipo

    Descripción

    Limitaciones de la base de datos de origen

    Las tablas que se sincronicen deben tener una clave primaria o una restricción única, y todos los campos de la restricción deben ser únicos. De lo contrario, podrían existir datos duplicados en la base de datos de destino. Al sincronizar a nivel de tabla y editar objetos (como asignar nombres de columnas), una sola tarea admite hasta 1,000 tablas. Si se supera este límite, se reporta un error al enviar la tarea. En este caso, se recomienda dividir las tablas en varias tareas o configurar una tarea para sincronizar toda la base de datos. Binlog debe estar habilitado y el parámetro binlog_row_image debe establecerse en full. Para obtener más información sobre cómo habilitar Binlog, consulte Modify instance parameters. De lo contrario, la comprobación previa fallará y la tarea de sincronización de datos no podrá iniciarse.

  • Otras limitaciones:

    Tipo

    Descripción

    Otras limitaciones

    Antes de sincronizar los datos, evalúe el rendimiento de las bases de datos de origen y de destino. Se recomienda ejecutar la sincronización de datos durante las horas de menor actividad. La sincronización inicial completa consume recursos de lectura y escritura en ambas bases de datos, lo que podría aumentar su carga. La sincronización inicial completa ejecuta operaciones INSERT concurrentes, lo que puede causar fragmentación en las tablas de la base de datos de destino. Como resultado, el espacio de las tablas en la instancia de destino será mayor que en la instancia de origen después de la sincronización. Si sincroniza tablas individuales en lugar de toda la base de datos, no ejecute cambios DDL en línea en las tablas de origen mediante herramientas como gh-ost o pt-online-schema-change durante la sincronización de datos. Hacerlo provocará que la sincronización falle. Puede utilizar Data Management Service (DMS) para ejecutar cambios DDL en línea. Para obtener más información, consulte Change schemas without locking tables. Durante la sincronización de DTS, no escriba datos en la base de datos de destino desde ninguna fuente distinta de DTS. Esto puede provocar inconsistencias en los datos. Por ejemplo, si utiliza DMS para ejecutar un cambio DDL en línea mientras otra fuente escribe en la base de datos de destino, podría producirse una pérdida de datos. De forma predeterminada, DTS deshabilita las restricciones de claves externas al sincronizar con la base de datos de destino. Por lo tanto, las operaciones en cascada y de eliminación de la base de datos de origen no se sincronizan.

Facturación

• La migración de ApsaraDB RDS a PolarDB es gratuita. Solo se le cobra por el nuevo clúster de PolarDB. Para obtener más información sobre los precios de los clústeres de PolarDB, consulte Billable items.

• Se le cobra por el clúster de PolarDB y por la tarea de sincronización de datos de DTS. Sin embargo, la tarea es gratuita durante los primeros 30 días como parte de una prueba. Esta prueba gratuita no está disponible para cuentas de operadores de redes virtuales (VNO), cuentas Jushita, cuentas del sitio internacional de Alibaba Cloud ni usuarios de RAM (subcuentas). En la siguiente tabla se describen los detalles.

  Objeto de migración	Cargo
  Sincronización de esquemas y datos completos	No se le cobra por la tarea de sincronización durante los 30 días posteriores a su creación. Después de 30 días, la tarea de sincronización se cancela automáticamente. Nota Puede ir a la Data Synchronization Tasks page de la nueva consola de DTS para consultar el tiempo restante de la tarea de sincronización.

En las siguientes secciones se describe cómo clonar una instancia de ApsaraDB RDS for MySQL a un clúster de PolarDB for MySQL.

Comprobaciones previas (solo migración lógica)

Paso 1: Clonar desde una instancia de RDS

Este paso crea un clúster de PolarDB que contiene los mismos datos que la instancia de RDS de origen.

1. Inicie sesión en la consola de PolarDB.

2. En la esquina superior izquierda, seleccione la región donde se despliega el clúster.

3. Haga clic en Create Cluster.

4. Seleccione Billing Method como Subscription, Pay-As-You-Go o Serverless.

   • Subscription: paga las tarifas de los nodos de computación al crear el clúster. El espacio de almacenamiento se factura por hora según el volumen real de datos y se deduce de su cuenta cada hora.

   • Pay-as-you-go: no requiere pago por adelantado. Tanto los nodos de computación como el espacio de almacenamiento (según el volumen real de datos) se facturan por hora y se deducen de su cuenta cada hora.

   • Serverless: no requiere pago por adelantado. Los nodos de computación, el espacio de almacenamiento, el proxy de base de datos y otros recursos escalan dinámicamente según la demanda real durante el uso del clúster, y se facturan de acuerdo con el consumo real.

5. Configure los siguientes parámetros.

   Nota

   Para los parámetros que no se describen detalladamente en la siguiente tabla, consulte la sección correspondiente en Purchase a cluster.

   Parámetro	Descripción
   Creation Method	Seleccione Clone from RDS.
   Region	Seleccione la región donde se encuentra la instancia de ApsaraDB RDS for MySQL de origen. Nota El nuevo clúster de PolarDB también se creará en esta región.
   Source RDS Version	La versión de la instancia de RDS de origen. Puede seleccionar 5.6, 5.7 o 8.0.
   Source RDS Instance	Seleccione la instancia de RDS de origen. Las instancias de solo lectura no aparecen en la lista.
   Database Engine	La versión del motor de base de datos para el clúster de PolarDB de destino. Puede seleccionar la misma versión que la instancia de RDS de origen o una versión diferente.
   Node Specifications	Seleccione una especificación según sus necesidades empresariales. Se recomienda elegir una especificación igual o superior a la de la instancia de RDS de origen. Para obtener más información sobre las especificaciones de nodos de PolarDB, consulte Compute node specifications for Enterprise Edition.

6. En la esquina superior derecha, revise la configuración del clúster. Establezca Subscription Duration (para clústeres de Subscription ), Quantity y si desea habilitar Auto-renewal.

7. Lea y acepte el Service Agreement. Haga clic en Buy Now.

8. En la página Payment , confirme los detalles del pedido pendiente y el método de pago, y luego haga clic en Place Order .

   Nota

   • Después de realizar el pago correctamente, la creación del clúster tarda entre 10 y 15 minutos. Luego podrá ver el nuevo clúster en Cluster List .

   • Si los nodos del clúster muestran Creating , significa que aún no está listo. Solo podrá utilizarlo cuando el estado del clúster sea Running .

   • Asegúrese de haber seleccionado la región correcta. De lo contrario, no verá su clúster.

   • Si la comprobación previa falla, el clúster de destino permanece en el estado Creating y la actualización no puede continuar automáticamente. Resuelva el error de la comprobación previa según el mensaje de error y, a continuación, haga clic en Continue Upgrade para continuar. En este caso, la creación del clúster puede tardar más de 15 minutos, lo cual es normal.

9. Inicie sesión en la consola de PolarDB y consulte el estado del nuevo clúster de PolarDB.

   Nota

   Si utiliza la migración lógica, haga clic en el ID del clúster para ir a la página Basic Information y compruebe el estado de la migración. Si el estado de la migración de RDS cambia a Pre-check failed, siga las instrucciones de la sección Error Message para resolver el problema.

   Por ejemplo, si existen disparadores (triggers) en la instancia de RDS de origen, la comprobación previa fallará con el error "RDS instance has triggers". Elimine primero los disparadores de la instancia de RDS de origen y luego haga clic en Continue migrating, o bien haga clic en Give up migration y cree manualmente una tarea de migración en la consola de DTS. Para obtener más información, consulte Configure tasks for source databases with triggers.

   También puede seleccionar Give up migration en este paso. Para obtener información sobre los impactos, consulte FAQ.

Paso 2: Consultar los detalles de la sincronización de datos (solo migración lógica)

Si utiliza la migración lógica, haga clic en el ID del clúster para ir a la página Basic Information y compruebe el estado de la migración. Si se produce un error de migración (como un fallo en la comprobación previa) u otra excepción (como una latencia alta de replicación), puede ir a la página de detalles de la tarea de sincronización de datos de DTS correspondiente para consultar la información específica.

1. Vaya a la consola de PolarDB.

2. Busque el clúster de destino y haga clic en su ID.

3. En la página Basic Information, dentro de la sección RDS Migration, haga clic en el nombre de la tarea bajo DTS Data Synchronization Task para ir a la lista de sincronización de datos en la consola de DTS.

4. Busque la tarea de sincronización de datos correspondiente. Allí podrá consultar los detalles del fallo de la comprobación previa, los detalles de la tarea y sus registros.

   En la página de detalles de la tarea, la sección Task Progress muestra el estado de ejecución de cuatro etapas: comprobación previa, migración de esquema 1, migración completa y migración de esquema 2. Haga clic en la pestaña Check Items para consultar la tasa de éxito de la comprobación previa y los resultados de cada elemento verificado, incluidas las comprobaciones de conectividad y permisos de las bases de datos de origen y de destino. La comprobación previa es exitosa si todos los elementos se aprueban.

Preguntas frecuentes

• P: ¿Cuál es la diferencia entre upgrading an ApsaraDB RDS for MySQL instance y la clonación con un clic de una instancia de ApsaraDB RDS for MySQL a un clúster de PolarDB for MySQL?

  R: En la siguiente tabla se describen las diferencias.

  Elemento	One-click upgrade	Clonación con un clic de ApsaraDB RDS for MySQL a PolarDB for MySQL
  Migración de datos incrementales	Compatible	No compatible
  Impacto en las operaciones de RDS de origen	Sin impacto	Sin impacto
  Migración entre versiones	Compatible	Compatible

• P: ¿La clonación desde RDS afecta a la instancia de RDS de origen?

  R: La clonación no afecta el funcionamiento normal de la instancia de RDS de origen. Sin embargo, el proceso de clonación completa consume algunos recursos de dicha instancia.

• P: ¿Cuáles son los impactos de cancelar la migración?

  R: Cancelar la migración tiene los siguientes impactos:

  • El enlace de sincronización entre el clúster de origen y el clúster de destino se desconecta, y ambos clústeres dejan de estar asociados.

  • El clúster de destino vuelve al estado de lectura y escritura, y no se libera automáticamente. Si ya no necesita el clúster, libérelo lo antes posible para evitar cargos adicionales.

  • Cuando cancele la migración manualmente, podrá elegir si desea deshabilitar el registro binario (Binlog) del clúster. Si la migración se cancela automáticamente, Binlog no se deshabilita.

    Nota

    Deshabilitar Binlog mejora ligeramente el rendimiento de escritura. Una vez deshabilitado, los archivos de Binlog existentes se conservan. Puede acortar primero el periodo de retención de dichos archivos, esperar a que los innecesarios se eliminen automáticamente y luego deshabilitar Binlog. Después de deshabilitarlo, el clúster se reinicia automáticamente. La tarea de reinicio se completa en menos de 5 minutos, y el servicio se desconecta de forma transitoria durante unos 40 segundos. La duración exacta depende del volumen de datos y de la cantidad de tablas. Se recomienda ejecutar esta operación durante las horas de menor actividad y asegurarse de que su aplicación cuente con un mecanismo de reconexión.

Referencia de API

Pasos siguientes

Actualice la dirección de conexión a la base de datos de su aplicación por la dirección de PolarDB. Para obtener más información, consulte Manage endpoints.