MySQL® version upgrade
You can upgrade a Managed Service for MySQL® cluster to any supported minor or major version.
In single-host clusters, only the master host is taken offline for upgrades. Unlike multi-host clusters, these clusters are not available for reads and writes during an upgrade. After the DBMS resumes operation, it will take time to warm up the buffer pool, which may temporarily affect the query performance, particularly for large, heavily indexed databases.
In multi-host clusters, upgrades proceed in this sequence:
-
Replicas are taken offline for an upgrade and stopped, one by one. The replicas are queued randomly. Following the upgrade, the replicas get back online. Read performance may temporarily degrade at this stage, as some replicas will be unavailable.
-
The master becomes read-only. One of the replicas is promoted to master and becomes write-enabled. This ensures the cluster is upgraded with minimal downtime.
-
The original master is taken offline, upgraded, and then brought online as a replica. The master does not switch back to avoid the risk of extra failovers.
Note
In MySQL® 8.0, replica failover is more reliable and efficient due to improved metadata processing.
For information on minor version upgrades and host maintenance, see Maintenance.
Alert
-
After the DBMS upgrade, you cannot revert the cluster to the previous version.
-
Upgrade your cluster during low load periods to reduce risks and minimize the impact on users.
-
Whether a MySQL® version upgrade succeeds depends on many factors, such as the following:
- Cluster settings and specific configurations.
- Nature and structure of stored data.
- MySQL® features deployed (especially JSON functionality and full-text search).
- App compatibility with the new version.
- Correctness of stored procedures and triggers.
- Current database state and data quality.
We recommend that you start with upgrading a test cluster with the same data and configuration.
Before upgrading a version
When getting ready for an upgrade, a comprehensive approach to testing and compatibility analysis is of particular importance. Our experience shows that most upgrade issues can be prevented in advance:
-
Check the MySQL® release notes
to learn how upgrades may affect your applications.Examples of changes in MySQL® 8.0
-
Changes in the behavior of SQL functions and query optimizer:
-- Example of a command for analyzing a query execution plan EXPLAIN ANALYZE SELECT * FROM <table_name> WHERE complex_condition ORDER BY <field>; -
Deprecated and removed features, especially related to security:
-- Checking authentication SELECT user, host, plugin FROM mysql.user WHERE user NOT LIKE 'mysql.%'; -
Changes in full-text search and JSON processing:
-- Checking the use of JSON functions SELECT COUNT(*) FROM information_schema.routines WHERE routine_definition LIKE '%JSON%'; -
New default values for DBMS settings.
-
Aspects of working with metadata and temporary tables.
-
-
Try upgrading a test cluster.
-
Deploy a test cluster from a backup of the main cluster using the
PRESTABLEenvironment and upgrade it to the required version. -
Make sure critical queries and stored procedures work as expected.
-
Check the features that use JSON and full-text search.
-
Run a load test:
-- Monitoring performance during tests SELECT EVENT_NAME, COUNT_STAR, AVG_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest WHERE SCHEMA_NAME = '<DB_name>' ORDER BY AVG_TIMER_WAIT DESC LIMIT 10;
-
-
Create a backup of the main cluster immediately before upgrading.
-
Ensure high availability of the cluster:
- Make sure the main and test clusters have at least one master and one replica. Add hosts as needed.
- Optionally, check the replication status and lag:
-- Checking the replication status SHOW SLAVE STATUS\G -- Checking the replication lag SELECT SUBSTRING_INDEX(HOST, ':', 1) AS slave_host, SUBSTRING_INDEX(HOST, ':', -1) AS slave_port, SECONDS_BEHIND_MASTER, SLAVE_IO_RUNNING, SLAVE_SQL_RUNNING FROM information_schema.PROCESSLIST WHERE COMMAND = 'Binlog Dump';
Updating the MySQL® version
- Go to Managed Service for MySQL.
- Select your cluster from the list and click
Edit. - In the Version field, select the new version number.
- Click Save changes.
As soon as you run the upgrade, the cluster status will change to Updating. Wait for the operation to complete and then check the cluster version.
The time required for an upgrade depends on multiple factors, such as the amount of data or the number of databases in your cluster. Usually, an upgrade takes a few minutes; for large databases, it can take 10 minutes or more.
If you do not have the Yandex Cloud CLI installed yet, install and initialize it.
By default, the CLI uses the folder specified when creating the profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also set a different folder for any specific command using the --folder-name or --folder-id parameter.
To upgrade a MySQL® version:
-
Get the list of your MySQL® clusters using this command:
yc managed-mysql cluster list -
Get the details of the cluster in question and check its MySQL® version in the
config.versionsetting:yc managed-mysql cluster get <cluster_name_or_ID> -
Run the MySQL® upgrade:
yc managed-mysql cluster update <cluster_name_or_ID> \ --mysql-version <new_version_number>
The time required for an upgrade depends on multiple factors, such as the amount of data or the number of databases in your cluster. Usually, an upgrade takes a few minutes; for large databases, it can take 10 minutes or more.
-
Open the current Terraform configuration file describing your infrastructure.
For information on how to create such a file, see Creating a cluster.
-
Add the
versionfield to theyandex_mdb_mysql_clusterresource or change the field value if it already exists:resource "yandex_mdb_mysql_cluster" "<cluster_name>" { ... version = "<MySQL®_version>" ... } -
Make sure the settings are correct.
-
In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure.
-
Run this command:
terraform validateTerraform will show any errors found in your configuration files.
-
-
Confirm updating the resources.
-
Run this command to view the planned changes:
terraform planIf you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.
-
If everything looks correct, apply the changes:
-
Run this command:
terraform apply -
Confirm updating the resources.
-
Wait for the operation to complete.
-
-
For more information, see this Terraform provider article.
Timeouts
The Terraform provider sets the following timeouts for Managed Service for MySQL® cluster operations:
- Creating a cluster, including by restoring it from a backup: 15 minutes.
- Updating a cluster, including the MySQL® version update: 60 minutes.
- Deleting a cluster: 15 minutes.
Operations exceeding the timeout are aborted.
How do I change these limits?
Add the timeouts section to the cluster description, such as the following:
resource "yandex_mdb_mysql_cluster" "<cluster_name>" {
...
timeouts {
create = "1h30m" # 1 hour 30 minutes
update = "2h" # 2 hours
delete = "30m" # 30 minutes
}
}
-
Get an IAM token for API authentication and set it as an environment variable:
export IAM_TOKEN="<IAM_token>" -
Call the Cluster.update method, e.g., via the following cURL
request:Warning
The API method will assign default values to all the parameters of the object you are modifying unless you explicitly provide them in your request. To avoid this, list the settings you want to change in the
updateMaskparameter as a single comma-separated string.curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://mdb.api.cloud.yandex.net/managed-mysql/v1/clusters/<cluster_ID>' \ --data '{ "updateMask": "configSpec.version", "configSpec": { "version": "<MySQL®_version>" } }'Where:
-
updateMask: Comma-separated list of settings you want to update.Here, we provide only one setting.
-
configSpec.version: New MySQL® version.
You can get the cluster ID with the list of clusters in the folder.
-
-
View the server response to make sure your request was successful.
-
Get an IAM token for API authentication and set it as an environment variable:
export IAM_TOKEN="<IAM_token>" -
Clone the cloudapi
repository:cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapiBelow, we assume the repository contents are stored in the
~/cloudapi/directory. -
Call the ClusterService/Update method, e.g., via the following gRPCurl
request:Warning
The API method will assign default values to all the parameters of the object you are modifying unless you explicitly provide them in your request. To avoid this, list the settings you want to change in the
update_maskparameter as an array ofpaths[]strings.Format for listing settings
"update_mask": { "paths": [ "<setting_1>", "<setting_2>", ... "<setting_N>" ] }grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/mdb/mysql/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "<cluster_ID>", "update_mask": { "paths": [ "config_spec.version" ] }, "config_spec": { "version": "<MySQL®_version>" } }' \ mdb.api.cloud.yandex.net:443 \ yandex.cloud.mdb.mysql.v1.ClusterService.UpdateWhere:
-
update_mask: List of settings you want to update as an array of strings (paths[]).Here, we provide only one setting.
-
config_spec.version: New MySQL® version.
You can get the cluster ID with the list of clusters in the folder.
-
-
Check the server response to make sure your request was successful.
The time required for an upgrade depends on multiple factors, such as the amount of data or the number of databases in your cluster. Usually, an upgrade takes a few minutes; for large databases, it can take 10 minutes or more.
Examples
Let's consider the following example showing how to upgrade a cluster from version 5.7 to 8.0. This use case is particularly interesting as it covers the most significant changes in the MySQL® architecture.
-
Get the list of clusters with their IDs and names:
yc managed-mysql cluster listResult example:
+----------------------+------------+---------------------+--------+---------+ | ID | NAME | CREATED AT | HEALTH | STATUS | +----------------------+------------+---------------------+--------+---------+ | c9q8p8j2gaih******** | mysql406 | 2021-10-23 12:44:17 | ALIVE | RUNNING | +----------------------+------------+---------------------+--------+---------+ -
Get detailed information about a specific cluster:
yc managed-mysql cluster get mysql406The output will show the current MySQL® version:
id: c9q8p8j2gaih******** ... config: version: "5.7" ... -
Start the upgrade to 8.0:
yc managed-mysql cluster update mysql406 --mysql-version 8.0As soon as you run this command, the system will start upgrading your cluster. It may take anywhere from a few minutes to an hour depending on the database size and cluster configuration.
-
Open the current Terraform configuration file describing your infrastructure.
-
Set the
versionfield to8.0in theyandex_mdb_mysql_clusterresource:resource "yandex_mdb_mysql_cluster" "<cluster_name>" { ... version = "8.0" ... } -
Make sure the settings are correct:
-
In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure.
-
Run this command:
terraform validateTerraform will show any errors found in your configuration files.
-
-
Apply the changes:
-
Run this command to view the planned changes:
terraform planIf you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.
-
If everything looks correct, apply the changes:
-
Run this command:
terraform apply -
Confirm updating the resources.
-
Wait for the operation to complete.
-
-
Terraform will automatically detect the need for version upgrade and start the process.
After a successful upgrade:
-
Check the status of all critical components:
-- Checking the InnoDB status SHOW ENGINE INNODB STATUS\G -- Checking the replication status SHOW SLAVE STATUS\G -
Make sure your applications work correctly:
- Check the execution time of critical queries.
- Check error statistics.
- Monitor resource usage.
-
Optimize your configuration for the new version:
-- Analyzing buffer pool usage SELECT POOL_ID, POOL_SIZE, FREE_BUFFERS, DATABASE_PAGES FROM information_schema.INNODB_BUFFER_POOL_STATS; -- Checking performance settings SHOW VARIABLES LIKE '%buffer%';
See also
- Technical overview of MySQL® 8.0 features with focus on the new version's changes in terms of performance and functionality.