Change configuration for a ClickHouse community-compatible version - ApsaraDB for ClickHouse

Para adaptarse a los cambios en los requisitos del negocio, puede ajustar la configuración o el tamaño de su clúster de Alibaba Cloud ClickHouse Community-Compatible Edition. Puede realizar un escalamiento vertical u horizontal en su clúster de Alibaba Cloud ClickHouse para lograr un equilibrio óptimo entre costo y rendimiento.

Descripción general del escalamiento vertical y horizontal

El escalamiento vertical es más rápido y genera menos interrupciones en su negocio que el escalamiento horizontal. Si el rendimiento de su clúster es insuficiente, considere primero el escalamiento vertical.

Método de escalamiento	Casos de uso	Funcionamiento	Impacto	Acciones
Escalamiento vertical	Ajusta los recursos de los nodos cuando la capacidad de CPU, memoria o disco es insuficiente o está sobreaprovisionada.	Aumenta o disminuye las especificaciones de los nodos, la capacidad de almacenamiento y las especificaciones de ZooKeeper para un clúster de Alibaba Cloud ClickHouse Community-Compatible Edition, lo que ajusta su potencia de cómputo, capacidad de almacenamiento y capacidades de coordinación distribuida. Nota No puede utilizar el escalamiento vertical para reducir la capacidad de almacenamiento. Las siguientes soluciones están disponibles para reducir la capacidad de almacenamiento: Para una instancia multinodo, puede reducir nodos para disminuir la capacidad de almacenamiento según sus necesidades comerciales. Para una instancia de nodo único, puede crear una nueva instancia y migrar los datos para reducir la capacidad de almacenamiento.	Actualizar el tipo de almacenamiento o aumentar la capacidad de almacenamiento de un clúster de Alibaba Cloud ClickHouse Community-Compatible Edition no afecta a la instancia (esto aplica solo a instancias creadas después del 1 de diciembre de 2021). Sin embargo, cambiar las especificaciones del clúster o de ZooKeeper reinicia el clúster. Importante El escalamiento vertical tarda entre 5 y 10 minutos. El tiempo necesario para reiniciar un clúster depende del volumen de datos. Cuantas más bases de datos, tablas y datos fríos tenga un clúster, más tardará el reinicio. En un clúster de réplica dual, el escalamiento puede causar interrupciones transitorias en la conexión mientras las solicitudes cambian entre réplicas. Realice el escalamiento fuera de las horas pico y asegúrese de que su aplicación cuente con un mecanismo de reintento. Un clúster de réplica única no estará disponible durante todo el proceso de escalamiento. Realice esta operación fuera de las horas pico o cuando las operaciones de escritura estén suspendidas, y asegúrese de que su aplicación tenga un mecanismo de reintento. Si cambia las especificaciones de ZooKeeper durante las horas pico, pueden producirse inconsistencias entre los metadatos de la tabla y los datos reales. Realice esta operación fuera de las horas pico o cuando las operaciones de escritura estén suspendidas.	Scale up or scale down
Escalamiento horizontal (scale-out)	Escalamiento horizontal con migración de datos: Utilice este método cuando sea necesario redistribuir los datos del clúster después del escalamiento. Escalamiento horizontal simple: Utilice este método cuando su clúster cumpla con las siguientes condiciones: Antes de escalar el clúster, los datos se escriben directamente en tablas locales o en tablas distribuidas cuya clave de fragmentación está establecida en `rand`. No se requiere reequilibrio de datos entre nodos. Importante No utilice el escalamiento horizontal simple para clústeres que contengan tablas con motores como ReplacingMergeTree, CollapsingMergeTree o VersionedCollapsingMergeTree. Los datos en estos tipos de tablas solo se pueden fusionar en el mismo nodo. El escalamiento horizontal simple dispersa los datos que necesitan fusionarse en diferentes nodos, lo que impide su fusión.	Escalamiento horizontal con migración de datos: Aumenta el número de nodos en un clúster de Alibaba Cloud ClickHouse Community-Compatible Edition para escalar horizontalmente su potencia de cómputo. Los datos existentes se migran y redistribuyen. Escalamiento horizontal simple: Aumenta el número de nodos en un clúster de Alibaba Cloud ClickHouse Community-Compatible Edition para escalar horizontalmente su potencia de cómputo. Este método se utiliza cuando los datos se escriben directamente en tablas locales y no se requiere reequilibrio de datos entre nodos.	Las operaciones DDL están prohibidas durante todo el proceso de escalamiento horizontal. El uso de CPU y memoria del clúster aumenta durante el proceso de escalamiento horizontal. La sobrecarga estimada de recursos es inferior a 5 núcleos de CPU y 20 GB de memoria por nodo. Una vez completado el escalamiento horizontal, seguirá un periodo de operaciones de fusión de alta frecuencia. Esto incrementa el uso de E/S y puede provocar una mayor latencia en las solicitudes del negocio.	Scale out and scale in
Reducción de nodos (scale-in)	Reducción estándar de nodos: Reduce el número de nodos para ahorrar costos. Los nodos se dan de baja de forma aleatoria. No puede especificar qué nodos eliminar. Reducción de nodos especificados: Da de baja nodos específicos para clústeres con grandes especificaciones de almacenamiento.	Reduce el número de nodos en un clúster de Alibaba Cloud ClickHouse Community-Compatible Edition para reducir costos.	Las operaciones DDL están prohibidas durante todo el proceso de reducción de nodos. El uso de CPU y memoria del clúster aumenta durante el proceso de reducción de nodos. La sobrecarga estimada de recursos es inferior a 5 núcleos de CPU y 20 GB de memoria por nodo. Una vez completada la reducción de nodos, seguirá un periodo de operaciones de fusión de alta frecuencia. Esto incrementa el uso de E/S y puede provocar una mayor latencia en las solicitudes del negocio.	Scale out and scale in

Requisitos previos

El clúster debe ser de Alibaba Cloud ClickHouse Community-Compatible Edition.
El estado del clúster debe ser Running.
El clúster no debe tener órdenes de renovación pendientes de pago.

Nota
Inicie sesión en la consola de Alibaba Cloud ClickHouse. En la esquina superior derecha de la página, elija Fee > Expenses and Costs. En el panel de navegación izquierdo, haga clic en Order Management y complete el pago o cancele la orden.

Notas de uso

Escalamiento vertical: Solo puede cambiar las especificaciones de ZooKeeper para clústeres de Alibaba Cloud ClickHouse Community-Compatible Edition creados después del 1 de diciembre de 2021. Para obtener información sobre los precios de las especificaciones de ZooKeeper, consulte ZooKeeper specification pricing for Community-Compatible Edition.
Escalamiento horizontal:
- Cuando escala horizontalmente un clúster con tablas de motor de la familia MergeTree, el sistema migra los datos existentes al nuevo clúster y los redistribuye automáticamente.
  Contenido compatible con la migración:
  - Bases de datos, diccionarios de datos y vistas materializadas.
  - Esquema de tabla: todos los esquemas de tabla, excepto los de tablas que utilizan el motor Kafka o RabbitMQ.
  - Datos: Los datos de tablas que utilizan motores de la familia MergeTree se migran de forma incremental.
  Contenido no compatible con la migración:
  - Esquemas de tabla y datos para tablas con motores Kafka y RabbitMQ.
    
    Importante
    Durante un cambio de configuración, los datos se migran a una nueva instancia y el tráfico finalmente se cambia a la nueva instancia. Para evitar que los datos se dividan entre Kafka y RabbitMQ, elimine primero las tablas con motores Kafka y RabbitMQ del clúster de origen. Vuelva a crearlas una vez completado el cambio de configuración.
  - Data in non-MergeTree tables, such as external tables and Log-family tables.
  Importante
  Durante el proceso de escalamiento, debe manejar manualmente el contenido no compatible tal como se describe en el procedimiento.
- Las operaciones DDL están prohibidas durante todo el proceso de escalamiento horizontal. El incumplimiento de esta regla puede provocar fallos en la validación de datos y causar que el escalamiento falle.
- Después de un escalamiento horizontal, las direcciones IP internas de los nodos cambian. Si su aplicación depende de las direcciones IP de los nodos para la escritura y el acceso a datos, debe obtener el nuevo bloque CIDR de VPC del clúster. Para obtener más información, consulte Obtain the VPC CIDR block of a cluster.
- Solo los clústeres basados en disco local admiten la reducción de nodos mediante la especificación de nodos. En este modo, los datos en los nodos que se dan de baja se pierden. En el modo de reducción estándar de nodos, el sistema no pierde datos, sino que los redistribuye.
Después de cambiar la configuración del clúster, seguirá un periodo de operaciones de fusión de alta frecuencia. Esto incrementa el uso de E/S y puede provocar una mayor latencia en las solicitudes del negocio. Planifique con antelación para mitigar el posible impacto de la latencia de las solicitudes. Para obtener información sobre cómo calcular la duración de la fusión, consulte Calculate the merge duration after migration.
Durante el cambio de configuración del clúster, aumenta el uso de CPU y memoria. La sobrecarga estimada de recursos es inferior a 5 núcleos de CPU y 20 GB de memoria por nodo.

Facturación

Después de cambiar la configuración del clúster, las tarifas cambian. Prevalece el costo real mostrado en la consola. Para obtener más información, consulte Billing for configuration changes.

Aumentar y reducir escala

Importante

Para obtener información sobre los impactos del escalamiento vertical, consulte Overview of vertical and horizontal scaling y Usage notes.

Inicie sesión en la consola de Alibaba Cloud ClickHouse. En la esquina superior izquierda de la página, seleccione la región donde se encuentra su clúster.
En la página Clusters, haga clic en Clusters of Community-compatible Edition.
En la columna Actions del clúster objetivo, haga clic en Change Configurations.
En el cuadro de diálogo Change Configurations, seleccione Scale Up o Scale Down y haga clic en OK.
En la página Change Specification o Scale Down, seleccione las configuraciones deseadas según sus necesidades comerciales.
Nota
- No puede modificar la Storage Capacity o el Storage Type y la Specification al mismo tiempo cuando realiza un Change Specification.
- De forma predeterminada, los clústeres vienen con especificaciones de ZooKeeper de 4 núcleos de CPU y 8 GB de memoria. En la página Monitoring and Alerting, consulte las métricas de ZooKeeper en el panel Cluster Monitoring para comprobar si existen cuellos de botella en los recursos. Si las especificaciones predeterminadas son insuficientes, aumente la escala rápidamente.
Haga clic en Buy and Start y complete el pago según las indicaciones.
En la página Paid, haga clic en Console.
En la página Clusters of Community-compatible Edition, consulte el estado del clúster objetivo en la columna Status.
Nota
- Después de cambiar la Storage Capacity, el cambio surte efecto inmediatamente y el estado del clúster permanece como Running.
- Después de cambiar la Specification y las ZooKeeper Specifications, espere aproximadamente de 10 a 15 minutos. La operación de aumento o reducción de escala es exitosa cuando el estado del clúster cambia de Changing Specification a Running.

Escalamiento horizontal y reducción de nodos

Importante

Para obtener información sobre los impactos del escalamiento horizontal, consulte Overview of vertical and horizontal scaling y Usage notes.

Paso 1: Registrar y eliminar tablas de Kafka/RabbitMQ

La función de escalamiento en la consola no puede migrar directamente tablas con motores Kafka y RabbitMQ. Antes de escalar el clúster, debe registrar las sentencias DDL de estas tablas y eliminarlas del clúster para evitar interferencias con la tarea de escalamiento.

Inicie sesión en el clúster y ejecute la siguiente sentencia para consultar todas las tablas con motores Kafka y RabbitMQ y sus dependencias posteriores.

/*
create_table_query: The table definition statement.
dependencies_database: The database that depends on the table.
dependencies_table: The name of the table that depends on the table.
You can use dependencies_database and dependencies_table to identify materialized views that depend on Kafka/RabbitMQ tables.
*/
SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

Consulte la definición de la vista materializada para comprobar si su tabla destino es una tabla implícita.

/*
View the materialized view definition.
If the target table of the materialized view is an implicit table, pay special attention to the following:
When you delete the materialized view, the implicit table is also deleted, resulting in data loss.
Example: If the TO clause is not specified in CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name],
the system automatically creates an implicit table in the format '.inner_id.<TABLE_UUID>' or '.inner.<TABLE>'.
*/
SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

Si se creó una vista materializada sin una cláusula TO, el sistema genera automáticamente una tabla destino implícita con el prefijo .inner o .inner_id. Estas tablas implícitas se migran a los nuevos nodos durante el escalamiento, pero debido a mecanismos internos de nomenclatura, volver a crear directamente la vista materializada original puede causar conflictos de nombres. Por lo tanto, primero debe renombrar las tablas destino implícitas a nombres de tabla regulares.
```
-- Rename the implicit target table to a regular table name (execute on all nodes).
RENAME TABLE <database>.`.inner_id.<uuid>` TO <database>.<new_target_table_name> ON CLUSTER default;
```
Elimine las vistas materializadas y las tablas con motores Kafka/RabbitMQ.

Importante
Debe eliminar las vistas materializadas que hacen referencia a las tablas de Kafka/RabbitMQ antes de eliminar las tablas con motores Kafka/RabbitMQ. De lo contrario, la operación de escalamiento fallará.
```
-- Remove the materialized views first.
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then, remove the Kafka/RabbitMQ engine tables.
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;
```

Importante

Asegúrese de guardar todas las sentencias DDL registradas. Necesitará volver a crear estas tablas en el clúster escalado más adelante. Si realizó una operación RENAME, utilice la cláusula TO para apuntar a la tabla destino renombrada cuando vuelva a crear la vista materializada. Para obtener más información, consulte CREATE MATERIALIZED VIEW.

Si el clúster no contiene tablas con motores Kafka/RabbitMQ, puede omitir el Paso 1, el Paso 4, el Paso 5 y el Paso 6, y comenzar desde el Paso 2.

Paso 2: Realizar copia de seguridad de data of non-MergeTree tables

Log on to the cluster and run the following statement to identify the non-MergeTree tables that require data migration.

SELECT
    `database` AS database_name,
    `name` AS table_name,
    `engine`
FROM `system`.`tables`
WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
    SELECT `name`
    FROM `system`.`databases`
    WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
))

Realice una copia de seguridad de los datos.

Realice una copia de seguridad de business data in the non-MergeTree tables. For more information, see Back up data to OSS.

Paso 3: Escalar en la consola

Inicie sesión en la consola de Alibaba Cloud ClickHouse. En la esquina superior izquierda de la página, seleccione la región donde se encuentra su clúster.
En la página Clusters, haga clic en Clusters of Community-compatible Edition.
En la columna Actions del clúster objetivo, haga clic en Change Configurations.
En el cuadro de diálogo Change Configurations, seleccione Scale Out o Scale In y haga clic en OK.
En la ventana de verificación de escalamiento horizontal o reducción de nodos, consulte el estado de la verificación.

Nota
Cuando ingresa a la ventana de verificación para Scale Out, la opción Migration Expansion está seleccionada de forma predeterminada. Para seleccionar Simple Expansion, haga clic en Previous en esta página. En el cuadro de diálogo Scale-out, seleccione Simple Expansion y haga clic en Next para ir a la página Change Specification.

Si el clúster contiene tablas con motores Kafka/RabbitMQ, realice el Paso 4 para volver a crear las tablas con motores Kafka/RabbitMQ en el clúster cuando la tarea de escalamiento entre en la etapa de Data Migration (después de completar la migración del esquema de tablas). Esto permite que los datos incrementales reanuden su flujo y se sincronicen con los nuevos nodos.

Antes de que comience la ventana de suspensión de escritura configurada, realice el Paso 5 para eliminar las tablas con motores Kafka/RabbitMQ y sus vistas materializadas posteriores del clúster. Esto evita que las acumulaciones de mensajes durante la ventana de suspensión de escritura causen inconsistencias en los datos.
- Si la verificación es exitosa, haga clic en Next.
- Si la verificación falla, solucione el problema según las indicaciones en la página y haga clic en Retry Detection. Una vez que la verificación sea exitosa, haga clic en Next.
  Las razones comunes por las que falla una verificación de escalamiento horizontal incluyen:
  Falta una tabla distribuida única: Una tabla local no tiene una tabla distribuida correspondiente. Debe crear una.
  
  La tabla distribuida correspondiente no es única: Una tabla local tiene más de una tabla distribuida. Elimine las tablas distribuidas adicionales y conserve solo una.
  
  Tablas con motores Kafka/RabbitMQ no compatibles: El clúster contiene tablas con motores Kafka o RabbitMQ. Debe eliminarlas.
  
  Tablas MergeTree no replicadas en una instancia de múltiples réplicas: Los datos son inconsistentes entre réplicas, lo que provoca errores de migración de datos durante el escalamiento.
  
  Las columnas de la tabla distribuida y la tabla local son inconsistentes: Debe hacer que las columnas sean consistentes. De lo contrario, se producirán errores de migración de datos durante el escalamiento.
  
  Falta la tabla en algunos nodos: Debe crear tablas con el mismo nombre en diferentes fragmentos. Para la tabla interna de una vista materializada, se recomienda renombrar la tabla interna y luego volver a crear la vista materializada para que apunte a la tabla interna renombrada. Para obtener más información, consulte The inner table of a materialized view is inconsistent across shards.
En la página Change Specification o Scale Down, configure el número de Server Nodes y la ventana de suspensión de escritura.SYNC: 同步中文变更 - 补充停写窗口定义说明和判断逻辑
Nota
Una ventana de suspensión de escritura es un periodo configurado por el cliente durante el cual se permite al kernel detener la escritura. La lógica interna de migración determina si se deben suspender las escrituras basándose en lo siguiente: Si la hora actual está dentro de la ventana de suspensión de escritura y los datos restantes se pueden migrar en 10 minutos, el sistema entra automáticamente en el estado de suspensión de escritura. Durante la suspensión, el backend continúa migrando datos hasta que todos los datos estén sincronizados. Una vez completada la migración, el sistema sale automáticamente del estado de suspensión de escritura.

La migración de datos ocurre durante el escalamiento del clúster. Para garantizar una migración exitosa, la ventana de suspensión de escritura debe cumplir con los siguientes requisitos:
- Se recomienda establecer la ventana de suspensión de escritura en al menos 30 minutos.
- El escalamiento debe completarse dentro de los 5 días posteriores a la creación del cambio de configuración. Por lo tanto, la hora de finalización de la ventana de suspensión de escritura para el clúster de origen no debe ser posterior a la fecha actual + 5 días.
- Para minimizar el impacto en su negocio, se recomienda establecer la ventana de suspensión de escritura fuera de las horas pico.
Haga clic en Buy and Start y complete el pago según las indicaciones.
En la página Purchase successful, haga clic en Console.
En la página Clusters of Community-compatible Edition, consulte el estado del clúster objetivo en la columna Status.

Nota

Se espera que el escalamiento horizontal tome 30 minutos o más. La duración depende del volumen de datos. El estado del clúster en la consola muestra el estado real de ejecución de la tarea.

Paso 4: Volver a crear tablas de Kafka/RabbitMQ

Cuando la tarea de escalamiento entra en la etapa de Data Migration (después de completar la migración del esquema de tablas), utilice las sentencias DDL que guardó para volver a crear las tablas con motores Kafka/RabbitMQ y sus vistas materializadas posteriores. Después de volver a crearlas, los datos incrementales reanudan su flujo y se sincronizan automáticamente con los nuevos nodos del clúster.

Importante

Si realizó una operación RENAME en tablas destino implícitas en el Paso 1, utilice la cláusula TO para apuntar a la tabla destino renombrada cuando vuelva a crear la vista materializada. Para obtener más información sobre la cláusula TO, consulte CREATE MATERIALIZED VIEW.

-- Re-create Kafka/RabbitMQ engine tables.
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Re-create the materialized view (use the TO clause to point to the renamed target table).
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Paso 5: Eliminar tablas de Kafka/RabbitMQ antes de la suspensión de escritura

Antes de que comience la ventana de suspensión de escritura configurada, elimine las tablas con motores Kafka/RabbitMQ y sus vistas materializadas posteriores para detener las escrituras de datos incrementales y garantizar la consistencia final de la sincronización de datos.

-- Remove materialized views first.
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then, remove Kafka/RabbitMQ engine tables.
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

Paso 6: Volver a crear tablas de Kafka/RabbitMQ después del escalamiento

Una vez completada la tarea de escalamiento, utilice las sentencias DDL que guardó para volver a crear las tablas con motores Kafka/RabbitMQ y sus vistas materializadas posteriores en el clúster escalado, a fin de restaurar la canalización de consumo de datos incrementales.

Importante

-- Re-create Kafka/RabbitMQ engine tables.
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Re-create the materialized view (use the TO clause to point to the renamed target table).
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Paso 7: Migrar datos de tablas que no son MergeTree

Inicie sesión en el clúster y utilice OSS to migrate los datos de los que realizó una copia de seguridad en Step 2. For more information, see Import data from OSS.