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

Source: https://srvscripts.com/guides/convert-mysql-to-mariadb-safely/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

In short: 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.

**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](/guides/upgrade-mariadb-directadmin-custombuild/) covers the subsequent LTS hops once the server is on MariaDB.

## Convert MySQL to MariaDB at a glance

**Official documentation:** [MariaDB documentation](https://mariadb.com/docs/), [DirectAdmin documentation](https://docs.directadmin.com/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Upgrading MariaDB safely on DirectAdmin: 10.6 → 10.11 → 11.8 → 12.3 with CustomBuild](https://srvscripts.com/guides/upgrade-mariadb-directadmin-custombuild/) · [How to upgrade MySQL 8.0 to MariaDB 11.8 in WHM without losing databases](https://srvscripts.com/guides/upgrade-mysql-8-to-mariadb-11-8-whm/) · [MariaDB 10.6 is end-of-life: upgrade paths to 11.8 or 12.3 for hosting servers](https://srvscripts.com/guides/mariadb-10-6-end-of-life/).

## Frequently asked questions

### Does converting MySQL to MariaDB work the same way on cPanel?

The data work is identical, but on cPanel the engine change goes through WHM » SQL Services » MySQL/MariaDB Upgrade rather than CustomBuild, so that `whmapi1 current_mysql_version` and the backup system know which engine is installed.

### How long does a MySQL to MariaDB conversion take?

Budget roughly one to two hours per 50 GB of data for the dump and restore combined, plus the CustomBuild rebuild; the databases are unavailable for the whole window, so announce it in advance.

### Can I go back to MySQL if the restore fails?

Yes. The data directory was moved aside rather than deleted, and CustomBuild keeps its own copy when `mysql_backup` is set to yes, so switching `mysql_inst` back to mysql, rebuilding and restoring the directory returns the server to its previous state.