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

# настройки сеанса load_balancing_*

> Настройки сеанса ClickHouse в автоматически сгенерированной группе 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
  }}>Тип</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>По умолчанию</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Изменяется без перезапуска
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Эти настройки доступны в [system.settings](/docs/ru/reference/system-tables/settings) и автоматически генерируются на основе [исходного файла](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

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

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

Указывает алгоритм выбора реплик, используемый для распределённой обработки запросов.

ClickHouse поддерживает следующие алгоритмы выбора реплик:

* [случайный](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-random) (по умолчанию)
* [близкое имя хоста](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-nearest_hostname)
* [расстояние Левенштейна для имени хоста](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-hostname_levenshtein_distance)
* [Наибольший общий префикс имени хоста](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_prefix)
* [Наибольший общий суффикс имени хоста](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_suffix)
* [заданный порядок](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-in_order)
* [Первый либо случайный](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-first_or_random)
* [Round robin](/docs/ru/reference/settings/session-settings/load-balancing#load_balancing-round_robin)

См. также:

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

<div id="load_balancing-random">
  ### Random (по умолчанию)
</div>

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

Для каждой реплики подсчитывается количество ошибок. Запрос отправляется на реплику с наименьшим числом ошибок, а если таких несколько — на любую из них.
Недостатки: не учитывается близость сервера; если на репликах разные данные, вы также получите разные результаты.

<div id="load_balancing-nearest_hostname">
  ### Наиболее близкое имя хоста
</div>

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

Количество ошибок подсчитывается для каждой реплики. Каждые 5 минут количество ошибок целочисленно делится на 2. Таким образом, для недавнего времени количество ошибок вычисляется с экспоненциальным сглаживанием. Если есть одна реплика с минимальным количеством ошибок (то есть на других репликах ошибки возникали недавно), запрос отправляется на неё. Если есть несколько реплик с одинаковым минимальным количеством ошибок, запрос отправляется на реплику с именем хоста, наиболее похожим на имя хоста сервера в файле конфигурации (по числу различающихся символов в одинаковых позициях, до минимальной длины обоих имён хостов).

Например, example01-01-1 и example01-01-2 различаются в одной позиции, а example01-01-1 и example01-02-2 — в двух.
Этот метод может показаться примитивным, но он не требует внешних данных о топологии сети и не сравнивает IP-адреса, что было бы сложно в случае наших IPv6-адресов.

Таким образом, если есть равноценные реплики, предпочтение отдаётся ближайшей по имени.
Мы также можем предположить, что при отправке запроса на один и тот же сервер при отсутствии сбоев распределённый запрос тоже будет отправляться на одни и те же серверы. Поэтому, даже если на репликах размещены разные данные, запрос будет возвращать в основном одинаковые результаты.

<div id="load_balancing-hostname_levenshtein_distance">
  ### Расстояние Левенштейна для имени хоста
</div>

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

Как и `nearest_hostname`, но сравнивает имена хостов по [расстоянию Левенштейна](https://en.wikipedia.org/wiki/Levenshtein_distance). Например:

```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">
  ### Наибольший общий префикс имени хоста
</div>

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

Как и `nearest_hostname`, но предпочтение отдаётся реплике, чьё имя хоста имеет самый длинный общий префикс с локальным именем хоста (чем длиннее общий префикс, тем выше приоритет). В отличие от `nearest_hostname`, который подсчитывает различающиеся символы позиция за позицией, эта стратегия не сбивается из-за имён хостов, у которых числовые части имеют разную длину. Например, для локального имени хоста `sfe301`:

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

sfe301 sfe10101
3

sfe301 sde505
1
```

Здесь предпочтение отдаётся `sfe10101`, потому что у него самый длинный общий префикс (`sfe`, длина 3) с `sfe301`.

Реплики с одинаковой длиной общего префикса выбираются случайным образом. В частности, если ни одна реплика не имеет общего префикса с локальным именем хоста (все длины общих префиксов равны нулю), эта стратегия работает точно так же, как `random`.

<div id="load_balancing-hostname_longest_common_suffix">
  ### Наибольший общий суффикс имени хоста
</div>

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

Как и `hostname_longest_common_prefix`, но вместо префикса сравнивается самый длинный общий *суффикс*. Это полезно, когда идентификатор центра обработки данных закодирован в виде суффикса имени хоста. Например, для локального имени хоста `et46gtghn.qc.localdomain`:

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

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

Здесь предпочтение отдаётся `ab999.qc.localdomain`, поскольку у него самый длинный общий суффикс (`.qc.localdomain`, длина 15) с `et46gtghn.qc.localdomain`.

Реплики с одинаковой длиной общего суффикса выбираются случайным образом. В частности, если ни одна реплика не имеет общего суффикса с локальным именем хоста (то есть длина всех общих суффиксов равна нулю), эта стратегия работает точно так же, как `random`.

<div id="load_balancing-in_order">
  ### В заданном порядке
</div>

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

К репликам с одинаковым числом ошибок обращаются в том порядке, в котором они указаны в конфигурации.
Этот метод подходит, если вы точно знаете, какая реплика предпочтительнее.

<div id="load_balancing-first_or_random">
  ### Первый либо случайный
</div>

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

Этот алгоритм выбирает первую реплику в наборе или случайную, если первая недоступна. Он эффективен в топологиях с перекрестной репликацией, но бесполезен в других конфигурациях.

Алгоритм `first_or_random` решает проблему алгоритма `in_order`. При использовании `in_order`, если одна реплика выходит из строя, следующая получает двойную нагрузку, тогда как остальные реплики обрабатывают обычный объем трафика. При использовании алгоритма `first_or_random` нагрузка равномерно распределяется между репликами, которые остаются доступными.

Можно явно задать, какая реплика считается первой, с помощью настройки `load_balancing_first_offset`. Это дает больше контроля над перебалансировкой рабочих нагрузок запросов между репликами.

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

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

Этот алгоритм использует политику round-robin для реплик с одинаковым количеством ошибок (учитываются только запросы с политикой `round_robin`).

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

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

Указывает, в какую реплику предпочтительно отправлять запрос при использовании стратегии балансировки нагрузки FIRST\_OR\_RANDOM.