ApsaraDB for ClickHouse:Migrate data between ClickHouse community-compatible clusters

• Los clústeres de origen y de destino deben cumplir los siguientes requisitos:

  • Ambos deben ser clústeres de la edición compatible con la comunidad.

    Nota

    Si necesita migrar de un clúster de la edición compatible con la comunidad a uno de la edición empresarial, o viceversa, consulte Migrate a ClickHouse community-compatible edition cluster to an enterprise edition cluster.

  • Ambos clústeres se encuentran en estado Running.

  • Cuenta con una cuenta de base de datos y una contraseña para cada clúster.

  • Ambos clústeres tienen la misma política de almacenamiento por niveles para datos calientes y fríos.

  • Ambos clústeres utilizan la misma VPC, se encuentran en la misma región y sus direcciones IP están incluidas mutuamente en sus listas blancas. Si no se cumple esta condición, primero debe resolver el problema de conectividad de red. Para obtener más información, consulte How to resolve network connectivity issues between a destination cluster and a data source.

    Nota

    Puede consultar la dirección IP de una instancia de Alibaba Cloud ClickHouse mediante la ejecución del comando SELECT * FROM system.clusters;. Para obtener información sobre cómo configurar una lista blanca, consulte Configure a whitelist.

• El clúster de destino también debe cumplir los siguientes requisitos:

  • La versión es posterior o igual a la versión del clúster de origen. Para obtener información sobre la versión más reciente, consulte Community-compatible edition.

  • El espacio disponible en disco (excluyendo el almacenamiento en frío) es como mínimo 1.2 veces el espacio utilizado en disco (excluyendo el almacenamiento en frío) del clúster de origen.

• Cada tabla local en el clúster de origen debe tener una tabla distribuida única.

Paso 1: Registrar y limpiar las tablas con motor Kafka/RabbitMQ

Antes de iniciar la migración, registre las definiciones de todas las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes en el clúster de origen, gestione las tablas implícitas y luego elimine dichas tablas para evitar errores de migración.

1. Inicie sesión en el clúster de origen y consulte todas las tablas con motor Kafka y RabbitMQ junto con sus dependencias posteriores.

   /*
   create_table_query: table definition
   dependencies_database: database of the table that depends on this table
   dependencies_table: table that depends on this table
   From dependencies_database and dependencies_table, you can identify the materialized views that depend on Kafka/RabbitMQ tables
   */
   SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

2. Consulte la definición de la vista materializada para verificar si su tabla de destino es una tabla implícita.

   /*
   View the materialized view definition.
   If the target table of the materialized view is an implicit table, pay special attention:
   Dropping the materialized view will also drop the implicit table, causing data loss.
   Example: If CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name] does not specify TO,
   the system automatically creates an implicit table, possibly in the format '.inner_id.<TABLE_UUID>' or '.inner.<TABLE>'
   */
   SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

3. Si la tabla de destino de una vista materializada es una tabla implícita, cambie el nombre (RENAME) de la tabla de destino a uno nuevo para evitar la pérdida de datos cuando se elimine la vista materializada posteriormente.

   -- Rename the implicit target table to a new name to protect data
   RENAME TABLE <DATABASE>.`.inner_id.<TABLE_UUID>` TO <DATABASE>.<new_target_table_name>;

4. Elimine las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes.

   -- Drop materialized views first
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- Then drop Kafka/RabbitMQ engine tables
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

Paso 2: Crear una tarea de migración

1. Inicie sesión en la consola de Alibaba Cloud ClickHouse.

2. En la página Clusters, haga clic en la pestaña Clusters of Community-compatible Edition y luego haga clic en el ID del clúster de destino.

3. En el panel de navegación izquierdo, haga clic en Data Migration and Synchronization > Migration from ClickHouse.

4. Haga clic en Create Migration Task.

   1. Configure las instancias de origen y de destino.

      Configure la información requerida y haga clic en Test Connectivity and Proceed.

      Nota

      Si la prueba de conexión es exitosa, continúe con el siguiente paso. Si la prueba falla, vuelva a configurar las instancias de origen y de destino según las indicaciones.

      • Source Instance: Seleccione el source access method (como Express Connect/VPN Gateway/Smart Access Gateway/ECS-hosted ClickHouse) y luego especifique Instance Region, Cluster Name, Source Cluster Name, VPC IP Address, Database Account y Database Password.

      • Destination Instance: Especifique Instance Region, Instance ID, Database Account y Database Password.

   2. Confirme el contenido de la migración.

      Revise el contenido de la migración y luego haga clic en Next: Pre-detect and Start Synchronization.

   3. El sistema ejecuta una verificación previa e inicia la tarea.

      El sistema realiza la Instance Status Detection, la Storage Space Detection y la Local Table and Distributed Table Detection en las instancias de origen y de destino.

      • Si la verificación previa es exitosa:

        1. Revise el impacto en las instancias durante la migración.

        2. Establezca la Time of Stopping Data Writing.

           Nota

           • Las escrituras en el clúster de origen deben detenerse durante los últimos 10 minutos de la migración para garantizar la consistencia de los datos.

           • Para garantizar una alta tasa de éxito, se recomienda establecer la duración de detención de escritura en al menos 30 minutos.

           • Una tarea de migración debe completarse dentro de los cinco días posteriores a su creación. Por lo tanto, la fecha de finalización para la Time of Stopping Data Writing debe ser a más tardar current date + 5 days.

           • Para minimizar el impacto en su negocio, se recomienda establecer la ventana de detención de escritura durante las horas de menor actividad.

        3. Haga clic en Completed.

           Nota

           Después de hacer clic en este botón, la tarea se crea e inicia.

      • Si la verificación previa falla, siga las indicaciones para resolver los problemas y reintente la migración de datos. La siguiente tabla describe los elementos de verificación previa y sus requisitos.

        Elemento de verificación	Requisito
        Instance Status Detection	Asegúrese de que no haya tareas de gestión, como escalado o cambios de configuración, ejecutándose en el clúster de origen o de destino. No puede iniciar la migración si hay una tarea en curso.
        Storage Space Detection	El espacio de almacenamiento disponible del clúster de destino debe ser al menos 1.2 veces el espacio de almacenamiento utilizado del clúster de origen.
        Local Table and Distributed Table Detection	La verificación falla si una tabla local en el clúster de origen no tiene una tabla distribuida correspondiente o si la tabla distribuida no es única. Debe eliminar cualquier tabla distribuida adicional o crear una tabla distribuida única para cada tabla local.

Paso 3: Evaluar la finalización de la migración

Si la velocidad de escritura del clúster de origen es menor que 20 MB/s, puede omitir este paso.

Si la velocidad de escritura del clúster de origen es mayor que 20 MB/s, debe verificar la velocidad de escritura real del clúster de destino para evaluar si la migración puede completarse. La velocidad de escritura del clúster de destino debe poder igualar la del clúster de origen. Para ello, siga estos pasos:

1. Verifique el rendimiento del disco del clúster de destino para determinar su velocidad de escritura real. Para obtener más información, consulte View cluster monitoring information.

2. Compare las velocidades de escritura de los clústeres de destino y de origen.

   1. Si la velocidad de escritura del clúster de destino es mayor que la del clúster de origen, es muy probable que la migración sea exitosa. Continúe con el Paso 4.

   2. Si la velocidad de escritura del clúster de destino es menor que la del clúster de origen, es muy probable que la migración falle. Se recomienda cancel the migration task y realizar una manual migration.

Paso 4: Consultar la tarea de migración

1. En la página Clusters, haga clic en la pestaña Clusters of Community-compatible Edition y luego haga clic en el ID del clúster de destino.

2. En el panel de navegación izquierdo, haga clic en Data Migration and Synchronization > Migration from ClickHouse.

   En la página de lista de migración de instancias, consulte el Migration Status, la Running Information y la Data Write-Stop Window de la tarea.

   Nota

   Cuando el tiempo restante estimado en la columna Running Information es de 10 minutos o menos y el Migration Status es Migrating, se activa una detención de escritura en el clúster de origen para garantizar la consistencia de los datos. Las reglas son las siguientes:

   • Si el momento de activación está dentro de la ventana de detención de escritura configurada, se detienen las escrituras en el clúster de origen.

   • Si el momento de activación está fuera de la ventana de detención de escritura configurada pero es igual o anterior a la task start (that is, task creation) date + 5 days, puede modificar la ventana de detención de escritura para continuar la migración.

   • Si el momento de activación está fuera de la ventana de detención de escritura configurada y es posterior a la task start (that is, task creation) date + 5 days, la migración falla. Debe cancelar la tarea de migración, borrar los datos migrados del clúster de destino y crear una nueva tarea de migración.

   Importante

   • Si el clúster de origen contiene tablas con motor Kafka/RabbitMQ: cuando la tarea de migración entra en la fase de data migration (es decir, la migración del esquema de tablas ha terminado), realice el Paso 5 para reconstruir las tablas con motor Kafka/RabbitMQ en el clúster de origen, de modo que los datos incrementales reanuden su flujo y se sincronicen con el clúster de destino.

   • Poco antes de la ventana de detención de escritura configurada, realice el Paso 6 para eliminar las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes en el clúster de origen, a fin de evitar que la acumulación de mensajes durante el periodo de detención de escritura cause inconsistencia en los datos.

Paso 5: Reconstruir las tablas con motor Kafka/RabbitMQ en el clúster de origen

Después de que la tarea de migración entre en la fase de data migration (es decir, la migración del esquema de tablas ha terminado), utilice las sentencias DDL guardadas previamente para reconstruir las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes en el clúster de origen. Una vez reconstruidas, los datos incrementales reanudarán su flujo y se sincronizarán automáticamente con el clúster de destino.

-- Rebuild Kafka/RabbitMQ engine tables on the source cluster
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Rebuild materialized view (pointing to the renamed target table)
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Paso 6: Eliminar las tablas con motor Kafka/RabbitMQ en el clúster de origen

Poco antes de la ventana de detención de escritura configurada, elimine las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes en el clúster de origen para detener la escritura de datos incrementales y garantizar la consistencia de la sincronización final de datos.

-- Delete materialized views first
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then delete Kafka/RabbitMQ engine tables
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

Paso 7: Reconstruir las tablas con motor Kafka/RabbitMQ en el clúster de destino

Una vez completada la tarea de migración, utilice las sentencias DDL guardadas previamente para reconstruir las tablas con motor Kafka/RabbitMQ y sus vistas materializadas dependientes en el clúster de destino, a fin de restaurar la canalización de consumo de datos incrementales.

-- Rebuild Kafka/RabbitMQ engine tables on the destination cluster
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Rebuild materialized view
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Paso 8: (Opcional) Cancelar la tarea de migración

1. En la página Clusters, haga clic en la pestaña Clusters of Community-compatible Edition y luego haga clic en el ID del clúster de destino.

2. En el panel de navegación izquierdo, haga clic en Data Migration and Synchronization > Migration from ClickHouse.

3. En la columna Actions de la tarea de migración, haga clic en Cancel Migration.

4. En el cuadro de diálogo Cancel Migration, haga clic en OK.

   Nota

   • Después de cancelar la migración, la lista de tareas no se actualiza inmediatamente. Actualice la página periódicamente para verificar el estado de la tarea.

   • Una vez cancelada la tarea, su Migration Status cambia a Completed.

   • Antes de iniciar una nueva migración, debe borrar los datos migrados del clúster de destino para evitar la duplicación de datos.

Paso 9: (Opcional) Modificar la ventana de detención de escritura

1. En la página Clusters, haga clic en la pestaña Clusters of Community-compatible Edition y luego haga clic en el ID del clúster de destino.

2. En el panel de navegación izquierdo, haga clic en Data Migration and Synchronization > Migration from ClickHouse.

3. En la columna Actions de la tarea de migración, haga clic en Modify Data Write-Stop Time Window.

4. En el cuadro de diálogo Modify Data Write-Stop Time Window, seleccione una nueva Time of Stopping Data Writing.

   Nota

   Las reglas para establecer la Time of Stopping Data Writing son las mismas que para crear una tarea de migración.

5. Haga clic en OK.