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 ApsaraDB RDS for MySQL instance to a new RDS instance that uses 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.

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

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 SSDs.
If read-only RDS instances are attached to a primary 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.
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 running task is complete before you can upgrade the major engine version.
If an RDS instance runs RDS High-availability Edition, a 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 primary RDS instance and the secondary RDS instance. You can check the Replication Thread Status of Secondary Instances and Replication Latency of Secondary Instances 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 Disable SSL encryption.
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. For more information, see Method 2: Upgrade the major engine version of an RDS instance by migrating data.
Database access If an event is created in a database on an RDS instance that runs MySQL 5.7, you cannot upgrade the major engine version of the RDS instance from MySQL 5.7 to MySQL 8.0. You must delete the event, upgrade the major engine version, and then re-create the event.
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 may fail. We recommend that you delete the tables that you no longer require 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.
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 Change the specifications of an ApsaraDB RDS for MySQL instance.
Notice ApsaraDB RDS 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 perform a major engine version upgrade during off-peak hours.
Before you begin
  • Make sure that you understand the differences between the current major engine version and the major engine version to which you want to upgrade. We recommended that you create an RDS instance that runs MySQL 8.0 and test the syntax. This way, you can ensure that the features and syntax 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 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 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 expected 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 is 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, transient connections 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.
  • Make sure that the amount of available storage is sufficient before a major engine version upgrade.
  • We recommend that you modify the retention policies for 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. Access RDS Instances, select a region at the top, and then click the ID of the target RDS instance.
  2. In the Configuration Information section of the Basic Information page, click Upgrade Database.
    Note If Upgrade Database is not displayed, you must check whether the major engine version of the RDS instance meets the requirements.
  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.

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

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 verify that your workloads run as expected on the new RDS instance, you can release the original RDS instance.

Notice 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. This improves the security of your database system.
  • Online DDL operations are supported. For example, you can use the RENAME INDEX clause 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, and 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
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
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 for concurrency control are no longer available 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 recorded 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?

To ensure service stability, ApsaraDB RDS upgrades the major engine version of the secondary RDS instances. Then, ApsaraDB RDS switches your workloads to the secondary RDS instance before it 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?

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.

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.