Esta página não se aplica ao ClickHouse Cloud. O procedimento descrito aqui é automatizado nos serviços do ClickHouse Cloud.
Detalhes de implementação
clickhouse-keeper-converter permite converter dados do ZooKeeper em snapshots do ClickHouse Keeper. O protocolo entre servidores no ClickHouse Keeper também é incompatível com o ZooKeeper, portanto um cluster misto de ZooKeeper / ClickHouse Keeper é impossível.
O ClickHouse Keeper oferece suporte a listas de controle de acesso (ACLs) da mesma forma que o ZooKeeper. O ClickHouse Keeper oferece suporte ao mesmo conjunto de permissões e tem os mesmos esquemas internos: world, auth e digest. O esquema de autenticação digest usa o par username:password; a senha é codificada em Base64.
Integrações externas não são suportadas.
Configuração
.xml.
Configurações do Keeper
<keeper_server> e tem os seguintes parâmetros:
Outros parâmetros comuns são herdados da configuração do servidor ClickHouse (
listen_host, logger e assim por diante).
Configurações internas de coordenação
<keeper_server>.<coordination_settings> e têm os seguintes parâmetros:
A configuração de quórum fica na seção
<keeper_server>.<raft_configuration> e contém a descrição dos servidores.
O único parâmetro para todo o quórum é secure, que habilita conexão criptografada para a comunicação entre os participantes do quórum. O parâmetro pode ser definido como true se uma conexão SSL for necessária para a comunicação interna entre os nós, ou deixado sem especificação caso contrário.
Os principais parâmetros de cada <server> são:
id— Identificador do servidor em um quórum.hostname— Hostname em que este servidor está localizado.port— Porta na qual este servidor aceita conexões.can_become_leader— Defina comofalsepara configurar o servidor comolearner. Se omitido, o valor serátrue.
Em caso de mudança na topologia do seu cluster ClickHouse Keeper (por exemplo, ao substituir um servidor), certifique-se de manter consistente o mapeamento de
server_id para hostname e evite trocar ou reutilizar um server_id existente para servidores diferentes (por exemplo, isso pode acontecer se você depender de scripts de automação para implantar o ClickHouse Keeper)Se o host de uma instância do Keeper puder mudar, recomendamos definir e usar um hostname em vez de endereços IP. Alterar o hostname equivale a remover e adicionar o servidor novamente, o que, em alguns casos, pode ser impossível (por exemplo, por não haver instâncias do Keeper suficientes para quórum).async_replication é desabilitado por padrão para evitar quebrar a compatibilidade com versões anteriores. Se todas as instâncias do Keeper no cluster estiverem executando uma versão com suporte a async_replication (v23.9+), recomendamos habilitá-lo, pois isso pode melhorar o desempenho sem desvantagens.test_keeper_. Exemplo de configuração para o servidor #1:
Como executar
<keeper_server> ao seu /etc/your_path_to_config/clickhouse-server/config.xml e iniciar o servidor ClickHouse como de costume. Se você quiser executar o standalone ClickHouse Keeper, poderá iniciá-lo de forma semelhante com:
clickhouse-keeper), poderá criá-lo ou especificar keeper como argumento para clickhouse:
Comandos de quatro letras
mntr, stat etc. Há outros comandos interessantes: stat fornece informações gerais sobre o servidor e os clientes conectados, srvr fornece detalhes adicionais sobre o servidor, e cons fornece detalhes adicionais sobre as conexões.
Os comandos 4lw têm uma configuração de lista de permissões, four_letter_word_white_list, cujo valor padrão é conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld.
Você pode enviar os comandos ao ClickHouse Keeper via telnet ou nc, pela porta do cliente.
ruok: Testa se o servidor está em execução sem apresentar erros. O servidor responderá comimokse estiver em execução. Caso contrário, não responderá de forma alguma. Uma respostaimoknão indica necessariamente que o servidor entrou no quórum, apenas que o processo do servidor está ativo e associado à porta de cliente especificada. Use “stat” para ver detalhes sobre o estado em relação ao quórum e informações sobre conexões de clientes.
mntr: Gera uma lista de variáveis que podem ser usadas para monitorar o estado de saúde do cluster.
srvr: Lista todos os detalhes do servidor.
stat: Exibe detalhes resumidos do servidor e dos clientes conectados.
srst: Zera as estatísticas do servidor. O comando afetará o resultado desrvr,mntrestat.
conf: Imprime detalhes da configuração do servidor.
cons: Liste os detalhes completos de conexão/sessão de todos os clientes conectados a este servidor. Inclui informações como o número de pacotes recebidos/enviados, ID da sessão, latências das operações, última operação executada etc…
crst: Zera as estatísticas de conexão/sessão de todas as conexões.
envi: Exibe detalhes sobre o ambiente do servidor
dirs: Mostra o tamanho total, em bytes, dos arquivos de snapshot e de log
isro: Verifica se o servidor está em modo somente leitura. O servidor responderá comrose estiver em modo somente leitura ourwcaso contrário.
wchs: Exibe informações resumidas sobre os watches do servidor.
wchc: Lista informações detalhadas sobre watches do servidor, por sessão. Isso gera uma lista de sessões (conexões) com os watches (caminhos) associados. Observe que, dependendo do número de watches, essa operação pode ser custosa (afetar o desempenho do servidor); use-a com cuidado.
wchp: Lista informações detalhadas sobre watches do servidor, por caminho. A saída é uma lista de caminhos (znodes) com as sessões associadas. Observe que, dependendo do número de watches, essa operação pode ser custosa (ou seja, pode impactar o desempenho do servidor); use-a com cuidado.
dump: Lista as sessões em aberto e os nós efêmeros. Isso só funciona no nó líder.
csnp: Agenda uma tarefa de criação de snapshot. Em caso de sucesso, retorna o último índice do log confirmado do snapshot agendado; em caso de falha, retornaFailed to schedule snapshot creation task.. O comandolgifpode ajudar a determinar se o snapshot foi concluído.
lgif: informações de log do Keeper.first_log_idx: meu primeiro índice de log no armazenamento de logs;first_log_term: meu primeiro termo do log;last_log_idx: meu último índice de log no armazenamento de logs;last_log_term: meu último termo do log;last_committed_log_idx: meu último índice de log confirmado na máquina de estado;leader_committed_log_idx: índice de log confirmado do líder, do meu ponto de vista;target_committed_log_idx: índice de log de destino que deve ser confirmado;last_snapshot_idx: o maior índice de log confirmado no último snapshot.
rqld: Solicitação para se tornar o novo líder. RetornaSent leadership request to leader.se a solicitação for enviada ouFailed to send leadership request to leader.se ela não for enviada. Se o nó já for o líder, o resultado será o mesmo de quando a solicitação é enviada.
ftfl: Lista todas as feature flags e indica se estão ativadas para a instância do Keeper.
ydld: Solicitação para abrir mão da liderança e se tornar seguidor. Se o servidor que receber a solicitação for o líder, ele primeiro pausará as operações de gravação, aguardará até que o sucessor (o líder atual nunca pode ser o sucessor) conclua a sincronização com o Log mais recente e, então, renunciará. O sucessor será escolhido automaticamente. RetornaSent yield leadership request to leader.se a solicitação for enviada ouFailed to send yield leadership request to leader.se a solicitação não for enviada. Se o nó já for um seguidor, o resultado será o mesmo de quando a solicitação é enviada.
pfev: Retorna os valores de todos os eventos coletados. Para cada evento, retorna o nome, o valor e a descrição do evento.
Controle HTTP
/ready:
Feature flags
keeper_server.feature_flags.
Todos os recursos podem ser desativados explicitamente.
Se você quiser ativar um novo recurso no seu cluster do Keeper, recomendamos primeiro atualizar todas as instâncias do Keeper no cluster para uma versão que ofereça suporte ao recurso e só então ativar o próprio recurso.
Exemplo de configuração de feature flag que desativa multi_read e ativa check_not_exists:
Alguns dos feature flags vêm habilitados por padrão a partir da versão 25.7.
A forma recomendada de atualizar o Keeper para a versão 25.7+ é primeiro atualizar para a versão 24.9+.
Migração do ZooKeeper
clickhouse-keeper-converter converte logs e snapshots do ZooKeeper em um snapshot do ClickHouse Keeper. Ela requer o ZooKeeper 3.4 ou posterior.
Preparação para a migração
Etapas da migração
- Interrompa a ingestão de dados em todos os nós do ClickHouse.
- Interrompa todas as tarefas em segundo plano em todos os nós do ClickHouse (veja acima).
- Interrompa todos os nós do ZooKeeper.
- Opcional, mas recomendado: identifique o nó líder do ZooKeeper, inicie-o e interrompa-o novamente. Isso força o ZooKeeper a gravar um snapshot consistente em disco antes da conversão.
-
Execute
clickhouse-keeper-converterno nó líder. Se você tiver o binário completo do ClickHouse instalado, use o subcomandokeeper-converter(clickhouse keeper-converter). Se nenhum dos dois estiver disponível, baixe o binário.
- Copie o snapshot para todos os nós do ClickHouse Keeper. O snapshot deve estar presente em todos os nós antes de qualquer um ser iniciado — se um nó for iniciado sem um snapshot, ele poderá se eleger líder com estado vazio.
- Atualize a configuração do ClickHouse para apontar para o novo cluster do Keeper.
- Inicie o ClickHouse Keeper em todos os nós e, em seguida, reinicie o ClickHouse.
- Compare as métricas com sua linha de base pré-migração para verificar a consistência.
- Retome as tarefas em segundo plano e reinicie a ingestão de dados.
Consolidando vários clusters do ZooKeeper
clickhouse-keeper-converter só oferece suporte a conversões um para um (um cluster do ZooKeeper para um snapshot do Keeper), portanto a consolidação exige modificar o código-fonte do conversor para mesclar vários snapshots:
- Execute
clickhouse-keeper-converterseparadamente em cada cluster do ZooKeeper, gravando cada saída em um diretório distinto. - Desserialize os arquivos de snapshot sequencialmente. Ao mesclar, recalcule os valores de
numChildrenpara evitar conflitos de IDs de nós entre espaços de nomes de diferentes clusters de origem. - Grave a saída mesclada no diretório de snapshots de destino do ClickHouse Keeper.
Como lidar com criptografia e ACLs
world, auth, digest). A forma de lidar com ACLs durante a conversão depende da sua configuração do ZooKeeper:
- Totalmente criptografado ou totalmente sem criptografia: Converta diretamente. O conversor preserva as informações de ACL existentes.
- Parcialmente criptografado: Antes de converter, atribua privilégios de superadministrador a uma conta e limpe as ACLs com
setAcl -Rnos paths afetados. Converta e, em seguida, reative a criptografia no ClickHouse Keeper, se necessário.
Verificando a migração
- Caminhos comuns: caminhos presentes em vários clusters de origem com dados idênticos — eles devem ser deduplicados no resultado consolidado.
- Caminhos diferenciados: caminhos que existem apenas em clusters específicos (por exemplo, em
/clickhouse/tablespara cada grupo de shards) — eles devem ser preservados a partir da origem correta.
Ajustes pós-migração
Essas configurações são definidas em
coordination_settings na sua configuração do Keeper.
Recuperação após perder quórum
- Certifique-se de que os nós com falha não possam se conectar ao cluster novamente.
- Não inicie nenhum dos novos nós até que isso seja especificado nas etapas.
- Escolha um único nó Keeper para ser seu novo líder. Lembre-se de que os dados desse nó serão usados em todo o cluster, por isso recomendamos usar um nó com o estado mais atualizado.
- Antes de fazer qualquer outra coisa, faça um backup das pastas
log_storage_pathesnapshot_storage_pathdo nó escolhido. - Reconfigure o cluster em todos os nós que você pretende usar.
- Envie o comando de quatro letras
rcvrpara o nó escolhido, o que colocará o nó em modo de recuperação, OU pare a instância do Keeper no nó escolhido e inicie-a novamente com o argumento--force-recovery. - Um por um, inicie as instâncias do Keeper nos novos nós, garantindo que
mntrretorneseguidorparazk_server_stateantes de iniciar o próximo. - Enquanto estiver em modo de recuperação, o nó líder retornará uma mensagem de erro para o comando
mntraté atingir quórum com os novos nós e recusará quaisquer solicitações do cliente e dos seguidores. - Depois que o quórum for atingido, o nó líder voltará ao modo normal de operação, aceitando todas as solicitações usando a verificação do Raft com
mntr, que deve retornarleaderparazk_server_state.
Usando discos com Keeper
- s3_plain
- s3
- local
keeper_server.log_storage_disk deve ser definida com o nome do disco.
Para usar um disco para snapshots, a configuração keeper_server.snapshot_storage_disk deve ser definida com o nome do disco.
Além disso, keeper_server.latest_log_storage_disk pode ser usado para os logs mais recentes, e keeper_server.latest_snapshot_storage_disk, para os snapshots mais recentes.
Nesse caso, o Keeper moverá automaticamente os arquivos para os discos corretos quando novos logs ou snapshots forem criados.
Para usar um disco para o arquivo de estado, a configuração keeper_server.state_storage_disk deve ser definida com o nome do disco.
Mover arquivos entre discos é seguro, e não há risco de perda de dados se o Keeper parar no meio da transferência.
Até que o arquivo seja completamente movido para o novo disco, ele não é excluído do disco antigo.
O Keeper com keeper_server.coordination_settings.force_sync definido como true (true por padrão) não consegue atender a algumas garantias em todos os tipos de disco.
No momento, apenas discos do tipo local oferecem suporte à sincronização persistente.
Se force_sync for usado, log_storage_disk deverá ser um disco local se latest_log_storage_disk não for usado.
Se latest_log_storage_disk for usado, ele deverá ser sempre um disco local.
Se force_sync estiver desabilitado, discos de todos os tipos poderão ser usados em qualquer configuração.
Uma possível configuração de armazenamento para uma instância do Keeper poderia ser a seguinte:
log_s3_plain, enquanto o log mais recente ficará no disco log_local.
A mesma lógica se aplica aos snapshots: todos os snapshots, exceto o mais recente, serão armazenados em snapshot_s3_plain, enquanto o snapshot mais recente ficará no disco snapshot_local.
Alterando a configuração de disco
keeper_server.old_snapshot_storage_disk e keeper_server.old_log_storage_disk.
A configuração a seguir mostra como passar da configuração anterior com 2 discos para uma nova configuração com um único disco:
log_local e log_s3_plain para o disco log_local2.
Além disso, todos os arquivos de snapshot serão movidos de snapshot_local e snapshot_s3_plain para o disco snapshot_local2.
Configurando o cache de logs
latest_logs_cache_size_threshold- tamanho total dos logs mais recentes armazenados no cachecommit_logs_cache_size_threshold- tamanho total dos logs subsequentes que precisam ser confirmados em seguida
Você pode usar o comando
pfev para verificar a quantidade de logs lidos de cada cache e do arquivo.
Você também pode usar métricas do endpoint do Prometheus para acompanhar o tamanho atual de ambos os caches.Prometheus
endpoint– Endpoint HTTP para a coleta de métricas pelo servidor Prometheus. Deve começar com ’/’.port– Porta doendpoint.metrics– Sinalizador que define se as métricas da tabela system.metrics serão expostas.events– Sinalizador que define se as métricas da tabela system.events serão expostas.asynchronous_metrics– Sinalizador que define se os valores atuais das métricas da tabela system.asynchronous_metrics serão expostos.
127.0.0.1 pelo endereço IP ou pelo hostname do seu servidor ClickHouse):
Guia do usuário do ClickHouse Keeper
1
Configure os nós com as configurações do Keeper
-
Instale 3 instâncias do ClickHouse em 3 hosts (
chnode1,chnode2,chnode3). (Consulte o Quick Start para mais detalhes sobre a instalação do ClickHouse.) -
Em cada nó, adicione a seguinte entrada para permitir a comunicação externa por meio da interface de rede.
-
Adicione a seguinte configuração do ClickHouse Keeper aos três servidores, atualizando a configuração
<server_id>em cada servidor; parachnode1, seria1, parachnode2, seria2e assim por diante.Estas são as configurações básicas usadas acima: -
Habilite o componente Zookeeper. Ele usará o mecanismo ClickHouse Keeper:
Estas são as configurações básicas usadas acima:
-
Reinicie o ClickHouse e verifique se cada instância do Keeper está em execução. Execute o comando a seguir em cada servidor. O comando
ruokretornaimokse o Keeper estiver em execução e funcionando corretamente: -
O banco de dados
systemtem uma tabela chamadazookeeperque contém os detalhes das suas instâncias do ClickHouse Keeper. Vamos ver essa tabela:A tabela tem esta aparência:
2
Configure um cluster no ClickHouse
-
Vamos configurar um cluster simples com 2 shards e apenas uma réplica em 2 dos nós. O terceiro nó será usado para atingir um quorum exigido pelo ClickHouse Keeper. Atualize a configuração em
chnode1echnode2. O cluster a seguir define 1 shard em cada nó, totalizando 2 shards sem replicação. Neste exemplo, parte dos dados ficará em um nó e parte ficará no outro: -
Reinicie o ClickHouse e verifique se o cluster foi criado:
Você deverá ver seu cluster:
3
Criar e testar a tabela distribuída
-
Crie um novo banco de dados no novo cluster usando o clickhouse client em
chnode1. A cláusulaON CLUSTERcria automaticamente o banco de dados em ambos os nós. -
Crie uma nova tabela no banco de dados
db1. Mais uma vez,ON CLUSTERcria a tabela em ambos os nós. -
No nó
chnode1, adicione algumas linhas: -
Adicione algumas linhas no nó
chnode2: -
Observe que executar uma instrução
SELECTem cada nó mostra apenas os dados daquele nó. Por exemplo, emchnode1:Emchnode2: -
-
Você pode criar uma tabela
Distributedpara representar os dados nos dois shards. Tabelas com o engineDistributednão armazenam dados próprios, mas permitem o processamento distribuído de consultas em vários servidores. As leituras atingem todos os shards, e as gravações podem ser distribuídas entre os shards. Execute a seguinte consulta emchnode1: -
Observe que consultar
dist_tableretorna todas as quatro linhas de dados dos dois shards:
Resumo
Configurando o ClickHouse Keeper com caminhos exclusivos
Esta página não se aplica ao ClickHouse Cloud. O procedimento descrito aqui é automatizado nos serviços do ClickHouse Cloud.
Descrição
{uuid}
para criar entradas exclusivas no ClickHouse Keeper ou ZooKeeper. Caminhos exclusivos
ajudam ao criar e remover tabelas com frequência, pois
isso evita ter de esperar vários minutos até que a coleta de lixo do Keeper
remova entradas de caminho, já que, sempre que um caminho é criado, um novo uuid é usado
nesse caminho; os caminhos nunca são reutilizados.
Ambiente de Example
Configuração de Example para o cluster:
Procedimentos para configurar tabelas para usarem {uuid}
- Configure as macros em cada servidor exemplo para o servidor 1:
Observe que definimos macros para
shard e réplica, mas {uuid} não está definido aqui — ele já vem embutido, então não é necessário defini-lo.- Crie um banco de dados
- Crie uma tabela no cluster usando as macros e
{uuid}
- Crie uma tabela distribuída
Teste
- Insira dados no primeiro nó (por exemplo,
chnode1)
- Insira dados no segundo nó (por exemplo,
chnode2)
- Visualize os registros usando a tabela distribuída
Alternativas
{uuid}
- Defina o padrão das tabelas em cada nó
- Crie a tabela sem parâmetros explícitos:
- Verifique se ele usou as mesmas configurações da configuração padrão
Solução de problemas
O banco de dados deve ser
Atomic; se você estiver atualizando de uma versão anterior, o
banco de dados default provavelmente será do tipo Ordinary.Reconfiguração dinâmica do ClickHouse Keeper
Esta página não se aplica ao ClickHouse Cloud. O procedimento descrito aqui é automatizado nos serviços do ClickHouse Cloud.
Descrição
reconfig
do ZooKeeper para reconfiguração dinâmica do cluster se keeper_server.enable_reconfiguration estiver ativado.
Se essa configuração estiver desativada, você poderá reconfigurar o cluster alterando manualmente a seção
raft_configuration da réplica. Certifique-se de editar os arquivos em todas as réplicas, pois somente o líder aplicará as alterações.
Como alternativa, você pode enviar uma consulta reconfig por meio de qualquer cliente compatível com ZooKeeper./keeper/config contém a última configuração do cluster confirmada no seguinte formato:
- Cada entrada de servidor é separada por uma quebra de linha.
server_typeéparticipantoulearner(learner não participa das eleições de líder).server_priorityé um inteiro não negativo que indica quais nós devem ser priorizados nas eleições de líder. Prioridade 0 significa que o servidor nunca será líder.
reconfig para adicionar novos servidores, remover os existentes e alterar as
prioridades dos servidores atuais. Veja alguns exemplos (usando clickhouse-keeper-client):
kazoo:
joining devem estar no formato de servidor descrito acima. As entradas de servidor devem ser separadas por vírgulas.
Ao adicionar novos servidores, você pode omitir server_priority (o valor padrão é 1) e server_type (o valor padrão
é participant).
Se quiser alterar a prioridade de um servidor existente, adicione-o a joining com a prioridade desejada.
O host, a porta e o tipo do servidor devem ser iguais aos da configuração existente do servidor.
Os servidores são adicionados e removidos na ordem em que aparecem em joining e leaving.
Todas as atualizações de joining são processadas antes das atualizações de leaving.
Há algumas ressalvas na implementação da reconfiguração do Keeper:
-
Apenas a reconfiguração incremental é suportada. Requisições com
new_membersnão vazio são recusadas. A implementação do ClickHouse Keeper depende da API do NuRaft para alterar a composição dinamicamente. O NuRaft oferece uma forma de adicionar um único servidor ou remover um único servidor, um de cada vez. Isso significa que cada alteração na configuração (cada parte dejoining, cada parte deleaving) deve ser decidida separadamente. Portanto, não há reconfiguração em lote, pois isso seria enganoso para os usuários finais. Alterar o tipo do servidor (participant/learner) também não é possível, já que isso não é suportado pelo NuRaft, e a única forma seria remover e adicionar o servidor, o que, novamente, seria enganoso. -
Você não pode usar o valor
znodestatretornado. -
O campo
from_versionnão é usado. Todas as requisições comfrom_versiondefinido são recusadas. Isso ocorre porque/keeper/configé um nó virtual, o que significa que ele não é armazenado em armazenamento persistente, mas sim gerado em tempo real com a configuração de nó especificada para cada requisição. Essa decisão foi tomada para não duplicar dados, já que o NuRaft já armazena essa configuração. -
Diferentemente do ZooKeeper, não há como esperar a reconfiguração do cluster enviando um comando
sync. A nova configuração será aplicada eventualmente, mas sem garantias de tempo. -
O comando
reconfigpode falhar por vários motivos. Você pode verificar o estado do cluster e ver se a atualização foi aplicada.
Convertendo um keeper de nó único em um cluster
- IMPORTANTE: novos nós devem ser adicionados em lotes menores que o quórum atual; caso contrário, eles elegerão um líder entre si. Neste exemplo, eles são adicionados um a um.
- O nó keeper existente deve ter o parâmetro de configuração
keeper_server.enable_reconfigurationhabilitado. - Inicie um segundo nó com a nova configuração completa do cluster keeper.
- Depois que ele iniciar, adicione-o ao nó 1 usando
reconfig. - Em seguida, inicie um terceiro nó e adicione-o usando
reconfig. - Atualize a configuração do
clickhouse-server, adicionando o novo nó keeper, e reinicie-o para aplicar as alterações. - Atualize a configuração do Raft no nó 1 e, opcionalmente, reinicie-o.
Recursos não suportados
createnão oferece suporte ao retorno do objetoStatcreatenão oferece suporte a TTLaddWatchnão funciona com watchesPERSISTENTremoveWatcheremoveAllWatchesnão têm suportesetWatchesnão tem suporte- A criação de znodes do tipo
CONTAINERnão tem suporte - A
autenticação SASLnão tem suporte