ApsaraDB for ClickHouse:Migrar dados entre clusters compatíveis com a comunidade do ClickHouse

• Os clusters de origem e de destino devem atender aos seguintes requisitos:

  • Ambos devem ser clusters da edição compatível com a comunidade.

    Nota

    Caso precise migrar de um cluster da edição compatível com a comunidade para um cluster da edição empresarial, ou vice-versa, consulte Migrate a ClickHouse community-compatible edition cluster to an enterprise edition cluster.

  • Ambos os clusters devem estar no estado Running.

  • Você deve ter uma conta de banco de dados e senha para cada cluster.

  • Os dois clusters precisam compartilhar a mesma política de armazenamento em camadas para dados quentes e frios.

  • Os clusters devem usar a mesma VPC, estar na mesma região e ter seus endereços IP incluídos nas listas de permissões mútuas. Se essa condição não for atendida, resolva primeiro o problema de conectividade de rede. Para mais informações, consulte How to resolve network connectivity issues between a destination cluster and a data source.

    Nota

    Para visualizar o endereço IP de uma instância do Alibaba Cloud ClickHouse, execute o comando SELECT * FROM system.clusters;. Para obter detalhes sobre como configurar uma lista de permissões, consulte Configure a whitelist.

• O cluster de destino também deve cumprir os requisitos abaixo:

  • A versão deve ser posterior ou igual à versão do cluster de origem. Para informações sobre a versão mais recente, consulte Community-compatible edition.

  • O espaço em disco disponível (excluindo o cold storage) deve ser pelo menos 1,2 vezes maior que o espaço em disco utilizado (excluindo o cold storage) do cluster de origem.

• Cada tabela local no cluster de origem precisa ter uma tabela distribuída exclusiva.

Etapa 1: Registrar e limpar tabelas com engine Kafka/RabbitMQ

Antes de iniciar a migração, registre as definições de todas as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes no cluster de origem, trate as tabelas implícitas e, em seguida, exclua essas tabelas para evitar erros de migração.

1. Faça login no cluster de origem e consulte todas as tabelas com engines Kafka e RabbitMQ, bem como suas dependências downstream.

   /*
   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. Visualize a definição da visualização materializada para verificar se sua tabela de destino é uma tabela 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. Caso a tabela de destino de uma visualização materializada seja implícita, renomeie-a para evitar perda de dados quando a visualização for excluída 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. Exclua as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes.

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

Etapa 2: Criar uma tarefa de migração

1. Faça login no console do Alibaba Cloud ClickHouse.

2. Na página Clusters, clique na aba Clusters of Community-compatible Edition e, em seguida, clique no ID do cluster de destino.

3. No painel de navegação à esquerda, clique em Data Migration and Synchronization > Migration from ClickHouse.

4. Clique em Create Migration Task.

   1. Configure as instâncias de origem e de destino.

      Preencha as informações necessárias e clique em Test Connectivity and Proceed.

      Nota

      Se o teste de conexão for bem-sucedido, prossiga para a próxima etapa. Em caso de falha, reconfigure as instâncias de origem e de destino conforme as instruções exibidas.

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

      • Destination Instance: Especifique a Instance Region, o Instance ID, a Database Account e a Database Password.

   2. Confirme o conteúdo da migração.

      Revise o conteúdo a ser migrado e clique em Next: Pre-detect and Start Synchronization.

   3. O sistema executa uma verificação prévia e inicia a tarefa.

      O sistema realiza a Instance Status Detection, a Storage Space Detection e a Local Table and Distributed Table Detection nas instâncias de origem e de destino.

      • Se a verificação prévia for bem-sucedida:

        1. Analise o impacto nas instâncias durante a migração.

        2. Defina o Time of Stopping Data Writing.

           Nota

           • As gravações no cluster de origem devem ser interrompidas nos últimos 10 minutos da migração para garantir a consistência dos dados.

           • Para assegurar uma alta taxa de sucesso, recomenda-se definir a duração da parada de gravação em pelo menos 30 minutos.

           • Uma tarefa de migração deve ser concluída em até cinco dias após sua criação. Portanto, a data final para o Time of Stopping Data Writing deve ser no máximo current date + 5 days.

           • Para minimizar o impacto no seu negócio, configure a janela de parada de gravação durante o horário de menor movimento.

        3. Clique em Completed.

           Nota

           Após clicar neste botão, a tarefa é criada e iniciada.

      • Se a verificação prévia falhar, siga as instruções para resolver os problemas e tente novamente a migração de dados. A tabela a seguir descreve os itens verificados e seus respectivos requisitos.

        Item de verificação	Requisito
        Instance Status Detection	Garanta que nenhuma tarefa de gerenciamento, como dimensionamento ou alterações de configuração, esteja em execução no cluster de origem ou de destino. Não é possível iniciar a migração se houver uma tarefa em andamento.
        Storage Space Detection	O espaço de armazenamento disponível no cluster de destino deve ser pelo menos 1,2 vezes maior que o espaço utilizado no cluster de origem.
        Local Table and Distributed Table Detection	A verificação falha se uma tabela local no cluster de origem não tiver uma tabela distribuída correspondente ou se a tabela distribuída não for exclusiva. É necessário excluir tabelas distribuídas extras ou criar uma tabela distribuída exclusiva para cada tabela local.

Etapa 3: Avaliar a conclusão da migração

Se a velocidade de gravação do cluster de origem for inferior a 20 MB/s, pule esta etapa.

Caso a velocidade de gravação do cluster de origem seja superior a 20 MB/s, verifique a velocidade real de gravação do cluster de destino para avaliar se a migração será concluída. A velocidade de gravação do destino precisa acompanhar a da origem. Para isso, siga estes passos:

1. Verifique o throughput de disco do cluster de destino para determinar sua velocidade real de gravação. Para mais informações, consulte View cluster monitoring information.

2. Compare as velocidades de gravação dos clusters de destino e de origem.

   1. Se a velocidade de gravação do cluster de destino for maior que a do cluster de origem, há alta probabilidade de sucesso na migração. Prossiga para a Etapa 4.

   2. Se a velocidade de gravação do cluster de destino for menor que a do cluster de origem, há alta probabilidade de falha na migração. Recomendamos que você cancel the migration task e realize uma manual migration.

Etapa 4: Visualizar a tarefa de migração

1. Na página Clusters, clique na aba Clusters of Community-compatible Edition e, em seguida, clique no ID do cluster de destino.

2. No painel de navegação à esquerda, clique em Data Migration and Synchronization > Migration from ClickHouse.

   Na página da lista de migração de instâncias, visualize o Migration Status, as Running Information e a Data Write-Stop Window da tarefa.

   Nota

   Quando o tempo restante estimado na coluna Running Information for de 10 minutos ou menos e o Migration Status for Migrating, uma parada de gravação é acionada no cluster de origem para garantir a consistência dos dados. As regras são as seguintes:

   • Se o momento do acionamento estiver dentro da janela de parada de gravação configurada, as gravações no cluster de origem são interrompidas.

   • Se o momento do acionamento estiver fora da janela de parada de gravação configurada, mas for igual ou anterior à task start (that is, task creation) date + 5 days, modifique a janela de parada de gravação para continuar a migração.

   • Se o momento do acionamento estiver fora da janela de parada de gravação configurada e for posterior à task start (that is, task creation) date + 5 days, a migração falha. Cancele a tarefa de migração, limpe os dados migrados do cluster de destino e crie uma nova tarefa.

   Importante

   • Se o cluster de origem contiver tabelas com engine Kafka/RabbitMQ: quando a tarefa de migração entrar na fase de data migration (ou seja, a migração do esquema da tabela estiver concluída), execute a Etapa 5 para reconstruir as tabelas com engine Kafka/RabbitMQ no cluster de origem, permitindo que os dados incrementais voltem a fluir e sejam sincronizados com o cluster de destino.

   • Pouco antes da janela de parada de gravação configurada, execute a Etapa 6 para excluir as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes no cluster de origem, evitando que o acúmulo de mensagens durante o período de parada cause inconsistência nos dados.

Etapa 5: Reconstruir tabelas com engine Kafka/RabbitMQ no cluster de origem

Depois que a tarefa de migração entrar na fase de data migration (isto é, após a conclusão da migração do esquema das tabelas), use as instruções DDL salvas anteriormente para reconstruir as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes no cluster de origem. Após a reconstrução, o fluxo de dados incrementais é retomado e sincronizado automaticamente com o cluster 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>;

Etapa 6: Excluir tabelas com engine Kafka/RabbitMQ no cluster de origem

Pouco antes da janela de parada de gravação configurada, exclua as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes no cluster de origem para interromper as gravações de dados incrementais e garantir a consistência da sincronização final dos dados.

-- 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;

Etapa 7: Reconstruir tabelas com engine Kafka/RabbitMQ no cluster de destino

Após a conclusão da tarefa de migração, use as instruções DDL salvas anteriormente para reconstruir as tabelas com engine Kafka/RabbitMQ e suas visualizações materializadas dependentes no cluster de destino, restaurando assim o pipeline de consumo de dados incrementais.

-- 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>;

Etapa 8: (Opcional) Cancelar a tarefa de migração

1. Na página Clusters, clique na aba Clusters of Community-compatible Edition e, em seguida, clique no ID do cluster de destino.

2. No painel de navegação à esquerda, clique em Data Migration and Synchronization > Migration from ClickHouse.

3. Na coluna Actions da tarefa de migração, clique em Cancel Migration.

4. Na caixa de diálogo Cancel Migration, clique em OK.

   Nota

   • Após cancelar a migração, a lista de tarefas não é atualizada imediatamente. Atualize a página periodicamente para verificar o status da tarefa.

   • Depois que a tarefa for cancelada, seu Migration Status mudará para Completed.

   • Antes de iniciar uma nova migração, limpe os dados migrados do cluster de destino para evitar duplicidade.

Etapa 9: (Opcional) Modificar a janela de parada de gravação

1. Na página Clusters, clique na aba Clusters of Community-compatible Edition e, em seguida, clique no ID do cluster de destino.

2. No painel de navegação à esquerda, clique em Data Migration and Synchronization > Migration from ClickHouse.

3. Na coluna Actions da tarefa de migração, clique em Modify Data Write-Stop Time Window.

4. Na caixa de diálogo Modify Data Write-Stop Time Window, selecione um novo Time of Stopping Data Writing.

   Nota

   As regras para definir o Time of Stopping Data Writing são as mesmas aplicadas na criação de uma tarefa de migração.

5. Clique em OK.