Skip to main content
Esta página não se aplica ao ClickHouse Cloud. O procedimento descrito aqui é automatizado nos serviços do ClickHouse Cloud.
O ClickHouse Keeper fornece o sistema de coordenação para a replicação de dados e a execução de consultas de DDL distribuído. O ClickHouse Keeper é compatível com o ZooKeeper.

Detalhes de implementação

O ZooKeeper é um dos primeiros sistemas de coordenação open-source amplamente conhecidos. Ele é implementado em Java e tem um modelo de dados simples e poderoso. O algoritmo de coordenação do ZooKeeper, ZooKeeper Atomic Broadcast (ZAB), não fornece garantias de linearizabilidade para leituras, porque cada nó do ZooKeeper atende às leituras localmente. Diferentemente do ZooKeeper, o ClickHouse Keeper é escrito em C++ e usa a implementação do algoritmo RAFT. Esse algoritmo permite linearizabilidade para leituras e escritas e tem várias implementações open-source em diferentes linguagens. Por padrão, o ClickHouse Keeper fornece as mesmas garantias que o ZooKeeper: escritas linearizáveis e leituras não linearizáveis. Ele tem um protocolo cliente-servidor compatível, portanto qualquer cliente ZooKeeper padrão pode ser usado para interagir com o ClickHouse Keeper. Snapshots e logs têm um formato incompatível com o ZooKeeper, mas a ferramenta 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

O ClickHouse Keeper pode ser usado como um substituto independente do ZooKeeper ou como uma parte interna do servidor ClickHouse. Em ambos os casos, a configuração usa praticamente o mesmo arquivo .xml.

Configurações do Keeper

A principal tag de configuração do ClickHouse 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

As configurações internas de coordenação ficam na seçã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 como false para configurar o servidor como learner. 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.
Exemplos de configuração de quórum com três nós podem ser encontrados nos testes de integração com o prefixo test_keeper_. Exemplo de configuração para o servidor #1:

Como executar

O ClickHouse Keeper vem incluído no pacote do servidor ClickHouse; basta adicionar a configuração de <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:
Se você não tiver o link simbólico (clickhouse-keeper), poderá criá-lo ou especificar keeper como argumento para clickhouse:

Comandos de quatro letras

O ClickHouse Keeper também oferece comandos 4lw que são praticamente os mesmos do ZooKeeper. Cada comando é composto por quatro letras, como 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.
Abaixo estão os comandos 4lw detalhados:
  • ruok: Testa se o servidor está em execução sem apresentar erros. O servidor responderá com imok se estiver em execução. Caso contrário, não responderá de forma alguma. Uma resposta imok nã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 de srvr, mntr e stat.
  • 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á com ro se estiver em modo somente leitura ou rw caso 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, retorna Failed to schedule snapshot creation task.. O comando lgif pode 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. Retorna Sent leadership request to leader. se a solicitação for enviada ou Failed 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. Retorna Sent yield leadership request to leader. se a solicitação for enviada ou Failed 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

O ClickHouse Keeper fornece uma interface HTTP para verificar se uma réplica está pronta para receber tráfego. Ela pode ser usada em ambientes de Cloud, como o Kubernetes. Exemplo de configuração que habilita o endpoint /ready:

Feature flags

O Keeper é totalmente compatível com o ZooKeeper e seus clientes, mas também introduz alguns recursos e tipos de requisição exclusivos que podem ser usados pelo ClickHouse client. Como esses recursos podem introduzir alterações incompatíveis com versões anteriores, a maioria deles vem desativada por padrão e pode ser ativada usando a configuração 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:
Os seguintes recursos estão disponíveis:
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

A migração sem interrupção do ZooKeeper para o ClickHouse Keeper não é possível. É preciso parar o cluster do ZooKeeper, converter os dados e iniciar o ClickHouse Keeper. A ferramenta 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

A migração exige interromper a ingestão de dados. Planeje uma janela de manutenção antes de começar. Antes de parar o ZooKeeper, interrompa as tarefas em segundo plano do ClickHouse que modificam os metadados de coordenação. Por exemplo:
Registre as métricas de comparação antes da migração para poder verificar a consistência depois.

Etapas da migração

  1. Interrompa a ingestão de dados em todos os nós do ClickHouse.
  2. Interrompa todas as tarefas em segundo plano em todos os nós do ClickHouse (veja acima).
  3. Interrompa todos os nós do ZooKeeper.
  4. 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.
  5. Execute clickhouse-keeper-converter no nó líder. Se você tiver o binário completo do ClickHouse instalado, use o subcomando keeper-converter (clickhouse keeper-converter). Se nenhum dos dois estiver disponível, baixe o binário.
  1. 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.
  2. Atualize a configuração do ClickHouse para apontar para o novo cluster do Keeper.
  3. Inicie o ClickHouse Keeper em todos os nós e, em seguida, reinicie o ClickHouse.
  4. Compare as métricas com sua linha de base pré-migração para verificar a consistência.
  5. Retome as tarefas em segundo plano e reinicie a ingestão de dados.

Consolidando vários clusters do ZooKeeper

Se você usa vários clusters do ZooKeeper — por exemplo, um por grupo de shards — pode consolidá-los em um único cluster do ClickHouse Keeper. A ferramenta oficial 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:
  1. Execute clickhouse-keeper-converter separadamente em cada cluster do ZooKeeper, gravando cada saída em um diretório distinto.
  2. Desserialize os arquivos de snapshot sequencialmente. Ao mesclar, recalcule os valores de numChildren para evitar conflitos de IDs de nós entre espaços de nomes de diferentes clusters de origem.
  3. Grave a saída mesclada no diretório de snapshots de destino do ClickHouse Keeper.

Como lidar com criptografia e ACLs

O ClickHouse Keeper oferece suporte aos mesmos esquemas de ACL do ZooKeeper (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 -R nos paths afetados. Converta e, em seguida, reative a criptografia no ClickHouse Keeper, se necessário.

Verificando a migração

Após iniciar o ClickHouse Keeper e reiniciar o ClickHouse, compare suas principais métricas com a linha de base pré-migração para confirmar que a migração foi bem-sucedida. Ao consolidar vários clusters do ZooKeeper, distinga entre:
  • 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/tables para cada grupo de shards) — eles devem ser preservados a partir da origem correta.
Evite percorrer diretamente grandes árvores do ZooKeeper para fazer essa comparação. Em vez disso, grave todos os caminhos convertidos em um arquivo durante a conversão.

Ajustes pós-migração

Após a migração, considere ajustar estas configurações para clusters maiores ou com maior vazão: Essas configurações são definidas em coordination_settings na sua configuração do Keeper.

Recuperação após perder quórum

Como o ClickHouse Keeper usa Raft, ele pode tolerar uma certa quantidade de falhas de nós, dependendo do tamanho do cluster. Por exemplo, em um cluster de 3 nós, ele continuará funcionando corretamente se apenas 1 nó falhar. A configuração do cluster pode ser alterada dinamicamente, mas há algumas limitações. A reconfiguração também depende do Raft, portanto, para adicionar/remover um nó do cluster, você precisa ter quórum. Se muitos nós do cluster falharem ao mesmo tempo, sem nenhuma chance de iniciá-los novamente, o Raft deixará de funcionar e não permitirá reconfigurar seu cluster da forma convencional. Ainda assim, o ClickHouse Keeper tem um modo de recuperação que permite reconfigurar o cluster à força com apenas 1 nó. Isso deve ser feito apenas como último recurso, se você não conseguir iniciar seus nós novamente nem iniciar uma nova instância no mesmo endpoint. Pontos importantes antes de continuar:
  • 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.
Depois de garantir que tudo acima está correto, você precisa fazer o seguinte:
  1. 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.
  2. Antes de fazer qualquer outra coisa, faça um backup das pastas log_storage_path e snapshot_storage_path do nó escolhido.
  3. Reconfigure o cluster em todos os nós que você pretende usar.
  4. Envie o comando de quatro letras rcvr para 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.
  5. Um por um, inicie as instâncias do Keeper nos novos nós, garantindo que mntr retorne seguidor para zk_server_state antes de iniciar o próximo.
  6. Enquanto estiver em modo de recuperação, o nó líder retornará uma mensagem de erro para o comando mntr até atingir quórum com os novos nós e recusará quaisquer solicitações do cliente e dos seguidores.
  7. 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 retornar leader para zk_server_state.

Usando discos com Keeper

O Keeper oferece suporte a um subconjunto de discos externos para armazenar snapshots, arquivos de log e o arquivo de estado. Os tipos de disco compatíveis são:
  • s3_plain
  • s3
  • local
A seguir, um exemplo de definições de disco contidas em uma configuração.
Para usar um disco para logs, a configuração 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:
Esta instância armazenará todos os logs, exceto o mais recente, no disco 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

Antes de aplicar uma nova configuração de disco, faça manualmente um backup de todos os logs e snapshots do Keeper.
Se uma configuração de disco em camadas estiver definida (usando discos separados para os arquivos mais recentes), o Keeper tentará mover automaticamente os arquivos para os discos corretos na inicialização. Aplica-se a mesma garantia de antes: até que o arquivo seja completamente movido para o novo disco, ele não é excluído do disco antigo, portanto, é seguro reiniciar várias vezes. Se for necessário mover arquivos para um disco totalmente novo (ou passar de uma configuração com 2 discos para uma configuração com um único disco), é possível usar várias definições de 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:
Ao iniciar, todos os arquivos de log serão movidos de 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

Para minimizar a quantidade de dados lidos do disco, o Keeper mantém entradas de log em cache na memória. Se as solicitações forem grandes, as entradas de log consumirão memória demais, então o volume de logs em cache é limitado. O limite é controlado por estas duas configurações:
  • latest_logs_cache_size_threshold - tamanho total dos logs mais recentes armazenados no cache
  • commit_logs_cache_size_threshold - tamanho total dos logs subsequentes que precisam ser confirmados em seguida
Se os valores padrão forem grandes demais, você pode reduzir o uso de memória diminuindo essas duas configurações.
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

O Keeper pode expor dados de métricas para coleta pelo Prometheus. Configurações:
  • endpoint – Endpoint HTTP para a coleta de métricas pelo servidor Prometheus. Deve começar com ’/’.
  • port – Porta do endpoint.
  • 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.
Exemplo
Verifique (substitua 127.0.0.1 pelo endereço IP ou pelo hostname do seu servidor ClickHouse):
Consulte também a integração com Prometheus do ClickHouse Cloud.

Guia do usuário do ClickHouse Keeper

Este guia apresenta configurações simples e mínimas para configurar o ClickHouse Keeper, com um exemplo de como testar operações distribuídas. Este exemplo é executado em 3 nós Linux.
1

Configure os nós com as configurações do Keeper

  1. 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.)
  2. Em cada nó, adicione a seguinte entrada para permitir a comunicação externa por meio da interface de rede.
  3. Adicione a seguinte configuração do ClickHouse Keeper aos três servidores, atualizando a configuração <server_id> em cada servidor; para chnode1, seria 1, para chnode2, seria 2 e assim por diante.
    Estas são as configurações básicas usadas acima:
  4. Habilite o componente Zookeeper. Ele usará o mecanismo ClickHouse Keeper:
    Estas são as configurações básicas usadas acima:
  5. 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 ruok retorna imok se o Keeper estiver em execução e funcionando corretamente:
  6. O banco de dados system tem uma tabela chamada zookeeper que 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

  1. 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 chnode1 e chnode2. 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:
  2. Reinicie o ClickHouse e verifique se o cluster foi criado:
    Você deverá ver seu cluster:
3

Criar e testar a tabela distribuída

  1. Crie um novo banco de dados no novo cluster usando o clickhouse client em chnode1. A cláusula ON CLUSTER cria automaticamente o banco de dados em ambos os nós.
  2. Crie uma nova tabela no banco de dados db1. Mais uma vez, ON CLUSTER cria a tabela em ambos os nós.
  3. No nó chnode1, adicione algumas linhas:
  4. Adicione algumas linhas no nó chnode2:
  5. Observe que executar uma instrução SELECT em cada nó mostra apenas os dados daquele nó. Por exemplo, em chnode1:
    Em chnode2:
  6. Você pode criar uma tabela Distributed para representar os dados nos dois shards. Tabelas com o engine Distributed nã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 em chnode1:
  7. Observe que consultar dist_table retorna todas as quatro linhas de dados dos dois shards:

Resumo

Este guia mostrou como configurar um cluster usando o ClickHouse Keeper. Com o ClickHouse Keeper, você pode configurar clusters e definir tabelas distribuídas que podem ser replicadas entre os shards.

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

Este artigo descreve como usar a configuração da macro interna {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

Um cluster de três nós que será configurado para ter o ClickHouse Keeper em todos os três nós e o ClickHouse em dois deles. Isso fornece ao ClickHouse Keeper três nós (incluindo um nó de desempate) e um único shard do ClickHouse composto por duas réplicas. Configuração de Example para o cluster:

Procedimentos para configurar tabelas para usarem {uuid}

  1. 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.
  1. Crie um banco de dados
  1. Crie uma tabela no cluster usando as macros e {uuid}
  1. Crie uma tabela distribuída

Teste

  1. Insira dados no primeiro nó (por exemplo, chnode1)
  1. Insira dados no segundo nó (por exemplo, chnode2)
  1. Visualize os registros usando a tabela distribuída

Alternativas

O caminho de replicação padrão pode ser definido previamente por macros e também com {uuid}
  1. Defina o padrão das tabelas em cada nó
Você também pode definir uma macro {database} em cada nó, caso os nós sejam usados para bancos de dados específicos.
  1. Crie a tabela sem parâmetros explícitos:
  1. Verifique se ele usou as mesmas configurações da configuração padrão

Solução de problemas

Exemplo de comando para obter informações da tabela e o UUID:
Comando de exemplo para obter informações sobre a tabela no ZooKeeper usando o UUID da tabela acima
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.
Para verificar: Por exemplo,

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

O ClickHouse Keeper oferece suporte parcial ao comando 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.
Um nó virtual /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 é participant ou learner (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.
Exemplo:
Você pode usar o comando reconfig para adicionar novos servidores, remover os existentes e alterar as prioridades dos servidores atuais. Veja alguns exemplos (usando clickhouse-keeper-client):
E aqui estão exemplos de kazoo:
Os servidores em 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_members nã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 de joining, cada parte de leaving) 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 znodestat retornado.
  • O campo from_version não é usado. Todas as requisições com from_version definido 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 reconfig pode 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

Às vezes, é necessário expandir um nó keeper experimental para formar um cluster. Veja a seguir como fazer isso passo a passo em um cluster de 3 nós:
  • 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_reconfiguration habilitado.
  • 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.
Para se familiarizar com o processo, aqui está um repositório sandbox.

Recursos não suportados

Embora o ClickHouse Keeper tenha como objetivo ser totalmente compatível com o ZooKeeper, alguns recursos ainda não foram implementados (embora o desenvolvimento continue em andamento):
Última modificação em 23 de julho de 2026