A MariaDB major-version upgrade changes server binaries, system tables, defaults, and sometimes query behavior. Treat it as a planned database migration, not a routine package update.
This guide explains how to upgrade MariaDB 10.11 to MariaDB 11.4 on Rocky Linux 9, AlmaLinux 9, RHEL 9, or CentOS Stream 9. It follows a documented long-term-support upgrade path and puts backup, compatibility testing, and rollback first.
The original article upgraded an old CentOS installation to MariaDB 10.4. Do not reuse that obsolete repository. If your starting version is older than 10.11, uses Galera, replication, a hosting panel, or vendor packages, follow the exact MariaDB or product-vendor upgrade path for that environment.
Read This Before Upgrading
- Schedule a maintenance window and tell application owners.
- Test the upgrade on a restored copy of production data.
- Keep a verified logical backup and a physical backup or snapshot.
- Store backups outside the database server.
- Record the current packages, repository, configuration, plugins, and storage engines.
- Plan rollback as a restore, because major-version downgrades are not supported.
For a critical production service, a staged migration through a newer replica or a new server can reduce downtime and risk. An in-place upgrade is simpler but gives you a smaller rollback window.
Confirm the Current MariaDB Installation
mariadb --version sudo mariadb -e 'SELECT VERSION();' sudo systemctl status mariadb --no-pager rpm -qa | grep -i '^MariaDB\|^mariadb' | sort dnf repolist --enabled
Do not mix the operating system’s lowercase mariadb-* packages with MariaDB.org’s uppercase MariaDB-* packages. Identify which source owns the current installation before changing repositories.
Check Database Health and Compatibility
sudo mariadb-check --all-databases sudo mariadb -e 'SHOW ENGINES;' sudo mariadb -e 'SHOW PLUGINS;' sudo mariadb -e 'SHOW VARIABLES LIKE "datadir";' sudo mariadb -e 'SHOW VARIABLES LIKE "innodb_fast_shutdown";'
Review MariaDB’s 10.11-to-11.4 incompatible changes. Version 11.0 rewrote parts of the optimizer, so important queries can choose different execution plans. Remove or replace configuration options that no longer exist. Test connectors, authentication plugins, stored routines, events, application queries, and backups.
Create and Verify Backups
Use the backup method already tested for your workload. A logical dump is portable but may be slow on a large database:
sudo sh -c 'mariadb-dump --all-databases --single-transaction --routines --events --triggers > /root/mariadb-preupgrade.sql' sudo ls -lh /root/mariadb-preupgrade.sql sudo tail -n 20 /root/mariadb-preupgrade.sql
Do not put a database password directly in the command line. For large or busy servers, MariaDB recommends mariadb-backup. A filesystem copy of /var/lib/mysql is not automatically a consistent backup while MariaDB is running.
Copy the dump to protected off-server storage and perform a restore test on another machine. Our mysqldump backup guide explains logical restore checks.
Save Configuration and Package Information
sudo cp -a /etc/my.cnf /root/my.cnf.preupgrade 2>/dev/null || true sudo cp -a /etc/my.cnf.d /root/my.cnf.d.preupgrade 2>/dev/null || true sudo rpm -qa | sort > /root/rpm-list-preupgrade.txt sudo mariadb -e 'SHOW GLOBAL VARIABLES;' > /root/mariadb-variables-preupgrade.txt
Also preserve application credentials, grants, monitoring rules, and repository files using your secure backup process.
Configure the MariaDB 11.4 Repository
MariaDB provides a repository setup script. Download it first so you can review what will run:
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup -o /tmp/mariadb_repo_setup less /tmp/mariadb_repo_setup sudo bash /tmp/mariadb_repo_setup --mariadb-server-version="mariadb-11.4"
Confirm that the repository points to the intended version and inspect package candidates:
dnf repolist --enabled dnf list --showduplicates MariaDB-server | tail -n 20
Stop MariaDB Cleanly
Put applications into maintenance mode and stop writes. Confirm innodb_fast_shutdown is appropriate for the documented upgrade path, then stop MariaDB:
sudo systemctl stop mariadb sudo systemctl is-active mariadb ps -ef | grep '[m]ariadbd'
Do not continue if a server process is still writing to the data directory.
Replace the Server Packages
MariaDB’s RPM major-upgrade procedure removes the old server package before installing the new one. Removing packages should preserve the data directory, but that is not a rollback plan—your verified backups are.
sudo dnf remove MariaDB-server sudo dnf install MariaDB-server MariaDB-client MariaDB-backup
Read the transaction summary before confirming. Package names differ when upgrading from distribution packages. Do not blindly remove a large dependency set; stop and reconcile the repository/package source.
Review MariaDB Configuration
Compare the saved files with any new sample files and version-specific incompatible changes. Remove unsupported options and keep custom settings only when you understand their 11.4 behavior.
sudo grep -R '^[^#[:space:]]' /etc/my.cnf /etc/my.cnf.d 2>/dev/null sudo mariadbd --verbose --help > /tmp/mariadbd-help.txt
Start MariaDB and Run mariadb-upgrade
sudo systemctl start mariadb sudo systemctl status mariadb --no-pager sudo journalctl -u mariadb -n 100 --no-pager sudo mariadb-upgrade sudo systemctl restart mariadb
mariadb-upgrade updates system tables and checks table compatibility. Do not skip it merely because the service starts.
Verify the Upgrade
mariadb --version sudo mariadb -e 'SELECT VERSION();' sudo mariadb-check --all-databases sudo systemctl is-enabled mariadb sudo systemctl is-active mariadb
Then run application smoke tests: login, read, write, update, background jobs, reports, backups, and monitoring. Compare important query plans and latency with pre-upgrade results. Watch MariaDB and application logs during the maintenance window.
Rollback Plan
Do not try to downgrade the new data directory in place. MariaDB states that major-version downgrades are not supported. If the upgrade fails badly, stop the new service, rebuild the old version in a clean environment, and restore the pre-upgrade backup or snapshot according to your tested recovery plan.
Special Cases
- Galera Cluster: use the Galera-specific rolling-upgrade documentation.
- Replication: upgrade and validate replicas before the primary, following MariaDB’s topology guidance.
- cPanel, Plesk, or another panel: use the panel’s supported database-upgrade tool and version matrix.
- MySQL to MariaDB: this is a migration with separate compatibility concerns, not the same procedure.
- Very large databases: prefer staged migration or replica promotion to reduce downtime and improve rollback options.
Frequently Asked Questions
Can I upgrade directly from MariaDB 10.4 to 11.4?
MariaDB supports broad major-version upgrade compatibility, but you must read every relevant version-specific incompatibility, validate plugins and configuration, and test with restored data. A staged migration is safer for an old production server.
Is a copy of /var/lib/mysql a backup?
Not by itself while MariaDB is running. Use a consistent logical dump, mariadb-backup, or a coordinated snapshot method and prove that it restores.
Can I downgrade if an application breaks?
Do not downgrade a major-version data directory in place. Restore the old environment and pre-upgrade backup.
Conclusion
A safe MariaDB upgrade is mostly preparation: identify the exact starting point, read incompatibilities, test a restore, preserve configuration, schedule downtime, run mariadb-upgrade, and validate the application. Keep the old environment and backups until the new server has passed real workload checks.
For related administration, read our database and user management guide and secure remote database access guide.
Reviewed and updated: August 2026. The process was checked against MariaDB’s official guides for upgrading 10.11 to 11.4, major-version upgrades, and repository setup.
Comments