Cette page ne concerne pas ClickHouse Cloud. La procédure décrite ici est automatisée dans les services ClickHouse Cloud.
Détails d’implémentation
clickhouse-keeper-converter permet de convertir les données ZooKeeper en snapshots ClickHouse Keeper. Le protocole interserver de ClickHouse Keeper est lui aussi incompatible avec ZooKeeper ; un cluster mixte ZooKeeper / ClickHouse Keeper est donc impossible.
ClickHouse Keeper prend en charge les listes de contrôle d’accès (ACL) de la même manière que ZooKeeper. ClickHouse Keeper prend en charge le même ensemble de permissions et dispose des mêmes schémas intégrés : world, auth et digest. Le schéma d’authentification digest utilise la paire username:password ; le mot de passe est encodé en Base64.
Les intégrations externes ne sont pas prises en charge.
Configuration
.xml est quasiment le même.
Paramètres de configuration de Keeper
<keeper_server> et comporte les paramètres suivants :
Les autres paramètres courants sont hérités de la config du serveur ClickHouse (
listen_host, logger, etc.).
Paramètres de coordination interne
Les paramètres de coordination interne se trouvent dans la section<keeper_server>.<coordination_settings> et comprennent les paramètres suivants :
La configuration du quorum se trouve dans la section
<keeper_server>.<raft_configuration> et contient la description des serveurs.
Le seul paramètre pour l’ensemble du quorum est secure, qui active une connexion chiffrée pour la communication entre les participants au quorum. Le paramètre peut être défini sur true si une connexion SSL est requise pour la communication interne entre les nœuds, ou laissé non spécifié dans le cas contraire.
Les principaux paramètres de chaque <server> sont :
id— Identifiant du serveur dans un quorum.hostname— Nom d’hôte où ce serveur est hébergé.port— Port sur lequel ce serveur écoute les connexions.can_become_leader— Définissezfalsepour configurer le serveur commelearner. Si ce paramètre est omis, la valeur esttrue.
En cas de modification de la topologie de votre cluster ClickHouse Keeper (par ex., remplacement d’un serveur), veillez à conserver une association cohérente entre
server_id et hostname, et évitez de permuter ou de réutiliser un server_id existant pour différents serveurs (par ex., cela peut se produire si vous utilisez des scripts d’automatisation pour déployer ClickHouse Keeper)Si l’hôte d’une instance Keeper est susceptible de changer, nous recommandons de définir et d’utiliser un nom d’hôte plutôt que des adresses IP brutes. Modifier le nom d’hôte revient à supprimer le serveur puis à l’ajouter de nouveau, ce qui peut dans certains cas être impossible (par ex., s’il n’y a pas assez d’instances Keeper pour atteindre le quorum).async_replication est désactivé par défaut afin d’éviter de rompre la compatibilité descendante. Si toutes les instances Keeper de votre cluster exécutent une version prenant en charge async_replication (v23.9+), nous recommandons de l’activer, car cela peut améliorer les performances sans aucun inconvénient.test_keeper_. Exemple de configuration pour le serveur #1 :
Comment l’exécuter
<keeper_server> à votre fichier /etc/your_path_to_config/clickhouse-server/config.xml et de démarrer le serveur ClickHouse comme d’habitude. Si vous souhaitez exécuter ClickHouse Keeper en mode standalone, vous pouvez le démarrer de manière similaire avec :
clickhouse-keeper), vous pouvez le créer ou passer keeper en argument à clickhouse :
Commandes à quatre lettres
ClickHouse Keeper fournit également des commandes 4lw, presque identiques à celles de ZooKeeper. Chaque commande se compose de quatre lettres, commemntr, stat, etc. Parmi les commandes les plus utiles : stat fournit des informations générales sur le serveur et les clients connectés, srvr fournit des détails supplémentaires sur le serveur, et cons fournit des détails supplémentaires sur les connexions.
Les commandes 4lw utilisent une configuration de liste blanche, four_letter_word_white_list, dont la valeur par défaut est conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,rclc,clrs,ftfl,ydld,bpon,bpof,pfev,lgrq, à laquelle s’ajoutent jmst,jmfp,jmep,jmdp dans les builds avec jemalloc. La liste est lue une seule fois au démarrage ; sa modification nécessite donc un redémarrage.
Vous pouvez envoyer ces commandes à ClickHouse Keeper via telnet ou nc, sur le port client.
ruok: teste si le serveur est en cours de fonctionnement et ne se trouve pas dans un état d’erreur. Le serveur répond parimoks’il est en cours d’exécution. Sinon, il ne répond pas du tout. Une réponseimokn’indique pas nécessairement que le serveur a rejoint le quorum, mais seulement que le processus serveur est actif et lié au port client spécifié. Utilisez “stat” pour obtenir des détails sur l’état vis-à-vis du quorum et les informations de connexion du client.
mntr: affiche une liste de variables pouvant être utilisées pour surveiller l’état du cluster.
zk_sum_leader_unavailable_time, zk_cnt_leader_unavailable_time, zk_sum_election_time et zk_cnt_election_time sont des métriques cumulatives réservées au leader. Elles constituent des observations par serveur, et non des mesures de disponibilité à l’échelle du cluster : le suivi commence lorsque ce serveur cesse d’observer un leader actif. Lors d’une partition réseau, cela peut inclure le temps pendant lequel un ancien leader reste actif dans une autre partition. Les métriques d’élection n’enregistrent qu’une élection réussie qui suit une fenêtre locale observée sans leader ; un transfert de leadership qui n’expose pas d’état sans leader échantillonné n’est intentionnellement pas comptabilisé.
Keeper échantillonne son état local de leader NuRaft une fois par heart_beat_interval_ms, mais jamais à une fréquence supérieure à une fois toutes les 100 millisecondes. Chaque limite de fenêtre peut différer de cette transition d’état locale d’un maximum égal à l’intervalle effectif, et les fenêtres plus courtes que cet intervalle peuvent ne pas être détectées. Keeper enregistre la fin d’une élection locale lors de BecomeLeader de NuRaft. srst réinitialise les quatre valeurs.
La durée de la fenêtre la plus récente de chaque type observée localement est également exportée vers system.asynchronous_metrics sous les noms KeeperLastLeaderElectionTime et KeeperLastLeaderUnavailableTime, en millisecondes. KeeperLastLeaderElectionTime suit la même définition de fenêtre sans leader que zk_sum_election_time. Les deux sont également réservées au leader : un nœud qui n’est pas le leader actif, ou qui n’a pas encore terminé de fenêtre, indique 0. srst les réinitialise avec les compteurs cumulatifs.
srvr: affiche les informations détaillées du serveur.
stat: Affiche des informations succinctes sur le serveur et les clients connectés.
srst: Réinitialise les statistiques du serveur. La commande affecte le résultat desrvr,mntretstat.
conf: Affiche les détails de la configuration de service.
cons: Répertorie les informations détaillées sur la connexion/session de tous les clients connectés à ce serveur. Inclut des informations sur le nombre de paquets reçus/envoyés, l’identifiant de session, les latences des opérations, la dernière opération effectuée, etc…
crst: Réinitialise les statistiques de connexion et de session pour toutes les connexions.
envi: Afficher les détails de l’environnement d’exécution
dirs: Affiche la taille totale des snapshots et des fichiers de log, en octets
isro: vérifie si le serveur est en mode lecture seule. Le serveur renvoieros’il est en mode lecture seule, ourwdans le cas contraire.
wchs: Affiche de brèves informations sur les watches du serveur.
wchc: Liste les informations détaillées sur les watches du serveur, par session. Cette commande affiche une liste de sessions (connexions) avec les watches associées (chemins). Notez que, selon le nombre de watches, cette opération peut être coûteuse (et affecter les performances du serveur) ; utilisez-la avec précaution.
wchp: répertorie des informations détaillées sur les watches du serveur, par chemin. La commande renvoie une liste de chemins (znodes) avec les sessions associées. Notez que, selon le nombre de watches, cette opération peut être coûteuse (c.-à-d. affecter les performances du serveur) ; utilisez-la avec précaution.
dump: répertorie les sessions ouvertes et les nœuds éphémères. Cette commande fonctionne uniquement sur le leader.
csnp: planifie une tâche de création de snapshot. Renvoie le dernier index de log validé du snapshot planifié en cas de succès, ouFailed to schedule snapshot creation task.en cas d’échec. La commandelgifpeut vous aider à déterminer si le snapshot est terminé.
lgif: Informations sur le log de Keeper.first_log_idx: mon premier index de log dans le stockage de logs ;first_log_term: mon premier terme de log ;last_log_idx: mon dernier index de log dans le stockage de logs ;last_log_term: mon dernier terme de log ;last_committed_log_idx: mon dernier index de log validé dans la machine à états ;leader_committed_log_idx: l’index de log validé du leader, de mon point de vue ;target_committed_log_idx: l’index de log cible qui doit être validé ;last_snapshot_idx: le plus grand index de log validé dans le dernier snapshot.
rqld: Demande à devenir le nouveau leader. RenvoieSent leadership request to leader.si la demande est envoyée, ouFailed to send leadership request to leader.dans le cas contraire. Si le nœud est déjà leader, le résultat est le même que si la demande avait été envoyée.
ftfl: Répertorie tous les feature flags et indique s’ils sont enabled pour l’instance Keeper.
-
bpon: demande au leader d’attendre les répliques qui n’arrivent pas à suivre. Tant que l’option est activée, le leader n’avance pas l’index de commit au-delà d’une réplique qu’il peut joindre, de sorte qu’une réplique en retard peut combler l’écart au lieu de dériver jusqu’à avoir besoin d’un snapshot. Les écritures sont alors validées à la vitesse de la réplique votante joignable la plus lente : activez-la donc délibérément, observez les répliques rattraper leur retard, puis désactivez-la avecbpof. Il n’existe aucun seuil de lag : chaque réplique votante que le leader peut joindre est attendue, quel que soit son retard, y compris une réplique en train de recevoir un snapshot. Une réplique dontcan_become_leadervautfalsene vote pas et n’est jamais attendue ; elle peut donc continuer à dériver jusqu’à avoir besoin d’un snapshot — la contre-pression ne la protège pas. Si l’intention est seulement qu’une réplique ne devienne pas leader, donnez-lui plutôtpriority0: elle vote toujours, elle est donc toujours attendue, alors quecan_become_leaderfalsela retire complètement du quorum. Une réplique n’est écartée que lorsque l’attente ne mène à rien : sa dernière requête a échoué, elle n’a fait aucun progrès dans le délaislow_member_backpressure_no_progress_timeout_ms, elle n’a pas encore répondu du tout sur une nouvelle connexion et aucun snapshot ne lui est envoyé non plus — ce qui laisse le leader sans aucune idée de son état —, ou elle se situe hors de la plage de logs du leader, de sorte que ni le log ni un snapshot ne peuvent la rétablir ; attendre une telle réplique figerait l’index de commit pour rien. Définissez égalementslow_member_backpressure_max_uncommitted_log_entries. Retenir l’index de commit n’empêche pas le leader d’ajouter des entrées : sans ce paramètre, le log continue donc de grossir pendant que la réplique est attendue. La commande peut être envoyée à n’importe quel nœud : un follower la transmet au leader actuel et ne modifie rien localement, de sorte que seul le leader détient le paramètre. Vérifiez-le aveczk_slow_member_backpressuredansmntrsur le leader, quezk_server_stateidentifie. Le paramètre ne dure que le temps d’un leadership — il est désactivé aussi bien lorsqu’un nœud devient leader que lorsqu’il cesse de l’être — et n’est pas persisté : un nœud redémarré démarre donc avec l’option désactivée. Seul le leader peut répondre au sujet du paramètre, donc seule sa réponse le confirme. Un follower indique qu’il a transmis la requête, et rien de plus : le leader refuse une requête qui arrive après qu’il a cessé d’être leader.
bpof: demande au leader de cesser d’attendre les répliques qui n’arrivent pas à suivre. Cette commande peut être envoyée à n’importe quel nœud et parvient au leader de la même manière quebpon.
ydld: demande de céder le leadership et de devenir follower. Si le serveur qui reçoit la requête est le leader, il suspend d’abord les opérations d’écriture, attend que le successeur (le leader actuel ne peut jamais être le successeur) termine le catch-up du dernier log, puis démissionne. Le successeur est choisi automatiquement. RetourneSent yield leadership request to leader.si la requête a été envoyée ouFailed to send yield leadership request to leader.si elle ne l’a pas été. Si le nœud est déjà un follower, le résultat est le même que lorsque la requête est envoyée.
pfev: renvoie les valeurs de tous les événements collectés. Pour chaque événement, il renvoie le nom de l’événement, sa valeur et sa description.
Contrôle HTTP
/ready :
Feature flags
keeper_server.feature_flags.
Toutes les fonctionnalités peuvent aussi être désactivées explicitement.
Si vous souhaitez activer une nouvelle fonctionnalité pour votre cluster Keeper, nous vous recommandons de commencer par mettre à jour toutes les instances Keeper du cluster vers une version qui prend en charge cette fonctionnalité, puis d’activer la fonctionnalité elle-même.
Exemple de config de feature flag qui désactive multi_read et active check_not_exists :
Certains feature flags sont activés par défaut à partir de la version 25.7.
La méthode recommandée pour mettre à niveau Keeper vers la version 25.7+ consiste à commencer par effectuer la mise à niveau vers la version 24.9+.
Migration depuis ZooKeeper
clickhouse-keeper-converter convertit les logs et snapshots ZooKeeper en un snapshot ClickHouse Keeper. Il nécessite ZooKeeper 3.4 ou une version ultérieure.
Préparation avant la migration
Étapes de la migration
- Arrêtez l’ingestion de données sur tous les nœuds ClickHouse.
- Arrêtez toutes les tâches en arrière-plan sur tous les nœuds ClickHouse (voir ci-dessus).
- Arrêtez tous les nœuds ZooKeeper.
- Facultatif, mais recommandé : identifiez le nœud leader de ZooKeeper, démarrez-le, puis arrêtez-le à nouveau. Cela force ZooKeeper à écrire un snapshot cohérent sur le disque avant la conversion.
-
Exécutez
clickhouse-keeper-convertersur le nœud leader. Si vous avez installé le binaire complet de ClickHouse, utilisez plutôt la sous-commandekeeper-converter(clickhouse keeper-converter). Si aucun des deux n’est disponible, téléchargez le binaire.
- Copiez le snapshot sur tous les nœuds ClickHouse Keeper. Le snapshot doit être présent sur chaque nœud avant qu’aucun nœud ne démarre — si un nœud démarre sans snapshot, il peut s’élire leader avec un état vide.
- Mettez à jour votre configuration ClickHouse afin qu’elle pointe vers le nouveau cluster Keeper.
- Démarrez ClickHouse Keeper sur tous les nœuds, puis redémarrez ClickHouse.
- Comparez les métriques à votre référence pré-migration pour vérifier leur cohérence.
- Reprenez les tâches en arrière-plan et redémarrez l’ingestion des données.
Consolidation de plusieurs clusters ZooKeeper
clickhouse-keeper-converter ne prend en charge que les conversions un à un (un cluster ZooKeeper vers un snapshot Keeper) ; la consolidation exige donc de modifier le code source du convertisseur pour fusionner plusieurs snapshots :
- Exécutez
clickhouse-keeper-converterséparément sur chaque cluster ZooKeeper, en enregistrant chaque sortie dans un répertoire distinct. - Désérialisez les fichiers de snapshot successivement. Lors de la fusion, recalculez les valeurs
numChildrenpour éviter les conflits d’ID de nœud entre les espaces de noms provenant de différents clusters source. - Écrivez la sortie fusionnée dans le répertoire cible des snapshots ClickHouse Keeper.
Gestion du chiffrement et des ACL
world, auth, digest). La façon de gérer les ACL pendant la conversion dépend de votre configuration ZooKeeper :
- Entièrement chiffré ou entièrement non chiffré : convertissez directement. Le convertisseur conserve les informations d’ACL existantes.
- Partiellement chiffré : avant la conversion, accordez des privilèges de super-administrateur à un compte, puis supprimez les ACL avec
setAcl -Rsur les chemins concernés. Convertissez, puis réactivez le chiffrement dans ClickHouse Keeper si nécessaire.
Vérification de la migration
- Chemins communs : chemins présents dans plusieurs clusters sources avec des données identiques — ils doivent être dédupliqués dans la sortie fusionnée.
- Chemins distincts : chemins qui n’existent que dans des clusters spécifiques (par exemple, sous
/clickhouse/tablespour chaque groupe de shards) — ils doivent être conservés depuis la source appropriée.
Ajustements après migration
Ces paramètres se configurent sous
coordination_settings dans votre configuration de Keeper.
Récupération après la perte du quorum
- Assurez-vous que les nœuds défaillants ne puissent plus se reconnecter au cluster.
- Ne démarrez aucun des nouveaux nœuds tant que cela n’est pas indiqué dans les étapes.
- Choisissez un seul nœud Keeper pour en faire votre nouveau leader. Gardez à l’esprit que les données de ce nœud seront utilisées pour l’ensemble du cluster. Nous vous recommandons donc d’utiliser un nœud dont l’état est le plus à jour possible.
- Avant toute autre action, effectuez une sauvegarde des répertoires
log_storage_pathetsnapshot_storage_pathdu nœud sélectionné. - Reconfigurez le cluster sur tous les nœuds que vous souhaitez utiliser.
- Envoyez la commande à quatre lettres
rcvrau nœud choisi, ce qui fera passer le nœud en mode de récupération, OU arrêtez l’instance Keeper sur le nœud choisi et redémarrez-la avec l’argument--force-recovery. - Démarrez ensuite, un par un, les instances Keeper sur les nouveaux nœuds, en vous assurant que
mntrrenvoiefollowerpourzk_server_stateavant de démarrer le suivant. - En mode de récupération, le nœud leader renverra un message d’erreur pour la commande
mntrjusqu’à ce qu’il atteigne le quorum avec les nouveaux nœuds, et il refusera toutes les requêtes du client et des followers. - Une fois le quorum atteint, le nœud leader reviendra à un fonctionnement normal et acceptera toutes les requêtes via Raft ; vérifiez-le avec
mntr, qui doit renvoyerleaderpourzk_server_state.
Utiliser des disques avec Keeper
- s3_plain
- s3
- local
keeper_server.log_storage_disk doit être défini sur le nom du disque.
Pour utiliser un disque pour les snapshot, le paramètre keeper_server.snapshot_storage_disk doit être défini sur le nom du disque.
De plus, keeper_server.latest_log_storage_disk peut être utilisé pour les logs les plus récents et keeper_server.latest_snapshot_storage_disk pour les snapshot les plus récents.
Dans ce cas, Keeper déplacera automatiquement les fichiers vers les disques appropriés lors de la création de nouveaux logs ou snapshot.
Pour utiliser un disque pour le fichier d’état, le paramètre keeper_server.state_storage_disk doit être défini sur le nom du disque.
Le déplacement de fichiers entre disques est sûr et il n’y a aucun risque de perte de données si Keeper s’arrête au milieu du transfert.
Tant que le fichier n’a pas été entièrement déplacé vers le nouveau disque, il n’est pas supprimé de l’ancien.
Lorsque keeper_server.coordination_settings.force_sync est défini sur true (true par défaut), Keeper ne peut pas garantir certaines propriétés pour tous les types de disques.
À l’heure actuelle, seuls les disques de type local prennent en charge la synchronisation persistante.
Si force_sync est utilisé, log_storage_disk doit être un disque local si latest_log_storage_disk n’est pas utilisé.
Si latest_log_storage_disk est utilisé, il doit toujours être un disque local.
Si force_sync est désactivé, des disques de tout type peuvent être utilisés dans n’importe quelle configuration.
Voici à quoi pourrait ressembler une configuration de stockage possible pour une instance Keeper :
log_s3_plain, tandis que le log le plus récent sera stocké sur le disque log_local.
La même logique s’applique aux snapshot : tous les snapshot, sauf les plus récents, seront stockés sur le disque snapshot_s3_plain, tandis que le snapshot le plus récent sera stocké sur le disque snapshot_local.
Modifier la configuration des disques
keeper_server.old_snapshot_storage_disk et keeper_server.old_log_storage_disk.
La configuration suivante montre comment passer de la précédente configuration à 2 disques à une toute nouvelle configuration à disque unique :
log_local et log_s3_plain vers le disque log_local2.
De même, tous les fichiers d’instantané seront déplacés depuis snapshot_local et snapshot_s3_plain vers le disque snapshot_local2.
Configuration du cache des logs
Afin de minimiser la quantité de données lues sur le disque, Keeper met les entrées de journal en cache en mémoire. Si les requêtes sont volumineuses, les entrées de journal consomment trop de mémoire ; le volume de logs mis en cache est donc plafonné. Les limites du cache des logs les plus récents sont définies par :latest_logs_cache_size_threshold- mémoire occupée par les logs les plus récents mis en cachelatest_logs_cache_entry_count_threshold- nombre d’entrées que le cache peut contenir
0 ne laisse que l’autre en vigueur.
Le seuil de taille comptabilise la mémoire réellement occupée par une entrée mise en cache, et non uniquement la taille de l’entrée de journal
elle-même : chaque entrée mise en cache transporte également les objets qui la rendent joignable, et son allocation
est arrondie à une size class de l’allocator. Pour les petites entrées, cette surcharge représente plusieurs fois la taille de
l’entrée ; le nombre d’entrées que le cache peut contenir peut donc être bien inférieur à celui obtenu en divisant le seuil par la
taille d’une entrée. KeeperLatestLogsCacheSize indique la même quantité que celle bornée par le seuil.
Si les valeurs par défaut sont trop élevées, vous pouvez réduire l’utilisation de la mémoire en diminuant ces valeurs de configuration.
Les entrées de journal nécessaires à la validation suivante sont fournies par un lecteur de prélecture décodé, dont la taille est définie par
log_readahead_commit_window_bytes (0 désactive la prélecture lors de la validation). Ce paramètre remplace les paramètres
obsolètes commit_logs_cache_size_threshold et commit_logs_cache_entry_count_threshold,
conservés uniquement pour assurer la compatibilité de configuration (le premier est toujours associé à log_readahead_commit_window_bytes si
celui-ci n’est pas défini ; le second n’a aucun effet). Le même mécanisme de prélecture prend également en charge les lectures de rattrapage de
réplication des nœuds followers lorsque log_readahead_enabled est défini sur true ; consultez
log_readahead_window_bytes, log_readahead_max_peer_readers, log_readahead_eviction_timeout_ms,
log_readahead_pool_threads, log_readahead_serve_wait_timeout_ms et log_readahead_chunk_size
dans les paramètres de coordination interne pour les options de réglage
côté pair.
Vous pouvez utiliser la commande
pfev pour vérifier la quantité de logs lue depuis chaque cache et depuis un fichier.
Vous pouvez également utiliser les métriques de l’endpoint Prometheus pour suivre la taille actuelle des deux caches.Prometheus
endpoint– Endpoint HTTP de collecte des métriques par le serveur Prometheus. Doit commencer par ’/’.port– Port deendpoint.metrics– Indicateur qui active l’exposition des métriques de la table system.metrics.events– Indicateur qui active l’exposition des métriques de la table system.events.asynchronous_metrics– Indicateur qui active l’exposition des valeurs actuelles des métriques de la table system.asynchronous_metrics.
127.0.0.1 par l’adresse IP ou le nom d’hôte de votre serveur ClickHouse) :
Guide d’utilisation de ClickHouse Keeper
1
Configurer les nœuds avec les paramètres de Keeper
-
Installez 3 instances de ClickHouse sur 3 hôtes (
chnode1,chnode2,chnode3). (Consultez le Quick Start pour plus de détails sur l’installation de ClickHouse.) -
Sur chaque nœud, ajoutez l’entrée suivante pour permettre les communications externes via l’interface réseau.
-
Ajoutez la configuration ClickHouse Keeper suivante sur les trois serveurs en mettant à jour le paramètre
<server_id>pour chacun d’eux ; pourchnode1, la valeur serait1, pourchnode2, ce serait2, etc.Voici les paramètres de base utilisés ci-dessus : -
Activez le composant Zookeeper. Il utilisera le moteur ClickHouse Keeper :
Voici les paramètres de base utilisés ci-dessus :
-
Redémarrez ClickHouse et vérifiez que chaque instance de Keeper est en fonctionnement. Exécutez la commande suivante sur chaque serveur. La commande
ruokrenvoieimoksi Keeper est en fonctionnement et sain : -
La base de données
systemcomporte une table nomméezookeeper, qui contient les détails de vos instances ClickHouse Keeper. Affichons la table :Le tableau ressemble à ceci :
2
Configurer un cluster dans ClickHouse
-
Configurons un cluster simple avec 2 shards et une seule réplique sur 2 des nœuds. Le troisième nœud sera utilisé pour atteindre le quorum requis par ClickHouse Keeper. Mettez à jour la configuration sur
chnode1etchnode2. Le cluster suivant définit 1 shard sur chaque nœud, pour un total de 2 shards sans réplication. Dans cet exemple, une partie des données sera sur un nœud et une autre sur l’autre nœud : -
Redémarrez ClickHouse et vérifiez que le cluster a bien été créé :
Vous devriez voir votre cluster :
3
Créer et tester une table distribuée
-
Créez une nouvelle base de données sur le nouveau cluster à l’aide du client ClickHouse sur
chnode1. La clauseON CLUSTERcrée automatiquement la base de données sur les deux nœuds. -
Créez une nouvelle table dans la base de données
db1. Là encore,ON CLUSTERcrée la table sur les deux nœuds. -
Sur le nœud
chnode1, ajoutez quelques lignes : -
Ajoutez quelques lignes sur le nœud
chnode2: -
Notez que l’exécution d’une instruction
SELECTsur chaque nœud n’affiche que les données présentes sur ce nœud. Par exemple, surchnode1:Surchnode2: -
-
Vous pouvez créer une table
Distributedpour représenter les données réparties sur les deux shards. Les tables utilisant le moteur de tableDistributedne stockent pas leurs propres données, mais permettent le traitement distribué des requêtes sur plusieurs serveurs. Les lectures accèdent à tous les shards, et les écritures peuvent être réparties entre eux. Exécutez la requête suivante surchnode1: -
Notez qu’une requête sur
dist_tablerenvoie les quatre lignes de données provenant des deux shards :
Résumé
Configuration de ClickHouse Keeper avec des chemins uniques
Cette page ne concerne pas ClickHouse Cloud. La procédure décrite ici est automatisée dans les services ClickHouse Cloud.
Description
{uuid}
pour créer des entrées uniques dans ClickHouse Keeper ou ZooKeeper. Des
chemins uniques sont utiles lorsque vous créez et supprimez des tables
fréquemment, car cela évite d’avoir à attendre plusieurs minutes que le nettoyage automatique de Keeper
supprime les entrées de chemin, puisque chaque fois qu’un chemin est créé, un nouveau uuid est utilisé
dans ce chemin ; les chemins ne sont jamais réutilisés.
Environnement d’exemple
Exemple de configuration du cluster :
Procédures pour configurer les tables afin d’utiliser {uuid}
- Configurez les macros sur chaque serveur exemple pour le serveur 1 :
Notez que nous définissons des macros pour
shard et replica, mais que {uuid} n’est pas défini ici — il est intégré et n’a pas besoin d’être défini.- Créer une base de données
- Créez une table sur le cluster à l’aide des macros et de
{uuid}
- Créez une table distribuée
Test
- Insérez des données dans le premier nœud (par exemple
chnode1)
- Insérez des données sur le deuxième nœud (par ex.,
chnode2)
- Consulter les enregistrements à l’aide d’une table distribuée
Alternatives
{uuid}
- Définir le chemin par défaut pour les tables sur chaque nœud
- Créez la table sans paramètres explicites :
- Vérifiez qu’il a bien repris les paramètres de la configuration par défaut
Dépannage
La base de données doit être
Atomic ; lors d’une mise à niveau depuis une version précédente, la
base de données default est probablement de type Ordinary.Reconfiguration dynamique de ClickHouse Keeper
Cette page ne concerne pas ClickHouse Cloud. La procédure décrite ici est automatisée dans les services ClickHouse Cloud.
Description
reconfig
pour la reconfiguration dynamique du cluster si keeper_server.enable_reconfiguration est activé.
Si ce paramètre est désactivé, vous pouvez reconfigurer le cluster en modifiant manuellement la section
raft_configuration
de la réplique. Veillez à modifier les fichiers sur toutes les répliques, car seul le leader appliquera les modifications.
Vous pouvez également envoyer une requête reconfig via n’importe quel client compatible avec ZooKeeper./keeper/config contient la dernière configuration du cluster validée au format suivant :
- Chaque entrée de serveur est séparée par un saut de ligne.
server_typevaut soitparticipant, soitlearner(learner ne participe pas à l’élection du leader).server_priorityest un entier positif ou nul indiquant quels nœuds doivent être prioritaires lors de l’élection du leader. Une priorité de 0 signifie qu’un serveur ne sera jamais leader.
reconfig pour ajouter de nouveaux serveurs, supprimer des serveurs existants et modifier la priorité de serveurs existants. Voici quelques exemples (avec clickhouse-keeper-client) :
kazoo :
joining doivent être au format de serveur décrit ci-dessus. Les entrées de serveur doivent être séparées par des virgules.
Lors de l’ajout de nouveaux serveurs, vous pouvez omettre server_priority (la valeur par défaut est 1) et server_type (la valeur par défaut
est participant).
Si vous souhaitez modifier la priorité d’un serveur existant, ajoutez-le à joining avec la priorité cible.
L’hôte, le port et le type du serveur doivent correspondre à ceux de la configuration du serveur existante.
Les serveurs sont ajoutés et supprimés dans l’ordre d’apparition dans joining et leaving.
Toutes les mises à jour de joining sont traitées avant celles de leaving.
Il existe quelques points à connaître concernant l’implémentation de la reconfiguration de Keeper :
-
Seule la reconfiguration incrémentielle est prise en charge. Les requêtes avec un
new_membersnon vide sont refusées. L’implémentation de ClickHouse Keeper s’appuie sur l’API NuRaft pour modifier dynamiquement les membres. NuRaft permet d’ajouter un seul serveur ou de supprimer un seul serveur, un à la fois. Cela signifie que chaque modification de la configuration (chaque partie dejoining, chaque partie deleaving) doit être décidée séparément. Il n’existe donc pas de reconfiguration en bloc, car cela serait trompeur pour les utilisateurs finaux. Il n’est pas non plus possible de modifier le type de serveur (participant/learner), car NuRaft ne le prend pas en charge, et le seul moyen serait de supprimer puis de rajouter le serveur, ce qui serait là encore trompeur. -
Vous ne pouvez pas utiliser la valeur
znodestatrenvoyée. -
Le champ
from_versionn’est pas utilisé. Toutes les requêtes avecfrom_versiondéfini sont refusées. Cela est dû au fait que/keeper/configest un nœud virtuel, ce qui signifie qu’il n’est pas stocké dans le stockage persistant, mais généré à la volée à partir de la configuration de nœud spécifiée pour chaque requête. Cette décision a été prise afin de ne pas dupliquer les données, puisque NuRaft stocke déjà cette configuration. -
Contrairement à ZooKeeper, il n’existe aucun moyen d’attendre la reconfiguration du cluster en soumettant une commande
sync. La nouvelle configuration sera à terme appliquée, mais sans aucune garantie de délai. -
La commande
reconfigpeut échouer pour diverses raisons. Vous pouvez vérifier l’état du cluster et voir si la mise à jour a été appliquée.
Conversion d’un Keeper mono-nœud en cluster
- IMPORTANT : les nouveaux nœuds doivent être ajoutés par lots inférieurs au quorum actuel, sinon ils éliront un leader entre eux. Dans cet exemple, ils sont ajoutés un par un.
- Le nœud Keeper existant doit avoir le paramètre de configuration
keeper_server.enable_reconfigurationactivé. - Démarrez un deuxième nœud avec la nouvelle configuration complète du cluster Keeper.
- Une fois démarré, ajoutez-le au nœud 1 à l’aide de
reconfig. - Démarrez ensuite un troisième nœud et ajoutez-le de la même manière à l’aide de
reconfig. - Mettez à jour la configuration de
clickhouse-serveren y ajoutant le nouveau nœud Keeper, puis redémarrez-le pour appliquer les modifications. - Mettez à jour la configuration Raft du nœud 1 et, si nécessaire, redémarrez-le.
Fonctionnalités non prises en charge
createne prend pas en charge le retour de l’objetStatcreatene prend pas en charge TTLaddWatchne fonctionne pas avec les watchesPERSISTENTremoveWatchetremoveAllWatchesne sont pas pris en chargesetWatchesn’est pas pris en charge- La création de znodes de type
CONTAINERn’est pas prise en charge - L’authentification SASL n’est pas prise en charge