Upgrading the Minor Version of a DB Instance

Kernel version

There are three scenarios for upgrading a minor version based on different kernel versions:

• Scenario 1: If the instance's kernel version is below 2.0.51.240305, it will be upgraded to 2.0.51.240305 or 2.0.51.240311 first, followed by a minor version pre-upgrade and then a minor version upgrade.
• Scenario 2: If the instance's kernel version is between 2.0.51.240305 and 2.0.51.240311, it will undergo a minor version pre-upgrade first. After that, you need to click Upgrade again to start a minor version upgrade. The following operations use this upgrade method as an example.
• Scenario 3: If the instance's kernel version is above 2.0.51.240311, clicking Upgrade will directly trigger a minor version upgrade.

• If the kernel version is between 2.0.51.240305 and 2.0.51.240311, the upgrade involves changes to the underlying data dictionary and may take a long time.
• For scenario 2, binlog needs to be enabled before the upgrade. Ensure that the value of rds_global_sql_log_bin is ON, the value of binlog_expire_logs_seconds is at least 86400, and the value of default_collation_for_utf8mb4 is utf8mb4_0900_ai_ci.

Upgrade time

There are two ways to upgrade a minor version based on different upgrade times.

• Upon submission: The system upgrades the minor version upon your manual submission of the upgrade request.
• In maintenance window: A scheduled upgrade task is generated. The system upgrades the minor version during the maintenance window you have specified. For details about how to change the maintenance window, see Changing the Maintenance Window of a DB Instance.

If the kernel version of your instance has potential risks or major defects, has expired, or has been brought offline, the system will notify you by SMS message or email and deliver an upgrade task during the maintenance window.

Before the upgrade

• If the kernel version is between 2.0.51.240305 and 2.0.51.240311, to upgrade it to 2.0.54.240600 or later, ensure that the value of rds_global_sql_log_bin is ON and the value of binlog_expire_logs_seconds is at least 86400. For details about how to set these parameters, see Modifying Parameters of a DB Instance.
• If the rds_global_sql_log_bin parameter is set to ON, you need to connect to the database and run the following command to check whether binlog is enabled for all threads.

  select @@session.rds_sql_log_bin_inconsistent_count;

• If the replication latency between the primary node and read replicas is longer than 300 seconds, the minor version cannot be upgraded.
• If you want to upgrade the minor version of your instance from 8.0.18 to 8.0.22 and there are more than 1,000 partitions, the upgrade may fail. Contact Huawei Cloud engineers to check the version compatibility before the upgrade.

During the upgrade

• Scenario 1 or 3: If the primary node and read replicas of an instance are deployed in the same AZ, a minor version upgrade will trigger a failover. If they are in different AZs, a minor version upgrade will trigger two failovers. A failover means that the system fails over to a read replica in case the primary node is unavailable.
• Scenario 1 or 3: The upgrade will cause the instance to reboot and briefly interrupt workloads for about 30 to 90 seconds. To minimize the impact of the upgrade, perform the upgrade during off-peak hours, or ensure that your applications support automatic reconnection.
• Scenario 2: During the minor version pre-upgrade, the instance will not reboot, which means workloads will not be affected.
• Scenario 2: The minor version upgrade will cause the instance to reboot, so workloads will be interrupted. The upgrade takes 15 to 20 minutes, and workloads are intermittently interrupted for 1 to 2 minutes. To minimize the impact, perform the upgrade during off-peak hours.
• If an instance contains a large number of table partitions (more than 1 million), it may take more than 2 hours to reboot the instance.
• When you upgrade the minor version of an instance, minor versions of read replicas (if any) will also be upgraded. During the upgrade, the read replicas will reboot. To minimize the impact, perform the upgrade during off-peak hours. Minor versions of read replicas cannot be upgraded separately. Once you upgrade the minor version, the instance will be upgraded to the latest minor version. A minor version upgrade cannot be rolled back after the upgrade is complete.
• DDL operations on events, such as CREATE EVENT, DROP EVENT, and ALTER EVENT, are not allowed during a minor version upgrade.
• If the message "Upgrade failed. Reduce the service load of the instance and click Retry" is displayed on the console, the upgrade fails due to heavy service load. Reduce the service load or retry the upgrade during off-peak hours.

After the upgrade

• Scenario 2: If the upgrade fails, the instance will be rolled back to a previous version and its data will be restored to a new instance named original_instance_name_copy. The original instance will become unavailable after the rollback, and the new instance will start to incur charges once the original instance is deleted.
• Data cannot be restored to a point in time when a data dictionary upgrade was in progress. By default, the system searches for the most recent available point in time instead.
• During the period between a data dictionary upgrade and the next full backup, data of the instance cannot be restored to the original instance or an existing instance.
• When data is restored from a backup, the versions of the source and destination instances must adhere to the following constraints:
  • If the source instance's kernel version is 2.0.54.240600 or later, the destination instance's kernel version cannot be earlier than 2.0.54.240600.
  • If the source instance's kernel version is earlier than 2.0.54.240600, the destination instance's kernel version cannot be 2.0.54.240600 or later.