ApsaraDB for ClickHouse:Migrar de ClickHouse autogerenciado para Cloud ClickHouse

Durante a migração

• Durante a migração, o processo de merge é pausado no cluster de destino, mas continua no cluster autogerenciado.

  Nota

  Se uma tarefa de migração durar muito tempo, pode haver acúmulo excessivo de metadados no cluster de destino. Recomendamos que as tarefas de migração não excedam 5 dias de duração. Tarefas que ultrapassam 5 dias são canceladas automaticamente.

• O cluster de destino deve ser o cluster default. Se o seu cluster autogerenciado usar um nome diferente, o service converte automaticamente a definição de cluster nas tabelas distribuídas para default.

Escopo da migração

• Objetos suportados

  • Bancos de dados, dicionários de dados e materialized views.

    • Este service suporta a migração de dicionários de dados criados com SQL, mas não aqueles criados com XML.

      Para verificar isso, execute a seguinte instrução: SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database);. Se a instrução retornar linhas, isso indica que você possui dicionários de dados criados usando XML.

    • Quando um dicionário de dados acessa um service externo, garanta que o service externo esteja disponível e que o cluster esteja adicionado à sua lista de permissões. Se a fonte de dados de um dicionário de dados for uma tabela interna no cluster ClickHouse atual e o parâmetro HOST na definição for um endereço IP, o acesso ao dicionário poderá falhar após a migração devido à alteração do endereço IP. Reconfirme o HOST do cluster ClickHouse atual e crie o dicionário de dados manualmente.

  • Esquemas de tabela: Todos os esquemas de tabela, exceto tabelas com engines Kafka e RabbitMQ.

  • Dados: Migração incremental de dados de tabelas da família MergeTree.

• Objetos e dados não suportados

  • Tabelas com engines Kafka e RabbitMQ, e seus dados.

  • Dados de tabelas não-MergeTree, como tabelas externas e tabelas Log.

  Importante

  Migre manualmente os itens não suportados listados acima.

• Limites de volume de dados

  • Dados frios: A migração de dados frios é lenta. Para evitar falhas causadas por tempos de migração longos, recomendamos limpar os dados frios do seu cluster autogerenciado para garantir que o volume total não exceda 1 TB.

  • Dados quentes: Se o volume de dados quentes exceder 10 TB, é provável que a tarefa de migração falhe.

  Se o volume de dados exceder esses limites, considere usar a solução manual migration.

Etapa 1: Verificar o cluster e ativar tabelas de sistema

Antes de migrar dados, modifique o arquivo config.xml no seu cluster autogerenciado para ativar a migração incremental. As modificações necessárias dependem de as tabelas system.part_log e system.query_log estarem ativadas.

<part_log>
    <database>system</database>
    <table>part_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

<query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

Etapa 2: Configurar compatibilidade do cluster de destino

Etapa 3: (Opcional) Ativar a engine MaterializedMySQL

Se o seu cluster autogerenciado contiver tabelas que usam a engine MaterializedMySQL, execute a seguinte instrução para ativar essa engine.

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

Etapa 4: Registrar e limpar tabelas com engines Kafka/RabbitMQ

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

1. Faça logon no cluster autogerenciado e consulte todas as tabelas com engines Kafka e RabbitMQ, juntamente com suas dependências.

   /*
   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 materialized view 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. Se a tabela de destino de uma materialized view for uma tabela implícita, renomeie a tabela de destino para um novo nome para evitar perda de dados quando a materialized view 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 engines Kafka/RabbitMQ e suas materialized views 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 5: Criar uma tarefa de migração de dados

1. Faça logon no console do ApsaraDB for ClickHouse.

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

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

4. Na página de tarefas de migração, clique em Create Migration Task.

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

      Defina as seguintes configurações e clique em Test Connectivity and Proceed.

      Nota

      Se o teste de conexão for bem-sucedido, prossiga para a próxima etapa. Se o teste de conexão falhar, reconfigure as instâncias de origem e destino com base nas mensagens exibidas.

      Parâmetros do cluster de origem

      Parâmetro	Descrição	Exemplo
      Source Access Method	Selecione Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance.	Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance
      Cluster Name	O nome do cluster de origem. O nome pode conter apenas dígitos e letras minúsculas.	source
      Source Cluster Name	Execute SELECT * FROM system.clusters; para obter o Source Cluster Name.	default
      VPC IP Address	O endereço IP e PORTA (endereço TCP) de cada shard no cluster, separados por vírgulas. Importante Não é possível usar o nome de domínio VPC ou o endereço SLB de um cluster ApsaraDB for ClickHouse. Formato: IP:PORT,IP:PORT,...... O método para obter o endereço IP e a PORTA do cluster varia dependendo do cenário de migração de dados. Migração entre contas ou entre regiões Use a seguinte instrução SQL para obter o endereço IP e a PORTA do cluster autogerenciado: SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = 'default' and replica_num = 1; Aqui, replica_num=1 seleciona o primeiro conjunto de réplicas. Você também pode escolher outros conjuntos de réplicas ou selecionar uma réplica de cada shard. Migração de ClickHouse fora da Alibaba Cloud Se o endereço IP não puder ser facilmente mapeado para a Alibaba Cloud, use a seguinte instrução SQL para obter o endereço IP e a PORTA do cluster autogerenciado: SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = '<cluster_name>' and replica_num = 1; Os parâmetros são descritos da seguinte forma: cluster_name: o nome do cluster de destino. replica_num=1 seleciona o primeiro conjunto de réplicas. Você também pode escolher outros conjuntos de réplicas ou selecionar uma réplica de cada shard. Se o endereço IP e a porta forem mapeados para a Alibaba Cloud por meio de tradução de rede, configure o endereço IP e a porta mapeados correspondentes.	192.168.0.5:9000,192.168.0.6:9000
      Database Account	A conta de banco de dados do cluster de origem.	test
      Database Password	A senha da conta de banco de dados do cluster de origem.	test

      Parâmetros do cluster de destino

      Parâmetro	Descrição	Exemplo
      Database Account	A conta de banco de dados do cluster de destino.	test
      Database Password	A senha da conta de banco de dados do cluster de destino.	test

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

      Revise cuidadosamente as informações sobre os dados a serem migrados na página e, em seguida, clique em Next: Pre-detect and Start Synchronization.

   3. O sistema executa uma pré-verificação no link de migração em segundo plano e inicia a tarefa.

      O sistema executa uma Instance Status Detection, uma Storage Space Detection e uma Local Table and Distributed Table Detection nos clusters de origem e destino.

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

        Após o sucesso da pré-verificação, a página mostra que três verificações foram aprovadas: Instance status check, Storage space check e Local table and distributed table check. O topo da página mostra que o tempo estimado de migração é de 2 minutos e descreve os impactos durante a migração:

        • A instância de origem permite leitura e escrita, mas operações DDL não podem ser realizadas.

        • A instância de destino permite leitura, mas não é possível gravar nas tabelas migradas.

        • Quando o tempo restante for inferior a 10 minutos, pare as gravações para acionar o fim da migração.

        • Tabelas não-MergeTree retêm apenas a estrutura da tabela sem migração de dados após o dimensionamento.

        1. Revise cuidadosamente como o processo de migração de dados afeta as instâncias.

        2. Clique em Completed.

           Importante

           • Ao clicar em Complete, o sistema cria e inicia a tarefa, e seu status muda para Running. Visualize a tarefa na lista de tarefas.

           • Após criar a tarefa, monitore-a. Na fase final da migração, pare as operações de escrita no cluster autogerenciado e migre os esquemas de banco de dados e tabelas restantes. Para mais informações, consulte Monitor the migration task and stop writes to the self-managed cluster.

      • Se a pré-verificação falhar: Siga as instruções na mensagem de erro e execute a tarefa de migração de dados novamente. A tabela a seguir descreve os itens de pré-verificação e seus requisitos. Para mais informações sobre mensagens de erro de pré-verificação e suas soluções, consulte Migration precheck errors and solutions.

        Item de verificação	Requisito
        Instance Status Detection	A tarefa de migração de dados não pode iniciar se tarefas de gerenciamento (como scale-out, upgrade ou downgrade) estiverem em execução no cluster de origem ou destino.
        Storage Space Detection	O espaço de armazenamento disponível do cluster de destino deve ser pelo menos 1,2 vezes o espaço de armazenamento utilizado do cluster autogerenciado.
        Local Table and Distributed Table Detection	Se uma tabela local no cluster autogerenciado não tiver uma tabela distribuída correspondente ou tiver mais de uma tabela distribuída, a verificação falha. Para resolver isso, exclua as tabelas distribuídas redundantes ou crie uma tabela distribuída única para a tabela local.

Etapa 8: Recriar tabelas com engines Kafka/RabbitMQ no cluster autogerenciado

Depois que a tarefa de migração entrar na fase de migração de dados (ou seja, a migração do esquema da tabela estiver concluída), use as instruções DDL salvas anteriormente para recriar as tabelas com engines Kafka/RabbitMQ e suas materialized views dependentes no cluster autogerenciado. Uma vez recriadas, os dados incrementais voltam a fluir e são sincronizados automaticamente com o cluster de destino.

-- Rebuild Kafka/RabbitMQ engine tables on the self-managed 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 9: Parar gravações e realizar o cutover

Quando o tempo restante estimado para a migração for inferior a 10 minutos ou o progresso da migração atingir 99%, execute as seguintes etapas de cutover:

1. Pare as gravações de negócio. No cluster autogerenciado, exclua as tabelas com engines Kafka/RabbitMQ recriadas anteriormente e suas materialized views 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>;

2. Aguarde até que o progresso da migração atinja 100% e a migração seja totalmente concluída.

3. Conecte-se ao cluster de destino e use as instruções DDL salvas anteriormente para recriar as tabelas com engines Kafka/RabbitMQ e suas materialized views dependentes.

   Importante

   Se você realizou uma operação RENAME em tabelas de destino implícitas anteriormente, use a cláusula TO apontando para a tabela de destino renomeada ao recriar a materialized view.

   -- Rebuild Kafka/RabbitMQ engine tables on the destination 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>;

4. Verifique se o pipeline de dados no cluster de destino está funcionando corretamente e se os dados estão fluindo normalmente.

Etapa 10: Concluir a migração

Após parar as gravações no cluster autogerenciado, clique em Complete the task. Esta etapa migra os dados restantes, realiza uma verificação de volume de dados e migra os esquemas de banco de dados e tabelas restantes. Visualize o conteúdo migrado em task details.

1. Faça logon no console do ApsaraDB for ClickHouse.

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

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

4. Para a tarefa de migração alvo, clique em Complete Migration na coluna Actions.

5. Na caixa de diálogo Complete Migration, clique em OK.

Etapa 11: Migrar dados para tabelas não-MergeTree

A tarefa de migração transfere apenas o esquema da tabela de tabelas não-MergeTree (como tabelas externas e tabelas Log), criando-as no cluster de destino sem dados de negócio. Migre os dados de negócio manualmente. Siga estas etapas:

1. Faça logon no cluster autogerenciado e execute a seguinte instrução para identificar as tabelas não-MergeTree que requerem migração de dados.

   SELECT
       `database` AS database_name,
       `name` AS table_name,
       `engine`
   FROM `system`.`tables`
   WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
       SELECT `name`
       FROM `system`.`databases`
       WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
   ))

2. Faça logon no cluster de destino e use a função remote para migrar os dados da tabela. Para instruções detalhadas, consulte Migrate data using the remote function.

Outras operações

Quando uma tarefa de migração é concluída, seu Migration Status muda para Completed. A lista de tarefas não é atualizada imediatamente, portanto, atualize a página periodicamente para visualizar o status mais recente.

Método 1: Usar os comandos BACKUP e RESTORE

Para mais informações, consulte Use the BACKUP and RESTORE commands to back up and restore data.

Método 2: Usar a instrução INSERT FROM SELECT