[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for MySQL®](../index.md) > [Концепции](index.md) > Репликация

# Репликация в Managed Service for MySQL®

В кластерах Managed Service for MySQL® используется [полусинхронная репликация](https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html): по умолчанию мастер ожидает завершения транзакции хотя бы на одной реплике.

{% note info %}

Число реплик, требуемых для завершения транзакции, можно изменить в настройке [Rpl semi sync master wait for slave count](settings-list.md#setting-rpl-wait-slave-count).

{% endnote %}

## Управление схемой репликации {#replication}

### Рекомендуемая конфигурация кластера {#replication-auto}


{% note info %}

В [регионе Казахстан](../../overview/concepts/region.md) доступна только [зона доступности](../../overview/concepts/geo-scope.md) `kz1-a`.

{% endnote %}


После создания кластера MySQL® из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.

Пример конфигурации кластера с автоматической репликацией:

![MMY replicas auto control](../../_assets/mdb/mmy-replicas-auto.svg)

Здесь хост-мастер и две реплики размещены в разных зонах доступности. В этом случае:

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

Если реплика и мастер находятся в разных зонах доступности, то задержка подтверждения транзакции (latency) будет не меньше, чем время передачи данных туда и обратно (Round-Trip Time, RTT) между дата-центрами, которые размещены в этих зонах доступности. В результате при записи в один поток и включенном режиме [AUTOCOMMIT](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_autocommit) производительность кластера может существенно снижаться. Чтобы достигнуть максимальной производительности, рекомендуется записывать в несколько потоков, где это возможно, а также [отключать AUTOCOMMIT](https://dev.mysql.com/doc/refman/8.0/en/commit.html) и группировать запросы в транзакции.

В кластере Managed Service for MySQL® используется механизм автоматического выбора и переключения на новый мастер. При выходе из строя хоста-мастера одна из реплик становится новым мастером.

Подробнее о процессе выбора мастера смотрите в подразделе [Выбор мастера при выходе из строя основного мастера](#master-failover).

### Ручное управление конфигурацией кластера {#manual-source}

При ручном управлении для любой реплики кластера источником репликации могут выступать другие хосты в кластере. Реплики, в которых вручную [установлен источник репликации](../operations/hosts.md#update), называются _каскадными_. Для каскадных реплик применяется асинхронная репликация с хоста-источника. Поэтому каскадная реплика не может стать мастером при выходе из строя или ручном переключении хоста-мастера.

Если хост-источник не отвечает, каскадная реплика временно переключается на мастер, пока хост-источник не станет снова доступным.

{% note info %}

Кластер из двух хостов, один из которых — каскадная реплика, не является [высокодоступным](high-availability.md).

{% endnote %}

Пример конфигурации кластера с каскадной репликацией и хостами, размещенными в двух зонах доступности:

![MMY replicas auto control](../../_assets/mdb/mmy-cascade-replicas.svg)

Назначьте для хостов кластера источник репликации, чтобы:

- Полностью управлять процессом репликации в кластере и не использовать автоматическую репликацию.
- Настроить каскадную репликацию для кластера MySQL® с древовидной топологией, в котором часть реплик будет управляться автоматически средствами Managed Service for MySQL®, а часть — вручную. Это снизит нагрузку на сеть хоста-мастера.
- Выделить часть реплик под аналитическую нагрузку, так как они гарантированно не станут мастером.

## Выбор мастера при выходе из строя основного мастера {#master-failover}

Если хост-мастер выйдет из строя, то новым мастером станет любой из хостов кластера, доступных для репликации. Чтобы повлиять на процесс выбора мастера в кластере MySQL®, [установите нужные значения приоритета](../operations/hosts.md#update) для хостов кластера. Мастером будет выбран хост с наибольшим приоритетом. Если в кластере есть несколько хостов с максимальным приоритетом, будет выбран хост с наименьшим отставанием от мастера. Хосты с отставанием большим, чем величина настройки [Mdb priority choice max lag](settings-list.md#setting-mdb-priority-choice-max-lag) (по умолчанию 60 с), исключаются из выбора.

Задать приоритет хоста можно:

* при [создании кластера](../operations/cluster-create.md) с помощью CLI, [API](../../glossary/rest-api.md) или Terraform;
* при [изменении настроек хоста](../operations/hosts.md#update).

Наименьший приоритет — `0` (по умолчанию), наивысший — `100`.

Также вы можете запустить выборы нового мастера или назначить эту роль одной из реплик [вручную](../operations/update.md#start-manual-failover).

## Примеры использования {#examples}

* [Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer](../tutorials/cdc-data-transfer.md)
* [Миграция данных из Managed Service for MySQL® в Yandex MPP Analytics for PostgreSQL с помощью Yandex Data Transfer](../tutorials/mmy-to-mgp.md)
* [Миграция базы данных из Managed Service for MySQL® в сторонний кластер MySQL®](../tutorials/mmy-to-mysql-migration.md)
* [Миграция данных из Yandex Managed Service for PostgreSQL в Managed Service for MySQL® с помощью Yandex Data Transfer](../tutorials/mpg-to-mmy.md)
* [Миграция базы данных из MySQL® в ClickHouse® с помощью Yandex Data Transfer](../tutorials/mysql-to-clickhouse.md)