ApsaraDB for ClickHouse:Perguntas frequentes

O ApsaraDB for ClickHouse corrige bugs de estabilidade presentes na versão da comunidade e oferece resource queues para definir prioridades de uso de recursos por função de usuário.

Experimente estas soluções:

• Verifique a conectividade de rede. Use ping para testar o alcance da rede e telnet para confirmar se as portas de banco de dados 3306 e 8123 estão abertas.

• Valide a configuração da lista de permissões do ClickHouse. Configure a whitelist.

• Confirme o endereço IP público da sua máquina cliente. Em redes corporativas, esse endereço pode mudar com frequência; utilize um serviço de consulta de IP como o whatsmyip.

Nas versões 20.3 e 20.8, o sistema valida automaticamente a conexão ao criar uma tabela externa. A criação bem-sucedida da tabela confirma a conectividade de rede. Se a criação falhar, os motivos mais comuns incluem:

• O endpoint de destino e o ClickHouse não estão na mesma VPC, o que impede a conectividade de rede.

• O servidor MySQL utiliza uma lista de permissões. É necessário adicionar o ClickHouse à lista de permissões do MySQL.

Causas comuns de falhas de conexão e suas respectivas soluções:

• Causa: O ambiente de rede está configurado incorretamente. A conexão pela rede interna só funciona se a aplicação e a instância estiverem na mesma VPC. Caso estejam em VPCs diferentes, ative um endpoint público e conecte-se pela rede pública.

  Solução: Ative o acesso pela rede pública. Apply for and release public IP addresses.

• Causa: O endereço IP do cliente não consta na lista de permissões da instância.

  Solução: Adicione o IP do cliente à lista de permissões. Configure a whitelist.

• Causa: O grupo de segurança da sua instância ECS bloqueia o tráfego na porta necessária.

  Solução: Atualize as regras do grupo de segurança da ECS. Security group operation guide.

• Causa: Um firewall corporativo está bloqueando a conexão.

  Solução: Modifique as regras do firewall para permitir o tráfego de saída para a instância.

• Causa: O nome de usuário ou a senha na string de conexão contém caracteres especiais, como !@#$%^&*()_+=. O cliente pode não interpretar esses caracteres corretamente, causando falha na conexão.

  Solução: Codifique em URL quaisquer caracteres especiais na string de conexão. As regras de codificação são as seguintes:

  ! : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  Por exemplo, se sua senha for ab@#c, a senha codificada na string de conexão deve ser ab%40%23c.

• Causa: O ApsaraDB for ClickHouse provisiona automaticamente uma instância Server Load Balancer (SLB) no modelo pagamento conforme o uso para seu cluster. Se houver pagamentos pendentes na sua conta Alibaba Cloud, a instância SLB pode ser suspensa, tornando sua instância do ApsaraDB for ClickHouse inacessível.

  Solução: Verifique se há pagamentos pendentes na sua conta Alibaba Cloud e quite qualquer saldo devedor para restaurar o serviço.

Para resolver esse problema, adote uma das seguintes medidas:

• Divida arquivos grandes no OSS em arquivos menores antes de importá-los.

• Faça o dimensionamento vertical do cluster para aumentar a memória disponível. Vertical and horizontal scaling for Community Edition clusters.

Causas comuns e soluções:

• Causa 1: Configuração de parâmetros não otimizada. O ClickHouse apresenta melhor desempenho com um tamanho de batch grande e um número reduzido de concurrent operations. Um único batch pode conter dezenas ou até centenas de milhares de linhas, dependendo do tamanho médio da linha. Como diretriz geral, estime 100 bytes por linha, mas ajuste esse valor conforme as características reais dos seus dados.

  Solução: Defina o número de concurrent operations como 10 ou menos. Teste diferentes valores de parâmetros para encontrar a configuração ideal para sua carga de trabalho.

• Causa 2: Recursos insuficientes no exclusive resource group do DataWorks. As instâncias ECS no exclusive resource group podem estar subdimensionadas. CPU ou memória insuficientes limitam o número de concurrent operations e a network egress bandwidth disponível. Da mesma forma, definir um tamanho de batch grande em uma máquina com memória limitada pode acionar coletas de lixo (GC) frequentes do Java no processo do DataWorks, reduzindo o desempenho.

  Solução: Verifique as especificações da instância ECS nos logs de saída do DataWorks.

• Causa 3: O gargalo está na data source.

  Solução: Nos logs de saída do DataWorks, procure as métricas totalWaitReaderTime e totalWaitWriterTime. Se totalWaitReaderTime for significativamente maior que totalWaitWriterTime, o gargalo está na leitura (na data source), e não na escrita.

• Causa 4: Uso de um public network endpoint. Um public network endpoint possui largura de banda limitada e não é adequado para operações de importação ou exportação de dados de alto desempenho.

  Solução: Alterne para um endpoint de rede VPC network.

• Causa 5: Presença de dirty data. Normalmente, os dados são escritos em um batch. No entanto, se houver dirty data, a escrita do batch atual falha. O DataX então recorre ao modo de inserção linha a linha. Essa alternativa gera um excesso de data parts e reduz drasticamente o desempenho de escrita.

  Use os dois métodos a seguir para verificar a existência de dirty data.

  • Verifique mensagens de erro. Se o log contiver um erro Cannot parse, isso indica dirty data.

    Execute a consulta SQL a seguir para identificar exceções.

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • Monitore a contagem de linhas do batch. Se o número de linhas por batch cair para 1, é muito provável que o DataX tenha encontrado dirty data e alternado para o modo linha a linha.

    Utilize a consulta SQL abaixo para conferir a contagem de linhas.

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  Solução: Identifique e corrija ou remova os dirty data da data source.

Realize as verificações a seguir:

1. Consulte a tabela de sistema query_log em busca de erros durante a importação. A presença de erros geralmente indica perda de dados.

2. Verifique se o mecanismo da tabela suporta deduplicação. Por exemplo, ao usar o mecanismo ReplacingMergeTree, a quantidade de linhas no ClickHouse pode ser menor que no Hive, pois esse mecanismo remove duplicatas.

3. Confira a precisão da contagem de linhas na origem Hive, já que a contagem inicial da fonte pode estar incorreta.

Verifique os itens abaixo:

1. Analise a tabela de sistema query_log para identificar erros ocorridos durante a importação. Se houver erros, pode ter havido perda de dados.

2. Confirme se o mecanismo da tabela realiza deduplicação de dados. O mecanismo ReplacingMergeTree, por exemplo, remove entradas duplicadas, resultando em uma contagem de linhas menor no ClickHouse em comparação ao Kafka.

3. Verifique se o parâmetro kafka_skip_broken_messages está ativado na configuração da tabela externa do Kafka. Quando ativado, o ClickHouse ignora mensagens com falha de análise, reduzindo a contagem de linhas no ClickHouse em relação ao Kafka.

Escolha um destes métodos:

• Exporte arquivos usando o ClickHouse Client. Migrate data from a self-managed ClickHouse instance to ApsaraDB for ClickHouse Community Edition.

• Utilize a função remote.

  INSERT INTO <destination_table> SELECT * FROM remote('<connection_string>', '<database>', '<table>', '<username>', '<password>');

Solução: Siga estas etapas para ressincronizar os dados do MySQL.

1. Exclua a tabela que parou de sincronizar.

   DROP TABLE <table_name> ON cluster default;

   Nota

   Neste comando, table_name é o nome da tabela que parou de sincronizar. Se for uma tabela distribuída, exclua tanto a tabela distribuída quanto sua tabela local.

2. Reinicie o processo de sincronização.

   ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   Nota

   Neste comando, <database_name> é o nome do banco de dados sincronizado no ApsaraDB for ClickHouse.

• Causa: Alto consumo de memória.

  Solução: Ajuste o parâmetro max_insert_threads para reduzir o uso de memória.

• Causa: Uso da instrução insert into select para importar dados entre clusters ClickHouse.

  Solução: Migre os dados importando-os a partir de arquivos. Migrate data from a self-managed ClickHouse instance to ApsaraDB for ClickHouse Community Edition.

O servidor ClickHouse monitora o uso de memória em vários níveis. Para uma única consulta, um rastreador de memória agrega o consumo de todas as threads dessa consulta. Esse rastreador reporta a um rastreador global de memória. A solução depende do erro específico encontrado.

• Um erro com Memory limit (for query) significa que a consulta falhou por consumir memória excessiva, ultrapassando o limite de 70% da capacidade total de memória da instância. Para resolver, faça um upgrade vertical para aumentar a capacidade de memória da instância.

• Um erro com Memory limit (for total) indica que o uso geral de memória na instância excedeu o limite sistêmico de 90% da capacidade total. Esse erro pode resultar de alta concorrência de consultas ou tarefas assíncronas em segundo plano intensivas em recursos, como mesclagens de chave primária após escritas de dados. Primeiro, tente reduzir a concorrência de consultas. Se o erro persistir, realize um upgrade vertical para aumentar a memória da instância.

A concorrência máxima padrão de consultas para um servidor é 100. Modifique esse valor no console:

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

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

3. No painel de navegação à esquerda, clique em Parameter Configuration.

4. Na página Parameter Configuration, clique no ícone de edição na coluna Parameter Value referente ao parâmetro max_concurrent_queries.

5. Insira o novo valor na caixa de diálogo e clique em OK.

6. Clique em Submit Parameters.

7. Clique em OK.

Considere as seguintes soluções:

• Verifique se você está usando um cluster multi-nó. Em clusters multi-nó, é necessário criar uma tabela distribuída. Escreva e consulte essa tabela para obter resultados consistentes. Caso contrário, cada consulta pode atingir um shard diferente. Create a distributed table.

• Confirme se você está usando um cluster mestre-réplica. Nesse tipo de cluster, utilize tabelas com mecanismos da série Replicated para sincronizar dados entre réplicas. Sem isso, cada consulta pode atingir uma réplica diferente, causando inconsistência nos resultados. Table engines.

Causas comuns e soluções:

• Causa 1: Processo de criação de tabela incorreto. Um cluster distribuído ClickHouse não possui semântica DDL distribuída nativa. Se você usar uma instrução create table em um cluster ClickHouse autogerenciado, a instrução pode retornar sucesso, mas a tabela será criada apenas no servidor atualmente conectado. Ao conectar-se a outro servidor, a tabela não ficará visível.

  Solução:

  1. Ao criar uma tabela, use a instrução create table <table_name> on cluster default. A cláusula on cluster default transmite a instrução para todos os nós no cluster padrão.

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. Crie outra tabela utilizando o mecanismo de tabela distribuída sobre a tabela de teste.

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• Causa 2: Tabela ReplicatedMergeTree mal configurada. O mecanismo ReplicatedMergeTree é uma versão aprimorada do MergeTree que oferece sincronização mestre-réplica. Em instâncias de réplica única, só é possível criar tabelas com o mecanismo MergeTree. Já em instâncias mestre-réplica, é obrigatório criar tabelas com o mecanismo ReplicatedMergeTree.

  Solução: Ao criar uma tabela em uma instância mestre-réplica, use ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') ou ReplicatedMergeTree() para configurar o mecanismo ReplicatedMergeTree. Os argumentos em ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') fazem parte de um modelo fixo e não devem ser modificados.

Sintoma

Um TTL foi configurado corretamente para uma tabela, mas os dados expirados nela não são excluídos automaticamente. Isso indica que a configuração de TTL não está surtindo efeito.

Etapas de solução de problemas

1. Verifique se a configuração de TTL da tabela é adequada.

   Defina o TTL com base nos requisitos do seu negócio. Recomendamos configurar o TTL no nível de dia e evitar configurações no nível de segundo ou minuto, como TTL event_time + INTERVAL 30 SECOND.

2. Verifique o parâmetro materialize_ttl_after_modify.

   Esse parâmetro controla se uma nova regra de TTL se aplica aos dados existentes após a execução de uma instrução ALTER MODIFY TTL. O valor padrão é 1 (ativado). Um valor igual a 0 significa que a regra se aplica apenas a novos dados, e os dados existentes não são afetados pelo TTL.

   • Consulte a configuração do parâmetro

     SELECT * FROM system.settings WHERE name like 'materialize_ttl_after_modify';

   • Modifique a configuração do parâmetro

     Importante

     Este comando verifica todos os dados existentes e pode gerar uma alta carga de recursos. Use-o com cautela.

     ALTER TABLE $table_name MATERIALIZE TTL;

3. Analise a estratégia de limpeza de partições.

   Quando o parâmetro ttl_only_drop_parts está definido como 1, o ClickHouse exclui uma parte de dados somente quando todas as linhas dentro dessa parte expiraram.

   • Consulte a configuração do parâmetro ttl_only_drop_parts

     SELECT * FROM system.merge_tree_settings WHERE name LIKE 'ttl_only_drop';

   • Verifique o status de expiração da partição

     SELECT partition, name, active, bytes_on_disk, modification_time, min_time, max_time, delete_ttl_info_min, delete_ttl_info_max FROM system.parts c WHERE database = 'your_dbname' AND TABLE = 'your_tablename' LIMIT 100;

     • delete_ttl_info_min: Valor mínimo da chave datetime usado para a regra TTL DELETE nesta parte.

     • delete_ttl_info_max: Valor máximo da chave datetime usado para a regra TTL DELETE nesta parte.

   • Caso as regras de partição e de TTL não estejam alinhadas, alguns dados podem não ser limpos prontamente. A seguir, explicamos como as regras de partição e de TTL interagem.

     • Se as regras de partição e de TTL estiverem alinhadas (por exemplo, particionamento por dia e definição de um TTL diário), o ClickHouse consegue determinar a expiração com base no ID da partição e excluir uma partição inteira de uma só vez. Essa é a estratégia mais eficiente. Para obter o melhor desempenho, recomendamos combinar uma estratégia de particionamento (como por dia) com ttl_only_drop_parts=1 para excluir dados expirados de forma eficiente.

     • Quando as regras não estão alinhadas e ttl_only_drop_parts = 1, o ClickHouse verifica as informações de TTL de cada parte. Uma parte é excluída somente depois que todos os seus dados ultrapassam o timestamp delete_ttl_info_max.

     • Quando as regras não estão alinhadas e ttl_only_drop_parts = 0, o ClickHouse precisa verificar os dados dentro de cada parte para encontrar e excluir linhas expiradas individualmente. Esta é a estratégia que mais consome recursos.

4. Controle a frequência de acionamento de merges.

   A exclusão de dados expirados ocorre de forma assíncrona durante os merges, não em tempo real. É possível controlar a frequência de merges com o parâmetro merge_with_ttl_timeout ou forçar a materialização do TTL usando a instrução ALTER TABLE ... MATERIALIZE TTL.

   • Consulte o parâmetro

     SELECT * FROM system.merge_tree_settings WHERE name = 'merge_with_ttl_timeout';

     Nota

     A unidade é segundos. O valor padrão para uma instância online é 7200 segundos (2 horas).

   • Modifique o parâmetro

     Se merge_with_ttl_timeout estiver definido com um valor muito alto, a frequência de acionamento do merge de TTL diminui, atrasando a limpeza de dados expirados. Reduza esse parâmetro para aumentar a frequência de limpeza. Para mais detalhes, consulte Descrição do parâmetro.

5. Verifique as configurações dos parâmetros do pool de threads.

   A remoção de dados por TTL ocorre durante a fase de merge de partes e é limitada pelos parâmetros max_number_of_merges_with_ttl_in_pool (padrão: 2 para instâncias online) e background_pool_size (padrão: 16 para instâncias online).

   • Consulte a atividade atual das threads em segundo plano

     SELECT * FROM system.metrics WHERE metric LIKE 'Background%';

     A métrica BackgroundPoolTask indica o número de tarefas ativas no momento no pool em segundo plano.

   • Modifique os parâmetros

     Se as outras configurações de parâmetros estiverem corretas e a utilização da CPU estiver baixa, considere aumentar o parâmetro max_number_of_merges_with_ttl_in_pool conforme as necessidades do seu negócio, por exemplo, de 2 para 4 ou de 4 para 8. Se isso não resolver o problema, considere aumentar o parâmetro background_pool_size.

     Importante

     É necessário reiniciar o cluster se você ajustar o parâmetro max_number_of_merges_with_ttl_in_pool. Não é necessário reiniciar o cluster ao aumentar o parâmetro background_pool_size, mas é obrigatório reiniciá-lo ao diminuir o parâmetro background_pool_size.

6. Verifique se o esquema da tabela e o design de particionamento são adequados.

   Se uma tabela não for particionada de forma eficaz ou se a granularidade da partição for muito grosseira, a eficiência da limpeza por TTL diminui. Para uma limpeza eficiente, recomendamos alinhar a granularidade da partição com a granularidade do TTL (por exemplo, definindo ambos com um intervalo diário). Para mais detalhes, consulte Melhores práticas.

7. Verifique se o cluster tem espaço em disco suficiente.

   As operações de merge em segundo plano acionam a limpeza por TTL e exigem espaço em disco disponível. Partes de dados grandes ou espaço em disco insuficiente (por exemplo, uso superior a 90%) podem impedir operações de merge e as subsequentes exclusões por TTL.

8. Verifique outros parâmetros do sistema em system.merge_tree_settings.

   • merge_with_recompression_ttl_timeout: O atraso mínimo antes que um merge com TTL de recompressão possa se repetir. Por padrão, isso significa que as regras de TTL são aplicadas a uma tabela pelo menos a cada 4 horas. Se precisar aplicar regras de TTL com mais frequência, reduza este valor.

   • max_number_of_merges_with_ttl_in_pool: Este parâmetro controla o número máximo de threads disponíveis para tarefas de TTL. Se o número de tarefas de merge com TTL em andamento no pool de threads em segundo plano exceder esse valor, o ClickHouse não agendará novas tarefas de merge com TTL.

Um primary key merge deve atender aos dois pré-requisitos a seguir para funcionar corretamente.

• A chave ORDER BY deve incluir a partition key da storage table. Um primary key merge não ocorre entre partições diferentes.

• Para uma distributed table, a chave ORDER BY deve incluir a chave de sharding, determinada pelo hash algorithm. Um primary key merge não ocorre entre nós diferentes.

A tabela a seguir descreve comandos comuns de optimize e seus comportamentos.

A seguir estão as causas comuns e suas soluções.

• Causa 1: A evicção de dados por TTL ocorre durante a fase de merge de chave primária. Se uma parte de dados não for mesclada por um longo período, o sistema não conseguirá evictar os dados expirados contidos nela.

  Solução:

  • Acione manualmente uma tarefa de merge executando optimize final ou optimize a specific partition.

  • Ao criar uma tabela, defina parâmetros como merge_with_ttl_timeout e ttl_only_drop_parts para mesclar partes de dados que contenham dados expirados com maior frequência.

• Causa 2: Se o TTL de uma tabela for modificado ou adicionado, as partes de dados existentes podem ter informações de TTL ausentes ou incorretas. Isso também pode impedir a evicção de dados expirados.

  Solução:

  • Regenere as informações de TTL executando alter table materialize ttl.

  • Atualize as informações de TTL executando optimize partition.

Para modificar uma tabela local, execute uma instrução DDL. Para uma tabela distribuída, o procedimento depende se há dados sendo gravados nela no momento.

• Se nenhum dado estiver sendo gravado na tabela, modifique primeiro a tabela local e, em seguida, a tabela distribuída.

• Se houver dados sendo gravados na tabela, o procedimento dependerá do tipo de modificação.

  Tipo	Ações
  Adicionar uma coluna anulável	Modifique a tabela local. Modifique a tabela distribuída.
  Modificar o tipo de dados de uma coluna (para um tipo conversível)
  Excluir uma coluna anulável	Modifique a tabela distribuída. Modifique a tabela local.
  Adicionar uma coluna não anulável	Interrompa a gravação de dados. Execute SYSTEM FLUSH DISTRIBUTED na tabela distribuída. Modifique a tabela local. Modifique a tabela distribuída. Retome a gravação de dados.
  Excluir uma coluna não anulável
  Renomear uma coluna

Experimente estas soluções:

• Aguarde a conclusão da operação.

• Tente encerrar a consulta no console.

• Causa 1: O cliente ClickHouse analisa a sintaxe. No entanto, set global on cluster default é uma sintaxe do lado do servidor. Se a versão do cliente for incompatível com o servidor, o cliente bloqueará essa instrução.

  Solução:

  • Use uma ferramenta que não realize análise de sintaxe no lado do cliente. Exemplos incluem ferramentas baseadas em JDBC, como DataGrip e DBeaver.

  • Escreva um programa JDBC para executar a instrução.

• Causa 2: Na instrução set global on cluster default key = value;, o value é uma string, mas não está entre aspas.

  Solução: Coloque o valor da string entre aspas.

Se o seu cluster for da Enterprise Edition e a instrução de criação de tabela incluir ON CLUSTER default, você poderá encontrar o erro ON CLUSTER is not allowed for Replicated database. Isso ocorre em algumas versões menores. Atualize sua instância para a versão mais recente. Upgrade minor engine versions.

Problema: Se você usar um cluster Community Edition com vários nós, poderá encontrar o erro Exception: Double-distributed IN/JOIN subqueries is denied (distributed_product_mode = 'deny').  quando uma consulta usar JOIN ou IN para unir várias tabelas distribuídas.

Causa: Quando uma consulta une várias tabelas distribuídas, pode ocorrer amplificação de consulta. Por exemplo, em um cluster de três nós, uma consulta de junção entre duas tabelas distribuídas se expande em 3 x 3 subconsultas nas tabelas locais subjacentes. Isso consome recursos significativos e aumenta a latência. Para evitar isso, o sistema bloqueia essas consultas por padrão.

Como funciona: Ao substituir o operador IN ou JOIN por GLOBAL IN ou GLOBAL JOIN, você instrui o mecanismo a executar a subconsulta do lado direito em um único nó. O resultado é armazenado em uma tabela temporária, que é então transmitida para todos os outros nós para concluir a junção localmente.

Impacto do uso de GLOBAL IN ou GLOBAL JOIN:

• A tabela temporária é enviada para todos os servidores remotos. Evite essa estratégia para grandes conjuntos de dados.

• Usar GLOBAL IN ou GLOBAL JOIN com a função remote() pode produzir resultados incorretos. Isso acontece porque a subconsulta, que deveria ser executada na instância externa, é executada na instância atual.

  Por exemplo, você executa a seguinte instrução em instance_a para consultar dados da instância externa cc-bp1wc089c****.

  SELECT *
  FROM remote('cc-bp1wc089c****.clickhouse.ads.aliyuncs.com:3306', `default`, test_tbl_distributed1, '<your_Account>', '<YOUR_PASSWORD>')
  WHERE id GLOBAL IN
      (SELECT id
       FROM test_tbl_distributed1);

  Nesse caso, instance_a executa a subconsulta SELECT id FROM test_tbl_distributed1 para gerar uma tabela temporária, vamos chamá-la de temp_table_A. Os dados de temp_table_A são então enviados para a instância externa cc-bp1wc089c**** para a consulta final. A instância externa cc-bp1wc089c**** acaba executando a instrução SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temp_table_A);.

  O problema surge da origem dos dados na tabela temporária.

  Com base na descrição acima, a instrução final executada pela instância cc-bp1wc089c**** é SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temporary table A);. No entanto, o conjunto de condições definido na tabela temporária A foi gerado na instância a. Neste exemplo, a instância cc-bp1wc089c**** deveria ter executado SELECT * FROM default.test_tbl_distributed1 WHERE id IN (SELECT id FROM test_tbl_distributed1 );, e o conjunto de condições deveria ter se originado da instância cc-bp1wc089c****. Portanto, o uso de GLOBAL IN ou GLOBAL JOIN faz com que a subconsulta recupere o conjunto de condições de uma fonte incorreta, o que leva a um resultado incorreto.

Soluções:

Solução 1: Modifique o código SQL da sua aplicação para substituir manualmente IN ou JOIN por GLOBAL IN ou GLOBAL JOIN.

Por exemplo, altere esta instrução:

SELECT * FROM test_tbl_distributed WHERE id IN (SELECT id FROM test_tbl_distributed1);

para:

SELECT * FROM test_tbl_distributed WHERE id GLOBAL IN (SELECT id FROM test_tbl_distributed1);

Solução 2: Modifique o parâmetro de sistema distributed_product_mode ou prefer_global_in_and_join para que o sistema converta automaticamente IN ou JOIN em GLOBAL IN ou GLOBAL JOIN.

SET GLOBAL ON cluster default distributed_product_mode='global';

SET GLOBAL ON cluster default prefer_global_in_and_join = 1;

Para visualizar o espaço em disco usado por cada tabela, execute a seguinte consulta.

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

A seguir está um exemplo de consulta:

SELECT * FROM system.disks;

Utilize a seguinte consulta:

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

Para mover uma partição de dados para o cold storage, execute a seguinte instrução:

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

As causas mais comuns incluem:

• Uma consulta que aciona um erro OOM.

• Reinicialização da instância provocada por uma alteração de configuração.

• Reinício da instância após um upgrade ou downgrade.

A tabela a seguir descreve as tabelas de sistema mais utilizadas e suas funções.

Os parâmetros no nível do usuário correspondem aos itens de configuração no arquivo users.xml. Para alterar um parâmetro, execute a instrução abaixo.

SET global ON cluster default ${key}=${value};

Especifique o parâmetro de cota nas settings de uma instrução de execução:

settings max_memory_usage = XXX;

Em um cluster multi-node com dual-replica ou single-replica, o write node apresenta maior CPU usage e memory usage em comparação aos demais node s durante write operation s intensivas. O uso se equilibra entre os node s assim que os dados são sincronizados.

• Descrição do problema:

  Como visualizar logs detalhados do sistema para solucionar erros ou identificar possíveis problemas.

• Solução:

  1. Verifique o parâmetro text_log.level do seu cluster e adote uma das medidas a seguir:

     1. Se text_log.level estiver vazio, o log de texto está desativado. Para ativá-lo, defina um valor para esse parâmetro.

     2. Caso text_log.level já possua um valor, verifique se o nível de log atende aos seus requisitos. Se não atender, modifique o parâmetro para o nível desejado.

     Configure config.xml parameters.

  2. Conecte-se ao banco de dados alvo. Connect to a database.

  3. Execute a instrução a seguir para visualizar e analisar os logs.

     SELECT * FROM system.text_log;

Se o cluster de destino e a fonte de dados estiverem na mesma VPC e região, verifique se o endereço IP de cada um consta na lista de permissões do outro.

• Para configurar a lista de permissões do ClickHouse, consulte Set a Whitelist.

• Para outras fontes de dados, consulte a documentação específica de cada produto.

Caso as condições acima não sejam atendidas, estabeleça primeiro a conectividade usando uma solução de rede adequada. Em seguida, adicione o endereço IP de cada recurso à lista de permissões do outro.

Sim, é possível migrar um cluster ClickHouse Community Edition para um cluster Enterprise Edition.

A migração de dados entre clusters Enterprise Edition e Community Edition pode ser feita utilizando a função remote ou por meio da exportação e importação de arquivos de dados. Migrate data from a self-managed ClickHouse cluster to Alibaba Cloud ClickHouse Community-Compatible Edition.

Por padrão, instâncias da Enterprise Edition 24.5 ou superior utilizam o novo analisador de consultas. Esse analisador oferece melhor desempenho, mas pode não ser compatível com versões anteriores de algumas instruções SQL legadas. Se você encontrar um erro de parsing, reverta para o analisador legado. Saiba mais sobre o novo analisador.

SET allow_experimental_analyzer = 0;

O recurso de suspensão está disponível apenas para clusters Enterprise Edition. Clusters ClickHouse Community Edition não podem ser suspensos. Para suspender um cluster Enterprise Edition, acesse a página Enterprise Edition Clusters. Selecione a região desejada no canto superior esquerdo. Na lista de clusters, localize o cluster alvo e clique em > Suspend na coluna Actions.

Descrição do problema

Usuários sem familiaridade com o ClickHouse podem criar tabelas com o engine MergeTree equivocadamente em um cluster de múltiplas réplicas. Isso impede a sincronização de dados entre os nós de réplica de cada shard. Consequentemente, consultas na tabela distribuída correspondente podem retornar resultados inconsistentes. Para resolver esse problema, converta a tabela MergeTree em uma tabela ReplicatedMergeTree.

Solução

O ClickHouse não fornece uma instrução DDL para alterar diretamente o engine de armazenamento de uma tabela. Para converter uma tabela MergeTree em ReplicatedMergeTree, crie uma nova tabela com o engine ReplicatedMergeTree e importe os dados da tabela original.

Por exemplo, suponha que você tenha uma tabela MergeTree chamada table_src e sua respectiva tabela distribuída chamada table_src_d em um cluster de múltiplas réplicas. Para converter essa tabela MergeTree em ReplicatedMergeTree, siga estas etapas:

1. Crie a tabela ReplicatedMergeTree de destino, table_dst, e sua tabela distribuída correspondente, table_dst_d. CREATE TABLE.

2. Importe os dados da tabela MergeTree table_src para table_dst_d. Utilize um dos dois métodos a seguir.

Definir um session_id exclusivo garante que o servidor ClickHouse mantenha um contexto consistente para requisições com o mesmo session ID. Isso permite executar várias instruções SQL em uma única sessão. Este exemplo demonstra como fazer isso com o ClickHouse Java Client (V2).

1. Adicione a dependência ao arquivo pom.xml do seu projeto Maven.

   <dependency>
       <groupId>com.clickhouse</groupId>
       <artifactId>client-v2</artifactId>
       <version>0.8.2</version>
   </dependency>

2. Defina um session ID personalizado em CommandSettings.

   package org.example;
   
   import com.clickhouse.client.api.Client;
   import com.clickhouse.client.api.command.CommandSettings;
   public class Main {
   
       public static void main(String[] args) {
           Client client = new Client.Builder()
                   .addEndpoint("endpoint") // Instance endpoint
                   .setUsername("username")   // Username
                   .setPassword("password")   // Password
                   .build();
   
           try {
               client.ping(10);
               CommandSettings commandSettings = new CommandSettings();
               // Set the session_id
               commandSettings.serverSetting("session_id","examplesessionid");
               // Set the max_block_size parameter for the session
               client.execute("SET max_block_size=65409 ",commandSettings);
               // Execute the queries
               client.execute("SELECT 1 ",commandSettings);
               client.execute("SELECT 2 ",commandSettings);
   
           } catch (Exception e) {
               throw new RuntimeException(e);
           } finally {
               client.close();
           }
       }
   }

Neste exemplo, ambas as instruções SELECT são executadas na mesma sessão com max_block_size definido como 65409. ClickHouse Java Client: Java Client | ClickHouse Docs.

Por que as operações DELETE ou UPDATE ficam incompletas?

SELECT * FROM clusterAllReplicas('default', system.mutations) WHERE is_done = 0;

Como resolver o erro "Code: 241. DB::Exception: Memory limit (total) exceeded" no ApsaraDB for ClickHouse Enterprise Edition?

• Sintoma: Ao executar uma instrução SQL, você encontra a seguinte mensagem de erro, mesmo que a memória total do seu cluster exceda o limite de memória especificado na mensagem:

  Code: 241. DB::Exception: Memory limit (total) exceeded: would use 115.28 GiB (attempt to allocate chunk of 133791376 bytes), maximum: 115.20 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker.: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED) (version 24.2.2.16476 (official build))

• Causa: No ApsaraDB for ClickHouse Enterprise Edition, um único nó possui um limite de CCU (máximo de 32 CCUs, onde 1 CCU equivale aproximadamente a 1 vCore e 4 GiB de memória). Se uma única consulta SQL consumir mais memória do que o limiar do nó, o MemoryTracker intercepta a consulta. O limiar padrão é 0,9 vezes a memória total do nó. Execute a seguinte instrução SQL para consultar o limiar:

  SELECT *
  FROM system.server_settings
  WHERE name = 'max_server_memory_usage_to_ram_ratio';

• Solução: Defina o parâmetro allow_experimental_parallel_reading_from_replicas como 1. Isso distribui a fase de leitura de dados entre vários nós, diluindo o consumo de memória. Enterprise Edition.

Por que os resultados das consultas são inconsistentes?

Por que o ReplacingMergeTree falha na deduplicação após uma mesclagem forçada?

optimize TABLE <table_name> FINAL ON cluster default;