Upgrade MySQL 8 to MariaDB 11.8 in WHM Safely, Without Data Loss

MySQL 8.0 reached the end of extended support on 30 April 2026, and cPanel & WHM 136 added MariaDB 11.8 to its upgrade workflow. Many hosting servers that installed MySQL 8.0 a few years ago are now weighing whether to move to MySQL 8.4 or to MariaDB. MariaDB 11.8 is an LTS release supported until June 2028, it is the version cPanel now offers as the top of its MariaDB path on AlmaLinux 8, 9 and 10 and Ubuntu 24.04, and it removes the dependency on Oracle’s release cycle. This guide walks through the WHM upgrade and, more importantly, the checks around it.

Applies to cPanel & WHM 136+ on AlmaLinux 8, 9, 10 and Ubuntu 24.04; MySQL 8.0 to MariaDB 11.8

Short answer: Take a full mysqldump --all-databases, reset any caching_sha2_password accounts to mysql_native_password, and resolve crashed tables, then select MariaDB 11.8 in WHM → SQL Services → MySQL/MariaDB Upgrade or run whmapi1 start_background_mysql_upgrade version=11.8. The tool swaps the packages, starts MariaDB on the existing data directory and runs mariadb-upgrade; afterwards remove MySQL-only settings from /etc/my.cnf, restart once deliberately and test customer sites, because the switch cannot be reversed in place.

Understand what the switch involves

Switching from MySQL to MariaDB in WHM is a one-way operation. cPanel does not support downgrading, and neither MariaDB nor MySQL supports switching back in place. The upgrade removes the MySQL server packages, installs MariaDB, and starts it on the existing data directory. InnoDB tables carry across, but there are differences to be aware of:

• Any MySQL-only feature in use by a customer application will break. The most common are caching_sha2_password accounts created by application installers (MariaDB 11.8 does not offer it; that arrived in 12.x), JSON columns that were created as a native type in MySQL and become LONGTEXT with a check constraint in MariaDB, and a handful of functions with different names.
• Reserved words differ. ROW_NUMBER has been reserved since MariaDB 10.7, so an application with a column of that name will fail after the move.
• Default sql_mode differs, which can surface in strict-mode errors on inserts that MySQL tolerated.

For most shared hosting workloads, WordPress, Joomla, Laravel and similar, the move is uneventful. For a server that hosts a custom application, test the switch on a copy first.

Prepare

Start with a full logical dump of every database, in addition to the WHM backup you should already have. A logical dump is the only rollback if the data directory ends up in a state the old server cannot read:

mkdir -p /root/dbdump-$(date +%F)
mysqldump --all-databases --single-transaction --routines --events --triggers \
  > /root/dbdump-$(date +%F)/all.sql
mysql -e "SELECT user,host,plugin FROM mysql.user WHERE plugin='caching_sha2_password';"

The second command lists accounts that will need their authentication plugin changed. Reset them to mysql_native_password before the upgrade, or expect those applications to fail to connect afterwards.

Then check the server is healthy and up to date on cPanel. WHM → SQL Services → MySQL/MariaDB Upgrade will refuse to run if the current server is not cleanly shut down or if the cPanel version is behind. Run our MySQL health snapshot and resolve any crashed tables with mysqlcheck --all-databases --check first.

Confirm disk space on the partition holding /var/lib/mysql; the upgrade does not copy the data directory, but mariadb-upgrade may rebuild some system tables and you want headroom.

Finally, schedule downtime. Database connections will fail during the swap, which typically takes five to fifteen minutes, and then sites that cache connection errors may need a few minutes more.

Run the upgrade in WHM

Go to WHM → SQL Services → MySQL/MariaDB Upgrade. Select MariaDB 11.8 from the list. If the option is greyed out, hover the notice: on AlmaLinux 10 the list is restricted to MariaDB 10.11, 11.4 and 11.8, and on any OS the upgrade path from MySQL 8.0 goes directly to your chosen MariaDB version. Choose the interactive upgrade the first time so you can read each warning.

The interface performs its own checks, stops the current server with a slow shutdown, replaces the packages, starts MariaDB, and runs mariadb-upgrade to rebuild system tables. It then restarts cPanel services so that PHP, Exim and Dovecot pick up the new client library. You can do the same from the shell if you prefer to script it across a fleet:

whmapi1 start_background_mysql_upgrade version=11.8
whmapi1 background_mysql_upgrade_status upgrade_id=<id from the first command>

Watch /var/cpanel/logs/mysql_upgrade.log for progress. If the upgrade reports a failure in the mariadb-upgrade step, it usually names the table; fix it and rerun mariadb-upgrade --force by hand.

After the upgrade

Confirm the server runs and identifies itself correctly:

mysql -e 'SELECT VERSION();'
systemctl status mariadb

Review /etc/my.cnf. MySQL-specific settings that MariaDB rejects will stop the service on the next restart even if it is currently running, because the upgrade may have started it with a sanitised configuration. Remove or comment anything MariaDB does not know, particularly default_authentication_plugin, mysqlx_*, innodb_log_write_ahead_size and caching_sha2_password_* options. Then restart once deliberately so you find configuration problems during your maintenance window rather than during the next kernel update:

systemctl restart mariadb && tail -n 50 /var/log/mysqld.log

Rebuild PHP against the new client library if you compiled anything outside EasyApache 4, and restart PHP-FPM and Apache with /scripts/restartsrv_apache_php_fpm and /scripts/restartsrv_httpd.

Verify

Log into several customer sites that use a database. Run uapi --user=<user> Mysql list_databases for a couple of accounts and confirm that phpMyAdmin opens from cPanel. Check the error log for authentication failures:

grep -i 'access denied' /var/log/mysqld.log | tail

If you see accounts failing with plugin errors, reset them with ALTER USER 'name'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('...'). Finally re-run the health snapshot script and compare buffer pool and connection figures against the pre-upgrade values.

Common pitfall

The most common post-upgrade complaint is a single application failing with “Unknown collation” or “Invalid default value” on an insert. That is sql_mode. MariaDB 11.8 enables strict mode by default; if a legacy application depends on the old permissive behaviour, set sql_mode= (empty) or a reduced set in the [mysqld] section of /etc/my.cnf as a temporary bridge, restart, and then fix the application. Do not leave the global override in place indefinitely on a shared server.

Upgrade MySQL 8 to MariaDB 11.8 at a glance

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

Related guides: Upgrading MariaDB in WHM safely: backups, slow shutdown and mariadb-upgrade · MySQL 8.0 is end-of-life: moving cPanel servers to MySQL 8.4 or MariaDB · MariaDB won’t start after an upgrade: InnoDB recovery, mariadb-upgrade and sql_mode issues.

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

cPanel & WHM 136+ on AlmaLinux 8, 9, 10 and Ubuntu 24.04; MySQL 8.0 to MariaDB 11.8

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

mariadb.com/docs
docs.cpanel.net