When you run a precheck before upgrading an ApsaraDB RDS for MySQL instance to a new major engine version, the system checks multiple conditions and reports any blocking issues. This page explains each check item, what it looks for, why it fails, and how to fix it.
If you encounter an error not listed here, submit a ticket.
Check items
The table below covers all check items returned by the precheck. The supported upgrade paths are MySQL 5.6 → MySQL 5.7, MySQL 5.7 → MySQL 8.0, and MySQL 8.0 → MySQL 8.4.
check_ins_major_version
Error message: Current engine version does not support operations.
What it checks: Whether the current instance version and the target version form a supported major engine version upgrade path.
Cause: The upgrade path is not one of MySQL 5.6 to 5.7, MySQL 5.7 to 8.0, or MySQL 8.0 to 8.4, or the current instance form does not support the upgrade path.
Fix: See Prerequisites for a major engine version upgrade to confirm the source version, target version, and instance form. If the console does not provide the corresponding upgrade entry point, submit a ticket.
check_ins
Error message: Specified instance does not exist or not support.
What it checks: Whether the instance exists.
Cause: The instance was deleted or does not exist.
Fix: Verify that the target instance exists before running the precheck.
check_ins_status
Error message: Current DB instance state does not support this operation.
What it checks: Whether the instance is in the Running state.
Cause: Another operation is in progress—for example, an instance restart or network connection creation—so the instance is not in the Running state.
Fix: Wait for the current task to complete. After the instance returns to the Running state, initiate the precheck again.
check_master_ins
Error message: Current DB instance type does not support this operation.
What it checks: Whether the instance is a primary instance.
Cause: The instance is a disaster recovery instance or a read-only instance, not a primary instance.
Fix: Run the precheck on a primary instance.
check_ins_locked_state
Error message: Current DB instance lock mode does not support this operation.
What it checks: Whether the instance is locked.
Cause: The instance is in the Locking state.
Fix: Unlock the instance. After the instance status changes to Running, run the precheck again. For more information, see What do I do if my instance is in the Locking state?
check_maxscale_kernel
Error message: The Maxscale version used by the instance is too low, please upgrade the Maxscale version first.
What it checks: Whether the database proxy MaxScale minor version is compatible with the target major version, based on the upgrade path.
Cause: The proxy version does not meet the requirement for the target minor version. For upgrades from 5.7 to 8.0, the proxy version must be 1.13.41 or later. For upgrades from 8.0 to 8.4, the proxy version must be 2.25.11 or later.
Fix: Upgrade the proxy to a supported minor version, then run the precheck again. Upgrades from 8.0 to 8.4 require a resolvable proxy version of 2.25.11 or later.
check_ins_tde_state
Error message: Specified TDEStatus is not configured on the This custins.
What it checks: Whether transparent data encryption (TDE) is enabled.
Cause: TDE is enabled on the instance.
Fix: Instances with TDE enabled cannot be upgraded directly from the console. For the alternative upgrade procedure, see Upgrade the database version.
check_target_ins_level
Error message: Current DB instance level does not support this operation. (Error code: InvalidInstanceLevel.Malformed)
What it checks: Whether the current instance type is available for purchase.
Cause: The instance uses a phased-out instance type. It cannot be directly upgraded.
Fix: Change the instance to a currently available instance type, then retry the upgrade.
check_target_read_level
Error message: The read-only instance level is not supported in the target instance.
What it checks: Whether the read-only instance's instance type is available for purchase.
Cause: The read-only instance uses a phased-out instance type. This check applies to instances that use local SSDs.
Fix: Change the read-only instance to an available instance type, then run the precheck again.
To change the instance type, see Change the instance configuration.
To find available instance types, see Instance types for standard read-only instances or Instance types for Yitian read-only instances.
check_upgrade_check_task
Error message: The task already exists.
What it checks: Whether a precheck task is already running for this instance.
Cause: A major engine version upgrade precheck is already in progress.
Fix: Wait for the precheck to complete. After the instance status changes to Running, run the precheck again.
check_upgrade_task
Error message: The task already exists.
What it checks: Whether a major engine version upgrade task is already running for this instance.
Cause: A major engine version upgrade is already in progress.
Fix: Wait for the upgrade to complete. After the instance status changes to Running, run the precheck again.
check_storage_type
Error message: Cloud ssd does not support this operation, please upgrade to essd.
What it checks: Whether the instance uses standard SSDs.
Cause: The instance uses standard SSDs.
Fix: Upgrade the storage type to ESSD (enterprise SSD), then retry the upgrade.
check_source_category
Error message: Specified source category is invalid.
What it checks: Whether the instance edition is within the supported range for major engine version upgrades.
Cause: The instance is not on the High-availability Edition, Basic Edition, or Cluster Edition, or the upgrade path does not support the current instance type.
Fix: Upgrade prechecks are currently supported only for instances on the High-availability Edition or the 5.7 Basic Edition.
check_ins_biz_type
Error message: Specified biz type is not valid.
What it checks: Whether the instance is a public cloud instance.
Cause: The instance is not a public cloud instance.
Fix: Major engine version upgrade prechecks are supported only for public cloud instances.
check_ins_tables_number
Error message: Upgrade not allowed due to excessive number of tables: more than 1000,000.
or
Upgrade not allowed due to excessive number of tables: more than 1000,000.
What it checks: Whether the number of tables on the instance exceeds the limit allowed by the current upgrade path.
Cause:
A local SSD instance has more than 1,000,000 tables and cannot be upgraded.
A cloud disk instance has more than 1,000,000 tables and cannot be upgraded.
Fix: Delete redundant tables, then run the precheck again.
check_ins_db_engine
Error message: There are engines present such as MyISAM, Memory, TokuDB, Sphinx, or RocksDB.
What it checks: Whether any tables use a storage engine other than InnoDB.
Cause: The instance contains tables using MyISAM, Memory, TokuDB, Sphinx, or RocksDB. These storage engines are not supported for major engine version upgrades.
Fix: Convert all tables to InnoDB before upgrading. If the database already uses InnoDB but individual tables use other engines, run the following command for each affected table:
ALTER TABLE <table_name> engine=InnoDB;check_ins_fts
Error message: The current instance has an FTS index, and the minor version is less than 20221130.
What it checks: Whether the instance has full-text indexes, and whether the source instance's minor version is earlier than 20221130.
Cause: In older versions of RDS for MySQL 5.6, full-text indexes are created on the system tablespace. During an upgrade, these indexes can corrupt the tablespace. This issue is fixed in RDS for MySQL 5.6 minor engine version 20221130, where full-text indexes are created on a separate tablespace.
Fix: Before upgrading from RDS for MySQL 5.6 to 5.7, clear any full-text indexes from the system tablespace.
Make sure the instance is running RDS for MySQL 5.6 minor engine version 20221130 or later. If it is not, upgrade to the latest RDS for MySQL 5.6 minor engine version first.
Drop the full-text index on the system tablespace. Use the table name shown in the error prompt.
ALTER TABLE $table_name DROP INDEX $fts_name;Recreate the full-text index.
ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;Verify that no full-text indexes remain on the system tablespace. The following query returns any such indexes. An empty result means the precheck will not fail due to this issue.
SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);
check_read_ins_number
Error message: The number of read-only instances cannot be greater than 8.
What it checks: The number of read-only instances for instances using local SSDs.
Cause: The instance has more than 8 read-only instances. This limit applies only to instances that use local SSDs.
Fix: Release the extra read-only instances. After the upgrade is complete, recreate them.
check_slave_state
Error message: The slave status is unhealthy or has delays.
What it checks: The health and replication latency of the secondary node.
Cause: The secondary node is in an abnormal state or has a replication delay.
Fix: In the console, check the Node Replication Thread Status (seconds) and Node Replication Latency (seconds) monitoring metrics under Monitoring and alerts. Wait for the secondary node to return to normal, then run the precheck again.
check_account
Error message: The instance has an aliyun_root account.
What it checks: Whether an aliyun_root account exists on the instance.
Cause: A user manually created an aliyun_root account in RDS for MySQL 5.6. The aliyun_root account is a default system account in RDS for MySQL 5.7 and later. If it already exists in 5.6, the upgrade to 5.7 fails with a duplicate name error.
Fix: Delete or rename the manually created aliyun_root account before running the precheck. For information about system accounts, see System accounts.
check_sys_schema
Error message: The instance already has a sys database.
What it checks: Whether a sys database exists on the instance.
Cause: The sys database is created by default in RDS for MySQL 5.7. If it already exists in a 5.6 instance, the upgrade to 5.7 fails.
Fix: Rename the existing sys database. Because MySQL does not support RENAME DATABASE, run ALTER TABLE ... RENAME for each table individually.
To confirm whether the sys database exists, run:
SELECT * FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='sys';check_table_discard
Error message: There are tables that have been discarded.
What it checks: Whether the instance has tables with discarded tablespaces (tables on which ALTER TABLE ... DISCARD TABLESPACE was run) and have not been restored.
Cause: The instance contains discarded tables whose tablespace file size and block size are both 0.
Fix: After you confirm data safety, restore or delete the affected tables, then run the precheck again. For source version 5.7, run:
SELECT space,name FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES WHERE FS_BLOCK_SIZE=0 AND FILE_SIZE=0 AND name NOT LIKE '%#sql%';For source version 8.0, run:
SELECT SPACE, NAME FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE FS_BLOCK_SIZE=0 AND FILE_SIZE=0 AND NAME NOT LIKE '%#sql%';check_table_foreign_key
Error message: The partitioned table contains foreign keys.
What it checks: Whether any partitioned tables have foreign keys, or whether any partitioned tables are referenced by foreign keys of other tables.
Cause: A partitioned table contains a foreign key, or another table's foreign key references a partitioned table.
Fix: Resolve the conflicts between foreign keys and partitioned tables.
Query partitioned tables that contain foreign keys.
SELECT DISTINCT a.TABLE_SCHEMA, a.TABLE_NAME FROM information_schema.TABLE_CONSTRAINTS a, information_schema.PARTITIONS b WHERE a.CONSTRAINT_TYPE='FOREIGN KEY' AND a.TABLE_SCHEMA = b.TABLE_SCHEMA AND a.TABLE_NAME = b.TABLE_NAME AND (b.PARTITION_NAME IS NOT NULL OR b.SUBPARTITION_NAME IS NOT NULL);Query partitioned tables that are referenced by foreign keys of other tables.
SELECT DISTINCT a.TABLE_SCHEMA, a.TABLE_NAME, a.REFERENCED_TABLE_SCHEMA, a.REFERENCED_TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE a, information_schema.PARTITIONS b WHERE a.REFERENCED_TABLE_SCHEMA = b.TABLE_SCHEMA AND a.REFERENCED_TABLE_NAME = b.TABLE_NAME AND (b.PARTITION_NAME IS NOT NULL OR b.SUBPARTITION_NAME IS NOT NULL);
check_column_length
Error message: The number of views with column length greater than or equal to 64 is greater than 0.
What it checks: Whether any views have column names of 64 or more characters.
Cause: MySQL does not support view column names with 64 or more characters.
Fix: Query the affected views, then delete them or shorten the column names.
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME IN (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS) AND CHAR_LENGTH(COLUMN_NAME) >= 64;check_foreign_key_constraint
Error message: The number of tables with foreign key constraint length greater than 64 is greater than 0.
What it checks: Whether any tables have foreign key constraint names longer than 64 characters.
Cause: Foreign key constraint names longer than 64 characters are not supported.
Fix: Shorten the affected foreign key constraint names, then run the precheck again. For source version 5.7, query INFORMATION_SCHEMA.INNODB_SYS_FOREIGN. For source version 8.0, query INFORMATION_SCHEMA.INNODB_FOREIGN. The following example is for 5.7:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME IN (SELECT LEFT(SUBSTR(ID,INSTR(ID,'/')+1),INSTR(SUBSTR(ID,INSTR(ID,'/')+1),'_ibfk_')-1) FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN WHERE CHAR_LENGTH(SUBSTR(ID,INSTR(ID,'/')+1))>64);check_dictionary_table
Error message: In the MySQL 5.7 system database, there cannot be tables with the same name as those used by the MySQL 8.0 data dictionary.
What it checks: Whether any tables in the MySQL 5.7 system database share names with tables used by the MySQL 8.0 data dictionary.
Cause: One or more tables in the MySQL 5.7 system database have names that conflict with the MySQL 8.0 data dictionary.
Fix: Query for conflicting table names, then delete or rename them.
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE LOWER(
TABLE_SCHEMA) = 'mysql' and LOWER(TABLE_NAME) IN
('catalogs', 'character_sets', 'check_constraints', 'collations',
'column_statistics', 'column_type_elements', 'columns',
'dd_properties', 'events', 'foreign_key_column_usage', 'foreign_keys',
'index_column_usage', 'index_partitions', 'index_stats',
'indexes', 'parameter_type_elements', 'parameters', 'resource_groups', 'routines',
'schemata', 'st_spatial_reference_systems',
'table_partition_values', 'table_partitions', 'table_stats', 'tables',
'tablespace_files', 'tablespaces', 'triggers', 'view_routine_usage',
'view_table_usage');check_ins_health
Error message: The master node of the instance is not available.
What it checks: Instance connectivity and availability.
Cause: Resources such as CPU or disk are fully utilized, making the primary node unavailable.
Fix: In the console, use the Monitoring and alerts feature to check whether all monitoring metrics are within normal ranges.
check_table_index_type
Error message: For upgrades from 5.7 to 8.0: MySQL 8.0 does not support creating BTREE indexes on spatial fields.
For upgrades from 8.0 to 8.4: The current instance contains SPATIAL indexes. Drop these indexes before the upgrade and recreate them after the upgrade is complete.
What it checks: Index compatibility based on the upgrade path. For upgrades from 5.7 to 8.0, checks for BTREE indexes on spatial fields. For upgrades from 8.0 to 8.4, checks whether the instance contains SPATIAL indexes.
Cause: For upgrades from 5.7 to 8.0, the instance has BTREE indexes on spatial fields. For upgrades from 8.0 to 8.4, the instance has SPATIAL indexes.
Fix: Delete the detected incompatible indexes before the upgrade, and recreate them according to the target version rules after the upgrade. For upgrades from 5.7 to 8.0, run the following query:
SELECT DISTINCT s.* FROM INFORMATION_SCHEMA.STATISTICS s
INNER JOIN INFORMATION_SCHEMA.COLUMNS c
ON s.TABLE_SCHEMA = c.TABLE_SCHEMA
AND s.TABLE_NAME = c.TABLE_NAME
AND s.COLUMN_NAME = c.COLUMN_NAME
WHERE s.TABLE_SCHEMA NOT IN ('mysql', 'sys')
AND c.DATA_TYPE IN ('GEOMETRY', 'POINT', 'LINESTRING', 'POLYGON', 'MULTIPOINT',
'MULTILINESTRING', 'MULTIPOLYGON', 'GEOMETRYCOLLECTION')
AND s.INDEX_TYPE = 'BTREE';For upgrades from 8.0 to 8.4, run the following query:
SELECT DISTINCT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE INDEX_TYPE IN ('SPATIAL', 'RTREE') AND TABLE_SCHEMA NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema');check_read_ins_level
Error message: The specifications of read-only instances are inconsistent.
What it checks: Whether multiple read-only instances under a local SSD instance use consistent instance types.
Cause: The read-only instances under the same primary instance use different instance types, so the target instance type cannot be uniformly mapped during the upgrade.
Fix: Change the standard read-only instances to a consistent available instance type, then run the precheck again.
check_bak_read_exists
Error message: There is a read-only instance, but there is no standby read-only instance.
What it checks: Whether at least one standby read-only instance exists when a local SSD instance has standard read-only instances.
Cause: The instance has standard read-only instances but no standby read-only instance, which does not meet the upgrade switchover requirement.
Fix: Adjust the read-only instance topology and keep at least one standby read-only instance. If you cannot complete this in the console, submit a ticket.
check_bak_read_number
Error message: Verify that the number of spare read-only instances cannot exceed 5.
What it checks: Whether the number of standby read-only instances of a local SSD instance exceeds 5.
Cause: The number of standby read-only instances is greater than 5.
Fix: Release or adjust the extra standby read-only instances so that the number does not exceed 5, then run the precheck again.
check_read_ins_conn_type
Error message: The network types of the read-only instance and the standby read-only instance are inconsistent.
What it checks: Whether the network connection types of the standard read-only instance and the standby read-only instance are consistent.
Cause: Both LVS and DNS connection types exist in the same topology.
Fix: Change the standard read-only instance and the standby read-only instance to a consistent connection type, then run the precheck again.
check_interrupt_task
Error message: The standby read-only has unfinished tasks.
What it checks: Whether the standby read-only instance has unfinished or interrupted major version tasks.
Cause: The standby read-only instance still has tasks in the waiting, running, paused, or interrupted state.
Fix: Wait for the related tasks to complete, or handle and end the abnormal tasks, then run the precheck again.
check_mgr_disabled_for_84
Error message: MySQL 8.4 no longer supports Group Replication (MGR).
What it checks: Whether MGR is enabled on the source instance when upgrading from 8.0 to 8.4. Checks whether members exist in performance_schema.replication_group_members, or whether group_replication_start_on_boot is set to ON.
Cause: The instance has MGR members, or is configured to automatically start Group Replication when the instance starts.
Fix: Run STOP GROUP_REPLICATION; to stop MGR, remove the Group Replication related parameters, and restart the instance. After you confirm that MGR is no longer enabled, run the precheck again.