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

Эти настройки доступны в system.settings и автоматически генерируются на основе исходного файла.

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

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

• случайный (по умолчанию)
• близкое имя хоста
• расстояние Левенштейна для имени хоста
• Наибольший общий префикс имени хоста
• Наибольший общий суффикс имени хоста
• заданный порядок
• Первый либо случайный
• Round robin

См. также:

• distributed_replica_max_ignored_errors

load_balancing = random

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

load_balancing = nearest_hostname

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

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

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

load_balancing = hostname_levenshtein_distance

Как и nearest_hostname, но сравнивает имена хостов по расстоянию Левенштейна. Например:

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

load_balancing = hostname_longest_common_prefix

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

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

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

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

load_balancing = hostname_longest_common_suffix

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

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

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

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

load_balancing = in_order

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

load_balancing = first_or_random

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

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

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

load_balancing = round_robin

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

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