SYSTEM RELOAD EMBEDDED DICTIONARIES
Ok., independentemente do resultado da atualização dos dicionários internos.
SYSTEM RELOAD DICTIONARIES
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 DICTIONARIES [ON CLUSTER cluster_name]
dictionary_name, independentemente do estado do dicionário (LOADED / NOT_LOADED / FAILED).
Sempre retorna Ok., independentemente do resultado da atualização do dicionário.
SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name
system.dictionaries.
SELECT name, status FROM system.dictionaries;
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.
SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]
model_path.
Sintaxe
SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>
SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name
SYSTEM RELOAD ASYNCHRONOUS METRICS
SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]
SYSTEM CLEAR|DROP DNS CACHE
disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period.
SYSTEM CLEAR|DROP MARK CACHE
SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
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.
Limpa o cache de metadados do Parquet.
SYSTEM CLEAR|DROP TEXT INDEX CACHES
SYSTEM CLEAR TEXT INDEX HEADER CACHE,SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, ouSYSTEM CLEAR TEXT INDEX POSTINGS CACHE
Réplicas inativas de tabelas ReplicatedMergeTree podem ser removidas usando a sintaxe a seguir:
SYSTEM DROP REPLICA 'replica_name' FROM TABLE database.table;
SYSTEM DROP REPLICA 'replica_name' FROM DATABASE database;
SYSTEM DROP REPLICA 'replica_name';
SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/path/to/table/in/zk';
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
Replicated podem ser removidas com a seguinte sintaxe:
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM DATABASE database;
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'];
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM ZKPATH '/path/to/table/in/zk';
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
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
compile_expressions no nível de consulta/usuário/perfil.
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
SYSTEM CLEAR|DROP QUERY CACHE
SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG '<tag>'
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 CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]
SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]
SYSTEM FLUSH LOGS query_log, system.query_views_log;
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 CONFIG [ON CLUSTER cluster_name]
SYSTEM RELOAD USERS [ON CLUSTER cluster_name]
service clickhouse-server stop / kill {$pid_clickhouse-server})
Encerra o processo do ClickHouse (como kill -9 {$ pid_clickhouse-server})
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.
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
SYSTEM INSTRUMENT ADD FUNCTION HANDLER [PARAMETERS]
FUNCTION é qualquer função ou substring de uma função, como QueryMetricLog::startQuery, e o handler é um dos seguintes
Imprime o texto fornecido como argumento e o stack trace na ENTRY ou na EXIT da função.
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG ENTRY 'this is a log printed at entry'
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG EXIT 'this is a log printed at exit'
ENTRY ou EXIT:
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1
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 ADD 'QueryMetricLog::startQuery' PROFILE
SYSTEM INSTRUMENT REMOVE ID
ALL:
SYSTEM INSTRUMENT REMOVE ALL
SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')
SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'
system.instrumentation.
Gerenciando tabelas distribuídas
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
SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
SETTINGS; isso pode ser útil para contornar limitações temporárias, como max_concurrent_queries_for_all_users ou max_memory_usage.
SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]
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
SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
SYSTEM STOP LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
- 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.
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.
SYSTEM START LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
Gerenciamento de tabelas MergeTree
SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
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 [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
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 STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:
SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:
SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. mesmo que a tabela não exista. Retorna erro quando o banco de dados não existe:
SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
SYSTEM UNFREEZE WITH NAME <backup_name>
SYSTEM WAIT LOADING PARTS
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
Gerenciando tabelas ReplicatedMergeTree
ReplicatedMergeTree:
Sempre retorna Ok., independentemente do motor da tabela, mesmo que a tabela ou o banco de dados não existam.
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
ReplicatedMergeTree:
Sempre retorna Ok. independentemente do motor da tabela, mesmo que a tabela ou o banco de dados não existam.
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP REPLICATED SENDS
ReplicatedMergeTree:
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START REPLICATED SENDS
ReplicatedMergeTree:
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP REPLICATION QUEUES
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 STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START REPLICATION QUEUES
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 START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP PULLING REPLICATION LOG
ReplicatedMergeTree.
SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START PULLING REPLICATION LOG
SYSTEM STOP PULLING REPLICATION LOG.
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
ReplicatedMergeTree esteja sincronizada com outras réplicas em um cluster, mas por no máximo receive_timeout segundos.
SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]
[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.
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 SYNC DATABASE REPLICA replicated_database_name;
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 RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
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
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
CREATE DATABASE repl_db
ENGINE=Replicated("/clickhouse/repl_db", shard1, replica1);
CREATE TABLE repl_db.test_table (n UInt32)
ENGINE = ReplicatedMergeTree
ORDER BY n PARTITION BY n % 10;
-- zookeeper_delete_path("/clickhouse/repl_db", recursive=True) <- perda do nó raiz.
SYSTEM RESTORE DATABASE REPLICA repl_db;
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
CREATE TABLE test(n UInt32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/test/', '{replica}')
ORDER BY n PARTITION BY n % 10;
INSERT INTO test SELECT * FROM numbers(1000);
-- zookeeper_delete_path("/clickhouse/tables/test", recursive=True) <- perda da raiz.
SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
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
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
É muito pesado e pode ser usado indevidamente.
sync.
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
SYSTEM LOAD PRIMARY KEY [db.]name
SYSTEM UNLOAD PRIMARY KEY
SYSTEM UNLOAD PRIMARY KEY [db.]name
SYSTEM UNLOAD PRIMARY KEY
Gerenciando views materializadas atualizáveis
system.view_refreshes ao usá-las.
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
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 STOP VIEW [db.]name
SYSTEM START [REPLICATED] VIEW, START VIEWS
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 START VIEW [db.]name
SYSTEM PAUSE VIEW, PAUSE VIEWS
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 PAUSE VIEW [db.]name
SYSTEM REFRESH VIEW [db.]name
SYSTEM WAIT VIEW [db.]name
SYSTEM CANCEL VIEW [db.]name
SYSTEM FLUSH OBJECT STORAGE QUEUE
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
