> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# paramètres de session load_balancing_*

> Paramètres de session ClickHouse du groupe généré load_balancing_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Type</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Par défaut</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Modifiable sans redémarrage
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Ces paramètres sont disponibles dans [system.settings](/docs/fr/reference/system-tables/settings) et sont générés automatiquement à partir du [code source](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="load_balancing">
  ## load\_balancing
</div>

<SettingsInfoBlock type="LoadBalancing" default_value="random" />

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 :

* [Random](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-random) (par défaut)
* [nom d’hôte le plus proche](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-nearest_hostname)
* [distance de Levenshtein du nom d’hôte](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-hostname_levenshtein_distance)
* [plus long préfixe commun du nom d’hôte](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_prefix)
* [plus long suffixe commun du nom d’hôte](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_suffix)
* [dans l’ordre](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-in_order)
* [premier ou aléatoire](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-first_or_random)
* [Round robin](/docs/fr/reference/settings/session-settings/load-balancing#load_balancing-round_robin)

Voir aussi :

* [distributed\_replica\_max\_ignored\_errors](/docs/fr/reference/settings/session-settings/distributed-replica#distributed_replica_max_ignored_errors)

<div id="load_balancing-random">
  ### Random (par défaut)
</div>

```sql theme={null}
load_balancing = random
```

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.

<div id="load_balancing-nearest_hostname">
  ### Nom d’hôte le plus proche
</div>

```sql theme={null}
load_balancing = nearest_hostname
```

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.

<div id="load_balancing-hostname_levenshtein_distance">
  ### Distance de Levenshtein du nom d’hôte
</div>

```sql theme={null}
load_balancing = hostname_levenshtein_distance
```

Tout comme `nearest_hostname`, mais compare le nom d’hôte à l’aide de la [distance de Levenshtein](https://en.wikipedia.org/wiki/Levenshtein_distance). Par exemple :

```text theme={null}
example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3
```

<div id="load_balancing-hostname_longest_common_prefix">
  ### Plus long préfixe commun du nom d’hôte
</div>

```sql theme={null}
load_balancing = hostname_longest_common_prefix
```

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` :

```text theme={null}
sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1
```

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`.

<div id="load_balancing-hostname_longest_common_suffix">
  ### Plus long suffixe commun du nom d’hôte
</div>

```sql theme={null}
load_balancing = hostname_longest_common_suffix
```

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` :

```text theme={null}
et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15
```

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`.

<div id="load_balancing-in_order">
  ### Dans l’ordre
</div>

```sql theme={null}
load_balancing = in_order
```

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.

<div id="load_balancing-first_or_random">
  ### Premier ou aléatoire
</div>

```sql theme={null}
load_balancing = first_or_random
```

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.

<div id="load_balancing-round_robin">
  ### Round Robin
</div>

```sql theme={null}
load_balancing = 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).

<div id="load_balancing_first_offset">
  ## load\_balancing\_first\_offset
</div>

<SettingsInfoBlock type="UInt64" default_value="0" />

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.