Skip to main content
ClickHouse CLI (clickhousectl) es una herramienta de línea de comandos unificada para gestionar recursos de ClickHouse Cloud y trabajar con ClickHouse en entornos de desarrollo local. También permite gestionar servicios de ClickHouse Cloud Postgres y ClickPipes. Esta página es una referencia del conjunto de comandos de clickhousectl 0.4.2. Ejecuta clickhousectl --version para comprobar la versión que tienes instalada, y clickhousectl <command> --help en cualquier comando para ver la lista completa de indicadores.

Instalación

También se crea automáticamente un alias para chctl por comodidad. Para actualizar una instalación existente a la última versión:

Administración de Cloud

Autentíquese con ClickHouse Cloud y administre sus servicios directamente desde la línea de comandos.

Autenticación

Las API keys se guardan en .clickhouse/credentials.json (local del proyecto e ignorado por git). También puedes usar variables de entorno:
Precedencia de las credenciales, de mayor a menor: indicadores --api-key/--api-secret, credenciales del proyecto en .clickhouse/credentials.json, variables de entorno (shell y luego .env) y tokens OAuth de cloud auth login. Los tokens OAuth son de solo lectura; los comandos de escritura (create, delete, start, stop, update, scale) requieren autenticación mediante API key.

Servicios

Ejecución de consultas

Ejecuta SQL contra un servicio de Cloud a través de HTTP mediante la Query API, sin necesidad del binario clickhouse local ni de la contraseña del servicio. Se requiere exactamente uno de estos dos parámetros: --id o --name:
Con autenticación mediante API key, las consultas se ejecutan con acceso de lectura y escritura. La key autenticada se usa directamente cuando el query endpoint del servicio ya la autoriza; de lo contrario, la primera consulta aprovisiona un query endpoint y una key de lectura/escritura por servicio, y almacena esa key en .clickhouse/credentials.json. Pase --no-auto-enable para que falle en lugar de aprovisionar. Con OAuth, el SQL se ejecuta como su usuario de la nube con acceso de solo lectura (únicamente SELECT), y no se aprovisiona nada. Aspectos a tener en cuenta:
  • service query ejecuta una sola sentencia por solicitud. La Query API rechaza el SQL con múltiples sentencias, sin importar cómo llegue —--query, --queries-file o stdin—, con Error: SQL error 62: Syntax error (Multi-statements are not allowed). Un ; al final de una única sentencia no supone problema. Para scripts, ejecute clickhousectl local use latest y utilice clickhouse client contra el servicio en su lugar.
  • --query y --queries-file son mutuamente excluyentes (código de salida 2). Stdin solo se lee cuando no se indica ninguno de los dos. --query nunca lee stdin, por lo que redirigir o canalizar datos junto con él es un error grave y no un no-op silencioso: Error: --query cannot be combined with SQL or data on stdin. En su lugar, envíe un INSERT y sus datos como un único flujo —printf 'INSERT INTO t FORMAT CSV\n' | cat - data.csv | clickhousectl cloud service query --id <service-id>— o lea una sentencia completa desde stdin con --queries-file -.
  • El output format predeterminado es PrettyCompact en un terminal y TabSeparated cuando la salida se canaliza. --json selecciona JSONEachRow y no puede combinarse con --format (código de salida 2).
  • Una API key de consulta almacenada que el endpoint rechaza con HTTP 401/403 nunca se reemplaza automáticamente; la CLI lee el registro de administración de la key solo para informar del motivo. Reemplace esa credencial concreta con clickhousectl cloud service repair-query-key <service-id>, que además elimina la key reemplazada. En un servicio en ejecución, solo devuelve el código 0 cuando una consulta de prueba con la nueva key tiene éxito, lo que se informa bajo verification en la salida de --json. Si la Query API sigue rechazando la key cuando finaliza la ventana de readiness, el comando sale con código 1, pero la reparación se mantiene: no lo vuelva a ejecutar; ejecute cloud service query en su lugar.
  • La Query API expira tras unos 30 segundos; la sentencia continúa ejecutándose en el servicio, pero el resultado se pierde. Para operaciones más largas, ejecute clickhousectl local use latest para incorporar el binary estándar clickhouse al PATH y conéctese con clickhouse client --host <host> --secure --port 9440 --user default --password <password> en su lugar.

Endpoints y configuración del servicio

--backup-start-time debe corresponder exactamente a una hora en punto (HH:00) y la CLI lo valida antes de realizar cualquier llamada a la API. Además, requiere que el período de copia de seguridad sea de 24 o 48 horas: pase --backup-period-hours 24 o --backup-period-hours 48 en el mismo comando, o tenga ya almacenado uno de esos dos valores. Con cualquier otro período almacenado, la CLI rechaza la operación antes de llamar a la API, con Error: the stored backup period is 12 hours, but --backup-start-time requires 24 or 48. --clear-backup-start-time elimina la hora de inicio almacenada y suprime esa restricción. Combínelo con --backup-period-hours para borrar la hora de inicio y establecer cualquier período en una sola llamada. Entra en conflicto con --backup-start-time.

Copias de seguridad

Para restaurar una copia de seguridad, cree un nuevo servicio a partir de ella: clickhousectl cloud service create --name restored-service --backup-id <backup-id>.

ClickPipes

Administra los ClickPipes para ingestar datos en un servicio de Cloud. La mayoría de los comandos reciben el ID del servicio como primer argumento.
Aspectos que debe tener en cuenta:
  • clickpipe create postgres requiere uno de estos: --table-mapping <schema.table:target_table> (repetible, una tabla por indicador) o --table-mapping-json <json>; ambos pueden combinarse. La forma JSON toma literalmente el objeto de correspondencia de tablas de la API y es la única manera de establecer excludedColumns, sortingKeys, partitionByExpr, partitionKey y tableEngine. Tenga en cuenta que partitionKey particiona el snapshot inicial para lograr paralelismo y no guarda relación con el PARTITION BY de la tabla de destino, que corresponde a partitionByExpr. --iam-role es obligatorio con --auth IAM_ROLE y se rechaza con autenticación básica, y --replication-slot-name solo es válido con --replication-mode cdc_only.
  • Los ajustes de CDC de Postgres se aplican al crear el pipe: --sync-interval-seconds, --pull-batch-size, --initial-load-parallelism, --snapshot-rows-per-partition, --snapshot-parallel-tables, --allow-nullable-columns, --enable-failover-slots y --delete-on-merge. Solo el sync interval y el pull batch size pueden modificarse después; los ajustes de snapshot y de carga inicial, no.
  • --role <role> en cualquier subcomando clickpipe create es repetible y determina el rol de ClickHouse que se concede al usuario de destino del pipe. Sustituye al rol que ese usuario recibiría de otro modo: sin --role, el usuario tiene clickpipes_system y default_role; con --role my_role, tiene clickpipes_system y my_role. El rol debe poder crear tablas en la base de datos de destino: con un rol de solo lectura, la creación falla con Not enough privileges. Los nombres clickpipes y clickpipes_system, reservados por la API, se rechazan.
  • TLS y la verificación de certificados están activados de forma predeterminada para las fuentes Postgres. Una cadena de confianza pública en la fuente no requiere archivo de CA; para una CA de fuente privada o autofirmada, indique su paquete PEM con --ca-certificate <path>. Para una fuente ClickHouse Cloud Postgres, obtenga ese paquete con clickhousectl cloud postgres certs get. La verificación del hostname utiliza --host, salvo que --tls-host <hostname> lo anule.
  • En los pipes de Kafka y Kinesis, --auth se infiere de los indicadores de credenciales cuando se omite, y no se envía ninguna autenticación si no se proporciona ningún indicador de credencial.
  • clickpipe settings abarca únicamente los ajustes de ingestión de los pipes de streaming (Kafka, Kinesis) y de almacenamiento de objetos, y los ajustes exclusivos de Kafka se omiten en los pipes que no son de Kafka. Los pipes de CDC de bases de datos (Postgres, MySQL, MongoDB, BigQuery) no tienen ajustes de ingestión: settings get sobre uno de ellos finaliza con código 1 y remite a clickhousectl cloud clickpipe get <service-id> <clickpipe-id>, que es donde se informan su sync interval y su pull batch size.
  • Un pipe solo puede usar un reverse private endpoint que haya alcanzado el estado Ready; un endpoint de AWS PrivateLink permanece en PendingAcceptance hasta que se acepte la solicitud de conexión en la cuenta propietaria de la fuente. Los pipes de Kafka referencian el endpoint por ID con --reverse-private-endpoint-id (repetible); los pipes de CDC de Postgres y MySQL pasan uno de los dnsNames del endpoint como --host.
  • Los pipes de Google Cloud Pub/Sub están en vista previa limitada: contacte con soporte para habilitar la funcionalidad en su organización antes de crear uno. --service-account-file toma la ruta a una clave JSON de service account de GCP, o - para leer la clave desde stdin; la clave nunca se acepta en línea, de modo que no aparece en los listados de procesos ni en el historial del intérprete de comandos.

Servicios Postgres (beta)

Cree y administre servicios de ClickHouse Cloud Postgres.
Aspectos que debe conocer:
  • --provider toma por defecto el valor aws; también se acepta gcp, con tamaños de máquina de GCP como c4-standard-4. --size lo valida la Cloud API y no la CLI, por lo que un tamaño no admitido solo se rechaza en el servidor.
  • Los cambios de rol presentan consistencia eventual y la API confirma promote y switchover antes de aplicarlos, de modo que un código de salida 0 por sí solo no garantiza que el rol haya cambiado. Ambos aceptan --wait para sondear hasta que el destino informe el nuevo rol, y --wait-timeout <seconds> (300 por defecto) limita la duración del sondeo. El primary anterior puede seguir informando isPrimary=true durante varios minutos, así que compruebe con clickhousectl cloud postgres list --filter isPrimary=true que solo un servicio sea primary.
  • postgres delete funciona desde cualquier estado, incluido running, por lo que no es necesario detener antes el servicio.

Organizaciones

API keys

Miembros e invitaciones

Registro de actividad

Salida JSON

Usa el indicador --json para obtener respuestas en formato JSON de cualquier comando de la nube:
Los comandos org prometheus y service prometheus son la excepción: siempre emiten texto de exposición de Prometheus sin procesar e ignoran --json de forma silenciosa.

Desarrollo local

La CLI también gestiona instalaciones locales de ClickHouse, servidores locales e instancias locales de Postgres basadas en Docker. Consulte la página clickhousectl (CLI) para empezar a trabajar con el desarrollo local.
Aspectos que conviene conocer:
  • Los comandos local tienen alcance de proyecto: usan el directorio .clickhouse del directorio de trabajo actual exacto y nunca buscan en directorios superiores. Sitúese en la raíz del proyecto antes de ejecutarlos.
  • clickhousectl local use también crea un enlace simbólico a ~/.local/bin/clickhouse, lo que hace que los subcomandos estándar como clickhouse client, clickhouse benchmark y clickhouse format queden disponibles directamente. Pase --no-global para omitir el enlace simbólico.
  • local remove requiere una versión instalada exacta. Se niega a eliminar una versión que esté en uso por un servidor en ejecución en cualquier proyecto, o que sea la predeterminada actual; --force detiene esos servidores y borra tanto la predeterminada como el enlace simbólico global.
  • Sin nombre, local server stop detiene default si existe y, en caso contrario, el único servidor conocido; si hay varios servidores no predeterminados, solicita un nombre. local server remove sin nombre solo selecciona un default existente: nunca deduce un servidor personalizado.
  • local client acepta -v/--version para elegir una versión de cliente instalada en modo directo de host/puerto, admite -q repetido para varias consultas y acepta varias rutas en --queries-file. Combinar --query y --queries-file es un error de uso.
  • local postgres start se bloquea hasta que PostgreSQL acepta conexiones, con un límite de --wait-timeout segundos (60 de forma predeterminada, 600 como máximo). Si se omite --port, usa el 5432 si está libre y, en caso contrario, selecciona un puerto automáticamente; si el puerto solicitado explícitamente ya está ocupado, se rechaza.

Otros comandos

Requisitos

  • macOS (aarch64, x86_64) o Linux (aarch64, x86_64)
  • Los comandos de Cloud requieren una API key de ClickHouse Cloud para el acceso de escritura; el inicio de sesión con OAuth es de solo lectura
  • clickhousectl local postgres requiere Docker
Última modificación el 26 de septiembre de 2026