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

Pour répondre à l'évolution des besoins métier, vous pouvez ajuster la configuration ou la taille de votre cluster Alibaba Cloud ClickHouse Community-Compatible Edition. Effectuez une mise à l'échelle verticale et horizontale sur votre cluster Alibaba Cloud ClickHouse afin d'atteindre un équilibre optimal entre coûts et performances.

Présentation de la mise à l'échelle verticale et horizontale

La mise à l'échelle verticale est plus rapide et perturbe moins votre activité que la mise à l'échelle horizontale. Si les performances de votre cluster sont insuffisantes, privilégiez dans un premier temps la mise à l'échelle verticale.

Méthode de mise à l'échelle	Cas d'utilisation	Fonctionnement	Impact	Actions
Mise à l'échelle verticale	Ajuste les ressources des nœuds lorsque la capacité du CPU, de la mémoire ou du disque est insuffisante ou surdimensionnée.	Augmente ou diminue les spécifications des nœuds, la capacité de stockage et les spécifications ZooKeeper pour un cluster Alibaba Cloud ClickHouse Community-Compatible Edition, en adaptant sa puissance de calcul, sa capacité de stockage et ses capacités de coordination distribuée. Remarque La mise à l'échelle verticale ne permet pas de réduire la capacité de stockage. Les solutions suivantes sont disponibles pour réduire la capacité de stockage : Pour une instance multinœud, réduisez le nombre de nœuds pour diminuer la capacité de stockage selon vos besoins métier. Pour une instance mononœud, créez une nouvelle instance et migrez les données pour réduire la capacité de stockage.	La mise à niveau du type de stockage ou l'augmentation de la capacité de stockage d'un cluster Alibaba Cloud ClickHouse Community-Compatible Edition n'affecte pas l'instance (cela s'applique uniquement aux instances créées après le 1er décembre 2021). En revanche, la modification des spécifications du cluster ou de ZooKeeper entraîne un redémarrage du cluster. Important La mise à l'échelle verticale prend de 5 à 10 minutes. Le temps nécessaire au redémarrage d'un cluster dépend du volume de données. Plus un cluster contient de bases de données, de tables et de données froides, plus le redémarrage est long. Pour un cluster à double réplica, la mise à l'échelle peut provoquer des interruptions temporaires de connexion lors du basculement des requêtes entre les réplicas. Effectuez cette opération pendant les heures creuses et assurez-vous que votre application dispose d'un mécanisme de nouvelle tentative. Un cluster à réplica unique est indisponible tout au long du processus de mise à l'échelle. Réalisez cette opération pendant les heures creuses ou lorsque les opérations d'écriture sont suspendues, et assurez-vous que votre application dispose d'un mécanisme de nouvelle tentative. Si vous modifiez les spécifications ZooKeeper pendant les heures de pointe, des incohérences peuvent apparaître entre les métadonnées des tables et les données réelles. Effectuez cette opération pendant les heures creuses ou lorsque les opérations d'écriture sont suspendues.	Mise à l'échelle ascendante ou descendante
Mise à l'échelle horizontale (ajout de nœuds)	Mise à l'échelle avec migration des données : utilisez cette méthode lorsque les données du cluster doivent être redistribuées après l'ajout de nœuds. Mise à l'échelle simple : Utilisez cette méthode si votre cluster remplit les conditions suivantes : Avant la mise à l'échelle, les données sont écrites directement dans des tables locales ou dans des tables distribuées dont la clé de sharding est définie sur `rand`. Aucun rééquilibrage des données entre les nœuds n'est requis. Important N'utilisez pas la mise à l'échelle simple pour les clusters contenant des tables utilisant des moteurs tels que ReplacingMergeTree, CollapsingMergeTree ou VersionedCollapsingMergeTree. Les données de ces types de tables ne peuvent être fusionnées que sur le même nœud. La mise à l'échelle simple disperse les données devant être fusionnées sur différents nœuds, ce qui empêche leur fusion.	Mise à l'échelle avec migration des données : augmente le nombre de nœuds dans un cluster Alibaba Cloud ClickHouse Community-Compatible Edition pour mettre à l'échelle horizontalement sa puissance de calcul. Les données existantes sont migrées et redistribuées. Mise à l'échelle simple : augmente le nombre de nœuds dans un cluster Alibaba Cloud ClickHouse Community-Compatible Edition pour mettre à l'échelle horizontalement sa puissance de calcul. Cette méthode est utilisée lorsque les données sont écrites directement dans des tables locales et qu'aucun rééquilibrage des données entre les nœuds n'est requis.	Les opérations DDL sont interdites pendant toute la durée du processus de mise à l'échelle horizontale. L'utilisation du CPU et de la mémoire du cluster augmente pendant le processus de mise à l'échelle. La surcharge estimée des ressources est inférieure à 5 cœurs CPU et 20 Go de mémoire par nœud. Une fois la mise à l'échelle terminée, une période d'opérations de fusion à haute fréquence s'ensuit. Cela augmente l'utilisation des E/S et peut entraîner une latence accrue pour les requêtes métier.	Mise à l'échelle horizontale (ajout et retrait de nœuds)
Mise à l'échelle horizontale (retrait de nœuds)	Mise à l'échelle standard : Réduit le nombre de nœuds pour économiser des coûts. Les nœuds sont mis hors ligne de manière aléatoire. Vous ne pouvez pas spécifier quels nœuds supprimer. Mise à l'échelle en spécifiant les nœuds : met hors ligne des nœuds spécifiques pour les clusters disposant de grandes spécifications de stockage.	Réduit le nombre de nœuds dans un cluster Alibaba Cloud ClickHouse Community-Compatible Edition pour diminuer les coûts.	Les opérations DDL sont interdites pendant toute la durée du processus de mise à l'échelle horizontale. L'utilisation du CPU et de la mémoire du cluster augmente pendant le processus de mise à l'échelle. La surcharge estimée des ressources est inférieure à 5 cœurs CPU et 20 Go de mémoire par nœud. Une fois la mise à l'échelle terminée, une période d'opérations de fusion à haute fréquence s'ensuit. Cela augmente l'utilisation des E/S et peut entraîner une latence accrue pour les requêtes métier.	Mise à l'échelle horizontale (ajout et retrait de nœuds)

Prérequis

Le cluster est un cluster Alibaba Cloud ClickHouse Community-Compatible Edition.
L'état du cluster est Running.
Le cluster ne comporte aucune commande de renouvellement impayée.

Remarque
Connectez-vous à la console Alibaba Cloud ClickHouse. Dans le coin supérieur droit de la page, choisissez Fee > Expenses and Costs. Dans le volet de navigation de gauche, cliquez sur Order Management et effectuez le paiement ou annulez la commande.

Notes d'utilisation

Mise à l'échelle verticale : vous pouvez modifier les spécifications ZooKeeper uniquement pour les clusters Alibaba Cloud ClickHouse Community-Compatible Edition créés après le 1er décembre 2021. Pour obtenir des informations sur la tarification des spécifications ZooKeeper, consultez la rubrique Tarification des spécifications ZooKeeper pour l'Édition compatible avec la communauté.
Mise à l'échelle horizontale :
- Lorsque vous ajoutez des nœuds à un cluster contenant des tables utilisant la famille de moteurs MergeTree, le système migre les données existantes vers le nouveau cluster et les redistribue automatiquement.
  Contenu pris en charge pour la migration :
  - Bases de données, dictionnaires de données et vues matérialisées.
  - Schéma de table : tous les schémas de table, à l'exception de ceux des tables utilisant le moteur Kafka ou RabbitMQ.
  - Données : les données des tables utilisant les moteurs de la famille MergeTree sont migrées de manière incrémentielle.
  Contenu non pris en charge pour la migration :
  - Schémas de table et données des tables utilisant les moteurs Kafka et RabbitMQ.
    
    Important
    Lors d'une modification de configuration, les données sont migrées vers une nouvelle instance et le trafic est finalement basculé vers celle-ci. Pour éviter que les données ne soient fragmentées entre Kafka et RabbitMQ, supprimez d'abord les tables utilisant les moteurs Kafka et RabbitMQ du cluster source. Recréez-les une fois la modification de configuration terminée.
  - Données des tables n'appartenant pas à la famille MergeTree, telles que les tables externes et les tables de la famille Log.
  Important
  Pendant le processus de mise à l'échelle, gérez manuellement le contenu non pris en charge comme décrit dans la procédure.
- Les opérations DDL sont interdites pendant toute la durée du processus de mise à l'échelle horizontale. Le non-respect de cette règle peut entraîner des échecs de validation des données et faire échouer la mise à l'échelle.
- Après l'ajout de nœuds, les adresses IP internes des nœuds changent. Si votre application s'appuie sur les adresses IP des nœuds pour l'écriture et l'accès aux données, vous devez obtenir le nouveau bloc CIDR VPC du cluster. Pour plus d'informations, consultez la rubrique Obtenir le bloc CIDR VPC d'un cluster.
- Seuls les clusters basés sur des disques locaux prennent en charge la mise à l'échelle en spécifiant les nœuds. Dans ce mode, les données présentes sur les nœuds mis hors ligne sont perdues. En mode de mise à l'échelle standard, le système ne perd pas de données mais les redistribue.
Après la modification de la configuration du cluster, une période d'opérations de fusion à haute fréquence s'ensuit. Cela augmente l'utilisation des E/S et peut entraîner une latence accrue pour les requêtes métier. Planifiez à l'avance pour atténuer l'impact potentiel de la latence des requêtes. Pour savoir comment calculer la durée de fusion, consultez la rubrique Calculer la durée de fusion après la migration.
Pendant la modification de la configuration du cluster, l'utilisation du CPU et de la mémoire augmente. La surcharge estimée des ressources est inférieure à 5 cœurs CPU et 20 Go de mémoire par nœud.

Facturation

Après la modification de la configuration du cluster, les frais évoluent. Le coût réel affiché dans la console fait foi. Pour plus d'informations, consultez la rubrique Facturation des modifications de configuration.

Mise à l'échelle ascendante et descendante

Important

Pour obtenir des informations sur les impacts de la mise à l'échelle verticale, consultez les rubriques Présentation de la mise à l'échelle verticale et horizontale et Notes d'utilisation.

Connectez-vous à la console Alibaba Cloud ClickHouse. Dans le coin supérieur gauche de la page, sélectionnez la région où se trouve votre cluster.
Sur la page Clusters, cliquez sur Clusters of Community-compatible Edition.
Dans la colonne Actions du cluster cible, cliquez sur Change Configurations.
Dans la boîte de dialogue Change Configurations, sélectionnez Scale Up ou Scale Down, puis cliquez sur OK.
Sur la page Change Specification ou Scale Down, sélectionnez les configurations souhaitées en fonction de vos besoins métier.
Remarque
- Vous ne pouvez pas modifier simultanément la Storage Capacity ou le Storage Type et la Specification lorsque vous utilisez l'option Change Specification.
- Par défaut, les clusters sont fournis avec des spécifications ZooKeeper de 4 cœurs CPU et 8 Go de mémoire. Sur la page Monitoring and Alerting, consultez les métriques ZooKeeper dans le panneau Cluster Monitoring pour vérifier l'absence de goulots d'étranglement au niveau des ressources. Si les spécifications par défaut sont insuffisantes, effectuez une mise à l'échelle ascendante rapidement.
Cliquez sur Buy and Start et effectuez le paiement comme indiqué.
Sur la page Paid, cliquez sur Console.
Sur la page Clusters of Community-compatible Edition, consultez l'état du cluster cible dans la colonne Status.
Remarque
- Après la modification de la Storage Capacity, la modification prend effet immédiatement et l'état du cluster reste Running.
- Après la modification de la Specification et des ZooKeeper Specifications, patientez environ 10 à 15 minutes. L'opération de mise à l'échelle ascendante ou descendante aboutit lorsque l'état du cluster passe de Changing Specification à Running.

Mise à l'échelle horizontale (ajout et retrait de nœuds)

Important

Pour obtenir des informations sur les impacts de la mise à l'échelle horizontale, consultez les rubriques Présentation de la mise à l'échelle verticale et horizontale et Notes d'utilisation.

Étape 1 : Enregistrer et supprimer les tables Kafka/RabbitMQ

La fonctionnalité de mise à l'échelle de la console ne peut pas migrer directement les tables utilisant les moteurs Kafka et RabbitMQ. Avant de mettre à l'échelle le cluster, enregistrez les instructions DDL de ces tables et supprimez-les du cluster afin d'éviter toute interférence avec la tâche de mise à l'échelle.

Connectez-vous au cluster et exécutez l'instruction suivante pour interroger toutes les tables utilisant les moteurs Kafka et RabbitMQ ainsi que leurs dépendances descendantes.

/*
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');

Consultez la définition de la vue matérialisée pour vérifier si sa table cible est une table implicite.

/*
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 une vue matérialisée a été créée sans clause TO, le système génère automatiquement une table cible implicite préfixée par .inner ou .inner_id. Ces tables implicites sont migrées vers les nouveaux nœuds lors de la mise à l'échelle, mais en raison des mécanismes de nommage internes, la recréation directe de la vue matérialisée d'origine peut provoquer des conflits de nommage. Par conséquent, renommez d'abord les tables cibles implicites avec des noms de table réguliers.
```
-- 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;
```
Supprimez les vues matérialisées et les tables utilisant les moteurs Kafka/RabbitMQ.

Important
Vous devez supprimer les vues matérialisées qui référencent les tables Kafka/RabbitMQ avant de supprimer les tables utilisant les moteurs Kafka/RabbitMQ. Sinon, l'opération de mise à l'échelle échouera.
```
-- 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;
```

Important

Assurez-vous de sauvegarder toutes les instructions DDL enregistrées. Vous devrez recréer ces tables sur le cluster mis à l'échelle ultérieurement. Si vous avez effectué une opération RENAME, utilisez la clause TO pour pointer vers la table cible renommée lors de la recréation de la vue matérialisée. Pour plus d'informations, consultez la documentation CREATE MATERIALIZED VIEW.

Si le cluster ne contient pas de tables utilisant les moteurs Kafka/RabbitMQ, vous pouvez ignorer les étapes 1, 4, 5 et 6, et commencer directement à l'étape 2.

Étape 2 : Sauvegarder les données des tables n'appartenant pas à la famille MergeTree

Connectez-vous au cluster et exécutez l'instruction suivante pour identifier les tables n'appartenant pas à la famille MergeTree qui nécessitent une migration des données.

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')
))

Sauvegardez les données.

Sauvegardez les données métier des tables n'appartenant pas à la famille MergeTree. Pour plus d'informations, consultez la rubrique Sauvegarder des données vers OSS.

Étape 3 : Mettre à l'échelle dans la console

Connectez-vous à la console Alibaba Cloud ClickHouse. Dans le coin supérieur gauche de la page, sélectionnez la région où se trouve votre cluster.
Sur la page Clusters, cliquez sur Clusters of Community-compatible Edition.
Dans la colonne Actions du cluster cible, cliquez sur Change Configurations.
Dans la boîte de dialogue Change Configurations, sélectionnez Scale Out ou Scale In, puis cliquez sur OK.
Dans la fenêtre de vérification de mise à l'échelle horizontale (ajout ou retrait de nœuds), consultez l'état de la vérification.

Remarque
Lorsque vous accédez à la fenêtre de vérification pour l'option Scale Out, l'option Migration Expansion est sélectionnée par défaut. Pour sélectionner l'option Simple Expansion, cliquez sur Previous sur cette page. Dans la boîte de dialogue Scale-out, sélectionnez Simple Expansion et cliquez sur Next pour accéder à la page Change Specification.

Si le cluster contient des tables utilisant les moteurs Kafka/RabbitMQ, effectuez l'étape 4 pour recréer les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster lorsque la tâche de mise à l'échelle atteint l'étape Data Migration (après la migration du schéma de table). Cela permet aux données incrémentielles de reprendre leur flux et d'être synchronisées vers les nouveaux nœuds.

Avant le début de la fenêtre de suspension d'écriture configurée, effectuez l'étape 5 pour supprimer les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées descendantes du cluster. Cela évite que les messages en attente pendant la fenêtre de suspension d'écriture ne provoquent des incohérences de données.
- Si la vérification réussit, cliquez sur Next.
- Si la vérification échoue, corrigez le problème comme indiqué sur la page et cliquez sur Retry Detection. Une fois la vérification réussie, cliquez sur Next.
  Les raisons courantes d'un échec de vérification lors de l'ajout de nœuds incluent :
  Table distribuée unique manquante : une table locale n'a pas de table distribuée correspondante. Vous devez en créer une.
  
  La table distribuée correspondante n'est pas unique : une table locale possède plusieurs tables distribuées. Supprimez les tables distribuées supplémentaires et n'en conservez qu'une seule.
  
  Tables utilisant les moteurs Kafka/RabbitMQ non prises en charge : le cluster contient des tables utilisant les moteurs Kafka ou RabbitMQ. Vous devez les supprimer.
  
  Tables MergeTree non répliquées dans une instance à plusieurs réplicas : les données sont incohérentes entre les réplicas, ce qui provoque des erreurs de migration des données lors de la mise à l'échelle.
  
  Les colonnes de la table distribuée et de la table locale sont incohérentes : vous devez harmoniser les colonnes. Sinon, des erreurs de migration des données surviendront lors de la mise à l'échelle.
  
  La table est absente sur certains nœuds : vous devez créer des tables portant le même nom sur différents shards. Pour la table interne d'une vue matérialisée, nous vous recommandons de renommer la table interne, puis de recréer la vue matérialisée pour qu'elle pointe vers la table interne renommée. Pour plus d'informations, consultez la rubrique La table interne d'une vue matérialisée est incohérente entre les shards.
Sur la page Change Specification ou Scale Down, configurez le nombre de Server Nodes et la fenêtre de suspension d'écriture.
Remarque
Une fenêtre de suspension d'écriture est une période configurée par le client pendant laquelle le noyau est autorisé à arrêter les écritures. La logique de migration interne détermine s'il faut suspendre les écritures selon la logique suivante : si l'heure actuelle se situe dans la fenêtre de suspension d'écriture et que les données restantes peuvent être migrées en moins de 10 minutes, le système passe automatiquement en état de suspension d'écriture. Pendant la suspension, le backend continue de migrer les données jusqu'à ce que toutes les données soient synchronisées. Une fois la migration terminée, le système quitte automatiquement l'état de suspension d'écriture.

La migration des données se produit lors de la mise à l'échelle du cluster. Pour garantir le succès de la migration, la fenêtre de suspension d'écriture doit respecter les exigences suivantes :
- Nous vous recommandons de définir la fenêtre de suspension d'écriture sur au moins 30 minutes.
- La mise à l'échelle doit être terminée dans les 5 jours suivant la création de la modification de configuration. Par conséquent, l'heure de fin de la fenêtre de suspension d'écriture pour le cluster source ne doit pas dépasser la date actuelle + 5 jours.
- Pour minimiser l'impact sur votre activité, nous vous recommandons de définir la fenêtre de suspension d'écriture pendant les heures creuses.
Cliquez sur Buy and Start et effectuez le paiement comme indiqué.
Sur la page Purchase successful, cliquez sur Console.
Sur la page Clusters of Community-compatible Edition, consultez l'état du cluster cible dans la colonne Status.

Remarque

La mise à l'échelle horizontale devrait prendre 30 minutes ou plus. La durée dépend du volume de données. L'état du cluster dans la console affiche l'état réel de l'exécution de la tâche.

Étape 4 : Recréer les tables Kafka/RabbitMQ

Lorsque la tâche de mise à l'échelle atteint l'étape Data Migration (après la migration du schéma de table), utilisez les instructions DDL que vous avez enregistrées pour recréer les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées descendantes. Après la recréation, les données incrémentielles reprennent leur flux et se synchronisent automatiquement vers les nouveaux nœuds du cluster.

Important

Si vous avez effectué une opération RENAME sur les tables cibles implicites à l'étape 1, utilisez la clause TO pour pointer vers la table cible renommée lors de la recréation de la vue matérialisée. Pour plus d'informations sur la clause TO, consultez la documentation 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>;

Étape 5 : Supprimer les tables Kafka/RabbitMQ avant la suspension d'écriture

Avant le début de la fenêtre de suspension d'écriture configurée, supprimez les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées descendantes afin d'arrêter les écritures de données incrémentielles et de garantir la cohérence de la synchronisation finale des données.

-- 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;

Étape 6 : Recréer les tables Kafka/RabbitMQ après la mise à l'échelle

Une fois la tâche de mise à l'échelle terminée, utilisez les instructions DDL que vous avez enregistrées pour recréer les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées descendantes sur le cluster mis à l'échelle afin de restaurer le pipeline de consommation des données incrémentielles.

Important

-- 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>;

Étape 7 : Migrer les données des tables n'appartenant pas à la famille MergeTree

Connectez-vous au cluster et utilisez OSS pour migrer les données que vous avez sauvegardées à l'étape 2. Pour plus d'informations, consultez la rubrique Importer des données depuis OSS.