Pular para o conteúdo principal

SYSTEM RELOAD EMBEDDED DICTIONARIES

Recarrega todos os dicionários internos. Por padrão, os dicionários internos ficam desabilitados. Sempre retorna Ok., independentemente do resultado da atualização dos dicionários internos.

SYSTEM RELOAD DICTIONARIES

A consulta SYSTEM RELOAD DICTIONARIES recarrega dicionários com status LOADED (consulte a coluna status de system.dictionaries), ou seja, dicionários que já foram carregados com sucesso anteriormente. Por padrão, os dicionários são carregados sob demanda (consulte dictionaries_lazy_load), portanto, em vez de serem carregados automaticamente na inicialização, eles são inicializados no primeiro acesso, por meio da função dictGet ou de SELECT em tabelas com ENGINE = Dictionary. Sintaxe

SYSTEM RELOAD DICTIONARY

Recarrega por completo o dicionário dictionary_name, independentemente do estado do dicionário (LOADED / NOT_LOADED / FAILED). Sempre retorna Ok., independentemente do resultado da atualização do dicionário.
O status do dicionário pode ser verificado consultando a tabela system.dictionaries.

SYSTEM RELOAD MODELS

Este comando e SYSTEM RELOAD MODEL apenas removem os modelos CatBoost da memória do clickhouse-library-bridge. A função catboostEvaluate() carrega um modelo no primeiro acesso, caso ele ainda não esteja carregado.
Remove da memória todos os modelos CatBoost. Sintaxe

SYSTEM RELOAD MODEL

Descarrega um modelo CatBoost em model_path. Sintaxe

SYSTEM RELOAD FUNCTIONS

Recarrega todas as funções executáveis definidas pelo usuário registradas, ou uma delas, de um arquivo de configuração. Sintaxe

SYSTEM RELOAD ASYNCHRONOUS METRICS

Recalcula todas as métricas assíncronas. Como as métricas assíncronas são atualizadas periodicamente com base na configuração asynchronous_metrics_update_period_s, em geral não é necessário atualizá-las manualmente com esta instrução.

SYSTEM CLEAR|DROP DNS CACHE

Limpa o cache DNS interno do ClickHouse. Às vezes (em versões mais antigas do ClickHouse), é necessário usar este comando ao alterar a infraestrutura (mudando o endereço IP de outro servidor ClickHouse ou do servidor usado pelos dicionários). Para um gerenciamento de cache mais prático (automático), consulte os parâmetros disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period.

SYSTEM CLEAR|DROP MARK CACHE

Limpa o cache de marks.

SYSTEM CLEAR|DROP ICEBERG METADATA CACHE

Limpa o cache de metadados do Iceberg.

SYSTEM CLEAR|DROP AVRO SCHEMA CACHE

Limpa os caches por URL do Confluent Schema Registry usados pelo formato AvroConfluent. Isso remove tanto o cache de obtenção de schema (id → schema) quanto o cache de registro de schema (subject + schema → id), fazendo com que leituras e gravações subsequentes voltem a recorrer ao servidor do registry. É útil quando um schema foi excluído ou reescrito no registry, ou para verificar a idempotência do registry em testes.

SYSTEM DROP PARQUET METADATA CACHE

Limpa o cache de metadados do Parquet.

SYSTEM CLEAR|DROP TEXT INDEX CACHES

Limpa os caches de cabeçalho, de dicionário e de postings do índice de texto. Se quiser limpar um desses caches individualmente, você pode executar
  • SYSTEM CLEAR TEXT INDEX HEADER CACHE,
  • SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, ou
  • SYSTEM CLEAR TEXT INDEX POSTINGS CACHE

SYSTEM DROP REPLICA

Réplicas inativas de tabelas ReplicatedMergeTree podem ser removidas usando a sintaxe a seguir:
As consultas removerão o caminho da réplica ReplicatedMergeTree no ZooKeeper. Isso é útil quando a réplica está inativa e seus metadados não podem ser removidos do ZooKeeper com DROP TABLE, porque essa tabela não existe mais. Ela removerá apenas a réplica inativa/desatualizada e não pode remover a réplica local; para isso, use DROP TABLE. DROP REPLICA não remove nenhuma tabela nem remove dados ou metadados do disco. A primeira remove os metadados da réplica 'replica_name' da tabela database.table. A segunda faz o mesmo para todas as tabelas replicadas no banco de dados. A terceira faz o mesmo para todas as tabelas replicadas no servidor local. A quarta é útil para remover os metadados de uma réplica inativa quando todas as outras réplicas de uma tabela tiverem sido removidas. Ela exige que o caminho da tabela seja especificado explicitamente. Deve ser o mesmo caminho que foi passado como primeiro argumento do motor ReplicatedMergeTree na criação da tabela.

SYSTEM DROP DATABASE REPLICA

Réplicas inativas de bancos de dados Replicated podem ser removidas com a seguinte sintaxe:
Semelhante a SYSTEM DROP REPLICA, mas remove do ZooKeeper o caminho da réplica do banco de dados Replicated quando não existe um banco de dados sobre o qual executar DROP DATABASE. Observe que isso não remove réplicas ReplicatedMergeTree (portanto, talvez você também precise de SYSTEM DROP REPLICA). Os nomes do shard e da réplica são os que foram especificados nos argumentos do mecanismo Replicated ao criar o banco de dados. Além disso, esses nomes podem ser obtidos nas colunas database_shard_name e database_replica_name em system.clusters. Se a cláusula FROM SHARD estiver ausente, replica_name deverá ser um nome completo de réplica no formato shard_name|replica_name.

SYSTEM CLEAR|DROP UNCOMPRESSED CACHE

Limpa o cache de dados não comprimidos. O cache de dados não comprimidos é ativado/desativado pela configuração use_uncompressed_cache no nível de consulta/usuário/perfil. Seu tamanho pode ser configurado usando a configuração no nível de servidor uncompressed_cache_size.

SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE

Limpa o cache de expressões compiladas. O cache de expressões compiladas é ativado/desativado pela configuração compile_expressions no nível de consulta/usuário/perfil.

SYSTEM CLEAR|DROP QUERY CONDITION CACHE

Limpa o cache de condições de consulta.

SYSTEM CLEAR|DROP QUERY CACHE

Limpa o cache de consultas. Se uma tag for especificada, somente as entradas do cache de consultas com a tag especificada serão excluídas.

SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE

Limpa o cache dos esquemas carregados a partir de format_schema_path. Alvos compatíveis:
  • Protobuf: Remove da memória as definições de mensagens Protobuf importadas.
  • Files: Exclui os arquivos de esquema em cache armazenados localmente no format_schema_path, gerados quando format_schema_source é definido como query. Observação: Se nenhum alvo for especificado, ambos os caches serão limpos.

SYSTEM FLUSH LOGS

Descarrega mensagens de log em buffer nas tabelas de sistema, por exemplo, system.query_log. É útil principalmente para depuração, já que a maioria das tabelas de sistema tem um intervalo padrão de flush de 7,5 segundos. Isso também criará tabelas de sistema mesmo que a fila de mensagens esteja vazia.
Se você não quiser fazer flush de tudo, poderá fazer flush de um ou mais logs individuais informando o nome deles ou o da respectiva tabela de destino:

SYSTEM RELOAD CONFIG

Recarrega a configuração do ClickHouse. É usado quando a configuração está armazenada no ZooKeeper. Observe que SYSTEM RELOAD CONFIG não recarrega a configuração de USER armazenada no ZooKeeper; ele recarrega apenas a configuração de USER armazenada em users.xml. Para recarregar toda a configuração de USER, use SYSTEM RELOAD USERS

SYSTEM RELOAD USERS

Recarrega todos os armazenamentos de acesso, incluindo: users.xml, o armazenamento de acesso em disco local e o armazenamento de acesso replicado (no ZooKeeper).

SYSTEM SHUTDOWN

Normalmente encerra o ClickHouse (como service clickhouse-server stop / kill {$pid_clickhouse-server})

SYSTEM KILL

Encerra o processo do ClickHouse (como kill -9 {$ pid_clickhouse-server})

SYSTEM INSTRUMENT

Gerencia pontos de instrumentação usando o recurso XRay do LLVM, que está disponível quando o ClickHouse é compilado com ENABLE_XRAY=1. Isso permite depurar e gerar perfis em produção sem modificar o código-fonte e com sobrecarga mínima. Quando nenhum ponto de instrumentação é adicionado, o impacto no desempenho é desprezível, pois isso apenas adiciona um salto extra para um endereço próximo no prólogo e no epílogo das funções com mais de 200 instruções.

SYSTEM INSTRUMENT ADD

Adiciona um novo ponto de instrumentação. As funções instrumentadas podem ser inspecionadas na tabela de sistema system.instrumentation. Mais de um handler pode ser adicionado à mesma função, e eles serão executados na mesma ordem em que a instrumentação foi adicionada. As funções a serem instrumentadas podem ser obtidas na tabela de sistema system.symbols. Há três tipos diferentes de handlers que podem ser adicionados às funções: Sintaxe
em que FUNCTION é qualquer função ou substring de uma função, como QueryMetricLog::startQuery, e o handler é um dos seguintes

LOG

Imprime o texto fornecido como argumento e o stack trace na ENTRY ou na EXIT da função.

SLEEP

Suspende a execução por um número fixo de segundos em ENTRY ou EXIT:
ou para um número aleatório de segundos com distribuição uniforme, informando o mínimo e o máximo separados por um espaço em branco:

PROFILE

Mede o tempo gasto entre ENTRY e EXIT de uma função. O resultado do profiling é armazenado em system.trace_log e pode ser convertido no Chrome Event Trace Format.

SYSTEM INSTRUMENT REMOVE

Remove um único ponto de instrumentação com:
todos usando o parâmetro ALL:
um conjunto de IDs de uma subconsulta:
ou todos os pontos de instrumentação que tenham um determinado function_name:
As informações sobre o ponto de instrumentação podem ser obtidas na tabela de sistema system.instrumentation.

Gerenciando tabelas distribuídas

O ClickHouse pode gerenciar tabelas distribuídas. Quando um usuário insere dados nessas tabelas, o ClickHouse primeiro cria uma fila com os dados que devem ser enviados aos nós do cluster e depois os envia de forma assíncrona. Você pode gerenciar o processamento da fila com as consultas STOP DISTRIBUTED SENDS, FLUSH DISTRIBUTED e START DISTRIBUTED SENDS. Você também pode inserir dados distribuídos de forma síncrona com a configuração distributed_foreground_insert.

SYSTEM STOP DISTRIBUTED SENDS

Desativa a distribuição de dados em segundo plano ao inserir dados em tabelas distribuídas.
Se prefer_localhost_replica estiver habilitado (padrão), os dados ainda serão inseridos no shard local.

SYSTEM FLUSH DISTRIBUTED

Força o ClickHouse a enviar dados aos nós do cluster de forma síncrona. Se algum nó estiver indisponível, o ClickHouse gera uma exceção e interrompe a execução da consulta. Você pode tentar a consulta novamente até que ela seja concluída com sucesso, o que acontecerá quando todos os nós voltarem a ficar online. Você também pode sobrescrever algumas configurações usando a cláusula SETTINGS; isso pode ser útil para contornar limitações temporárias, como max_concurrent_queries_for_all_users ou max_memory_usage.
Cada bloco pendente é armazenado em disco com as configurações da consulta INSERT inicial; por isso, às vezes pode ser necessário substituir essas configurações.

SYSTEM START DISTRIBUTED SENDS

Ativa a distribuição de dados em segundo plano ao inserir dados em tabelas distribuídas.

SYSTEM STOP LISTEN

Fecha o socket e encerra de forma controlada as conexões existentes com o servidor na porta e no protocolo especificados. No entanto, se as configurações de protocolo correspondentes não tiverem sido especificadas na configuração do clickhouse-server, este comando não terá efeito.
  • Se o modificador CUSTOM 'protocol' for especificado, o protocolo personalizado com o nome indicado, definido na seção de protocolos da configuração do servidor, será interrompido.
  • Se o modificador QUERIES ALL [EXCEPT .. [,..]] for especificado, todos os protocolos serão interrompidos, exceto os especificados na cláusula EXCEPT.
  • Se o modificador QUERIES DEFAULT [EXCEPT .. [,..]] for especificado, todos os protocolos padrão serão interrompidos, exceto os especificados na cláusula EXCEPT.
  • Se o modificador QUERIES CUSTOM [EXCEPT .. [,..]] for especificado, todos os protocolos personalizados serão interrompidos, exceto os especificados na cláusula EXCEPT.

SYSTEM START LISTEN

Permite estabelecer novas conexões nos protocolos especificados. No entanto, se o servidor na porta e no protocolo especificados não tiver sido interrompido com o comando SYSTEM STOP LISTEN, este comando não terá efeito.

Gerenciamento de tabelas MergeTree

O ClickHouse pode gerenciar processos em segundo plano em tabelas MergeTree.

SYSTEM STOP MERGES

Permite interromper os merges em segundo plano de tabelas da família MergeTree:
O DETACH / ATTACH de uma tabela iniciará merges em segundo plano para a tabela, mesmo que os merges tenham sido interrompidos anteriormente para todas as tabelas MergeTree.

SYSTEM START MERGES

Permite iniciar merges em segundo plano para tabelas da família MergeTree:

SYSTEM STOP TTL MERGES

Permite interromper a exclusão em segundo plano de dados antigos de acordo com a expressão TTL para tabelas da família MergeTree: Retorna Ok. mesmo que a tabela não exista ou não use o motor MergeTree. Retorna erro quando o banco de dados não existe:

SYSTEM START TTL MERGES

Permite iniciar a exclusão em segundo plano de dados antigos de acordo com a expressão TTL para tabelas da família MergeTree: Retorna Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:

SYSTEM STOP MOVES

Permite interromper a movimentação de dados em segundo plano de acordo com a expressão TTL da tabela com a cláusula TO VOLUME ou TO DISK para tabelas da família MergeTree: Retorna Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:

SYSTEM START MOVES

Permite iniciar a movimentação de dados em segundo plano de acordo com a expressão TTL da tabela com as cláusulas TO VOLUME e TO DISK para tabelas da família MergeTree: Retorna Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:

SYSTEM SYSTEM UNFREEZE

Remove um backup congelado com o nome especificado de todos os disks. Veja mais sobre como descongelar partes individuais em ALTER TABLE table_name UNFREEZE WITH NAME

SYSTEM WAIT LOADING PARTS

Aguarde até que todas as partes de dados de uma tabela carregadas de forma assíncrona (partes de dados desatualizadas) sejam carregadas.

Gerenciando tabelas ReplicatedMergeTree

O ClickHouse pode gerenciar, em segundo plano, os processos relacionados à replicação em tabelas ReplicatedMergeTree.

SYSTEM STOP FETCHES

Permite interromper os fetches em segundo plano de partes inseridas em tabelas da família ReplicatedMergeTree: Sempre retorna Ok., independentemente do motor da tabela, mesmo que a tabela ou o banco de dados não existam.

SYSTEM START FETCHES

Oferece a possibilidade de iniciar fetches em segundo plano para partes inseridas em tabelas da família ReplicatedMergeTree: Sempre retorna Ok. independentemente do motor da tabela, mesmo que a tabela ou o banco de dados não existam.

SYSTEM STOP REPLICATED SENDS

Permite interromper, em segundo plano, o envio de novas partes inseridas para outras réplicas no cluster em tabelas da família ReplicatedMergeTree:

SYSTEM START REPLICATED SENDS

Permite iniciar, em segundo plano, o envio de novas partes inseridas para outras réplicas no cluster em tabelas da família ReplicatedMergeTree:

SYSTEM STOP REPLICATION QUEUES

Permite interromper tarefas de fetch em segundo plano das filas de replicação armazenadas no ZooKeeper para tabelas da família ReplicatedMergeTree. Os possíveis tipos de tarefas em segundo plano são: merges, fetches, mutation e instruções DDL com a cláusula ON CLUSTER:

SYSTEM START REPLICATION QUEUES

Permite iniciar tarefas de fetch em segundo plano a partir das filas de replicação armazenadas no Zookeeper para tabelas da família ReplicatedMergeTree. Os tipos possíveis de tarefas em segundo plano são - merges, fetches, mutation, instruções DDL com a cláusula ON CLUSTER:

SYSTEM STOP PULLING REPLICATION LOG

Interrompe a leitura de novas entradas do log de replicação para a fila de replicação em uma tabela ReplicatedMergeTree.

SYSTEM START PULLING REPLICATION LOG

Cancela SYSTEM STOP PULLING REPLICATION LOG.

SYSTEM SYNC REPLICA

Aguarde até que uma tabela ReplicatedMergeTree esteja sincronizada com outras réplicas em um cluster, mas por no máximo receive_timeout segundos.
Após executar esta instrução, [db.]replicated_merge_tree_family_table_name busca comandos do log replicado comum para sua própria fila de replicação, e então a consulta aguarda até que a réplica processe todos os comandos buscados. Há suporte para os seguintes modificadores:
  • Com IF EXISTS (disponível desde a versão 25.6), a consulta não gerará erro se a tabela não existir. Isso é útil ao adicionar uma nova réplica a um cluster, quando ela já faz parte da configuração do cluster, mas ainda está em processo de criação e sincronização da tabela.
  • Se um modificador STRICT for especificado, a consulta aguardará até que a fila de replicação fique vazia. A versão STRICT pode nunca ser concluída com sucesso se novas entradas continuarem aparecendo na fila de replicação.
  • Se um modificador LIGHTWEIGHT for especificado, a consulta aguardará apenas o processamento das entradas GET_PART, ATTACH_PART, DROP_RANGE, REPLACE_RANGE e DROP_PART. Além disso, o modificador LIGHTWEIGHT oferece suporte a uma cláusula opcional FROM ‘srcReplicas’, em que ‘srcReplicas’ é uma lista, separada por vírgulas, com nomes de réplicas de origem. Essa extensão permite uma sincronização mais direcionada, ao focar apenas nas tarefas de replicação originadas das réplicas de origem especificadas.
  • Se um modificador PULL for especificado, a consulta extrai novas entradas da fila de replicação do ZooKeeper, mas não aguarda o processamento de nada.

SYNC DATABASE REPLICA

Aguarda até que o banco de dados replicado especificado aplique todas as alterações de esquema presentes na fila DDL desse banco de dados. Sintaxe

SYSTEM RESTART REPLICA

Permite reinicializar o estado da sessão do ZooKeeper para a tabela ReplicatedMergeTree, comparar o estado atual com o ZooKeeper como fonte da verdade e adicionar tarefas à fila do ZooKeeper, se necessário. A inicialização da fila de replicação com base nos dados do ZooKeeper acontece da mesma forma que na instrução ATTACH TABLE. Por um curto período, a tabela ficará indisponível para qualquer operação.

SYSTEM RESTORE REPLICA

Restaura uma réplica se os dados [possivelmente] ainda estiverem presentes, mas os metadados do ZooKeeper tiverem sido perdidos. Funciona apenas em tabelas ReplicatedMergeTree somente leitura. É possível executar a consulta após:
  • Perda da raiz / do ZooKeeper.
  • Perda do caminho de réplicas /replicas.
  • Perda do caminho de uma réplica específica /replicas/replica_name/.
A réplica anexa as partes encontradas localmente e envia informações sobre elas ao ZooKeeper. As partes presentes em uma réplica antes da perda dos metadados não são buscadas novamente de outras réplicas se não estiverem desatualizadas (ou seja, restaurar a réplica não significa baixar novamente todos os dados pela rede).
As partes em qualquer estado são movidas para a pasta detached/. As partes que estavam ativas antes da perda dos dados (confirmadas) são anexadas.

SYSTEM RESTORE DATABASE REPLICA

Restaura uma réplica caso os dados [possivelmente] ainda estejam presentes, mas os metadados do Zookeeper tenham sido perdidos. Sintaxe
Exemplo
Sintaxe
Sintaxe alternativa:
Exemplo Criar uma tabela em vários servidores. Depois que os metadados da réplica no ZooKeeper são perdidos, a tabela será anexada em modo somente leitura, já que os metadados estão ausentes. A última consulta precisa ser executada em cada réplica.
Outra forma:

SYSTEM RESTART REPLICAS

Permite reinicializar o estado das sessões do Zookeeper para todas as tabelas ReplicatedMergeTree, comparando o estado atual com o Zookeeper como fonte da verdade e adicionando tarefas à fila do Zookeeper, se necessário

SYSTEM CLEAR|DROP FILESYSTEM CACHE

Permite limpar o cache do sistema de arquivos.

SYSTEM SYNC FILE CACHE

É muito pesado e pode ser usado indevidamente.
Executa a syscall sync.

SYSTEM LOAD PRIMARY KEY

Carrega as chaves primárias para a tabela especificada ou para todas as tabelas.

SYSTEM UNLOAD PRIMARY KEY

Descarrega as chaves primárias da tabela especificada ou de todas as tabelas.

Gerenciando views materializadas atualizáveis

Comandos para controlar tarefas em segundo plano executadas por views materializadas atualizáveis Fique de olho em system.view_refreshes ao usá-las.

SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS

Desativa a atualização periódica da view especificada ou de todas as views atualizáveis. Se houver uma atualização em andamento, ela também será cancelada. Se a view estiver em um banco de dados Replicated ou Shared, STOP VIEW afeta apenas a réplica atual, enquanto STOP REPLICATED VIEW afeta todas as réplicas.
O estado de parada não persiste após reinicializações do servidor. Após uma reinicialização, as views voltarão a seguir os agendamentos de atualização configurados. Em bancos de dados Replicated ou Shared, SYSTEM STOP VIEW afeta apenas a réplica atual. Use SYSTEM STOP REPLICATED VIEW para interromper as atualizações em todas as réplicas.

SYSTEM START [REPLICATED] VIEW, START VIEWS

Ativa a atualização periódica da view especificada ou de todas as views atualizáveis. Nenhuma atualização imediata é disparada. Se a view estiver em um banco de dados Replicated ou Shared, START VIEW desfaz o efeito de STOP VIEW, e START REPLICATED VIEW desfaz o efeito de STOP REPLICATED VIEW. START VIEW também desfaz o efeito de PAUSE VIEW.

SYSTEM PAUSE VIEW, PAUSE VIEWS

Desativa a atualização periódica da view especificada ou de todas as views atualizáveis. Ao contrário de SYSTEM STOP VIEW, SYSTEM PAUSE VIEW não interrompe uma atualização que já esteja em andamento: a atualização em execução pode terminar, e apenas as atualizações subsequentes são impedidas. Reative com SYSTEM START VIEW ou SYSTEM START VIEWS.
O estado de pausa não persiste após reinicializações do servidor. Depois de uma reinicialização, as views retomarão seus intervalos de atualização configurados. Em bancos de dados Replicated ou Shared, SYSTEM PAUSE VIEW afeta apenas a réplica atual.

SYSTEM REFRESH VIEW

Executa uma atualização imediata, fora do agendamento, de uma determinada view.

SYSTEM WAIT VIEW

Espera a atualização em execução ser concluída. Se nenhuma atualização estiver em execução, retorna imediatamente. Se a tentativa de atualização mais recente tiver falhado, retorna um erro. Pode ser usado logo após criar uma nova view materializada atualizável (sem a palavra-chave EMPTY) para aguardar a conclusão da atualização inicial. Se a view estiver em um banco de dados Replicated ou Shared, e a atualização estiver em execução em outra réplica, aguarda a conclusão dessa atualização.

SYSTEM CANCEL VIEW

Se houver uma atualização em andamento para a view especificada na réplica atual, interrompa-o e cancele-o. Caso contrário, não faça nada.

SYSTEM FLUSH OBJECT STORAGE QUEUE

Bloqueia até que o arquivo especificado seja processado ou falhe permanentemente pela tabela S3Queue ou AzureQueue informada. Retorna imediatamente se o arquivo já tiver sido processado. Gera um erro se o arquivo tiver falhado permanentemente (todas as tentativas esgotadas).
Última modificação em 19 de junho de 2026