MariaDB Not Starting After Upgrade: 5 Recovery Fixes

MariaDB upgrades through WHM usually complete in minutes, but when the service fails to come back the whole server’s sites go down at once. The failure is almost always one of four things: a configuration variable the new version no longer recognises, InnoDB refusing to recover from an unclean shutdown, system tables that have not been upgraded, or an application that cannot cope with the stricter defaults in 11.4 and later. This guide takes them in the order you should check.

Applies to MariaDB 10.6 to 11.x and 11.x to 12.x upgrades on cPanel & WHM

Short answer: Read the last [ERROR] line in /var/lib/mysql/<hostname>.err first. If it names an unknown variable, comment that line out of /etc/my.cnf and start again; if it reports InnoDB corruption, copy the data directory aside and start with --innodb-force-recovery=1 to take a dump; once the service is up, run mariadb-upgrade --force and, if sites now throw strict-mode errors, set sql_mode = "NO_ENGINE_SUBSTITUTION" as a bridge.

Read the error log first

Nothing else is worth doing until you have the last few lines of the error log:

systemctl status mariadb --no-pager
journalctl -u mariadb --no-pager | tail -30
tail -60 /var/lib/mysql/$(hostname).err

On cPanel the error log is the hostname-named file in the data directory unless log_error is set in /etc/my.cnf. The last [ERROR] line before Aborting names the cause.

Unknown variable: remove what the new version dropped

If the log says unknown variable 'innodb_log_write_ahead_size=...' or similar, the server is refusing to start because /etc/my.cnf (or a file under /etc/my.cnf.d/) references an option that was removed. Common victims on the 10.6 to 11.x and 11.x to 12.x jumps are innodb_log_write_ahead_size, wsrep_strict_ddl, keep_files_on_create, big_tables, large_page_size, storage_engine and the legacy innodb_file_format family. Comment the line out and try again:

grep -nE 'innodb_log_write_ahead_size|wsrep_strict_ddl|keep_files_on_create|big_tables|large_page_size|^storage_engine' /etc/my.cnf /etc/my.cnf.d/*.cnf
systemctl start mariadb

Repeat until the log stops complaining. Do not delete my.cnf wholesale; the buffer pool and connection settings in it are what keep the server usable under load. Our companion guide on unknown variable startup failures has the full list per version.

InnoDB will not recover

An InnoDB: Database page corruption or Plugin 'InnoDB' init function returned error message means the redo log or a tablespace is inconsistent, usually because the old version was killed rather than shut down cleanly before the packages were swapped. Before touching anything, copy the data directory somewhere safe:

systemctl stop mariadb
cp -a /var/lib/mysql /var/lib/mysql.pre-recovery

Then bring the server up in forced-recovery mode, starting at level 1 and increasing only if needed:

mysqld_safe --innodb-force-recovery=1 &

Levels 1 to 3 are read-safe and let you dump. Level 4 and above skip more of the recovery and can lose data, so only use them to extract a dump, never to run production. Once the server is up at the lowest working level, dump everything, stop it, move the corrupt tablespaces aside, start without the flag, and reload:

mariadb-dump --all-databases --single-transaction --routines --events > /root/all.sql

If the redo log was the problem (ib_logfile0), on a clean shutdown MariaDB recreates it. Do not delete redo logs on a server that has not shut down cleanly; that is how a recoverable crash becomes a rebuild from backup.

Run mariadb-upgrade

If the server starts but queries against mysql.* tables fail, privileges look wrong, or the log warns that tables need repair, the system tables are still in the old format:

mariadb-upgrade --force

WHM runs this as part of its upgrade workflow, but it is skipped if the server was not running at the end of the package step. It is idempotent, so run it whenever in doubt. Watch for Phase 4/8: Checking and upgrading tables errors that name a user table; those need mysqlcheck --repair individually.

Also note that since 11.x the canonical binaries are mariadb, mariadb-dump and mariadb-upgrade. The mysql* symlinks are still present in the cPanel packages, but scripts should move to the new names.

Stricter sql_mode and other 11.4+ defaults

The server is up, but customers report Incorrect integer value or Field 'x' doesn't have a default value errors on sites that worked yesterday. The upgrade changed the default sql_mode to include STRICT_TRANS_TABLES, and possibly ONLY_FULL_GROUP_BY. cPanel does not override this. Check the running value:

mysql -e "SELECT @@GLOBAL.sql_mode"

The correct fix is to update the application, but on a shared server you cannot fix five hundred sites tonight. A pragmatic bridge is to set a looser server-wide mode that matches the old version’s behaviour and let developers fix their code over time:

[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"

Add it to /etc/my.cnf, restart, and re-test. Reserved-word collisions are the other class of application break: ROW_NUMBER since 10.7 and CONVERSION and TO_DATE in 12.3 will break queries that use those as column names without backticks, and there is no server-side switch for those.

A common pitfall: mixed package sources

A server that once had a MariaDB repository from the vendor, or a Remi or CloudLinux MySQL governor package, can end up with binaries from one source and libraries from another after WHM’s upgrade. The symptom is a start failure mentioning a symbol or a version mismatch rather than a configuration error. Check:

rpm -qa | grep -iE 'mariadb|mysql' | sort
dnf repolist

Disable the foreign repository, run /scripts/check_cpanel_pkgs --fix, and let WHM’s MySQL/MariaDB Upgrade page reinstall the consistent set.

Verify

A healthy recovery ends with all of the following true:

systemctl is-active mariadb
mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime'"
mysqlcheck --all-databases --check-upgrade | grep -v OK
tail -5 /var/lib/mysql/$(hostname).err

No [ERROR] lines in the last minutes, no tables flagged by mysqlcheck, and the version reported by mysql -e "SELECT VERSION()" matches what WHM shows. Take a fresh full dump at this point, because the pre-recovery copy is now the only rollback and it will not be trustworthy for long. Our MySQL health snapshot script captures the state you will want to compare against next time, and the WHM upgrade guide covers the preparation steps (innodb_fast_shutdown=0, a clean stop, a verified backup) that avoid most of this in the first place.

MariaDB not starting after upgrade at a glance

Official documentation: MariaDB documentation, cPanel & WHM documentation, Linux man pages.

Related guides: Tuning InnoDB on MariaDB 11/12 for cPanel shared hosting: buffer pool, redo log and I/O · Fix “Too many connections” on MariaDB/MySQL (cPanel) · Installing and switching PHP versions in EasyApache 4 (8.2 to 8.5).

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

MariaDB 10.6 to 11.x and 11.x to 12.x upgrades on cPanel & WHM

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

mariadb.com/docs
docs.cpanel.net