Alta Disponibilidad ClickHouse¶

ClickHouse es una base de datos columnar para carga analítica: ingesta de gran volumen y consultas que recorren miles de millones de filas. Su disponibilidad funciona de forma distinta a la de una base transaccional — no hay un primario y un standby, sino réplicas que se coordinan entre sí a través de un servicio de consenso, ClickHouse Keeper.

Dos conceptos independientes definen la topología:

• Réplica — copia completa de los mismos datos. Sirve para la disponibilidad: si un nodo cae, otro responde.
• Shard — porción de los datos. Sirve para la escala: distribuye volumen y paraleliza la consulta.

Un clúster de producción normalmente combina ambos: cada shard tiene al menos dos réplicas.

Topología de referencia¶

La tabla distribuida es el punto de entrada de las consultas; cada shard guarda una porción de los datos en dos réplicas, y Keeper coordina la replicación.

• Tablas ReplicatedMergeTree — la replicación ocurre por tabla, no por servidor, y siempre es multi-master: cualquier réplica acepta INSERT.
• Quórum de ClickHouse Keeper con número impar de nodos (tres, en la topología estándar) — guarda el log de replicación, coordina los merges y realiza la deduplicación de bloques.
• Réplicas en hosts físicos distintos, con anti-affinity cuando el clúster corre en Kubernetes.
• Tabla distribuida sobre los shards, para que la aplicación use un único punto de entrada.

El camino de la escritura¶

Cualquier réplica acepta la escritura; la entrada registrada en Keeper hace que la otra réplica busque exactamente el mismo bloque de datos.

1. El INSERT llega a cualquier réplica del shard y se graba como un part local.
2. La réplica registra la operación en el log de replicación, en Keeper.
3. Las demás réplicas del mismo shard leen el log y buscan el part.
4. Los bloques idénticos reenviados se deduplican automáticamente por hash — lo que hace seguro el retry de una ingesta interrumpida.

Recomendaciones de ingesta que marcan más diferencia que cualquier ajuste de hardware:

• Lotes grandes y poco frecuentes — ClickHouse fue diseñado para recibir bloques, no filas sueltas. Miles de INSERT de una fila tumban el rendimiento de un clúster sano.
• Una cola por delante (Kafka, buffer o tabla intermedia) absorbe picos y sobrevive a una réplica no disponible.
• INSERT idempotente — manteniendo el mismo lote en el retry, la deduplicación evita datos duplicados.

El camino de la lectura¶

La consulta se envía a una réplica sana de cada shard; la réplica no disponible se ignora y los resultados parciales se fusionan en el nodo iniciador.

• Cada shard procesa su porción y devuelve una agregación parcial; el nodo iniciador fusiona.
• Basta una réplica sana por shard para responder la consulta.
• Si un shard entero está fuera, el resultado queda incompleto — por eso todo shard tiene como mínimo dos réplicas.
• La elección de la réplica considera el retraso de replicación y la carga, evitando enviar consultas a un nodo atrasado.

¿Kubernetes o máquinas virtuales?¶

Las cargas analíticas son pesadas en disco y memoria. En la práctica decidimos por el volumen de datos y el patrón de crecimiento — y, en ambos casos, con almacenamiento dedicado a la base de datos.

Backup y retención¶

La replicación no protege contra el error humano, y en ClickHouse eso es especialmente cierto: un DROP TABLE se propaga a todas las réplicas.

• Backup de los parts a almacenamiento de objetos, con retención definida y restauración probada.
• Snapshot de volumen cifrado en el clúster en Kubernetes, mantenido en Brasil o replicado a otro país — vea Soberanía de datos.
• TTL de datos — los datos analíticos antiguos pueden moverse a almacenamiento más barato o descartarse automáticamente; menos volumen es menos coste y consultas más rápidas.
• Permisos SYSTEM restringidos — los comandos destructivos y de manipulación de réplicas no pertenecen al usuario de la aplicación.

Monitorización que acompaña al clúster¶

• retraso de replicación y tamaño de la cola por réplica;
• disponibilidad y latencia del quórum de Keeper;
• parts por partición y ritmo de merge — el exceso de parts es el síntoma clásico de INSERT demasiado pequeños;
• uso de disco por shard, con proyección de crecimiento;
• consultas más lentas y consumo de memoria por consulta;
• éxito del backup y de la restauración de prueba.

Soberanía de datos¶

Todo el dato de este clúster permanece en Brasil. Las dos regiones de InteSys son brasileñas — br-sp-1 (Cirion SAO1), en Cotia/SP, y br-sp-2 (Equinix SP3), en el área metropolitana de São Paulo — y el dato solo sale del país si el cliente lo pide.

• Residencia de datos en Brasil — nodos primarios, réplicas, archivos de log de transacciones y backups permanecen en datacenter brasileño, sobre infraestructura operada por InteSys.
• LGPD sin transferencia internacional — en la configuración estándar no existe transferencia internacional de datos personales que documentar, ni base legal adicional que construir.
• Jurisdicción única — infraestructura brasileña, contrato brasileño y operación por equipo brasileño, sin la exposición a legislación extranjera de acceso a datos que alcanza a proveedores con sede fuera del país.
• Latencia como consecuencia — mantener el dato cerca del usuario brasileño es, a la vez, requisito de cumplimiento y ganancia de rendimiento.
• Sacar datos del país es una decisión explícita del cliente — cualquier copia fuera de Brasil existe solo cuando se solicita, y solo en volumen cifrado.

Snapshot de volumen cifrado¶

Además del backup de los parts a almacenamiento de objetos, el clúster en Kubernetes puede usar snapshots de volumen (VolumeSnapshot vía CSI): una copia del volumen entero, tomada en segundos — lo que importa cuando cada réplica guarda terabytes.

• Snapshot consistente — el operador coordina el flush y congela la escritura antes de disparar el snapshot, para que la restauración no dependa de recuperación tras fallo.
• Siempre en volumen cifrado — el dato está cifrado en reposo y el snapshot hereda ese cifrado; la clave la gestiona InteSys o la aporta el cliente.
• Copia cifrada en tránsito — la replicación del snapshot hacia otro destino viaja cifrada y se almacena cifrada en el destino.
• Retención y restauración probada — política de retención definida y restauración ejercitada periódicamente; un snapshot que nunca se restauró es una hipótesis, no un backup.
• Recuperación rápida — el snapshot devuelve el volumen entero en minutos; el backup de los parts sigue siendo lo que protege contra el DROP TABLE que se propaga a todas las réplicas.

Cómo lo implementa InteSys¶

1. Modelado de la carga — volumen de ingesta, retención, clave de ordenación y patrón de consulta.
2. Topología — número de shards y réplicas, dimensionamiento del quórum de Keeper.
3. Aprovisionamiento — réplicas en hosts físicos distintos, en Kubernetes o VMs, con almacenamiento dedicado.
4. Capa de ingesta — lotes, cola e idempotencia definidos junto al equipo de la aplicación.
5. Tablas distribuidas y permisos — punto de entrada único y separación entre el usuario de lectura y el de ingesta.
6. Backup, TTL y retención en almacenamiento de objetos.
7. Prueba de fallo — tumbamos una réplica y un nodo de Keeper en un entorno controlado, midiendo el impacto real.
8. Observabilidad y alertas — métricas, paneles y alertas conectados al equipo de operación.

Próximos Pasos¶

• Alta Disponibilidad PostgreSQL — HA para la carga transaccional que alimenta el analítico
• Alta Disponibilidad MySQL — La misma arquitectura aplicada a MySQL
• Kubernetes — Clústeres gestionados donde operar ClickHouse
• Centros de Datos InteSys — Detalles de las regiones br-sp-1 y br-sp-2