This topic describes how to upgrade the major engine version of an ApsaraDB RDS for MySQL instance. You can directly upgrade the major engine version of an RDS instance from MySQL 5.5 to MySQL 5.6 or from MySQL 5.6 to MySQL 5.7 in the ApsaraDB RDS console. If you want to upgrade an RDS instance between other major engine versions, you must migrate data. For example, this applies if you want to upgrade the major engine version of an RDS instance from MySQL 5.7 to MySQL 8.0.

You can use one of the following methods to upgrade the major engine version of an RDS instance:

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

Limits
  • You can upgrade the major engine version of an RDS instance in the ApsaraDB RDS console only when the instance runs RDS High-availability Edition.
  • Only the upgrade from MySQL 5.5 to MySQL 5.6 and the upgrade from MySQL 5.6 to MySQL 5.7 are supported. You cannot downgrade the major engine version of an RDS instance.
    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.
  • If read-only RDS instances are attached to an RDS instance and the instance types of the read-only RDS instances are different, you cannot upgrade the major engine version of the RDS instance.
  • If read-only RDS instances that use phased-out instance types are attached to an RDS instance, you must change the instance types of the read-only RDS instances to the most recent instance types before you upgrade the major engine version of the RDS instance. For more information, see Change the specifications of an ApsaraDB RDS for MySQL instance.
  • If the SSL encryption feature is enabled for an RDS instance, you cannot upgrade the major engine version of the RDS instance. Before you can upgrade the major engine version of the RDS instance, you must disable the SSL encryption feature.
  • If the Transparent Data Encryption (TDE) feature is enabled for an RDS instance, you cannot upgrade the major engine version of the RDS instance in the ApsaraDB RDS console. For more information, see the "Upgrade the major engine version of an RDS instance by migrating data" section of this topic.
  • You can upgrade the major engine version of an RDS instance only when the RDS instance is a primary RDS instance. If read-only RDS instances are attached to an RDS instance, you cannot upgrade the major engine version of the RDS instance in the ApsaraDB RDS console. For more information, see the "Upgrade the major engine version of an RDS instance by migrating data" section of this topic.
  • If more than 200,000 tables are created on an RDS instance, a major engine version upgrade may fail. We recommend that you delete the tables that you no longer need before a major engine version upgrade.
  • If an RDS instance runs RDS High-availability Edition, a major engine version upgrade is supported only when the RDS instance and its secondary RDS instance run as normal and no replication latency exists between the RDS instance and its secondary RDS instance. You can check the Replication Thread Status of Secondary Instances metric and the Replication Latency of Secondary Instances metric on the Monitoring and Alerts page in the ApsaraDB RDS console.
  • If the storage engine of an RDS instance is MyISAM, MEMORY, TokuDB, Sphinx, or RocksDB, you cannot upgrade the major engine version of the RDS instance. You must change the storage engine of the RDS instance to InnoDB before a major engine version upgrade.
  • 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, wait until the running task is completed before a major engine version upgrade.
  • If an RDS instance uses a phased-out instance type, you cannot upgrade the major engine version of the RDS instance. You must change the instance type of the RDS instance before a major engine version upgrade. For more information, see Change the specifications of an ApsaraDB RDS for MySQL instance.
Notice If you upgrade the major engine version of an RDS instance that runs MySQL 5.6 on RDS High-availability Edition, ApsaraDB RDS performs the upgrade on the RDS instance after ApsaraDB RDS upgrades the major engine version of the secondary RDS instance and performs a primary/secondary switchover. Your database service is unavailable for 5 minutes at most during the upgrade. We recommend that you perform a major engine version upgrade during off-peak hours.
Before you begin
  • We recommended that you familiarize yourself with the differences between the original major engine version and the new major engine version. This way, you can ensure the features and syntaxes that are used by your application are supported in the new major engine version. For more information about the differences between major engine versions, see MySQL 5.7 Release Notes or the "Appendix 2: Differences between MySQL 5.6 and MySQL 5.7" section of this topic.
  • We recommended that you familiarize yourself with the benefits of MySQL 5.7. For more information, see the "Appendix 1: Benefits of MySQL 5.7" section of this topic.
  • We recommend that you clone the original RDS instance before a major engine 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 runs as normal before you upgrade the major engine version of the original RDS instance.
  • Before a major engine version upgrade, check whether a full data backup file has been generated over the most recent seven days. If no full data backup file is generated over the most recent seven days, perform a full data backup.
  • When you upgrade the major engine version of an RDS instance, a transient connection may occur. We recommend that you perform the upgrade during off-peak hours or make sure that your application is configured to automatically reconnect to the RDS instance.
  • Make sure that a sufficient amount of available storage is reserved before a major engine version upgrade.
  • We recommend that you modify the retention policy of binary log files. You can increase the retention period and maximum storage usage of binary log files. For more information, see Retain the backup files of an ApsaraDB RDS for MySQL instance for a long period of time.
  1. Visit the RDS instance list, select a region above, and click the target instance ID.
  2. In the Configuration Information section of the Basic Information page, click Upgrade Database.
    Note If you cannot find the Upgrade Database button, check whether the major engine version of the RDS instance is MySQL 5.5 or MySQL 5.6.
  3. In the dialog box that appears, select Migrate Immediately or Switch Within Maintenance Window and click OK.
    • Migrate Immediately: The upgrade is immediately started.
    • Switch Within Maintenance Window: The upgrade is started within the specified maintenance window. For more information, see Set the maintenance window of an ApsaraDB RDS for MySQL instance. You can also click Change on the right to change the maintenance window.

Upgrade the major engine version of an RDS instance by migrating data

To upgrade the major engine version of an RDS instance that runs MySQL 5.7, perform the following steps:

  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, an RDS instance runs MySQL 5.7 and you want to upgrade the major engine version of the RDS instance to MySQL 8.0. In this case, you must first create an RDS instance that runs MySQL 8.0. Then, you must migrate the data of the original RDS instance to the new RDS instance. After you verify that your workloads run as expected on the new RDS instance, you can release the original RDS instance.

Notice You must verify the compatibility between the new major engine version and your workloads. You must also keep monitoring the new RDS instance for a specific period of time. You can release your original RDS instance only after you confirm that your workloads run as expected on the new RDS instance.

Appendix 1: Benefits of MySQL 5.7

MySQL 5.7 provides the following advantages over MySQL 5.6:

  • The security of an RDS instance is improved. New features such as password management, account locking, and connection encryption are added.
  • Online DDL operations are supported. For example, MySQL 5.7 supports the RENAME INDEX clause that allows you to rename an index.
  • The scalability of the InnoDB storage engine and the performance of temporary InnoDB tables are optimized to increase data loading speeds.
  • The JSON format is 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 an RDS instance.
  • New character sets are supported. These include the Chinese standard character set named GB18030.
  • A built-in ngram full-text parser plug-in that supports Chinese, Japanese, and Korean (CJK) is provided.
  • Dump threads on primary RDS instances are optimized to reduce lock contention and increase throughput.
  • The replication latency is reduced.
  • The sys system database is added to support multiple monitoring metrics. These metrics help you reduce the storage usage and improve the ease of use.

Appendix 2: 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 5.7 Release Notes.
Feature MySQL 5.6 MySQL 5.7
Usage of CREATE...AS SELECT when the global transaction identifiers (GTIDs) feature is enabled 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.
SELECT FOR UPDATE WAIT 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 column and the blocking_thd_id column 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 column and the query_memory column are removed from the results that are returned by the SHOW FULL PROCESSLIST statement.
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 that are used to specify the number of connections The following variables are removed 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 logged for the SHUTDOWN command.
  • Duplicate keys are no longer supported for table names.

FAQ

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

For service stability purposes, ApsaraDB RDS upgrades the major engine version of the secondary RDS instances and switches your workloads to the secondary RDS instance before ApsaraDB RDS upgrades the major engine version of the primary RDS instance. During the switchover, a transient connection occurs. The major engine upgrade does not cause other serious risks.

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

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.

Related operations

Operation Description
Upgrade the major engine version of an ApsaraDB RDS for MySQL instance Upgrades the major engine version of an ApsaraDB RDS instance.