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 soluções:

• Causa: O ambiente de rede está configurado incorretamente. A conexão via 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 em atraso na sua conta Alibaba Cloud, a instância SLB pode ser suspensa, tornando sua instância 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, execute uma das seguintes ações:

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

• Faça o dimensionamento vertical do seu cluster para aumentar a memória. 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 com base nas 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 pelas 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: Mude 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 reverte para um modo de inserção linha a linha. Essa reversão 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 encontrar 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, isso indica fortemente que o DataX encontrou dirty data e alternou para o modo linha a linha.

    Execute a consulta SQL a seguir para verificar 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 a dirty data da data source.

Realize as seguintes verificações:

1. Verifique erros durante a importação na tabela de sistema query_log. Se houver erros, provavelmente ocorreu perda de dados.

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

3. Valide a precisão da contagem de linhas na origem Hive, pois a contagem inicial da origem pode estar incorreta.

Verifique os seguintes pontos:

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

2. Verifique 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. Confira se o parâmetro kafka_skip_broken_messages está ativado na configuração da tabela externa do Kafka. Quando ativado, o ClickHouse ignora mensagens que falham na análise, reduzindo a contagem de linhas no ClickHouse em relação ao Kafka.

Utilize um destes métodos:

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

• Use 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 a tabela for distribuída, você deve excluir 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 uso de memória.

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

• Causa: Uso de uma 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 rastreia o uso de memória em vários níveis. Para uma única consulta, um rastreador de memória agrega o uso de memória de todos os threads dessa consulta. Esse rastreador então reporta a um rastreador de memória global. A solução depende do erro específico encontrado.

• Um erro com Memory limit (for query) significa que a consulta falhou porque consumiu memória excessiva, ultrapassando seu limite de 70% da capacidade total de memória da instância. Para resolver, realize 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 global de 90% da capacidade total de memória da instância. Esse erro pode resultar de alta concorrência de consultas ou de tarefas assíncronas em segundo plano intensivas em recursos, como tarefas de mesclagem de chave primária executadas após escritas de dados. Primeiro, tente reduzir a concorrência de consultas. Se o erro persistir, realize um upgrade vertical para aumentar a capacidade de memória da instância.

SETTINGS 
    allow_experimental_analyzer = 1,
    allow_experimental_parallel_reading_from_replicas = 1;

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 um cluster 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.

• Verifique se você está usando um cluster mestre-réplica. Em um cluster mestre-réplica, utilize tabelas com um mecanismo da série Replicated para sincronizar dados entre réplicas. Caso contrário, cada consulta pode atingir uma réplica diferente, levando a resultados inconsistentes. 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 uma mensagem de sucesso, mas a tabela será criada apenas no servidor atualmente conectado. Ao conectar-se a um servidor diferente, a tabela não estará 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 que utilize 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 de tabela ReplicatedMergeTree é uma versão aprimorada do mecanismo MergeTree que fornece sincronização mestre-réplica. Em uma instância de réplica única, só é possível criar tabelas com o mecanismo MergeTree. Em uma instância mestre-réplica, você deve 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 de tabela ReplicatedMergeTree. Os argumentos em ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') fazem parte de um modelo fixo e não devem ser modificados.

insert into <destination table> as select * from <Kafka external table>;

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 definir 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 expiram.

   • 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 TTL não estejam alinhadas, alguns dados podem não ser limpos prontamente. A seguir, explicamos como as regras de partição e TTL interagem.

     • Se as regras de partição e 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.

     • Se as regras não estiverem alinhadas e ttl_only_drop_parts = 0, o ClickHouse precisa verificar os dados dentro de cada parte para encontrar e excluir linhas expiradas individuais. 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 background

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

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

   • 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 é preciso 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 schema 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 background acionam a limpeza por TTL e exigem espaço disponível em disco. Partes de dados grandes ou espaço insuficiente em disco (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: Delay 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 background exceder esse valor, o ClickHouse não agenda 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.

Veja abaixo 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 consegue 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 contêm dados expirados com maior frequência.

• Causa 2: Se o TTL de uma tabela for modificado ou adicionado, 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.

• Caso haja dados sendo gravados na tabela, o procedimento depende 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)
  Remover 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.
  Remover 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 bloqueia esta 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 usa JOIN ou IN para unir múltiplas 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);

  Neste 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, um exemplo de consulta:

SELECT * FROM system.disks;

Use 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 comuns incluem:

• Uma consulta que aciona um erro OOM.

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

• Reinicialização da instância após upgrade ou downgrade.

A tabela a seguir descreve tabelas de sistema comuns e suas funções.

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

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

Especifique o parâmetro de quota 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 do que outros node s durante write operation s intensas. 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 problemas potenciais.

• Solução:

  1. Verifique o parâmetro text_log.level do seu cluster e siga um destes procedimentos:

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

     2. Se text_log.level tiver um valor, verifique se o nível de log atende aos seus requisitos. Caso contrário, 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 seguinte instrução 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 está 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 respectiva de cada produto.

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

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

Você pode migrar dados entre clusters Enterprise Edition e Community Edition usando a função remote ou exportando e importando 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 posterior 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 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 da Enterprise Edition. Clusters da ClickHouse Community Edition não podem ser suspensos. Para suspender um cluster da Enterprise Edition, acesse a página de Clusters da Enterprise Edition. 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 para 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 tabela distribuída correspondente 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 único 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;

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;

optimize TABLE <table_name> FINAL ON cluster default;