Convert MySQL to MariaDB Safely: No In-Place Switch in 2026

For a long time you could point CustomBuild at MariaDB on a MySQL server, rebuild, and let mysql_upgrade sort out the differences. That stopped being safe around MySQL 8.0 and MariaDB 10.4, and DirectAdmin removed the in-place switch from CustomBuild altogether; cPanel never allowed it for MySQL 8. The reason is not caution for its own sake. This guide explains what changed and then performs the conversion the supported way, which is a logical dump under MySQL and a restore into a clean MariaDB install.

Applies to MySQL 8.0 and later to MariaDB on DirectAdmin CustomBuild

Short answer: Since MySQL 8.0 the two servers use incompatible data dictionaries, InnoDB formats and authentication plugins, so neither cPanel nor DirectAdmin will swap binaries over an existing data directory. Convert by taking a mysqldump --all-databases under MySQL (excluding the privilege tables), exporting grants as SHOW GRANTS output, installing MariaDB through the panel (da build set mysql_inst mariadb on DirectAdmin) and restoring the dump into the fresh instance. Expect the database to be offline for the whole dump and restore.

Why in-place stopped working

MySQL 8.0 introduced a transactional data dictionary stored inside InnoDB, replacing the .frm files that both products had shared since the fork. MariaDB kept .frm files and has its own system-table layout. A MariaDB binary started against a MySQL 8 data directory finds no table definitions it can read. In the other direction, MariaDB’s InnoDB has diverged in page format details, encryption metadata and the redo log layout since 10.4, so MySQL cannot read MariaDB’s files either. Authentication differs too: MySQL 8 accounts on caching_sha2_password have no equivalent on MariaDB 11.x. There is no upgrade tool that reconciles all of that, and the panels stopped pretending there was.

The practical consequence is that a conversion is a migration: everything goes out through SQL and comes back in.

Prepare

Check the current engine and version, the total data size, and free disk space on the partition that will hold both the dump and the new data directory:

mysql -e "SELECT VERSION();"
da build versions | grep -iE 'mysql|mariadb'
du -sh /var/lib/mysql
df -h /var/lib/mysql /home

Plan for the database being unavailable for the whole dump-and-restore. On a server with 50 GB of data that is a couple of hours; announce the window.

Then find the accounts that will need recreating. Anything on caching_sha2_password cannot be imported into MariaDB 11.x with its hash intact:

mysql -N -e "SELECT CONCAT(user,'@',host) FROM mysql.user WHERE plugin='caching_sha2_password';"

On a DirectAdmin server most database users are created by the panel on mysql_native_password, but check.

Dump under MySQL

Stop application traffic first: on DirectAdmin, stop the web server and mail delivery briefly, or at minimum put the busiest sites into maintenance. Then dump the customer databases and, separately, the grants:

systemctl stop httpd nginx litespeed 2>/dev/null
mysqldump --all-databases --single-transaction --routines --events --triggers --hex-blob \
  --ignore-table=mysql.user --ignore-table=mysql.db --ignore-table=mysql.global_grants \
  | gzip -1 > /root/convert-data.sql.gz
mysql -N -e "SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user NOT IN ('root','mysql.sys','mysql.session','mysql.infoschema')" | mysql -N | sed 's/$/;/' > /root/convert-grants.sql

The first command deliberately excludes MySQL’s own privilege tables; importing those into MariaDB corrupts its mysql schema. The second reconstructs the grants as GRANT statements, which MariaDB accepts. Open /root/convert-grants.sql and remove any IDENTIFIED WITH 'caching_sha2_password' clauses; those accounts get new passwords after the restore. Also remove any MySQL-specific privileges MariaDB does not have (SESSION_VARIABLES_ADMIN, BACKUP_ADMIN and the other dynamic privileges); on a hosting server the panel-created users have only the standard set.

Verify the dump ended cleanly:

zcat /root/convert-data.sql.gz | tail -1

Install MariaDB

Tell DirectAdmin to back up the existing data directory and switch engines. mysql_backup yes makes CustomBuild copy /var/lib/mysql aside before touching it, which is your second safety net:

systemctl stop mysqld
mv /var/lib/mysql /var/lib/mysql.mysql8-$(date +%F)
da build set mysql_backup yes
da build set mysql_inst mariadb
da build set mariadb 11.8
da build mariadb

CustomBuild removes the MySQL packages, installs MariaDB, initialises a fresh data directory and starts the service. Confirm:

mariadb -e "SELECT VERSION();"
ls -la /run/mysql/mysql.sock

DirectAdmin’s socket path is /run/mysql/mysql.sock; update /usr/local/directadmin/conf/mysql.conf if the root credentials changed during the rebuild, then run da build php afterwards so PHP is linked against the MariaDB client library.

Restore

zcat /root/convert-data.sql.gz | mariadb
mariadb < /root/convert-grants.sql
mariadb -e "FLUSH PRIVILEGES;"
mariadb-upgrade

The restore may stop on a statement MariaDB does not accept. The usual suspects are MySQL 8 collation names (utf8mb4_0900_ai_ci is the one that appears everywhere; MariaDB maps it from 10.10 onwards but older targets need a sed to utf8mb4_unicode_ci), invisible columns syntax, and CREATE TABLE options MariaDB ignores with a warning rather than an error. Fix the file and re-run; because the dump contains DROP TABLE IF EXISTS, re-running is safe.

For accounts that were on caching_sha2_password, set new passwords and tell the customers:

ALTER USER 'shop_db'@'localhost' IDENTIFIED BY 'new-password';

Then restart the services you stopped.

Common pitfall

Forgetting that the panel keeps its own idea of which engine is installed. On DirectAdmin, da build set mysql_inst mariadb is what tells the rest of the system; on cPanel the equivalent is the WHM upgrade tool, and hand-installing packages leaves whmapi1 current_mysql_version wrong and the backup system confused. Always change engines through the panel’s own mechanism, then do the data work by hand.

Verify

mariadb -e "SELECT COUNT(*) FROM information_schema.SCHEMATA;"
mariadb -e "SELECT user, host, plugin FROM mysql.user WHERE user NOT IN ('root','mariadb.sys');"
mariadb-check --all-databases | grep -v OK
tail -30 /var/lib/mysql/$(hostname).err | grep -iE 'error|warn'

The schema count should match what MySQL reported before, every account should be present, and every table should check OK. Load the busiest customer sites, log into phpMyAdmin, and keep the MySQL data directory copy and the dump for at least two weeks before reclaiming the space. Our DirectAdmin MariaDB upgrade guide covers the subsequent LTS hops once the server is on MariaDB.

Convert MySQL to MariaDB at a glance

Official documentation: MariaDB documentation, DirectAdmin documentation, Linux man pages.

Related guides: Upgrading MariaDB safely on DirectAdmin: 10.6 → 10.11 → 11.8 → 12.3 with CustomBuild · How to upgrade MySQL 8.0 to MariaDB 11.8 in WHM without losing databases · MariaDB 10.6 is end-of-life: upgrade paths to 11.8 or 12.3 for hosting servers.

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

MySQL 8.0 and later to MariaDB on DirectAdmin CustomBuild

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

mariadb.com/docs
docs.directadmin.com