[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for MySQL®](../index.md) > [Concepts](index.md) > Replication

# Replication in Managed Service for MySQL®

Managed Service for MySQL® clusters use [semi-sync replication](https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html): by default, the master waits for a transaction to be completed in at least one replica.

{% note info %}

You can change the number of replicas required for a transaction to complete in the [Rpl semi sync master wait for slave count](settings-list.md#setting-rpl-wait-slave-count) setting.

{% endnote %}

## Managing replication procedures {#replication}

### Recommended cluster configuration {#replication-auto}


Once you create a MySQL® cluster with multiple hosts, it contains one master host and replicas. Replicas use the master host as a replication source.

Here is an example of an auto replicated cluster configuration:

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

In this example, a master and two replicas are located in different availability zones. In which case:

* Each transaction is saved to a minimum of two hosts.
* The cluster remains available for two consecutive host failures in one of the availability zones.

If a replica and the master are located in different availability zones, the transaction commit latency cannot be less than the round-trip time (RTT) between data centers located in these availability zones. As a result, for single-thread writes with [AUTOCOMMIT](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_autocommit) enabled, the cluster performance may drop considerably. For maximum performance, we recommend using multiple threads for write operations where possible, as well as disabling [AUTOCOMMIT](https://dev.mysql.com/doc/refman/8.0/en/commit.html) and grouping queries into transactions.

Managed Service for MySQL® clusters support automatic selection and failover to a new master. If the master host fails, one of its replicas becomes a new master.

For more information on master host selection, see [Selecting a master if the primary master fails](#master-failover).

### Manual cluster configuration management {#manual-source}

With manual management, other cluster hosts may serve as replication sources for any cluster replica. Replicas that have their [replication sources set](../operations/hosts.md#update) manually are referred to as _cascading_ replicas. Cascading replicas use asynchronous replication from a source host. Therefore, a cascading replica cannot become the master if the master host fails or is switched over manually.

If the source host is not responding, a cascading replica temporarily becomes the master until the source host is available again.

{% note info %}

A cluster of two hosts where one is cascading replica is not [highly available](high-availability.md).

{% endnote %}

Here is an example of cluster configuration with cascading replication and hosts in two availability zones:

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

Assigning a replication source for the cluster hosts allows you to:

- Fully manage the replication process in the cluster without using automatic replication.
- Configure cascading replication for a MySQL® cluster with a tree topology, in which some replicas are managed automatically using Managed Service for MySQL® tools and others manually. This will reduce the load on the master host's network.
- Allocate some replicas for analytical load, since they will not become a master under any condition.

## Selecting a master if the primary master fails {#master-failover}

If the master host fails, any of the cluster hosts available for replication may become a new master. To influence master selection in a MySQL® cluster, [set your preferred priority values](../operations/hosts.md#update) for the cluster hosts. The host with the highest priority will become the master. In a cluster with multiple hosts of equal priority, the one with the least lag behind the master will be selected. Hosts lagging more than the value of the [Mdb priority choice max lag](settings-list.md#setting-mdb-priority-choice-max-lag) setting (60 seconds by default) will be excluded from the selection.

You can set host priority:

* When [creating a cluster](../operations/cluster-create.md) with the CLI, API, or Terraform.
* When [changing the host settings](../operations/hosts.md#update).

The lowest priority is `0` (default), while the highest one is `100`.

You can also initiate master failover or assign this role to one of the replicas [manually](../operations/update.md#start-manual-failover).

## Use cases {#examples}

* [Transferring data to Yandex Managed Service for Apache Kafka® using Yandex Data Transfer](../tutorials/cdc-data-transfer.md)
* [Migrating data from Managed Service for MySQL® to Yandex MPP Analytics for PostgreSQL using Yandex Data Transfer](../tutorials/mmy-to-mgp.md)
* [Migrating a database from Managed Service for MySQL® to a third-party MySQL® cluster](../tutorials/mmy-to-mysql-migration.md)
* [Migrating data from Yandex Managed Service for PostgreSQL to Managed Service for MySQL® using Yandex Data Transfer](../tutorials/mpg-to-mmy.md)
* [Migrating a database from MySQL® to ClickHouse® using Yandex Data Transfer](../tutorials/mysql-to-clickhouse.md)