mysql_upgrade man page

mysql_upgrade — check and upgrade MySQL tables

Synopsis

mysql_upgrade [options]

Description

mysql_upgrade examines all tables in all databases for incompatibilities with the current version of MySQL Server. mysql_upgrade also upgrades the system tables so that you can take advantage of new privileges or capabilities that might have been added.

If mysql_upgrade finds that a table has a possible incompatibility, it performs a table check and, if problems are found, attempts a table repair. If the table cannot be repaired, see Section 2.11.3, “Rebuilding or Repairing Tables or Indexes” for manual table repair strategies.

You should execute mysql_upgrade each time you upgrade MySQL.

As of MySQL 5.7.5, mysql_upgrade communicates directly with the MySQL server, sending it the SQL statements required to perform an upgrade. Before 5.7.5, mysql_upgrade invokes the mysql and mysqlcheck client programs to perform the required operations. For the older implementation, if you install MySQL from RPM packages on Linux, you must install the server and client RPMs. mysql_upgrade is included in the server RPM but requires the client RPM because the latter includes mysqlcheck. (See Section 2.5.5, “Installing MySQL on Linux Using RPM Packages from Oracle”.)

Important

As of MySQL 5.7.12, the default --early-plugin-load value is empty. To load the keyring_file plugin, you must use an explicit --early-plugin-load option with a nonempty value.

In MySQL 5.7.11, the default --early-plugin-load value was the name of the keyring_file plugin library file, so that plugin was loaded by default. InnoDB tablespace encryption requires the keyring_file plugin to be loaded prior to InnoDB initialization, so this change of default value introduces an incompatibility for upgrades from 5.7.11 to 5.7.12 or higher. Administrators who have encrypted InnoDB tablespaces must take explicit action to ensure continued loading of the keyring_file plugin: Start the server with an --early-plugin-load option that names the plugin library file. For additional information, see Section 6.5.4, “The MySQL Keyring”.

Important

If you upgrade to MySQL 5.7.2 or later from a version older than 5.7.2, a change to the mysql.user table requires a special sequence of steps to perform an upgrade using mysql_upgrade. For details, see Section 2.11.1.1, “Changes Affecting Upgrades to MySQL 5.7”.

Note

On Windows Server 2008, Vista, and newer, you must run mysql_upgrade with administrator privileges. You can do this by running a Command Prompt as Administrator and running the command. Failure to do so may result in the upgrade failing to execute correctly.

Caution

You should always back up your current MySQL installation before performing an upgrade. See Section 7.2, “Database Backup Methods”.

Some upgrade incompatibilities may require special handling before you upgrade your MySQL installation and run mysql_upgrade. See Section 2.11.1, “Upgrading MySQL”, for instructions on determining whether any such incompatibilities apply to your installation and how to handle them.

To use mysql_upgrade, make sure that the server is running. Then invoke it like this to check and repair tables and to upgrade the system tables:

shell> mysql_upgrade [options]

After running mysql_upgrade, stop the server and restart it so that any changes made to the system tables take effect.

If you have multiple MySQL server instances running, invoke mysql_upgrade with connection parameters appropriate for connecting to the desired server. For example, with servers running on the local host on parts 3306 through 3308, upgrade each of them by connecting to the appropriate port:

shell> mysql_upgrade --protocol=tcp -P 3306 [other_options]
shell> mysql_upgrade --protocol=tcp -P 3307 [other_options]
shell> mysql_upgrade --protocol=tcp -P 3308 [other_options]

For local host connections on Unix, the --protocol=tcp option forces a connection using TCP/IP rather than the Unix socket file.

mysql_upgrade processes all tables in all databases, which might take a long time to complete. Each table is locked and therefore unavailable to other sessions while it is being processed. Check and repair operations can be time-consuming, particularly for large tables.

For details about what table-checking operations entail, see the description of the FOR UPGRADE option of the CHECK TABLE statement (see Section 13.7.2.2, “CHECK TABLE Syntax”).

All checked and repaired tables are marked with the current MySQL version number. This ensures that next time you run mysql_upgrade with the same version of the server, it can tell whether there is any need to check or repair the table again.

mysql_upgrade also saves the MySQL version number in a file named mysql_upgrade_info in the data directory. This is used to quickly check whether all tables have been checked for this release so that table-checking can be skipped. To ignore this file and perform the check regardless, use the --force option.

As of MySQL 5.7.2, mysql_upgrade checks user table rows and, for any row with an empty plugin column, sets that column to 'mysql_native_password' or 'mysql_old_password' depending on the hash format of the Password column value. As of MySQL 5.7.5, support for pre-4.1 password hashing and mysql_old_password was removed, so mysql_upgrade sets empty plugin values to 'mysql_native_password' if the credentials use a hash format compatible with that plugin. Rows with a pre-4.1 password hash must be upgraded manually. For account upgrade instructions, see Section 6.5.1.3, “Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin”.

mysql_upgrade does not upgrade the contents of the help tables. For upgrade instructions, see Section 5.1.10, “Server-Side Help”.

As of MySQL 5.7.7, unless invoked with the --skip-sys-schema option, mysql_upgrade installs the sys schema if it is not installed, and upgrades it to the current version otherwise. mysql_upgrade returns an error if a sys schema exists but has no version view, on the assumption that its absence indicates a user-created schema:

Error occurred: A sys schema exists with no sys.version view. If
you have a user created sys schema, this must be renamed for the
upgrade to succeed.

To upgrade in this case, remove or rename the existing sys schema first.

In MySQL 5.7.9 and later, mysql_upgrade checks for partitioned InnoDB tables that were created using the generic partitioning handler and attempts to upgrade them to InnoDB native partitioning (used in MySQL 5.7.6 and later). (Bug #76734, Bug #20727344) Also beginning with MySQL 5.7.9, you can upgrade such tables individually in the mysql client using the ALTER TABLE ... UPGRADE PARTITIONING SQL statement.

By default, mysql_upgrade runs as the MySQL root user. If the root password is expired when you run mysql_upgrade, you will see a message that your password is expired and that mysql_upgrade failed as a result. To correct this, reset the root password to unexpire it and run mysql_upgrade again. First, connect to the server as root:

shell> mysql -u root -p
Enter password: ****  <- enter root password here

Reset the password using the appropriate SQL statement. As of MySQL 5.7.6, use ALTER USER:

mysql> ALTER USER USER() IDENTIFIED BY 'root-password';

Before 5.7.6, use SET PASSWORD:

mysql> SET PASSWORD = PASSWORD('root-password');

Then exit mysql and run mysql_upgrade again:

shell> mysql_upgrade [options]

mysql_upgrade supports the following options, which can be specified on the command line or in the [mysql_upgrade] and [client] groups of an option file. For information about option files used by MySQL programs, see Section 4.2.6, “Using Option Files”.

See Also

For more information, please refer to the MySQL Reference Manual, which may already be installed locally and which is also available online at http://dev.mysql.com/doc/.

Author

Oracle Corporation (http://dev.mysql.com/).

Referenced By

mysql_install_db(1).

09/13/2017 MySQL 5.7 MySQL Database System