All Products
Search
Document Center

ApsaraDB RDS:Upgrade the major engine version

Last Updated:Jan 30, 2024

ApsaraDB RDS allows you to upgrade the major engine version of an ApsaraDB RDS for MySQL instance in the ApsaraDB RDS console. You can also migrate the data of an RDS instance to a new RDS instance that runs the required major engine version to upgrade the major engine version. For example, you can migrate the data of an RDS instance for which the Transparent Data Encryption (TDE) feature is enabled.

Upgrade methods

Note

If you fail to upgrade the major engine version of your RDS instance by using Method 1, try Method 2.

For more information about how to upgrade the major engine version of an RDS instance that runs a different database engine, see the following topics:

Method 1: Upgrade the major engine version of an RDS instance in the ApsaraDB RDS console

Description

You can perform the following upgrades in the ApsaraDB RDS console:

  • Upgrade from MySQL 5.7 to MySQL 8.0

  • Upgrade from MySQL 5.6 to MySQL 5.7

  • Upgrade from MySQL 5.5 to MySQL 5.6

Limits

Category

Description

Instances

You can upgrade the major engine version of an RDS instance in the ApsaraDB RDS console only if the instance runs RDS High-availability Edition and uses local disks.

You can upgrade the major engine version of a primary RDS instance that has multiple read-only RDS instances only if the instance types of the read-only RDS instances are the same. The instance types of the read-only RDS instances can be different from the instance type of the primary RDS instance.

A primary RDS instance can have up to eight read-only RDS instances.

We recommend that you release the read-only RDS instances, upgrade the major engine version of the primary RDS instance, and then re-create the read-only RDS instances. For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance and Create a read-only ApsaraDB RDS for MySQL instance.

Before you upgrade the major engine version of an RDS instance, make sure that the RDS instance is in the Running state. If the RDS instance is in a different state, such as Restarting or Creating Network Connection, you must wait until the ongoing task is complete before you can upgrade the major engine version.

If an RDS instance runs RDS High-availability Edition, the major engine version upgrade is supported only when both the primary RDS instance and the secondary RDS instance run as expected and no replication latency exists between the instances. You can check the Node Replication Thread Status and Node Replication Latency(second) metrics on the Monitoring and Alerts page in the ApsaraDB RDS console.

Upgrades

You can upgrade the major engine version of an RDS instance only to the next major engine version. For example, if you want to upgrade MySQL 5.6 to MySQL 8.0, you must first upgrade MySQL 5.6 to MySQL 5.7 and then to MySQL 8.0.

You cannot downgrade the major engine version of an RDS instance after the major engine version is upgraded.

Note

After you upgrade the major engine version of an RDS instance, you cannot use the data backup files that are generated before the upgrade to restore the data of the RDS instance. You can restore the data of the RDS instance only by using the data backup files that are generated after the upgrade.

Encryption

If the SSL encryption feature is enabled for an RDS instance, you must disable the feature before you can upgrade the major engine version of the RDS instance. For more information, see Configure the SSL encryption feature.

If the TDE feature is enabled for an RDS instance, you cannot upgrade the major engine version of the RDS instance in the ApsaraDB RDS console. In this case, you can upgrade the major engine version based on the instructions in Method 2: Upgrade the major engine version of an RDS instance in the DTS console.

If a stored procedure, trigger, view, or function in a database involves features that are not supported by MySQL 8.0, the major engine version upgrade fails. For more information, see Changes in MySQL 8.0.

If more than 200,000 tables are created in databases on an RDS instance, the major engine version upgrade is not supported. You must delete the tables that you no longer require to ensure that the number of tables in the databases does not exceed 200,000 before a major engine version upgrade.

If the storage engine of an RDS instance is MyISAM, MEMORY, TokuDB, Sphinx, or RocksDB, you must change the storage engine of the RDS instance to InnoDB before a major engine version upgrade.

Note

If your RDS instance runs the InnoDB storage engine but some tables still run a different storage engine, you can execute the ALTER TABLE <Table name> engine=InnoDB; statement to change the storage engine of the tables to InnoDB before you upgrade the major engine version of the RDS instance.

Before the upgrade, check whether your workloads depend on system tables in the sys, mysql, information_schema, and performance_schema databases in MySQL 5.7. Some system tables in MySQL 5.7 may change after the major engine version is upgraded to MySQL 8.0. For example, the tables are removed, table names are changed, or table schemas are changed. If your workloads depend on changed tables, errors may occur.

Instance types

If an RDS instance uses a phased-out instance type, you must upgrade the instance type of the RDS instance before you upgrade the major engine version of the RDS instance. For more information, see Primary ApsaraDB RDS for MySQL instance types and Change instance specifications.

Database proxy

If the RDS instance uses a database proxy, the major engine version upgrade is supported only when the database proxy version is 1.13.41 or later. If the database proxy version does not meet the requirement, you must upgrade the database proxy version before you upgrade the major engine version of the RDS instance.

For more information about how to upgrade the database proxy version, see Upgrade the database proxy version of an ApsaraDB RDS for MySQL instance.

Important

The system first upgrades the secondary RDS instance, performs a primary/secondary switchover, and then upgrades the original primary RDS instance. During the upgrade, your database system may become unavailable for up to 5 minutes. We recommend that you upgrade the major engine version during off-peak hours.

Preparations

  • Make sure that you understand the differences between the current major engine version and the major engine version to which you want to upgrade. Before an upgrade, we recommend that you create an RDS instance that runs the required major engine version and test the syntax to ensure that the features and syntax that are used by your application are supported in the new major engine version. For example, you can create an RDS instance that runs MySQL 8.0. For more information about the differences between major engine versions, see the following topics:

  • Before you upgrade the major engine version of your RDS instance, we recommend that you understand the benefits of the major engine version to which you want to upgrade. For more information, see Appendix 1: Advantages of MySQL 8.0 over MySQL 5.7 or Appendix 2: Advantages of MySQL 5.7 over MySQL 5.6.

  • We recommend that you clone the original RDS instance before a major engine version upgrade and use the cloned RDS instance to test whether the new major engine version is compatible with your workloads. Make sure that the cloned RDS instance with the new major engine version runs as expected before you upgrade the major engine version of the original RDS instance.

  • Before a major engine version upgrade, check whether full data backup files generated over the last seven days. If no full data backup files are generated over the last seven days, perform a full data backup.

  • When you upgrade the major engine version of an RDS instance, an instance switchover may occur. We recommend that you upgrade the major engine version during off-peak hours or make sure that your application is configured to automatically reconnect to the RDS instance. For more information about the impacts of an instance switchover, see Impacts of an instance switchover.

  • Make sure that the amount of available storage is sufficient before a major engine version upgrade.

  • We recommend that you check the reserved keywords and do not use the reserved keywords when you create user-defined functions (UDFs). For more information, see Reserved keywords of an ApsaraDB RDS for MySQL instance.

  • We recommend that you modify the retention policies for log files. You can increase the retention period and maximum storage usage of log files. For more information, see Retain the backup files of an ApsaraDB RDS for MySQL instance for a long period of time.

  • Before a major engine version upgrade to MySQL 8.0, check whether the comments in your database tables are garbled. Garbled comments are deleted during the upgrade.

    Note

    In 20221231 and later minor engine versions of MySQL 8.0, the loose_upgrade_clear_invalid_comment parameter is introduced. The default value of the parameter is ON. If the parameter is set to ON, the system deletes garbled comments from tables, fields, and indexes during an upgrade to prevent upgrade failures.

  • To ensure the stability and performance of the RDS instance that runs the required major engine version, the system no longer allows you to view or modify the parameters that are deprecated in the later version after the major engine version of the RDS instance is upgraded. Before you upgrade the major engine version of your RDS instance, we recommend that you back up the modification records of related parameters for subsequent operations and auditing.

  1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.
  2. In the Configuration Information section of the Basic Information page, click Upgrade Database.

    Note

    If Upgrade Database is not displayed, check whether the major engine version of the RDS instance meets the upgrade requirements.

  3. In the dialog box that appears, select Switch Immediately or Switch Within Maintenance Window and click OK.

    • Switch Immediately: After the upgrade is complete, the system immediately switches your workloads.

    • Switch Within Maintenance Window: After the upgrade is complete, the system switches your workloads over within the specified maintenance window. For more information, see Set the maintenance window of an ApsaraDB RDS for MySQL instance. You can also click Configure to the right of Maintenance Window to change the maintenance window.

    Note

    During the upgrade, the RDS instance is in the Migrating Version state.

Method 2: Upgrade the major engine version of an RDS instance in the DTS console

If the major engine version of an RDS instance cannot be upgraded in the ApsaraDB RDS console, you can perform the following operations to upgrade the major engine version:

  1. Create an RDS instance that runs the new major engine version. For more information, see Create an ApsaraDB RDS for MySQL instance.

  2. Migrate the data of the original RDS instance to the new RDS instance. For more information, see Migrate data between ApsaraDB RDS for MySQL instances.

  3. Release the original RDS instance. For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

For example, if you want to upgrade the major engine version of an RDS instance that runs MySQL 5.7 and has TDE enabled to MySQL 8.0, you must first create an RDS instance that runs MySQL 8.0 and migrate the data of the original RDS instance to the new RDS instance. After you confirm that your workloads run as expected on the new RDS instance, you can release the original RDS instance.

Important

You must verify that the new major engine version is compatible with your workloads after you upgrade your RDS instance by migrating data. You must also monitor the new RDS instance for a period of time. After you confirm that your workloads run as expected on the new RDS instance, you can release your original RDS instance.

Appendix 1: Advantages of MySQL 8.0 over MySQL 5.7

  • The security of your database system is enhanced. You can manage accounts in a more flexible manner.

  • You can create and manage resource groups.

  • The features of the InnoDB storage engine are enhanced.

  • New character sets, data types, and syntax are supported. Backup locks and optimizer_switch flags are introduced.

  • JSON and XML expressions are enhanced.

  • Optimizers are enhanced.

  • Replication performance is enhanced.

  • Multi-value indexes can be created. Derived condition pushdown is optimized.

  • MySQL grant tables can be read.

  • Resource allocation control is supported.

Appendix 2: Advantages of MySQL 5.7 over MySQL 5.6

  • New features such as password management, account locking, and connection encryption are introduced. These new features help improve the security of your database system.

  • Online DDL operations are supported. For example, you can use RENAME INDEX to rename an index.

  • The scalability of the InnoDB storage engine and the performance of temporary InnoDB tables are optimized to accelerate data loading.

  • JSON expressions are supported.

  • Index Condition Pushdown (ICP) is supported for partitioned tables, and spatial indexes are supported for InnoDB tables.

  • Most of the used parsers, optimizers, and cost models are optimized to improve the maintainability, scalability, and performance of your database system.

  • New character sets are supported. The character sets include the gb18030 character set that is defined in the Chinese National Standard GB 18030-2005: Information technology - Chinese coded character set.

  • The ngram full-text parser plug-in is provided. The plug-in supports Chinese, Japanese, and Korean (CJK).

  • Dump threads are optimized to reduce lock contention and increase throughput.

  • The replication latency is significantly reduced.

  • The sys system database is added to support multiple metrics. These metrics help reduce storage usage and simplify database management.

Appendix 3: Differences between MySQL 5.7 and MySQL 8.0

Note

The following table provides only the major differences between MySQL 5.7 and MySQL 8.0. For more information, see MySQL Release Notes.

Feature

5.7

8.0

GRANT...IDENTIFIED BY PASSWORD

Supported

Not supported

PASSWORD() function

Supported

Not supported

FLUSH QUERY CACHE and RESET QUERY CACHE

Supported

Not supported

Parameters for the SQL_MODE system variable: DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS

Supported

Not supported

GROUP BY for automatic sorting

Supported

Not supported

Syntax that contains the EXTENDED or PARTITIONS keyword

Supported

Not supported

Encryption functions such as ENCODE(), DECODE(), and ENCRYPT()

Supported

Not supported

Functions related to spatial analysis For more information, see Open source MySQL documentation.

Supported

Not supported

Functions that previously accepted either well-known binary (WKB) strings or geometry arguments but no longer accept geometry arguments

Supported

Not supported

Resolution of \N to NULL

Supported

Not supported

PROCEDURE ANALYSE() function

Supported

Not supported

Creation of partitioned tables by using the NDB storage engine

Supported

Not supported

Compression of temporary tables by using the InnoDB storage engine

Supported

Not supported

JSON_APPEND() function

Supported

Not supported

Placing of table partitions in shared tablespaces

Supported

Not supported

ALTER TABLE...UPGRADE PARTITIONING

Supported

Not supported

Appendix 4: Differences between MySQL 5.6 and MySQL 5.7

Note

The following table provides only the major differences between MySQL 5.6 and MySQL 5.7. For more information, see MySQL Release Notes.

Feature

5.6

5.7

CREATE...AS SELECT in global transaction identifier (GTID) mode

Supported

Not supported

Usage of temporary tables when the GTIDs feature is enabled

Supported

Not supported

Configuration of partition keys in partitioned tables

Supported

Not supported

ENGINE_NO_CACHE

Supported

Not supported

Invisible indexes

Supported

Not supported

UPDATE non_affected_rows INSERT

Supported

Not supported

Proxy-related commands

Supported in SET command mode

Supported in Call Procedure mode

TokuDB, Sphinx, RocksDB, and MEMORY storage engines

Supported

Not supported

str_ord() function

Supported

Not supported

raiseerror() function

Supported

Not supported

OPTIMIZE TABLE table ASYNC

Supported

Not supported

ENGINE_NO_CACHE

Supported

Not supported

INFORMATION.TABLE_UTILIZATION table

Supported

Not supported

The requesting_thd_id and blocking_thd_id columns of the INFORMATION_SCHEMA.INNODB_LOCK_WAITS table

Supported

Not supported

INFORMATION_SCHEMA.INNODB_RSEG table

Supported

Not supported

INFORMATION_SCHEMA.INNODB_IO_STATUS table

Supported

Not supported

Column compression

Supported

Not supported

Query Plan Cache

Supported

Not supported

Limit and Union syntax

Parentheses () not required

Parentheses () required

SHOW FULL PROCESSLIST

The memory and query_memory columns are removed from the results that are returned by the SHOW FULL PROCESSLIST statement in MySQL 5.7.

max_statement_time and max_execution_time

The max_statement_time parameter is removed from MySQL 5.7. The max_execution_time parameter is retained in MySQL 5.7.

RDS_SQL_MAX_AFFECTED

The number of rows on which the UPDATE or DELETE statement is executed can no longer be specified by the RDS_SQL_MAX_AFFECTED variable in MySQL 5.7. The number of rows is specified by the rds_sql_max_affected_rows variable.

Performance optimization and adjustment for concurrency control

The following parameters can no longer be used for concurrency control in MySQL 5.7:

  • innodb_adaptive_tickets_algo

  • innodb_min_concurrency_tickets

  • rds_threads_running_ctl_mode

  • rds_threads_running_high_watermark

  • rds_filter_key_cmp_in_order

  • rds_reset_all_filter

  • rds_sql_delete_filter

  • rds_sql_select_filter

  • rds_sql_update_filter

  • rds_strict_concurrency

  • rds_thread_extra_concurrency

  • rds_strict_trx_idle_timeout

  • rds_sql_buf_read_bandwidth

  • rds_sql_buf_read_threshold_bytes

  • rds_sql_buf_write_bandwidth

  • rds_sql_buf_write_threshold_bytes

  • rds_sql_max_iops

Variables used to specify the number of connections

The following variables are deleted from MySQL 5.7:

  • extra_max_connections

  • rds_root_connections

  • rds_sysinfo_connections

  • rds_sysinfo_user_list

Replication-related adjustments

  • Compatibility adjustments in MySQL 5.7:

    • Replication between GTIDs-enabled databases and GTIDs-disabled databases is no longer supported.

    • The sql_slave_skip_counter parameter is not supported when the GTIDs feature is enabled.

    • The CREATE...SELECT statement is no longer supported.

  • Adjustments to secondary RDS instances that run MySQL 5.7:

    • The SHOW SLAVE LAG statement is no longer supported.

    • The SHOW SLAVE STATUS statement no longer supports timeouts.

    • The amount of information that is returned by the SHOW SLAVE STATUS statement is reduced.

    • The sql_thread thread on a secondary RDS instance no longer supports timeouts.

    • The sql_thread thread on a secondary RDS instance can no longer skip specific statements.

  • Adjustments to binary logs in MySQL 5.7:

    • The transmission speed can no longer be adjusted.

    • The rds_rpl_receive_buffer_difftime parameter is no longer supported.

    • The rds_rpl_receive_buffer_size parameter is no longer supported.

Log-related adjustments

The following adjustments are made to error logs in MySQL 5.7:

  • The IP address, user, I/O latency, and network latency are no longer recorded for the SHUTDOWN command.

  • Duplicate keys are no longer supported for table names.

FAQ

  • Why does an instance switchover occur when I upgrade the major engine version of an RDS instance? Does the upgrade cause other serious risks?

    To ensure service stability, the system upgrades the major engine version of the secondary RDS instances. Then, the system switches your workloads over to the secondary RDS instance before it upgrades the major engine version of the primary RDS instance. In this case, a primary/secondary switchover occurs. The major engine version upgrade does not cause other serious risks. For more information about the impacts of a primary/secondary switchover, see Impacts.

  • Does ApsaraDB RDS upgrade the major engine version of the primary RDS instance and the secondary RDS instance at the same time?

    No, ApsaraDB RDS first upgrades the major engine version of the secondary RDS instance, switches your workloads to the secondary RDS instance, and then upgrades the major engine versions of the primary RDS instance.

  • Why am I unable to find the entry point to upgrade the major engine version of my RDS instance that runs RDS Basic Edition in the ApsaraDB RDS console? How do I upgrade the major engine version of the RDS instance?

    You cannot directly upgrade the major engine version of an RDS instance that runs RDS Basic Edition. Therefore, you cannot find the upgrade entry point in the ApsaraDB RDS console. In this case, you need to upgrade your RDS instance from RDS Basic Edition to RDS High-availability Edition and then upgrade the major engine version of your RDS instance. For more information, see Upgrade the RDS edition from RDS Basic Edition to RDS High-availability Edition and Upgrade the major engine version.

    Note
    • You can upgrade the major engine versions only of RDS instances that run RDS High-availability Edition and use local SSDs in the ApsaraDB RDS console.

    • When you upgrade an RDS instance that runs MySQL 5.7 and uses standard SSDs from RDS Basic Edition to RDS High-availability Edition, you can change the storage type of the instance from standard SSD to local SSD.

  • Can I change the configuration items of my RDS instance when I upgrade the major engine version of the RDS instance?

    You cannot change the configuration items of your RDS instance when you upgrade the major engine version of the RDS instance. You can perform other operations on your RDS instance only after the major engine version is upgraded.

  • Does ApsaraDB RDS support the automatic upgrade of a major engine version?

    No, the major engine version of your RDS instance does not support automatic upgrade.

  • Can I downgrade the major engine version of an RDS instance?

    No, you cannot downgrade the major engine version of an RDS instance or roll back the major engine version upgrade.

Related operations

Operation

Description

UpgradeDBInstanceEngineVersion

Upgrades the major engine version of an instance.