Esta página no se aplica a ClickHouse Cloud. El procedimiento que se documenta aquí está automatizado en los servicios de ClickHouse Cloud.
Detalles de implementación
clickhouse-keeper-converter permite convertir datos de ZooKeeper en instantáneas de ClickHouse Keeper. El protocolo entre servidores de ClickHouse Keeper también es incompatible con ZooKeeper, por lo que no es posible tener un cluster mixto de ZooKeeper / ClickHouse Keeper.
ClickHouse Keeper admite listas de control de acceso (ACL) del mismo modo que ZooKeeper. ClickHouse Keeper admite el mismo conjunto de permissions y tiene los mismos esquemas integrados: world, auth y digest. El esquema de authentication digest usa la pareja username:password; la contraseña se codifica en Base64.
No se admiten integrations externas.
Configuración
.xml.
Parámetros de configuración de Keeper
<keeper_server> y tiene los siguientes parámetros:
Otros parámetros comunes se heredan de la configuración del ClickHouse server (
listen_host, logger, etc.).
Configuración de coordinación interna
<keeper_server>.<coordination_settings> y tiene los siguientes parámetros:
La configuración del quórum se encuentra en la sección
<keeper_server>.<raft_configuration> y contiene la descripción de los servidores.
El único parámetro para todo el quórum es secure, que habilita una conexión cifrada para la comunicación entre los participantes del quórum. El parámetro puede establecerse en true si se requiere una conexión SSL para la comunicación interna entre nodos, o dejarse sin especificar en caso contrario.
Los parámetros principales para cada <server> son:
id— Identificador del servidor en un quórum.hostname— Nombre de host donde está ubicado este servidor.port— Puerto en el que este servidor escucha conexiones.can_become_leader— Establézcalo enfalsepara configurar el servidor comolearner. Si se omite, el valor estrue.
Si cambia la topología de su cluster de ClickHouse Keeper (por ejemplo, al sustituir un servidor), asegúrese de mantener coherente la asignación de
server_id a hostname y evite reorganizar o reutilizar un server_id existente para servidores distintos (por ejemplo, esto puede ocurrir si utiliza scripts de automatización para desplegar ClickHouse Keeper).Si el host de una instancia de Keeper puede cambiar, recomendamos definir y usar un nombre de host en lugar de direcciones IP sin procesar. Cambiar el nombre de host equivale a quitar y volver a añadir el servidor, lo que en algunos casos puede ser imposible (por ejemplo, si no hay suficientes instancias de Keeper para alcanzar el quórum).async_replication está deshabilitado de forma predeterminada para evitar romper la compatibilidad con versiones anteriores. Si todas las instancias de Keeper de su cluster ejecutan una versión compatible con async_replication (v23.9+), recomendamos habilitarlo, ya que puede mejorar el rendimiento sin inconvenientes.test_keeper_. Configuración de ejemplo para el servidor n.º 1:
Cómo ejecutarlo
<keeper_server> a tu /etc/your_path_to_config/clickhouse-server/config.xml e inicia ClickHouse server como siempre. Si quieres ejecutar ClickHouse Keeper en modo standalone, puedes iniciarlo de forma similar con:
clickhouse-keeper), puede crearlo o indicar keeper como argumento de clickhouse:
Comandos de cuatro letras
mntr, stat, etc. Hay algunos comandos especialmente interesantes: stat proporciona información general sobre el servidor y los clientes conectados, srvr proporciona detalles ampliados sobre el servidor y cons proporciona detalles ampliados sobre las conexiones.
Los comandos 4lw tienen una configuración de lista blanca, four_letter_word_white_list, cuyo valor predeterminado es conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld.
Puede enviar los comandos a ClickHouse Keeper mediante telnet o nc, en el puerto del cliente.
ruok: Comprueba si el servidor está en ejecución y sin errores. El servidor responderá conimoksi está en ejecución. De lo contrario, no responderá en absoluto. Una respuesta deimokno indica necesariamente que el servidor se haya unido al quórum, sino únicamente que el proceso del servidor está activo y vinculado al puerto cliente especificado. Use “stat” para obtener más detalles sobre el estado con respecto al quórum y la información de conexión del cliente.
mntr: Muestra una lista de variables que pueden usarse para supervisar el estado del clúster.
srvr: Muestra todos los detalles del servidor.
stat: Muestra información breve sobre el servidor y los clientes conectados.
srst: Reinicia las estadísticas del servidor. El comando afectará el resultado desrvr,mntrystat.
conf: Muestra detalles sobre la configuración del servicio.
cons: Enumera todos los detalles de conexión/sesión de todos los clientes conectados a este servidor. Incluye información sobre la cantidad de paquetes recibidos/enviados, el ID de sesión, las latencias de las operaciones, la última operación realizada, etc…
crst: Reinicia las estadísticas de conexión/sesión para todas las conexiones.
envi: Imprime detalles del entorno de servicio
dirs: Muestra el tamaño total de las instantáneas y los archivos de log en bytes
isro: Comprueba si el servidor está en modo de solo lectura. El servidor responderá conrosi está en modo de solo lectura o conrwen caso contrario.
wchs: Muestra información breve sobre los watches del servidor.
wchc: Muestra información detallada sobre los watches del servidor por sesión. Esto muestra una lista de sesiones (conexiones) con los watches asociados (rutas). Ten en cuenta que, dependiendo del número de watches, esta operación puede ser costosa (y afectar al rendimiento del servidor); úsala con cuidado.
wchp: Enumera información detallada sobre los watches del servidor por ruta. Muestra una lista de rutas (znodes) con las sesiones asociadas. Ten en cuenta que, según el número de watches, esta operación puede resultar costosa (es decir, afectar al rendimiento del servidor), así que úsala con cuidado.
dump: Enumera las sesiones activas y los nodos efímeros. Solo funciona en el líder.
csnp: Programa una tarea de creación de instantánea. Devuelve el índice de log confirmado más reciente de la instantánea programada si la operación se completa correctamente, oFailed to schedule snapshot creation task.si falla. El comandolgifpuede ayudarle a determinar si la instantánea ya está lista.
lgif: Información del log de Keeper.first_log_idx: mi primer índice de log en el almacén de logs;first_log_term: mi primer término de log;last_log_idx: mi último índice de log en el almacén de logs;last_log_term: mi último término de log;last_committed_log_idx: mi último índice de log confirmado en la máquina de estados;leader_committed_log_idx: índice de log confirmado del líder desde mi perspectiva;target_committed_log_idx: índice de log de destino que debe confirmarse;last_snapshot_idx: el índice de log confirmado más alto de la última snapshot.
rqld: Solicita convertirse en el nuevo líder. DevuelveSent leadership request to leader.si la solicitud se envía, oFailed to send leadership request to leader.si no se envía. Si el nodo ya es el líder, el resultado es el mismo que si la solicitud se hubiera enviado.
ftfl: Enumera todas las banderas de funcionalidad y si están habilitadas en la instancia de Keeper.
ydld: Solicitud para ceder el liderazgo y pasar a ser seguidor. Si el servidor que recibe la solicitud es el líder, primero pausará las operaciones de escritura, esperará a que el sucesor (el líder actual nunca puede ser el sucesor) termine de ponerse al día con el registro más reciente y, a continuación, dejará el cargo. El sucesor se elegirá automáticamente. DevuelveSent yield leadership request to leader.si la solicitud se envió oFailed to send yield leadership request to leader.si no se envió. Si el nodo ya es seguidor, el resultado es el mismo que si la solicitud se hubiera enviado.
pfev: Devuelve los valores de todos los eventos recopilados. Para cada evento, devuelve su nombre, su valor y su descripción.
Control HTTP
/ready:
Banderas de funcionalidad
keeper_server.feature_flags.
Todas las funcionalidades pueden deshabilitarse explícitamente.
Si desea habilitar una nueva funcionalidad en su clúster de Keeper, le recomendamos primero actualizar todas las instancias de Keeper del clúster a una versión que admita esa funcionalidad y, después, habilitar la funcionalidad en sí.
Ejemplo de configuración de banderas de funcionalidad que deshabilita multi_read y habilita check_not_exists:
Algunas de las banderas de funcionalidad están habilitadas de forma predeterminada a partir de la versión 25.7.
La forma recomendada de actualizar Keeper a 25.7+ es actualizar primero a la versión 24.9+.
Migración desde ZooKeeper
clickhouse-keeper-converter convierte los logs y instantáneas de ZooKeeper en una instantánea de ClickHouse Keeper. Requiere ZooKeeper 3.4 o posterior.
Preparación previa a la migración
Pasos de migración
- Detenga la ingestión de datos en todos los nodos de ClickHouse.
- Detenga todas las tareas en segundo plano en todos los nodos de ClickHouse (consulte más arriba).
- Detenga todos los nodos de ZooKeeper.
- Opcional, pero recomendable: identifique el nodo líder de ZooKeeper, inícielo y vuelva a detenerlo. Esto obliga a ZooKeeper a escribir una instantánea coherente en disco antes de la conversión.
-
Ejecute
clickhouse-keeper-converteren el nodo líder. Si tiene instalado el binario completo de ClickHouse, use en su lugar el subcomandokeeper-converter(clickhouse keeper-converter). Si no dispone de ninguno de los dos, descargue el binario.
- Copie la instantánea en todos los nodos de ClickHouse Keeper. La instantánea debe estar presente en cada nodo antes de que se inicie cualquiera de ellos; si un nodo se inicia sin una instantánea, puede elegirse a sí mismo como líder con un estado vacío.
- Actualice la configuración de ClickHouse para que apunte al nuevo clúster de Keeper.
- Inicie ClickHouse Keeper en todos los nodos y, a continuación, reinicie ClickHouse.
- Compare las métricas con la referencia previa a la migración para verificar la consistencia.
- Reanude las tareas en segundo plano y reinicie la ingestión de datos.
Consolidación de varios clústeres de ZooKeeper
clickhouse-keeper-converter solo admite conversiones uno a uno (un clúster de ZooKeeper a una instantánea de Keeper), por lo que la consolidación requiere modificar el código fuente del convertidor para fusionar varias instantáneas:
- Ejecute
clickhouse-keeper-converterpor separado en cada clúster de ZooKeeper y escriba cada salida en un directorio distinto. - Deserialice los archivos de instantánea de forma secuencial. Al fusionarlos, recalcule los valores de
numChildrenpara evitar conflictos de ID de nodo entre espacios de nombres de distintos clústeres de origen. - Escriba la salida fusionada en el directorio de instantáneas de ClickHouse Keeper de destino.
Gestión del cifrado y las ACL
world, auth, digest). La forma de gestionar las ACL durante la conversión depende de su configuración de ZooKeeper:
- Completamente cifrado o completamente sin cifrar: Convierta directamente. El convertidor conserva la información existente de las ACL.
- Parcialmente cifrado: Antes de convertir, conceda privilegios de superadministrador a una cuenta y borre las ACL con
setAcl -Ren las rutas afectadas. Convierta y, después, vuelva a habilitar el cifrado en ClickHouse Keeper si es necesario.
Verificación de la migración
- Rutas comunes: rutas presentes en varios clústeres de origen con datos idénticos; deben deduplicarse en el resultado combinado.
- Rutas diferenciadas: rutas que existen solo en clústeres específicos (por ejemplo, en
/clickhouse/tablespara cada grupo de segmentos); deben conservarse del origen correcto.
Ajustes posteriores a la migración
Estos parámetros se configuran en
coordination_settings de su configuración de Keeper.
Recuperación tras perder el quórum
- Asegúrate de que los nodos fallidos no puedan volver a conectarse al clúster.
- No inicies ninguno de los nodos nuevos hasta que se indique en los pasos.
- Elige un único nodo de Keeper para que sea tu nuevo líder. Ten en cuenta que los datos de ese nodo se usarán para todo el clúster, por lo que recomendamos usar un nodo con el estado más actualizado.
- Antes de hacer cualquier otra cosa, haz una copia de seguridad de las carpetas
log_storage_pathysnapshot_storage_pathdel nodo elegido. - Reconfigura el clúster en todos los nodos que quieras usar.
- Envía el comando de cuatro letras
rcvral nodo que elegiste, lo que pondrá ese nodo en modo de recuperación, O bien detén la instancia de Keeper en el nodo elegido y vuelve a iniciarla con el argumento--force-recovery. - Uno por uno, inicia las instancias de Keeper en los nodos nuevos y asegúrate de que
mntrdevuelvafollowerparazk_server_stateantes de iniciar el siguiente. - Mientras esté en modo de recuperación, el nodo líder devolverá un mensaje de error para el comando
mntrhasta que alcance quórum con los nodos nuevos, y rechazará cualquier solicitud del cliente y de los seguidores. - Cuando se alcance el quórum, el nodo líder volverá al modo de funcionamiento normal y aceptará todas las solicitudes usando Raft; verifícalo con
mntr, que debería devolverleaderparazk_server_state.
Uso de discos con Keeper
- s3_plain
- s3
- local
keeper_server.log_storage_disk debe establecerse con el nombre del disco.
Para usar un disco para las instantáneas, la configuración keeper_server.snapshot_storage_disk debe establecerse con el nombre del disco.
Además, keeper_server.latest_log_storage_disk puede usarse para los logs más recientes y keeper_server.latest_snapshot_storage_disk para las instantáneas más recientes.
En ese caso, Keeper moverá automáticamente los archivos a los discos correspondientes cuando se creen nuevos logs o instantáneas.
Para usar un disco para el archivo de estado, la configuración keeper_server.state_storage_disk debe establecerse con el nombre del disco.
Mover archivos entre discos es seguro y no hay riesgo de pérdida de datos si Keeper se detiene en mitad de la transferencia.
Hasta que el archivo se haya movido por completo al nuevo disco, no se elimina del disco anterior.
Keeper con keeper_server.coordination_settings.force_sync establecido en true (true de forma predeterminada) no puede ofrecer ciertas garantías en todos los tipos de disco.
En este momento, solo los discos de tipo local admiten sincronización persistente.
Si se usa force_sync, log_storage_disk debe ser un disco local si no se usa latest_log_storage_disk.
Si se usa latest_log_storage_disk, siempre debe ser un disco local.
Si force_sync está deshabilitado, pueden usarse discos de cualquier tipo en cualquier configuración.
Una posible configuración de almacenamiento para una instancia de Keeper podría ser la siguiente:
log_s3_plain, mientras que el log más reciente estará en el disco log_local.
La misma lógica se aplica a las instantáneas: todas las instantáneas, salvo la más reciente, se almacenarán en snapshot_s3_plain, mientras que la instantánea más reciente estará en el disco snapshot_local.
Cambio de la configuración de discos
keeper_server.old_snapshot_storage_disk y keeper_server.old_log_storage_disk.
La siguiente configuración muestra cómo pasar de la configuración anterior de 2 discos a una configuración completamente nueva de un solo disco:
log_local y log_s3_plain al disco log_local2.
Además, todos los archivos de instantánea se moverán de snapshot_local y snapshot_s3_plain al disco snapshot_local2.
Configuración de la caché de logs
latest_logs_cache_size_threshold- tamaño total de los logs más recientes almacenados en cachécommit_logs_cache_size_threshold- tamaño total de los logs posteriores pendientes de confirmación
Puede usar el comando
pfev para comprobar la cantidad de logs leídos desde cada caché y desde un archivo.
También puede usar métricas del endpoint de Prometheus para realizar un seguimiento del tamaño actual de ambas cachés.Prometheus
endpoint– endpoint HTTP para la recopilación de métricas por parte del servidor Prometheus. Debe comenzar con ’/’.port– Puerto deendpoint.metrics– Indicador que habilita la exposición de métricas de la tabla system.metrics.events– Indicador que habilita la exposición de métricas de la tabla system.events.asynchronous_metrics– Indicador que habilita la exposición de los valores actuales de las métricas de la tabla system.asynchronous_metrics.
127.0.0.1 por la dirección IP o el nombre de host de su servidor de ClickHouse):
Guía de usuario de ClickHouse Keeper
1. Configure los nodos con los ajustes de Keeper
-
Instale 3 instancias de ClickHouse en 3 hosts (
chnode1,chnode2,chnode3). (Consulte la Quick Start para obtener más información sobre cómo instalar ClickHouse.) -
En cada nodo, agregue la siguiente entrada para permitir la comunicación externa a través de la interfaz de red.
-
Añada la siguiente configuración de ClickHouse Keeper a los tres servidores y actualice el parámetro
<server_id>en cada uno; parachnode1sería1,chnode2sería2, etc.Estos son los ajustes básicos utilizados más arriba: -
Habilite el componente Zookeeper. Utilizará el motor ClickHouse Keeper:
Estos son los ajustes básicos utilizados anteriormente:
-
Reinicie ClickHouse y verifique que cada instancia de Keeper esté en funcionamiento. Ejecute el siguiente comando en cada servidor. El comando
ruokdevuelveimoksi Keeper se está ejecutando y está en buen estado: -
La base de datos
systemtiene una tabla llamadazookeeperque contiene los detalles de las instancias de ClickHouse Keeper. Veamos la tabla:La tabla se ve así:
2. Configurar un clúster en ClickHouse
-
Configuremos un clúster simple con 2 segmentos y solo una réplica en 2 de los nodos. El tercer nodo se utilizará para lograr el quorum requerido en ClickHouse Keeper. Actualiza la configuración en
chnode1ychnode2. El siguiente clúster define 1 segmento en cada nodo, para un total de 2 segmentos sin replicación. En este ejemplo, parte de los datos estará en un nodo y otra parte en el otro: -
Reinicia ClickHouse y verifica que el clúster se haya creado:
Deberías ver tu clúster:
3. Crear y probar una tabla distribuida
-
Cree una nueva base de datos en el nuevo clúster con el cliente de ClickHouse en
chnode1. La cláusulaON CLUSTERcrea automáticamente la base de datos en ambos nodos. -
Cree una nueva tabla en la base de datos
db1. Una vez más,ON CLUSTERcrea la tabla en ambos nodos. -
En el nodo
chnode1, agregue un par de filas: -
Agregue un par de filas en el nodo
chnode2: -
Tenga en cuenta que, al ejecutar una instrucción
SELECTen cada nodo, solo se muestran los datos de ese nodo. Por ejemplo, enchnode1:Enchnode2: -
-
Puede crear una tabla
Distributedpara representar los datos de los dos segmentos. Las tablas con el engine de tablaDistributedno almacenan datos propios, pero permiten el procesamiento distribuido de consultas en varios servidores. Las lecturas acceden a todos los segmentos, y las escrituras pueden distribuirse entre ellos. Ejecute la siguiente consulta enchnode1: -
Tenga en cuenta que consultar
dist_tabledevuelve las cuatro filas de datos de los dos segmentos:
Resumen
Configuración de ClickHouse Keeper con rutas únicas
Esta página no se aplica a ClickHouse Cloud. El procedimiento que se documenta aquí está automatizado en los servicios de ClickHouse Cloud.
Descripción
{uuid}
para crear entradas únicas en ClickHouse Keeper o ZooKeeper. Las
rutas únicas son útiles cuando se crean y eliminan tablas con frecuencia, porque
evitan tener que esperar varios minutos a que la recolección de basura de Keeper
elimine las entradas de ruta, ya que cada vez que se crea una ruta se utiliza un nuevo uuid
en ella; las rutas nunca se reutilizan.
Entorno de ejemplo
Configuración de ejemplo para el clúster:
Procedimiento para configurar tablas para usar {uuid}
- Configure las macros en cada servidor ejemplo para el servidor 1:
Tenga en cuenta que definimos macros para
shard y replica, pero {uuid} no está definido aquí; viene integrado y no es necesario definirlo.- Crear una base de datos
- Cree una tabla en el clúster usando las macros y
{uuid}
- Cree una tabla distribuida
Prueba
- Inserte datos en el primer nodo (p. ej.,
chnode1)
- Insertar datos en el segundo nodo (p. ej.,
chnode2)
- Ver registros mediante una tabla distribuida
Alternativas
{uuid}
- Configure el valor predeterminado para las tablas en cada nodo
- Cree la tabla sin parámetros explícitos:
- Verifique que se haya utilizado la misma configuración que en la configuración predeterminada
Solución de problemas
La base de datos debe ser
Atomic; si está actualizando desde una versión anterior, es probable que la
base de datos default sea de tipo Ordinary.Reconfiguración dinámica de ClickHouse Keeper
Esta página no se aplica a ClickHouse Cloud. El procedimiento que se documenta aquí está automatizado en los servicios de ClickHouse Cloud.
Descripción
reconfig de ZooKeeper
para la reconfiguración dinámica del clúster si keeper_server.enable_reconfiguration está habilitado.
Si esta configuración está deshabilitada, puede reconfigurar el clúster modificando manualmente la sección
raft_configuration de la réplica. Asegúrese de editar los archivos en todas las réplicas, ya que solo el líder aplicará los cambios.
Como alternativa, puede enviar una consulta reconfig a través de cualquier cliente compatible con ZooKeeper./keeper/config contiene la última configuración del clúster confirmada con el siguiente formato:
- Cada entrada de servidor está delimitada por un salto de línea.
server_typeesparticipantolearner(learner no participa en las elecciones de líder).server_priorityes un entero no negativo que indica qué nodos deben tener prioridad en las elecciones de líder. Una prioridad de 0 significa que el servidor nunca será líder.
reconfig para añadir nuevos servidores, eliminar los existentes y cambiar la
prioridad de los servidores existentes; a continuación se muestran algunos ejemplos (con clickhouse-keeper-client):
kazoo:
joining deben estar en el formato de servidor descrito anteriormente. Las entradas de servidor deben estar delimitadas por comas.
Al añadir nuevos servidores, puede omitir server_priority (el valor predeterminado es 1) y server_type (el valor predeterminado
es participant).
Si quiere cambiar la prioridad de un servidor existente, añádalo a joining con la prioridad de destino.
El host, el puerto y el tipo del servidor deben coincidir con la configuración existente del servidor.
Los servidores se añaden y se eliminan en el orden en que aparecen en joining y leaving.
Todas las actualizaciones de joining se procesan antes que las actualizaciones de leaving.
Hay algunas consideraciones que tener en cuenta en la implementación de la reconfiguración de Keeper:
-
Solo se admite la reconfiguración incremental. Se rechazan las solicitudes con
new_membersno vacío. La implementación de ClickHouse Keeper se basa en la API de NuRaft para cambiar la composición del clúster de forma dinámica. NuRaft permite añadir un solo servidor o eliminar un solo servidor, de uno en uno. Esto significa que cada cambio en la configuración (cada parte dejoining, cada parte deleaving) debe decidirse por separado. Por lo tanto, no hay reconfiguración en bloque, ya que resultaría engañosa para los usuarios finales. Tampoco es posible cambiar el tipo de servidor (participant/learner), ya que NuRaft no lo admite, y la única forma sería eliminar y volver a añadir el servidor, lo que de nuevo sería engañoso. -
No puede usar el valor
znodestatdevuelto. -
El campo
from_versionno se usa. Se rechazan todas las solicitudes confrom_versionestablecido. Esto se debe a que/keeper/configes un nodo virtual, lo que significa que no se almacena en almacenamiento persistente, sino que se genera sobre la marcha con la configuración del nodo especificado para cada solicitud. Esta decisión se tomó para no duplicar datos, ya que NuRaft ya almacena esta configuración. -
A diferencia de ZooKeeper, no hay forma de esperar a que se complete la reconfiguración del clúster enviando un comando
sync. La nueva configuración se aplicará con el tiempo, pero sin garantías de plazo. -
El comando
reconfigpuede fallar por varios motivos. Puede comprobar el estado del clúster y ver si la actualización se aplicó.
Convertir un keeper de un solo nodo en un clúster
- IMPORTANTE: los nodos nuevos deben añadirse en lotes inferiores al quórum actual; de lo contrario, elegirán un líder entre ellos. En este ejemplo, se añaden de uno en uno.
- El nodo keeper existente debe tener habilitado el parámetro de configuración
keeper_server.enable_reconfiguration. - Inicia un segundo nodo con la nueva configuración completa del clúster de keeper.
- Una vez iniciado, añádelo al nodo 1 mediante
reconfig. - A continuación, inicia un tercer nodo y añádelo mediante
reconfig. - Actualiza la configuración de
clickhouse-serverañadiendo el nuevo nodo keeper y reinícialo para aplicar los cambios. - Actualiza la configuración de Raft del nodo 1 y, opcionalmente, reinícialo.
Funciones no compatibles
createno permite devolver un objetoStatcreateno admite TTLaddWatchno funciona con watchesPERSISTENTremoveWatchyremoveAllWatchesno se admitensetWatchesno se admite- No se admite crear znodes de tipo
CONTAINER - La
autenticación SASLno se admite