[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for MySQL®](../index.md) > [Концепции](index.md) > Балансировщик нагрузки для хостов

# Балансировщик нагрузки для хостов

Managed Service for MySQL® позволяет использовать внутренний сетевой балансировщик для распределения нагрузки между хостами. Балансировщик работает на четвертом уровне сетевой модели OSI, но использует технологии третьего уровня для ускорения обработки пакетов.

{% note info %}

Функциональность находится на стадии [Preview](../../overview/concepts/launch-stages.md) и предоставляется по запросу в техническую поддержку.

{% endnote %}

Преимущества использования балансировщика:

* Единая точка входа для подключения к хосту-мастеру.
* Равномерное распределение запросов на чтение между репликами с учетом их загрузки.
* Выбор [политики балансировки](#balancing-policies). Например, можно задать `Least connections`, чтобы распределять нагрузку по репликам с наименьшим количеством соединений.
* Минимизация недоступности кластера при переключении мастера или изменении состава реплик.
* Для переключения приложения на новый кластер при восстановлении из резервной копии достаточно заменить один FQDN.

Балансировщик автоматически учитывает изменения топологии кластера: новые реплики включаются в балансировку нагрузки, а удаленные — исключаются.

В архитектуре кластера балансировщик реализован как отдельный сервис, который можно включить при создании кластера. Балансировщику присвоен общий для всех [зон доступности](../../overview/concepts/geo-scope.md) FQDN, который служит единой точкой входа для всех запросов к БД. При этом инстанс балансировщика создается во всех зонах доступности, где расположены хосты кластера.

Балансировщик останавливается и запускается одновременно с остановкой и запуском кластера. Поступающий на балансировщик трафик распределяется по всем хостам кластера, а при добавлении или удалении хостов в кластере они автоматически добавляются или удаляются из балансировки.

Чтобы получить FQDN балансировщика, воспользуйтесь [инструкцией](../operations/load-balancer.md#fqdn).

Схема регулировки сетевого трафика кластера с помощью балансировщика отображена ниже:

![mdb-balancer-routing](../../_assets/mdb/mmy-db-proxy-schema.svg)

{% note warning %}

Самостоятельное создание [Network Load Balancer](../../network-load-balancer/quickstart.md) (NLB) для доступа к кластеру не рекомендуется. Балансировщик, создаваемый автоматически при развертывании кластера, имеет критически важную конфигурацию proxy. Без этой настройки NLB будет блокировать трафик к портам обработчиков, что приведет к потере доступа к кластеру.

{% endnote %}

При включенном балансировщике остается возможность напрямую подключиться к БД по [FQDN хоста](../operations/connect/fqdn.md), минуя балансировщик.

Для анализа состояния и загрузки хостов используется отдельный прокси-сервис на основе [HAProxy](https://www.haproxy.org/). Прокси-сервис разворачивается на каждом хосте и выполняет следующие функции:

* Мониторинг доступности хостов.
* Проверка отставания реплик.
* Проверка роли хоста.

Балансировщик предоставляет несколько особых портов для целевых подключений:

#|
|| **Порт** | **Целевое подключение** ||
|| 3306 | Хост-мастер ||
|| 4307 | Все реплики ||
|| 4306 | Реплики с отставанием меньше предустановленного ||
|| 5307 | Каскадные реплики ||
|#

Трафик с каждого открытого порта балансировщика направляется на прокси-сервис и дальше распределяется по целевым подключениям в зависимости от номера порта.

Например, чтобы распределять запросы на чтение только по репликам, отстающим не более чем на 30 секунд:
  
1. Создайте кластер с включенным балансировщиком и укажите в настройках порта `4306` величину отставания реплик 30 секунд.
1. Укажите в настройках вашего приложения строку подключения к БД с FQDN балансировщика и портом `4306`.

## Политики балансировки {#balancing-policies}

Вы можете настраивать поведение балансировщика при распределении запросов по репликам кластера с помощью политик балансировки. Политика указывается для всех типов целевых подключений к репликам при создании кластера.

Доступны следующие политики:

* `Round Robin` — выбор реплики в соответствии с политикой [Round-Robin](https://ru.wikipedia.org/wiki/Round-robin_(алгоритм)).
* `Least connections` — выбор реплики с наименьшим числом соединений.
* `Localized Round Robin` — при выборе реплики в соответствии с политикой Round-Robin приоритет отдается репликам, расположенным в той же зоне доступности, что и инстанс балансировщика, на который поступил запрос.