MariaDB 10.6 reached end of life on 2026-07-06, and a lot of DirectAdmin servers built two or three years ago are still on it. CustomBuild tracks 10.6, 10.11, 11.4, 11.8 and 12.3 (added in 1.696), and since 1.693 it no longer offers MariaDB 10.3 or MySQL 5.7 at all. The upgrade itself is a handful of commands, but the version jumps are large and each one removes configuration variables or reserves words that a working server may depend on. Step through the LTS releases rather than jumping straight to 12.3.
Applies to DirectAdmin CustomBuild; MariaDB 10.6 to 10.11, 11.8 and 12.3
Table of Contents
Short answer: Take a logical dump, comment out variables the target release removed, set innodb_fast_shutdown=0, then in /usr/local/directadmin/custombuild run ./build set mysql_backup yes, ./build set mysql_inst mariadb, ./build set mariadb 10.11 and ./build mariadb, which installs the packages and runs mariadb-upgrade. Repeat with 11.8 and, once applications are confirmed on it, 12.3; there is no in-place downgrade, so the dump and the CustomBuild data-directory copy are the rollback.
Why step, and where to stop
MariaDB supports in-place upgrades across one or two major versions, and CustomBuild’s mariadb target runs mariadb-upgrade for you. Skipping from 10.6 to 12.3 in one hop is not a tested path and leaves you with no intermediate state to fall back to. The sensible stops are 10.11 (LTS until February 2028), 11.8 (LTS until June 2028) and 12.3 (LTS from May 2026 until June 2029). 11.4 is a valid LTS as well, supported to May 2029, but going 10.11 to 11.8 directly is supported and saves a maintenance window.
Whether you stop at 11.8 or continue to 12.3 depends on the applications. 12.x introduces caching_sha2_password, new reserved words such as CONVERSION and TO_DATE, and drops the big_tables, large_page_size and storage_engine variables. Older PHP applications with column names that collide with new reserved words fail after the upgrade with syntax errors, and nothing in the upgrade tool warns you in advance.
Note also that switching between MariaDB and MySQL in place is no longer supported by CustomBuild. A server on MySQL 8.0 that wants MariaDB is a dump-and-restore migration, not an upgrade.
Before the first hop
Take a logical dump as well as the CustomBuild backup, because the CustomBuild backup is a copy of the data directory that is only restorable to the same major version:
mariadb-dump --all-databases --single-transaction --routines --events --triggers > /root/all-$(date +%F).sqlThen check the running configuration for variables that the target release removes. On 10.6 to 10.11 the usual suspects are innodb_log_write_ahead_size, wsrep_strict_ddl and keep_files_on_create; if any appear in /etc/my.cnf or a file under /etc/my.cnf.d/, comment them out now, because a removed variable stops the server from starting at all after the upgrade.
Set a clean shutdown so that InnoDB writes everything to the tablespaces instead of relying on redo-log replay across versions:
mariadb -e "SET GLOBAL innodb_fast_shutdown=0;"Finally, check what CustomBuild believes it is running and whether a backup is enabled:
cd /usr/local/directadmin/custombuild
./build options | grep -E 'mysql_inst|mariadb=|mysql_backup'
./build versions | grep -i mariadbRunning the upgrade
Each hop is the same four commands with a different version number. For 10.6 to 10.11:
cd /usr/local/directadmin/custombuild
./build set mysql_backup yes
./build set mysql_inst mariadb
./build set mariadb 10.11
./build mariadbWith mysql_backup yes, CustomBuild copies the data directory to /usr/local/directadmin/custombuild/mysql_backups/ before it touches anything. Watch the output: the target downloads the packages, stops the server, installs, starts it and runs mariadb-upgrade. A failure between the stop and the start is the moment to inspect /var/lib/mysql/*.err or journalctl -u mariadb rather than re-running blindly.
Once the server is up, confirm the version and let the applications run on it for a period before the next hop. A day is enough on a busy server to surface reserved-word problems. Then repeat with ./build set mariadb 11.8 and ./build mariadb, and later with 12.3.
The 11.x line changed the canonical binary names to mariadb, mariadb-dump and mariadb-upgrade. The mysql* symlinks are still shipped, but check that any cron jobs or backup scripts calling mysqldump still work after each hop rather than assuming.
Configuration after each hop
DirectAdmin’s socket path is /run/mysql/mysql.sock; CustomBuild keeps the panel’s own client configuration in /usr/local/directadmin/conf/mysql.conf and the DA my.cnf in sync, but a customer-side application with a hard-coded socket in wp-config.php or a .env file needs the same path. 11.4 and later ship different defaults for several InnoDB and connection settings, so review max_connections, innodb_buffer_pool_size and tmp_table_size after the 11.8 hop instead of assuming the tuned values from 10.6 carried across. Our MySQL health snapshot script gives a quick view of the effective values and the connection headroom.
Rolling back
There is no in-place downgrade. If a hop fails and the server will not start, the recovery is to reinstall the previous version with ./build set mariadb 10.11 and ./build mariadb, then either restore the CustomBuild data-directory backup from mysql_backups/ or import the logical dump. The data-directory copy is faster; the logical dump is the one that works if the directory copy was taken while the server was mid-write, which is why we take both.
Verify
After the final hop:
mariadb -e "SELECT VERSION();"
mariadb-upgrade --version
mariadb -e "SHOW ENGINE INNODB STATUS\G" | grep -i 'log sequence'
tail -n 50 /var/lib/mysql/$(hostname).err | grep -Ei 'error|warn'Log into the panel and open phpMyAdmin from a user account, which proves that DirectAdmin’s own credentials in mysql.conf still work. Then run a quick write test against a customer database: log in to WordPress, save a post, and check that nothing lands in the error log. Keep the pre-upgrade dump for at least a week before deleting it.
Upgrade MariaDB DirectAdmin at a glance
Official documentation: MariaDB documentation, DirectAdmin documentation, Linux man pages.
Related guides: Converting MySQL to MariaDB (and why in-place switching is no longer supported) · Migrating cPanel accounts to DirectAdmin and the post-migration checklist · Migrate DirectAdmin to cPanel with the WHM Transfer Tool or pkgacct-da.
Frequently asked questions
Can I upgrade MariaDB 10.6 directly to 11.8 on DirectAdmin?
MariaDB supports upgrades across one or two major versions, so 10.6 to 10.11 and 10.11 to 11.8 are the tested hops. Going straight from 10.6 to 11.8 or 12.3 skips the intermediate state you would fall back to if something breaks, so step through 10.11 first.
How long does a CustomBuild MariaDB upgrade take?
The package swap and mariadb-upgrade run typically finish within ten to twenty minutes; the data-directory copy made by mysql_backup yes adds time proportional to the size of /var/lib/mysql. Sites are unavailable for the stop-install-start window only.
Does CustomBuild still let me switch from MySQL to MariaDB in place?
No. Recent CustomBuild releases removed the in-place engine switch, so a MySQL 8.0 server that wants MariaDB needs a full dump, a fresh MariaDB install and a restore, and the reverse direction is the same.
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
- DirectAdmin CustomBuild; MariaDB 10.6 to 10.11, 11.8 and 12.3
- Last full review
- Next review