Before upgrading to the latest MySQL 8.0 release, ensure the upgrade readiness of your current MySQL 5.7 or MySQL 8.0 server instance by performing the preliminary checks described below. The upgrade process may fail otherwise.
The same checks and others can be performed using the MySQL Shell upgrade checker utility. For more information, see Upgrade Checker Utility.
The following issues must not be present:
There must be no tables that use obsolete data types or functions.
In-place upgrade to MySQL 8.0 is not supported if tables contain old temporal columns in pre-5.6.4 format (
TIMESTAMPcolumns without support for fractional seconds precision). If your tables still use the old temporal column format, upgrade them using
REPAIR TABLEbefore attempting an in-place upgrade to MySQL 8.0. For more information, see Server Changes.
There must be no orphan
Triggers must not have a missing or empty definer or an invalid creation context (indicated by the
Database Collationattributes displayed by
SHOW TRIGGERSor the
TRIGGERStable). Any such triggers must be dumped and restored to fix the issue.
To check for these issues, execute this command:
mysqlcheck -u root -p --all-databases --check-upgrade
If mysqlcheck reports any errors, correct the issues.
There must be no partitioned tables that use a storage engine that does not have native partitioning support. To identify such tables, execute this query:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Any table reported by the query must be altered to use
InnoDBor be made nonpartitioned. To change a table storage engine to
InnoDB, execute this statement:
ALTER TABLE table_name ENGINE = INNODB;
For information about converting
InnoDB, see Converting Tables from MyISAM to InnoDB.
To make a partitioned table nonpartitioned, execute this statement:
ALTER TABLE table_name REMOVE PARTITIONING;
Some keywords may be reserved in MySQL 8.0 that were not reserved previously. See Keywords and Reserved Words. This can cause words previously used as identifiers to become illegal. To fix affected statements, use identifier quoting. See Schema Object Names.
There must be no tables in the MySQL 5.7
mysqlsystem database that have the same name as a table used by the MySQL 8.0 data dictionary. To identify tables with those names, execute this query:
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' );
Any tables reported by the query must be dropped or renamed (use
RENAME TABLE). This may also entail changes to applications that use the affected tables.
There must be no tables that have foreign key constraint names longer than 64 characters. Use this query to identify tables with constraint names that are too long:
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 LENGTH(SUBSTR(ID,INSTR(ID,'/')+1))>64);
For a table with a constraint name that exceeds 64 characters, drop the constraint and add it back with constraint name that does not exceed 64 characters (use
The must be no obsolete SQL modes defined in your
sql_modesystem variable setting. Attempting to use an obsolete SQL mode will cause a startup failure on MySQL 8.0. Applications that use obsolete SQL modes should also be revised to avoid them. For information about SQL modes removed in MySQL 8.0, see Server Changes.
There must be no views with explicitly defined columns names that exceed 64 characters (views with column names up to 255 characters were permitted in MySQL 5.7). To avoid upgrade errors, such views should be altered before upgrading. Currently, the only method of identify views with column names that exceed 64 characters is to inspect the view definition using
SHOW CREATE VIEW. You can also inspect view definitions by querying the
There must be no tables or stored procedures with individual
SETcolumn elements that exceed 255 characters or 1020 bytes in length. Prior to MySQL 8.0, the maximum combined length of
SETcolumn elements was 64K. In MySQL 8.0, the maximum character length of an individual
SETcolumn element is 255 characters, and the maximum byte length is 1020 bytes. (The 1020 byte limit supports multitibyte character sets). Before upgrading to MySQL 8.0, modify any
SETcolumn elements that exceed the new limits. Failing to do so causes the upgrade to fail with an error.
Before upgrading to MySQL 8.0.13 or higher, there must be no table partitions that reside in shared
InnoDBtablespaces, which include the system tablespace and general tablespaces. Identify table partitions in shared tablespaces by querying
If upgrading from MySQL 5.7, run this query:
SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';
If upgrading from an earlier MySQL 8.0 release, run this query:
SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';
Move table partitions from shared tablespaces to file-per-table tablespaces using
ALTER TABLE ... REORGANIZE PARTITION:
ALTER TABLE table_name REORGANIZE PARTITION partition_name INTO (partition_definition TABLESPACE=innodb_file_per_table);
There must be no queries and stored program definitions from MySQL 8.0.12 or lower that use
GROUP BYclauses. Otherwise, upgrading to MySQL 8.0.13 or higher may fail, as may replicating to MySQL 8.0.13 or higher slave servers. For additional details, see SQL Changes.
Your MySQL 5.7 installation must not use features that are not supported by MySQL 8.0. Any changes here are necessarily installation specific, but the following example illustrates the kind of thing to look for:
Some server startup options and system variables have been removed in MySQL 8.0. See Features Removed in MySQL 8.0, and Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.0. If you use any of these, an upgrade requires configuration changes.
Example: Because the data dictionary provides information about database objects, the server no longer checks directory names in the data directory to find databases. Consequently, the
--ignore-db-diroption is extraneous and has been removed. To handle this, remove any instances of
--ignore-db-dirfrom your startup configuration. In addition, remove or move the named data directory subdirectories before upgrading to MySQL 8.0. (Alternatively, let the 8.0 server add those directories to the data dictionary as databases, then remove each of those databases using
If you intend to change the
lower_case_table_namessetting to 1 at upgrade time, ensure that schema and table names are lowercase before upgrading. Otherwise, a failure could occur due to a schema or table name lettercase mismatch. You can use the following queries to check for schema and table names containing uppercase characters:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME != LOWER(TABLE_NAME) AND TABLE_TYPE = 'BASE TABLE'; mysql> SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME != LOWER(SCHEMA_NAME);
As of MySQL 8.0.19, if
lower_case_table_names=1, table and schema names are checked by the upgrade process to ensure that all characters are lowercase. If table or schema names are found to contain uppercase characters, the upgrade process fails with an error.Note
lower_case_table_namessetting at upgrade time is not recommended.
If upgrade to MySQL 8.0 fails due to any of the
issues outlined above, the server reverts all changes to the data
directory. In this case, remove all redo log files and restart the
MySQL 5.7 server on the existing data directory to
address the errors. The redo log files
ib_logfile*) reside in the MySQL data
directory by default. After the errors are fixed, perform a slow
shutdown (by setting
attempting the upgrade again.