The message Table 'mysql.plugin' doesn't exist means the database server tried to read a system table that is absent or incompatible with the running binaries. It often appears after an interrupted package upgrade, an unsupported MySQL-to-MariaDB switch, or a service starting against the wrong data directory.
Do not begin by copying a mysql.plugin table definition from another server. System-table layouts vary by product and version. A copied definition can hide the first error while creating a different problem in authentication, privileges or future upgrades.
This guide separates diagnosis from repair so that you can preserve the databases before changing anything.
Identify the database product and version
MySQL and MariaDB do not use the same upgrade process. Record the installed binaries first:
mysqld --version
mysql --versionIf the service starts, confirm what is actually running rather than relying only on the package name:
SELECT VERSION(), @@version_comment, @@datadir;Also review recent package-manager history. An unexpected change from MySQL to MariaDB, or the reverse, is more serious than a missed minor-version upgrade. Do not continue an in-place cross-product migration until you have confirmed that the chosen path is supported.
Preserve the current state before repairing it
If the databases matter and there is no verified backup, stop and create a storage snapshot or an offline copy of the complete data directory. A logical dump is preferable when the service can run reliably, but it may not be possible at this stage.
The backup must include the system schema, user databases, configuration files and enough information to identify the exact server build. Copying only one .ibd file is not a complete InnoDB backup.
For a production incident, our emergency server support service can investigate the failure without replacing the existing data directory.
Read the first database error, not only the last one
On systemd-based servers, check the service and journal. The unit name is commonly mysqld, mysql or mariadb:
systemctl status mysqld --no-pager
journalctl -u mysqld -n 200 --no-pagerUse the appropriate unit name for the installed product. Depending on the distribution, the database error log may be under /var/log/mysql/, /var/log/mariadb/ or the data directory. On a standard cPanel installation it is commonly /var/lib/mysql/hostname.err.
Look above the mysql.plugin message for the event that caused it. Useful clues include:
- A data directory that does not match the previous service configuration
- Permission denied or SELinux denials
- An upgrade from an unsupported source version
- Missing files under the
mysqlsystem schema - Package installation that ended before its post-installation steps completed
- A server binary that is older than the data directory it is trying to open
Check storage before attempting another start:
df -h
df -iA full filesystem or exhausted inode table can interrupt a package upgrade and leave system tables incomplete.
Confirm the configured data directory
The error can occur when a new service file or configuration fragment points MySQL at an empty or old data directory. Inspect the effective configuration:
my_print_defaults mysqldCompare the reported datadir with the location used before the upgrade. Check ownership and mount status, but do not recursively change permissions until you know why they differ. A blind recursive chown can damage intentionally separated files, mounted storage or security controls.
Never run mysqld --initialize against an existing production data directory. Initialization creates a new system schema; it is not a repair command for a missing system table.
Use the correct upgrade path
MySQL 8.0.16 and newer
From MySQL 8.0.16, the server performs the work that older releases delegated to mysql_upgrade. Running mysql_upgrade is therefore not the modern repair for this error.
After confirming a supported version path, a correct data directory and a usable backup, start the server normally and follow the upgrade messages in the error log. MySQL also provides the server option --upgrade=FORCE for forcing its upgrade checks, but it should be used in a planned maintenance window through the platform's supported startup configuration. Do not append it permanently to an unknown production configuration.
If the server cannot start because the system schema is missing, automatic upgrade cannot repair files that are not present. Restore the system schema from a compatible backup or build a clean instance of the exact required version and migrate the user databases using a supported logical or physical method.
See MySQL's current documentation on the server upgrade process.
Older MySQL releases
Older releases may require mysql_upgrade after the upgraded server starts. Use the documentation for the exact source and target versions. These versions are also likely to be outside normal vendor support, so a repair should include a plan to move to a supported release.
MariaDB
MariaDB continues to provide mariadb-upgrade, formerly exposed as mysql_upgrade. Run it only after the new MariaDB server starts and only after taking a backup:
mariadb-upgrade --forceThe --force option is useful when the tool believes an upgrade was already completed but system tables remain inconsistent. Review all output instead of assuming a zero exit status proves that every user database is healthy. MariaDB documents the current behavior in its mariadb-upgrade reference.
Do not recreate mysql.plugin manually
Old fixes commonly publish a CREATE TABLE mysql.plugin statement. That approach is risky for three reasons:
- The required definition depends on the server family and version.
- The missing table may be only one symptom of a wider incomplete system-schema upgrade.
- A hand-created table does not validate privileges, components, data dictionary state or other system tables.
If a supported upgrade process cannot recreate the missing system table, restore from a version-compatible backup or migrate into a clean instance. That takes longer than pasting a table definition, but it leaves an auditable and supportable database state.
Verify the recovery
After the service starts, confirm the product, data directory and plugin state:
SELECT VERSION(), @@version_comment, @@datadir;
SHOW PLUGINS;For MariaDB or a MySQL release that uses mysql.plugin, check the table directly:
CHECK TABLE mysql.plugin;Then review the complete error log from the successful startup. Test application authentication, scheduled backups and replication if it is configured. A server that accepts one local connection is not yet a verified recovery.
When the error follows a crash rather than an upgrade
If the log also reports InnoDB page corruption, redo-log failures or repeated crash recovery, stop treating the incident as a system-table-only problem. Follow a controlled InnoDB recovery procedure and preserve an offline copy before using recovery options.
Prevent the error during future upgrades
- Verify both logical backups and restore procedures before the maintenance window.
- Read the supported upgrade path for the exact source and target versions.
- Do not switch between MySQL and MariaDB by replacing packages over the same data directory.
- Confirm free disk space, inode availability and package repository consistency.
- Record the active data directory and configuration includes before upgrading.
- Review the database error log immediately after the first start.
- Test authentication, applications, replication and backups before closing the change.
Reliable database upgrades are part of ongoing Linux server management, particularly when the server hosts control panels or several production applications.
Need an engineer to manage the Linux server behind this issue?
Our Linux administrators handle monitoring, updates, security, performance and day-to-day technical problems.
