ApsaraDB for ClickHouse:Preguntas frecuentes

ApsaraDB for ClickHouse corrige los errores de estabilidad de la versión comunitaria y ofrece resource queues para establecer prioridades de uso de recursos según el rol del usuario.

Pruebe estas soluciones:

• Compruebe la conectividad de red. Use ping para verificar si la red es accesible y telnet para comprobar que los puertos de base de datos 3306 y 8123 estén abiertos.

• Verifique la configuración de la lista blanca de ClickHouse. Configure a whitelist.

• Confirme la dirección IP pública de su computadora cliente. En una red corporativa, esta dirección cambia con frecuencia, así que utilice un servicio de búsqueda de IP como whatsmyip.

En las versiones 20.3 y 20.8, el sistema valida automáticamente la conexión cuando usted crea una tabla externa. Si la tabla se crea correctamente, la conectividad de red está confirmada. Si la creación falla, las causas más comunes son:

• El endpoint de destino y ClickHouse no están en la misma VPC, lo que impide la conectividad de red.

• El servidor MySQL usa una lista blanca. Debe agregar ClickHouse a dicha lista.

Causas comunes de los fallos de conexión y sus soluciones:

• Causa: el entorno de red está mal configurado. Solo es posible conectarse por red interna si la aplicación y la instancia están en la misma VPC. Si se encuentran en VPC distintas, debe habilitar un endpoint público y conectarse por la red pública.

  Solución: habilite el acceso por red pública. Apply for and release public IP addresses.

• Causa: la dirección IP del cliente no está en la lista blanca de la instancia.

  Solución: agregue la IP del cliente a la lista blanca. Configure a whitelist.

• Causa: el security group de su instancia ECS bloquea el tráfico en el puerto necesario.

  Solución: actualice las reglas del security group de ECS. Security group operation guide.

• Causa: un firewall corporativo está bloqueando la conexión.

  Solución: modifique las reglas del firewall para permitir el tráfico saliente hacia la instancia.

• Causa: el nombre de usuario o la contraseña de la cadena de conexión contiene caracteres especiales, como !@#$%^&*()_+=. Es posible que el cliente no interprete estos caracteres correctamente, lo que provoca un fallo de conexión.

  Solución: debe codificar en URL cualquier carácter especial de la cadena de conexión. Las reglas de codificación son las siguientes:

  ! : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  Por ejemplo, si su contraseña es ab@#c, la contraseña codificada en la cadena de conexión debe ser ab%40%23c.

• Causa: ApsaraDB for ClickHouse aprovisiona automáticamente una instancia pay-as-you-go de Server Load Balancer (SLB) para su clúster. Si su cuenta de Alibaba Cloud tiene pagos pendientes, la instancia SLB podría suspenderse y dejar inaccesible su instancia de ApsaraDB for ClickHouse.

  Solución: compruebe si su cuenta de Alibaba Cloud tiene pagos pendientes y liquide el saldo adeudado para restaurar el servicio.

Para resolver este problema, aplique una de las siguientes opciones:

• Divida los archivos grandes de OSS en archivos más pequeños antes de importarlos.

• Escale verticalmente el clúster para aumentar su memoria. Vertical and horizontal scaling for Community Edition clusters.

Causas comunes y soluciones:

• Causa 1: configuración de parámetros poco óptima. ClickHouse ofrece el mejor rendimiento con un tamaño de batch grande y un número reducido de concurrent operations. Un solo batch suele contener decenas o incluso cientos de miles de filas, según el tamaño promedio de cada fila. Como regla general, calcule unos 100 bytes por fila, aunque debe ajustar este valor según las características reales de sus datos.

  Solución: Establezca el número de concurrent operations en 10 o menos. Pruebe distintos valores de parámetros hasta encontrar la configuración óptima para su carga de trabajo.

• Causa 2: recursos insuficientes en el exclusive resource group de DataWorks. Es posible que las instancias de ECS del exclusive resource group tengan un tamaño inferior al necesario. La falta de CPU o memoria limita la cantidad de concurrent operations y el network egress bandwidth disponible. Asimismo, configurar un tamaño de batch grande en una máquina con poca memoria provoca recolecciones de basura (GC) de Java frecuentes en el proceso de DataWorks, lo que reduce el rendimiento.

  Solución: Revise los registros de salida de DataWorks para comprobar las especificaciones de la instancia de ECS.

• Causa 3: el cuello de botella se encuentra en el data source.

  Solución: En los registros de salida de DataWorks, busque las métricas totalWaitReaderTime y totalWaitWriterTime. Si totalWaitReaderTime es significativamente mayor que totalWaitWriterTime, el cuello de botella está en la lectura (el data source) y no en la escritura.

• Causa 4: uso de un public network endpoint. Un public network endpoint tiene un ancho de banda limitado y no es adecuado para operaciones de importación o exportación de datos de alto rendimiento.

  Solución: Cambie a un endpoint de VPC network.

• Causa 5: presencia de dirty data. Normalmente, los datos se escriben en un batch. Sin embargo, si se detectan dirty data, la escritura del batch actual falla. Entonces, DataX recurre a un modo de inserción fila por fila. Este mecanismo alternativo genera una cantidad excesiva de data parts y reduce drásticamente el rendimiento de escritura.

  Utilice los dos métodos siguientes para detectar dirty data.

  • Busque mensajes de error. Si el registro contiene un error Cannot parse, significa que hay dirty data.

    Ejecute la siguiente consulta SQL para localizar excepciones.

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • Supervise el número de filas del batch. Si la cantidad de filas por batch cae a 1, es muy probable que DataX haya encontrado dirty data y haya cambiado al modo fila por fila.

    Ejecute la siguiente consulta SQL para comprobar el número de filas.

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  Solución: Identifique y corrija o elimine los dirty data del data source.

Realice las siguientes comprobaciones:

1. Revise la tabla del sistema query_log para detectar errores durante la importación. Si existen errores, es probable que se hayan perdido datos.

2. Compruebe si el motor de la tabla admite deduplicación. Por ejemplo, si utiliza el motor de tabla ReplacingMergeTree, el número de filas en ClickHouse puede ser menor que en Hive porque este motor elimina duplicados.

3. Verifique la exactitud del número de filas en el origen de Hive, ya que el conteo inicial podría ser incorrecto.

Compruebe lo siguiente:

1. Revise la tabla del sistema query_log para detectar errores ocurridos durante la importación. Si hay errores, es posible que se hayan perdido datos.

2. Compruebe si el motor de la tabla realiza deduplicación de datos. Por ejemplo, el motor ReplacingMergeTree elimina entradas duplicadas, lo que reduce el número de filas en ClickHouse respecto a Kafka.

3. Verifique si el parámetro kafka_skip_broken_messages está habilitado en la configuración de la tabla externa de Kafka. Si está habilitado, ClickHouse omite los mensajes que no se pueden analizar sintácticamente, lo que disminuye el número de filas en ClickHouse frente a Kafka.

Utilice uno de estos métodos:

• Exporte los archivos mediante ClickHouse Client. Migrate data from a self-managed ClickHouse instance to ApsaraDB for ClickHouse Community Edition.

• Utilice la función remote.

  INSERT INTO <destination_table> SELECT * FROM remote('<connection_string>', '<database>', '<table>', '<username>', '<password>');

Solución: Siga estos pasos para volver a sincronizar los datos de MySQL.

1. Elimine la tabla que dejó de sincronizarse.

   DROP TABLE <table_name> ON cluster default;

   Nota

   En este comando, table_name es el nombre de la tabla que dejó de sincronizarse. Si se trata de una tabla distribuida, debe eliminar tanto la tabla distribuida como su tabla local.

2. Reinicie el proceso de sincronización.

   ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   Nota

   En este comando, <database_name> es el nombre de la base de datos sincronizada en ApsaraDB for ClickHouse.

• Causa: uso elevado de memoria.

  Solución: Ajuste el parámetro max_insert_threads para reducir el consumo de memoria.

• Causa: uso de una instrucción insert into select para importar datos entre clústeres de ClickHouse.

  Solución: Migre los datos importándolos desde archivos. Migrate data from a self-managed ClickHouse instance to ApsaraDB for ClickHouse Community Edition.

El servidor de ClickHouse supervisa el uso de memoria en varios niveles. Para una consulta individual, un rastreador de memoria agrega el consumo de todos sus hilos de consulta y luego informa a un rastreador de memoria global. La solución depende del error específico que encuentre.

• Un error con Memory limit (for query) significa que la consulta falló porque consumió demasiada memoria y superó su límite del 70 % de la capacidad total de memoria de la instancia. Para resolverlo, realice una actualización vertical que aumente la capacidad de memoria de la instancia.

• Un error con Memory limit (for total) indica que el uso general de memoria en la instancia superó el límite global del 90 % de la capacidad total de memoria de la instancia. Este error puede deberse a una alta concurrencia de consultas o a tareas asíncronas en segundo plano que consumen muchos recursos, como las fusiones de claves primarias que se ejecutan después de escribir datos. Primero, intente reducir la concurrencia de consultas. Si el error persiste, realice una actualización vertical para aumentar la capacidad de memoria de la instancia.

SETTINGS 
    allow_experimental_analyzer = 1,
    allow_experimental_parallel_reading_from_replicas = 1;

La concurrencia máxima predeterminada de consultas para un servidor es 100. Modifique este valor en la consola:

1. Inicie sesión en la consola de ApsaraDB for ClickHouse.

2. En la página Clusters, seleccione Clusters of Community-compatible Edition y haga clic en el ID del clúster de destino.

3. En el panel de navegación izquierdo, haga clic en Parameter Configuration.

4. En la página Parameter Configuration, haga clic en el icono de edición de la columna Parameter Value correspondiente al parámetro max_concurrent_queries.

5. Introduzca el nuevo valor en el cuadro de diálogo y haga clic en OK.

6. Haga clic en Submit Parameters.

7. Haga clic en OK.

Considere las siguientes soluciones:

• Compruebe si utiliza un clúster de varios nodos. En este tipo de clúster, debe crear una tabla distribuida. Escriba y consulte esta tabla para obtener resultados consistentes; de lo contrario, cada consulta podría dirigirse a un fragmento distinto. Create a distributed table.

• Compruebe si utiliza un clúster maestro-réplica. En este tipo de clúster, use tablas con un motor de la serie Replicated para sincronizar los datos entre réplicas. De lo contrario, cada consulta podría dirigirse a una réplica distinta y generar resultados inconsistentes. Table engines.

Causas comunes y soluciones:

• Causa 1: el proceso de creación de la tabla es incorrecto. Un clúster distribuido de ClickHouse no cuenta con semántica DDL distribuida nativa. Si ejecuta una instrucción create table en un clúster de ClickHouse autogestionado, es posible que devuelva un mensaje de éxito, pero la tabla solo se creará en el servidor actualmente conectado. Al conectarse a otro servidor, la tabla no será visible.

  Solución:

  1. Cuando cree una tabla, utilice la instrucción create table <table_name> on cluster default. La cláusula on cluster default transmite la instrucción a todos los nodos del clúster default.

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. Cree otra tabla que utilice el motor de tabla distribuida sobre la tabla test.

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• Causa 2: la tabla ReplicatedMergeTree está mal configurada. El motor de tabla ReplicatedMergeTree es una versión mejorada del motor MergeTree que proporciona sincronización maestro-réplica. En una instancia de réplica única, solo puede crear tablas con el motor MergeTree. En una instancia maestro-réplica, debe crear tablas con el motor ReplicatedMergeTree.

  Solución: Cuando cree una tabla en una instancia maestro-réplica, utilice ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') o ReplicatedMergeTree() para configurar el motor de tabla ReplicatedMergeTree. Los argumentos de ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') forman parte de una plantilla fija y no deben modificarse.

insert into <destination table> as select * from <Kafka external table>;

Síntoma

Se configuró correctamente un TTL para una tabla, pero los datos caducados no se eliminan automáticamente. Esto significa que la configuración del TTL no está surtiendo efecto.

Pasos para la solución de problemas

1. Compruebe si la configuración del TTL de la tabla es adecuada.

   Establezca el TTL según sus requisitos de negocio. Se recomienda configurar el TTL a nivel de días y evitar configuraciones a nivel de segundos o minutos, como TTL event_time + INTERVAL 30 SECOND.

2. Revise el parámetro materialize_ttl_after_modify.

   Este parámetro controls whether a new TTL rule applies to existing data after you run anALTER MODIFY TTL statement. The default value is 1 (enabled). A value of 0 means the rule applies only to new data, and existing data is not affected by the TTL.

   • Consulte la configuración del parámetro

     SELECT * FROM system.settings WHERE name like 'materialize_ttl_after_modify';

   • Modifique la configuración del parámetro

     Importante

     Este comando analiza todos los datos existentes y puede generar una carga alta de recursos. Úselo con precaución.

     ALTER TABLE $table_name MATERIALIZE TTL;

3. Diagnostique la estrategia de limpieza de particiones.

   Cuando el parámetro ttl_only_drop_parts is set to 1, ClickHouse deletes a data part only when all rows within that part have expired.

   • Consulte la configuración del parámetro ttl_only_drop_parts

     SELECT * FROM system.merge_tree_settings WHERE name LIKE 'ttl_only_drop';

   • Check the partition expiration status

     SELECT partition, name, active, bytes_on_disk, modification_time, min_time, max_time, delete_ttl_info_min, delete_ttl_info_max FROM system.parts c WHERE database = 'your_dbname' AND TABLE = 'your_tablename' LIMIT 100;

     • delete_ttl_info_min: The minimum datetime key value used for the TTL DELETE rule in this part.

     • delete_ttl_info_max: The maximum datetime key value used for the TTL DELETE rule in this part.

   • If the partition and TTL rules do not align, some data might not be cleaned up promptly. The following explains how partition and TTL rules interact.

     • Si las reglas de partición y de TTL están alineadas (por ejemplo, particionar por día y establecer un TTL diario), ClickHouse determina la caducidad con base en el ID de la partición y elimina toda la partición de una sola vez. Esta es la estrategia más eficiente. For optimal performance, we recommend combining a partitioning strategy (such as by day) with ttl_only_drop_parts=1 to efficiently delete expired data.

     • Si las reglas no están alineadas y ttl_only_drop_parts = 1, ClickHouse comprueba la información del TTL de cada parte. A part is deleted only after all its data has exceeded the delete_ttl_info_max timestamp.

     • Si las reglas no están alineadas y ttl_only_drop_parts = 0, ClickHouse debe analizar los datos dentro de cada parte para encontrar y eliminar filas caducadas individuales. Esta es la estrategia que consume más recursos.

4. Control the merge trigger frequency.

   Expired data is deleted asynchronously during merges, not in real time. You can control the merge frequency with the merge_with_ttl_timeout parameter or force TTL materialization by using the ALTER TABLE ... MATERIALIZE TTL statement.

   • Check the parameter

     SELECT * FROM system.merge_tree_settings WHERE name = 'merge_with_ttl_timeout';

     Nota

     The unit is seconds. The default value for an online instance is 7200 seconds (2 hours).

   • Modify the parameter

     If merge_with_ttl_timeout is set too high, the TTL merge trigger frequency decreases, delaying the cleanup of expired data. You can lower this parameter to increase the cleanup frequency. For details, seeDescripción del parámetro.

5. Revise la configuración de los parámetros del pool de hilos.

   La eliminación de datos por TTL ocurre durante la fase de fusión de partes y está limitada por los parámetros max_number_of_merges_with_ttl_in_pool (predeterminado: 2 para instancias en línea) y background_pool_size (predeterminado: 16 para instancias en línea).

   • Consulte la actividad actual de los hilos en segundo plano

     SELECT * FROM system.metrics WHERE metric LIKE 'Background%';

     La métrica BackgroundPoolTask indica el número de tareas activas actualmente en el pool en segundo plano.

   • Modifique los parámetros

     Si el resto de sus parámetros son correctos y la utilización de CPU es baja, considere aumentar el parámetro max_number_of_merges_with_ttl_in_pool según sus necesidades de negocio; por ejemplo, de 2 a 4, o de 4 a 8. Si esto no resuelve el problema, considere aumentar el parámetro background_pool_size.

     Importante

     Debe reiniciar el clúster si ajusta el parámetro max_number_of_merges_with_ttl_in_pool. No es necesario reiniciar el clúster cuando aumenta el parámetro background_pool_size, pero sí debe reiniciarlo cuando disminuye el parámetro background_pool_size.

6. Compruebe si el esquema de la tabla y el diseño de particiones son adecuados.

   If a table is not partitioned effectively or if the partition granularity is too coarse, TTL cleanup efficiency decreases. For efficient cleanup, we recommend matching the partition granularity with the TTL granularity (for example, setting both to a daily interval). For details, seeMejores prácticas.

7. Compruebe si el clúster tiene suficiente espacio en disco.

   Las operaciones de fusión en segundo plano activan la limpieza por TTL y requieren espacio disponible en disco. Las partes de datos grandes o la falta de espacio en disco (por ejemplo, un uso superior al 90 %) pueden impedir las operaciones de fusión y las eliminaciones posteriores por TTL.

8. Revise otros parámetros del sistema en system.merge_tree_settings.

   • merge_with_recompression_ttl_timeout: El retraso mínimo antes de que se repita una fusión con un TTL de recompresión. De forma predeterminada, esto significa que las reglas de TTL se aplican a una tabla como mínimo cada 4 horas. Si necesita aplicar las reglas de TTL con mayor frecuencia, reduzca este valor .

   • max_number_of_merges_with_ttl_in_pool: This parameter controls the maximum number of threads available for TTL tasks. If the number of ongoing merge tasks with TTL in the background thread pool exceeds this value, ClickHouse does not schedule new merge tasks with TTL.

Para que una operación primary key merge funcione correctamente, debe cumplir los siguientes dos requisitos previos.

• La clave ORDER BY debe incluir la partition key de la storage table. Una operación primary key merge no se ejecuta entre distintas particiones.

• En una distributed table, la clave ORDER BY debe incluir la clave de fragmentación, determinada por el hash algorithm. Una operación primary key merge no se ejecuta entre distintos nodos.

A continuación se describen los comandos optimize comunes y su comportamiento.

A continuación se muestran las causas comunes y sus soluciones.

• Causa 1: La expulsión de datos por TTL ocurre durante la fase de fusión de clave primaria. Si una parte de datos no se fusiona durante un periodo prolongado, el sistema no puede expulsar los datos caducados que contiene.

  Solución:

  • Puede activar manualmente una tarea de fusión al ejecutar optimize final o optimize a specific partition.

  • Al crear una tabla, configure parámetros como merge_with_ttl_timeout y ttl_only_drop_parts para fusionar con mayor frecuencia las partes de datos que contienen información caducada.

• Causa 2: Si se modifica o agrega el TTL de una tabla, es posible que las partes de datos existentes tengan información de TTL faltante o incorrecta. Esto también puede impedir la expulsión de datos caducados.

  Solución:

  • Puede regenerar la información del TTL al ejecutar alter table materialize ttl.

  • Puede actualizar la información del TTL al ejecutar optimize partition.

Para modificar una tabla local, ejecute una instrucción DDL. En una tabla distribuida, el procedimiento depende de si se están escribiendo datos en ella en ese momento.

• Si no se están escribiendo datos en la tabla, modifique primero la tabla local y después la tabla distribuida.

• Si se están escribiendo datos en la tabla, el procedimiento depende del tipo de modificación.

  Tipo	Acciones
  Agregar una columna nullable	Modifique la tabla local. Modifique la tabla distribuida.
  Modificar el tipo de datos de una columna (a un tipo convertible)
  Eliminar una columna nullable	Modifique la tabla distribuida. Modifique la tabla local.
  Agregar una columna no nullable	Detenga la escritura de datos. Ejecute SYSTEM FLUSH DISTRIBUTED en la tabla distribuida. Modifique la tabla local. Modifique la tabla distribuida. Reanude la escritura de datos.
  Eliminar una columna no nullable
  Cambiar el nombre de una columna

Pruebe estas soluciones:

• Espere a que finalice la operación.

• Intente finalizar la consulta desde la consola.

• Causa 1: El cliente de ClickHouse analiza la sintaxis. Sin embargo, set global on cluster default es una sintaxis del lado del servidor. Si la versión del cliente no es compatible con el servidor, el cliente bloquea esta instrucción.

  Solución:

  • Use una herramienta que no analice la sintaxis del lado del cliente. Algunos ejemplos son las herramientas basadas en JDBC, como DataGrip y DBeaver.

  • Desarrolle un programa JDBC para ejecutar la instrucción.

• Causa 2: En la instrucción set global on cluster default key = value;, el value es una cadena, pero no está entre comillas.

  Solución: Escriba el valor de cadena entre comillas.

Si su clúster es de Enterprise Edition y la instrucción de creación de tabla incluye ON CLUSTER default, es posible que encuentre el error ON CLUSTER is not allowed for Replicated database. Esto ocurre en algunas versiones menores. Actualice su instancia a la versión más reciente. Upgrade minor engine versions.

Problema: Si usa un clúster de Community Edition con varios nodos, podría encontrar el error Exception: Double-distributed IN/JOIN subqueries is denied (distributed_product_mode = 'deny'). cuando una consulta utiliza JOIN o IN para unir varias tablas distribuidas.

Causa: Cuando una consulta une varias tablas distribuidas, puede producirse una amplificación de consultas. Por ejemplo, en un clúster de tres nodos, una consulta de unión entre dos tablas distribuidas se expande en 3 x 3 subconsultas sobre las tablas locales subyacentes. Esto consume muchos recursos y aumenta la latencia. Para evitarlo, el sistema bloquea estas consultas de forma predeterminada.

Funcionamiento: Al reemplazar el operador IN o JOIN por GLOBAL IN o GLOBAL JOIN, se indica al motor que ejecute la subconsulta del lado derecho en un solo nodo. El resultado se almacena en una tabla temporal, que luego se transmite a todos los demás nodos para completar la unión de forma local.

Impacto de usar GLOBAL IN o GLOBAL JOIN:

• La tabla temporal se envía a todos los servidores remotos. Evite esta estrategia con conjuntos de datos grandes.

• Usar GLOBAL IN o GLOBAL JOIN con la función remote() puede generar resultados incorrectos. Esto sucede porque la subconsulta, que debería ejecutarse en la instancia externa, se ejecuta en la instancia actual.

  Por ejemplo, ejecute la siguiente instrucción en instance_a para consultar datos de la instancia externa cc-bp1wc089c****.

  SELECT *
  FROM remote('cc-bp1wc089c****.clickhouse.ads.aliyuncs.com:3306', `default`, test_tbl_distributed1, '<your_Account>', '<YOUR_PASSWORD>')
  WHERE id GLOBAL IN
      (SELECT id
       FROM test_tbl_distributed1);

  En este caso, instance_a ejecuta la subconsulta SELECT id FROM test_tbl_distributed1 para generar una tabla temporal; llamémosla temp_table_A. Luego, los datos de temp_table_A se envían a la instancia externa cc-bp1wc089c**** para la consulta final. La instancia externa cc-bp1wc089c**** termina ejecutando la instrucción SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temp_table_A);.

  El problema surge del origen de los datos de la tabla temporal.

  Según la descripción anterior, la instrucción final que ejecuta la instancia cc-bp1wc089c**** es SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temporary table A);. Sin embargo, el conjunto de condiciones definido en la tabla temporal A se generó en la instancia a. En este ejemplo, la instancia cc-bp1wc089c**** debió ejecutar SELECT * FROM default.test_tbl_distributed1 WHERE id IN (SELECT id FROM test_tbl_distributed1 );, y el conjunto de condiciones debió originarse en la instancia cc-bp1wc089c****. Por lo tanto, el uso de GLOBAL IN o GLOBAL JOIN hace que la subconsulta obtenga el conjunto de condiciones de un origen incorrecto, lo que produce un resultado erróneo.

Soluciones:

Solución 1: Modifique el código SQL de su aplicación para reemplazar manualmente IN o JOIN por GLOBAL IN o GLOBAL JOIN.

Por ejemplo, cambie esta instrucción:

SELECT * FROM test_tbl_distributed WHERE id IN (SELECT id FROM test_tbl_distributed1);

por:

SELECT * FROM test_tbl_distributed WHERE id GLOBAL IN (SELECT id FROM test_tbl_distributed1);

Solución 2: Modifique el parámetro del sistema distributed_product_mode o prefer_global_in_and_join para que el sistema convierta automáticamente IN o JOIN en GLOBAL IN o GLOBAL JOIN.

SET GLOBAL ON cluster default distributed_product_mode='global';

SET GLOBAL ON cluster default prefer_global_in_and_join = 1;

Para consultar el espacio en disco que usa cada tabla, ejecute la siguiente consulta.

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

A continuación se muestra un ejemplo de consulta:

SELECT * FROM system.disks;

Use la siguiente consulta:

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

Para mover una partición de datos al almacenamiento frío, ejecute la siguiente instrucción:

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

Entre las causas comunes se incluyen:

• Una consulta que activa un error OOM.

• Un reinicio de instancia provocado por un cambio de configuración.

• Un reinicio de instancia posterior a una actualización o reducción de versión.

A continuación se describen las tablas del sistema más comunes y sus funciones.

Los parámetros a nivel de usuario corresponden a los elementos de configuración del archivo users.xml. Para modificar un parámetro, ejecute la siguiente sentencia.

SET global ON cluster default ${key}=${value};

Especifique el parámetro de cuota en la sección settings de una sentencia de ejecución:

settings max_memory_usage = XXX;

En un clúster node múltiple de tipo dual-replica o single-replica, el write node presenta un mayor CPU usage y memory usage que los demás node durante write operation intensivas. El uso se equilibra entre los node una vez que los datos se sincronizan.

• Descripción del problema:

  Cómo consultar los registros detallados del sistema para solucionar errores o identificar posibles problemas.

• Solución:

  1. Compruebe el parámetro text_log.level de su clúster y aplique una de las siguientes acciones:

     1. Si text_log.level está vacío, el registro de texto está deshabilitado. Para habilitarlo, establezca un valor para este parámetro.

     2. Si text_log.level tiene un valor asignado, compruebe que el nivel de registro cumpla con sus requisitos. De lo contrario, modifique el parámetro al nivel deseado.

     Configure config.xml parameters.

  2. Conéctese a la base de datos de destino. Connect to a database.

  3. Ejecute la siguiente sentencia para consultar y analizar los registros.

     SELECT * FROM system.text_log;

Si el clúster de destino y el origen de datos se encuentran en la misma VPC y región, compruebe que la dirección IP de cada uno esté incluida en la lista blanca del otro.

• Para configurar la lista blanca de ClickHouse, consulte Set a Whitelist.

• Para otros orígenes de datos, consulte la documentación de cada producto.

Si no se cumplen estas condiciones, establezca primero la conectividad mediante una solución de red adecuada. Después, agregue la dirección IP de cada componente a la lista blanca del otro.

Sí, es posible migrar un clúster de ClickHouse Community Edition a un clúster de Enterprise Edition.

Los datos se pueden migrar entre clústeres de Enterprise Edition y Community Edition mediante la función remote o al exportar e importar archivos de datos. Migrate data from a self-managed ClickHouse cluster to Alibaba Cloud ClickHouse Community-Compatible Edition.

De manera predeterminada, las instancias de Enterprise Edition 24.5 o versiones posteriores utilizan el nuevo analizador de consultas. Este analizador ofrece un mejor rendimiento, pero podría no ser compatible con versiones anteriores para ciertas sentencias SQL heredadas. Si encuentra un error de análisis sintáctico, vuelva al analizador anterior. Más información sobre el nuevo analizador.

SET allow_experimental_analyzer = 0;

La función de suspensión solo está disponible para clústeres de Enterprise Edition. Los clústeres de ClickHouse Community Edition no se pueden suspender. Para suspender un clúster de Enterprise Edition, vaya a la página Enterprise Edition Clusters. Seleccione la región de destino en la esquina superior izquierda. En la lista de clústeres, busque el clúster de destino y haga clic en > Suspend en la columna Actions.

Descripción del problema

Los usuarios que no están familiarizados con ClickHouse pueden crear por error tablas con el motor MergeTree en un clúster de múltiples réplicas. Esto impide que los datos se sincronicen entre los nodos de réplica de cada shard. Como consecuencia, las consultas en la tabla distribuida correspondiente pueden devolver resultados inconsistentes. Para resolver este problema, debe convertir la tabla MergeTree en una tabla ReplicatedMergeTree.

Solución

ClickHouse no proporciona una sentencia DDL para cambiar directamente el motor de almacenamiento de una tabla. Para convertir una tabla MergeTree en una tabla ReplicatedMergeTree, debe crear una tabla nueva con el motor ReplicatedMergeTree y luego importar los datos de la tabla original.

Por ejemplo, suponga que tiene una tabla MergeTree llamada table_src y su tabla distribuida correspondiente llamada table_src_d en un clúster de múltiples réplicas. Para convertir esta tabla MergeTree en una tabla ReplicatedMergeTree, siga estos pasos:

1. Cree la tabla ReplicatedMergeTree de destino, table_dst, y su tabla distribuida correspondiente, table_dst_d. CREATE TABLE.

2. Importe los datos de la tabla MergeTree table_src hacia table_dst_d. Puede utilizar uno de los dos métodos siguientes.

Establecer un session_id único garantiza que el servidor de ClickHouse mantenga un contexto consistente para las solicitudes con el mismo session ID. Esto le permite ejecutar varias sentencias SQL en una sola sesión. En este ejemplo se muestra cómo hacerlo con ClickHouse Java Client (V2).

1. Agregue la dependencia al archivo pom.xml de su proyecto Maven.

   <dependency>
       <groupId>com.clickhouse</groupId>
       <artifactId>client-v2</artifactId>
       <version>0.8.2</version>
   </dependency>

2. Establezca un session ID personalizado en CommandSettings.

   package org.example;
   
   import com.clickhouse.client.api.Client;
   import com.clickhouse.client.api.command.CommandSettings;
   public class Main {
   
       public static void main(String[] args) {
           Client client = new Client.Builder()
                   .addEndpoint("endpoint") // Instance endpoint
                   .setUsername("username")   // Username
                   .setPassword("password")   // Password
                   .build();
   
           try {
               client.ping(10);
               CommandSettings commandSettings = new CommandSettings();
               // Set the session_id
               commandSettings.serverSetting("session_id","examplesessionid");
               // Set the max_block_size parameter for the session
               client.execute("SET max_block_size=65409 ",commandSettings);
               // Execute the queries
               client.execute("SELECT 1 ",commandSettings);
               client.execute("SELECT 2 ",commandSettings);
   
           } catch (Exception e) {
               throw new RuntimeException(e);
           } finally {
               client.close();
           }
       }
   }

En este ejemplo, ambas sentencias SELECT se ejecutan en la misma sesión con un max_block_size de 65409. ClickHouse Java Client: Java Client | ClickHouse Docs.

¿Por qué las operaciones DELETE o UPDATE quedan incompletas?

SELECT * FROM clusterAllReplicas('default', system.mutations) WHERE is_done = 0;

¿Cómo resolver el error "Code: 241. DB::Exception: Memory limit (total) exceeded" en ApsaraDB for ClickHouse Enterprise Edition?

• Síntoma: al ejecutar una instrucción SQL, aparece a continuación el siguiente mensaje de error, incluso cuando la memoria total del clúster supera el límite indicado en dicho mensaje:

  Code: 241. DB::Exception: Memory limit (total) exceeded: would use 115.28 GiB (attempt to allocate chunk of 133791376 bytes), maximum: 115.20 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker.: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED) (version 24.2.2.16476 (official build))

• Causa: en ApsaraDB for ClickHouse Enterprise Edition, cada nodo tiene un límite de CCU (un máximo de 32 CCU, donde 1 CCU equivale aproximadamente a 1 vCore y 4 GiB de memoria). Si una sola consulta SQL consume más memoria que el umbral del nodo, MemoryTracker intercepta la consulta. El umbral predeterminado es 0.9 veces la memoria total del nodo. Ejecute la siguiente instrucción SQL para consultar el umbral:

  SELECT *
  FROM system.server_settings
  WHERE name = 'max_server_memory_usage_to_ram_ratio';

• Solución: establezca el allow_experimental_parallel_reading_from_replicas parameter to 1. This distributes the data reading phase across multiple nodes, spreading the memory consumption. Enterprise Edition.

¿Por qué los resultados de las consultas son inconsistentes?

¿Por qué ReplacingMergeTree no logra deduplicar después de una combinación forzada?

optimize TABLE <table_name> FINAL ON cluster default;