Skip to main content
Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source.

​
load_balancing

Spécifie l’algorithme de sélection des répliques utilisé pour le traitement distribué des requêtes. ClickHouse prend en charge les algorithmes suivants pour la sélection des répliques : Voir aussi :

​
Random (par défaut)

Le nombre d’erreurs est comptabilisé pour chaque réplique. La requête est envoyée à la réplique qui a le moins d’erreurs et, s’il y en a plusieurs, à l’une d’entre elles au hasard. Inconvénients : la proximité du serveur n’est pas prise en compte ; si les répliques contiennent des données différentes, vous obtiendrez également des données différentes.

​
Nom d’hôte le plus proche

Le nombre d’erreurs est compté pour chaque réplique. Toutes les 5 minutes, le nombre d’erreurs est divisé par 2 en division entière. Ainsi, le nombre d’erreurs est calculé sur une période récente avec un lissage exponentiel. S’il existe une réplique avec un nombre minimal d’erreurs (c.-à-d. que des erreurs se sont produites récemment sur les autres répliques), la requête lui est envoyée. S’il existe plusieurs répliques avec le même nombre minimal d’erreurs, la requête est envoyée à la réplique dont le nom d’hôte est le plus proche de celui du serveur dans le fichier de configuration (d’après le nombre de caractères différents aux mêmes positions, jusqu’à la longueur minimale des deux noms d’hôte). Par exemple, example01-01-1 et example01-01-2 diffèrent à une position, tandis que example01-01-1 et example01-02-2 diffèrent à deux positions. Cette méthode peut sembler primitive, mais elle ne nécessite pas de données externes sur la topologie du réseau et ne compare pas les adresses IP, ce qui serait compliqué avec nos adresses IPv6. Ainsi, s’il existe des répliques équivalentes, celle dont le nom est le plus proche est privilégiée. Nous pouvons également supposer que, lorsqu’une requête est envoyée au même serveur, en l’absence de défaillance, une requête distribuée ira elle aussi aux mêmes serveurs. Ainsi, même si des données différentes sont placées sur les répliques, la requête renverra pour l’essentiel les mêmes résultats.

​
Distance de Levenshtein du nom d’hôte

Tout comme nearest_hostname, mais compare le nom d’hôte à l’aide de la distance de Levenshtein. Par exemple :

​
Plus long préfixe commun du nom d’hôte

Comme nearest_hostname, mais la réplique dont le nom d’hôte a le plus long préfixe commun avec le nom d’hôte local est privilégiée (plus le préfixe commun est long, plus la priorité est élevée). Contrairement à nearest_hostname, qui compte les caractères différents position par position, cette stratégie n’est pas perturbée par des noms d’hôte dont les segments numériques ont des longueurs différentes. Par exemple, pour le nom d’hôte local sfe301 :
Ici, sfe10101 est privilégié, car il partage avec sfe301 le plus long préfixe commun (sfe, de longueur 3). Les répliques ayant un préfixe commun de même longueur sont choisies au hasard. En particulier, lorsqu’aucune réplique ne partage de préfixe avec le nom d’hôte local (toutes les longueurs de préfixe commun sont nulles), cette stratégie se comporte exactement comme random.

​
Plus long suffixe commun du nom d’hôte

Comme hostname_longest_common_prefix, mais ici, on compare le plus long suffixe commun au lieu du préfixe. Cela est utile lorsque l’identité du centre de données est encodée dans le suffixe du nom d’hôte. Par exemple, pour le nom d’hôte local et46gtghn.qc.localdomain :
Ici, ab999.qc.localdomain est préféré, car il partage avec et46gtghn.qc.localdomain le suffixe commun le plus long (.qc.localdomain, longueur 15). Les répliques ayant un suffixe commun de même longueur sont choisies au hasard. En particulier, lorsqu’aucune réplique ne partage de suffixe avec le nom d’hôte local (toutes les longueurs de suffixe commun sont nulles), cette stratégie se comporte exactement comme random.

​
Dans l’ordre

Les répliques ayant le même nombre d’erreurs sont consultées dans l’ordre où elles sont spécifiées dans la configuration. Cette méthode convient lorsque vous savez exactement quelle réplique privilégier.

​
Premier ou aléatoire

Cet algorithme choisit la première réplique de l’ensemble, ou une réplique aléatoire si la première n’est pas disponible. Il est efficace dans les topologies de réplication croisée, mais inutile dans les autres configurations. L’algorithme first_or_random résout le problème de l’algorithme in_order. Avec in_order, si une réplique tombe en panne, la suivante reçoit une charge doublée, tandis que les autres répliques continuent de gérer le volume de trafic habituel. Avec l’algorithme first_or_random, la charge est répartie uniformément entre les répliques encore disponibles. Il est possible de définir explicitement quelle réplique est la première à l’aide du paramètre load_balancing_first_offset. Cela offre davantage de contrôle pour rééquilibrer les charges de travail des requêtes entre les répliques.

​
Round Robin

Cet algorithme utilise une politique round-robin entre les répliques ayant le même nombre d’erreurs (seules les requêtes utilisant la politique round_robin sont prises en compte).

​
load_balancing_first_offset

Indique quelle réplique privilégier pour envoyer une requête lorsque la stratégie d’équilibrage de charge FIRST_OR_RANDOM est utilisée.
Dernière modification le 23 juillet 2026