Alta Disponibilidade ClickHouse¶

O ClickHouse é um banco colunar para carga analítica: ingestão em grande volume e consultas que varrem bilhões de linhas. A disponibilidade dele funciona de forma diferente de um banco transacional — não há um primário e um standby, e sim réplicas que se coordenam entre si através de um serviço de consenso, o ClickHouse Keeper.

Dois conceitos independentes definem a topologia:

• Réplica — cópia completa dos mesmos dados. Serve para disponibilidade: se um nó cai, outro responde.
• Shard — fatia dos dados. Serve para escala: distribui volume e paraleliza a consulta.

Um cluster de produção normalmente combina os dois: cada shard tem ao menos duas réplicas.

Topologia de referência¶

A tabela distribuída é o ponto de entrada das consultas; cada shard guarda uma fatia dos dados em duas réplicas, e o Keeper coordena a replicação.

• Tabelas ReplicatedMergeTree — a replicação acontece por tabela, não por servidor, e é sempre multi-master: qualquer réplica aceita INSERT.
• Quórum de ClickHouse Keeper com número ímpar de nós (três, na topologia padrão) — guarda o log de replicação, coordena os merges e faz a desduplicação de blocos.
• Réplicas em hosts físicos distintos, com anti-affinity quando o cluster roda em Kubernetes.
• Tabela distribuída sobre os shards, para que a aplicação use um único ponto de entrada.

O caminho da escrita¶

Qualquer réplica aceita a escrita; a entrada registrada no Keeper faz a outra réplica buscar exatamente o mesmo bloco de dados.

1. O INSERT chega em qualquer réplica do shard e é gravado como um part local.
2. A réplica registra a operação no log de replicação, no Keeper.
3. As demais réplicas do mesmo shard leem o log e buscam o part.
4. Blocos idênticos reenviados são desduplicados automaticamente pelo hash — o que torna seguro o retry de uma ingestão interrompida.

Recomendações de ingestão que fazem mais diferença que qualquer ajuste de hardware:

• Lotes grandes e pouco frequentes — o ClickHouse foi feito para receber blocos, não linhas soltas. Milhares de INSERT de uma linha derrubam o desempenho de um cluster saudável.
• Uma fila na frente (Kafka, buffer ou tabela intermediária) absorve picos e sobrevive a uma réplica indisponível.
• INSERT idempotente — mantendo o mesmo lote no retry, a desduplicação evita dado duplicado.

O caminho da leitura¶

A consulta é enviada a uma réplica saudável de cada shard; a réplica indisponível é ignorada e os resultados parciais são mesclados no nó iniciador.

• Cada shard processa a sua fatia e devolve uma agregação parcial; o nó iniciador mescla.
• Uma réplica saudável por shard basta para responder a consulta.
• Se um shard inteiro estiver fora, o resultado fica incompleto — por isso todo shard tem no mínimo duas réplicas.
• A escolha da réplica considera atraso de replicação e carga, evitando enviar consulta para um nó atrasado.

Kubernetes ou máquinas virtuais?¶

Cargas analíticas são pesadas em disco e memória. Na prática, decidimos pelo volume de dados e pelo padrão de crescimento — e, em ambos os casos, com storage dedicado ao banco.

Backup e retenção¶

Replicação não protege contra erro humano, e no ClickHouse isso é especialmente verdadeiro: um DROP TABLE se propaga para todas as réplicas.

• Backup dos parts para armazenamento de objetos, com retenção definida e restauração testada.
• Snapshot de volume criptografado no cluster em Kubernetes, mantido no Brasil ou replicado para outro país — veja Soberania de dados.
• TTL de dados — dados analíticos antigos podem ser movidos para armazenamento mais barato ou descartados automaticamente; menos volume é menos custo e consulta mais rápida.
• SYSTEM grants restritos — comandos destrutivos e de manipulação de réplica não pertencem ao usuário da aplicação.

Monitoramento que acompanha o cluster¶

• atraso de replicação e tamanho da fila por réplica;
• disponibilidade e latência do quórum de Keeper;
• parts por partição e ritmo de merge — excesso de parts é o sintoma clássico de INSERT pequenos demais;
• uso de disco por shard, com projeção de crescimento;
• consultas mais lentas e consumo de memória por consulta;
• sucesso do backup e da restauração de teste.

Soberania de dados¶

Todo o dado deste cluster fica no Brasil. As duas regiões da InteSys são brasileiras — br-sp-1 (Cirion SAO1), em Cotia/SP, e br-sp-2 (Equinix SP3), na região metropolitana de São Paulo — e o dado só sai do país se o cliente pedir.

• Residência de dados no Brasil — nós primários, réplicas, arquivos de log de transação e backups ficam em datacenter brasileiro, em infraestrutura operada pela InteSys.
• LGPD sem transferência internacional — na configuração padrão não existe transferência internacional de dados pessoais para documentar, nem base legal adicional a construir.
• Jurisdição única — infraestrutura brasileira, contrato brasileiro e operação por equipe brasileira, sem a exposição a legislação estrangeira de acesso a dados que alcança provedores sediados fora do país.
• Latência como consequência — manter o dado perto do usuário brasileiro é, ao mesmo tempo, requisito de conformidade e ganho de desempenho.
• Saída de dados é decisão explícita do cliente — qualquer cópia fora do país existe apenas quando pedida, e apenas em volume criptografado.

Snapshot de volume criptografado¶

Além do backup dos parts para armazenamento de objetos, o cluster em Kubernetes pode usar snapshots de volume (VolumeSnapshot via CSI): uma cópia do volume inteiro, tirada em segundos — o que faz diferença real quando cada réplica guarda terabytes.

• Snapshot consistente — o operador coordena o flush e o congelamento da escrita antes de disparar o snapshot, para que a restauração não dependa de recuperação de falha.
• Sempre em volume criptografado — o dado é cifrado em repouso e o snapshot herda essa criptografia; a chave é gerenciada pela InteSys ou fornecida pelo cliente.
• Cópia cifrada em trânsito — a replicação do snapshot para outro destino trafega criptografada e é armazenada cifrada no destino.
• Retenção e restauração testada — política de retenção definida e restauração exercitada periodicamente; snapshot que nunca foi restaurado é hipótese, não backup.
• Recuperação rápida — o snapshot devolve o volume inteiro em minutos; o backup dos parts continua sendo o que protege contra o DROP TABLE que se propaga para todas as réplicas.

Como a InteSys implanta¶

1. Modelagem da carga — volume de ingestão, retenção, chave de ordenação e padrão de consulta.
2. Topologia — número de shards e réplicas, dimensionamento do quórum de Keeper.
3. Provisionamento — réplicas em hosts físicos distintos, em Kubernetes ou VMs, com storage dedicado.
4. Camada de ingestão — lotes, fila e idempotência definidas junto com a equipe da aplicação.
5. Tabelas distribuídas e permissões — ponto de entrada único e separação entre usuário de leitura e de ingestão.
6. Backup, TTL e retenção em armazenamento de objetos.
7. Teste de falha — derrubamos uma réplica e um nó de Keeper em ambiente controlado, medindo o impacto real.
8. Observabilidade e alertas — métricas, painéis e alertas ligados ao time de operação.

Próximos Passos¶

• Alta Disponibilidade PostgreSQL — HA para a carga transacional que alimenta o analítico
• Alta Disponibilidade MySQL — A mesma arquitetura aplicada ao MySQL
• Kubernetes — Clusters gerenciados onde o ClickHouse pode ser operado
• Datacenters InteSys — Detalhes das regiões br-sp-1 e br-sp-2