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

# Maintenance in Managed Service for MySQL®

Maintenance in Managed Service for MySQL® includes:

* Automatic installation of DBMS updates and patches for hosts (including for stopped clusters).
* Other maintenance activities.

Changing a DBMS version is not part of maintenance. For more information about version changes, see [MySQL® version upgrade](../operations/cluster-version-update.md).

## Maintenance window {#maintenance-window}

You can set the maintenance window when [creating a cluster](../operations/cluster-create.md) or [updating its settings](../operations/update.md):

* The **At any time** option (default) allows performing maintenance at any time.
* The **By schedule** option allows you to select the day of the week and UTC time when the maintenance will be performed. For example, you can choose a time when the cluster is least loaded.

{% note info %}

To view maintenance task information, you need the `managed-mysql.maintenanceTask.viewer` [role](../security/index.md#managed-mysql-maintenanceTask-viewer) or higher.

To manage maintenance tasks, you need the `managed-mysql.maintenanceTask.editor` [role](../security/index.md#managed-mysql-maintenanceTask-editor) or higher.

{% endnote %}

## Maintenance workflow {#maintenance-order}

In Managed Service for MySQL® single-host clusters, a master host undergoes maintenance. Therefore, it may become unavailable in case it is restarted.

In multi-host clusters, the maintenance is run as follows:

1. [Replicas](replication.md) undergo maintenance one by one. The replicas are queued randomly. If a replica needs to be restarted during maintenance, it will become unavailable.
1. Master host undergoes maintenance and gets updated. If the master host needs to restart and becomes unavailable, one of the replicas will assume its role. Once the upgrade is complete, the host with the highest [failover priority](replication.md#master-failover) will become the new master. If the cluster has several hosts with maximum priority, the one with the least lag behind the master will be selected.

    For the master host to preserve its master role after an upgrade, set the highest failover priority for it. You can set failover priority when [creating a cluster](../operations/cluster-create.md) or [updating host settings](../operations/hosts.md#update).

    If you access a cluster using the [FQDN of the master host](../operations/connect/fqdn.md), the cluster may become unavailable. To make your application continuously available, access the cluster using a [special FQDN](../operations/connect/fqdn.md#special-fqdns) that always points to the current master host.