How to Upgrade MySQL/MariaDB in WHM Without Breaking Sites

If you've logged into WHM lately and noticed a banner nudging you toward a newer MariaDB version, you're not alone — cPanel has been pushing customers off older database versions as they hit end-of-life. The upgrade itself is usually painless, but "usually" is doing a lot of work in that sentence. Skip a step and you can end up with sites that can't connect, tables that convert wrong, or a WordPress install spitting out a database error page the morning after. Here's how to do it without any of that.

Why This Comes Up

MariaDB versions have a support lifecline just like PHP does. Once a version goes end-of-life, it stops getting security patches, and cPanel/WHM will start warning you — sometimes insistently — to move to a supported release. On a shared cPanel server this is usually handled by SkyServer during scheduled maintenance, but if you're on a VPS or a server where you manage WHM yourself, the upgrade is on you.

The jump is rarely MariaDB 10.3 straight to 10.11 in one go. WHM's MySQL/MariaDB Upgrade tool (under Software in WHM) walks you through supported version paths, and it won't offer you a hop that isn't supported.

Before You Touch Anything: Back Up

This is the one step people skip because "it's just a version bump." Don't. A version upgrade rewrites system tables and can touch the on-disk format for some storage engines. Take a full backup before you start:

• In WHM, run Backup Configuration to confirm backups are current, or trigger a manual backup for the accounts on the server.
• For a quick belt-and-suspenders copy, dump everything from the command line:

mysqldump --all-databases --routines --triggers --events > /root/pre-upgrade-backup-$(date +%F).sql

Check the file actually has content (ls -lh it) before you go further. A zero-byte backup file has ruined more than one Saturday.

Step 1: Check What You're Running and What's Supported

In WHM, go to Software → MySQL/MariaDB Upgrade. It shows your current version and lists the versions you can upgrade to directly. If your version is old enough, you may need to go through an intermediate version first — for example 10.3 → 10.6 → 10.11 rather than jumping straight to the newest release. The tool will only show you valid next steps, so don't try to force a version via command line unless you know exactly what you're doing.

While you're there, note which storage engines your databases use. Almost everything on a modern WordPress or PHP site is InnoDB, but if you've got old MyISAM tables kicking around from a legacy app, flag them — MyISAM has occasionally had rough edges across major version jumps.

Step 2: Check for Deprecated Features

Every MariaDB major version drops a few things. Two that trip people up most often:

If you've got a custom /etc/my.cnf with hand-tuned settings, review it against the release notes for your target version before upgrading. WHM's upgrade tool generally preserves your config, but a directive MariaDB no longer recognizes will stop the service from starting cleanly.

Step 3: Run the Upgrade

From WHM → MySQL/MariaDB Upgrade, select your target version and start the process. WHM handles the repository swap, package updates, and runs mysql_upgrade (or its MariaDB equivalent) automatically to fix up system tables. Expect a brief service restart — a few seconds to a couple of minutes depending on how many databases you have and how large they are.

Do this during a low-traffic window. Even a clean upgrade means a short MySQL restart, and every site on the server depends on that service being up.

Step 4: Verify Before You Walk Away

Don't close the tab the moment the progress bar finishes. Check these:

• Confirm the service is actually running: systemctl status mariadb (or mysqld, depending on your setup).
• Check the new version reports correctly: mysql --version.
• Load two or three sites that use the database heavily — ideally a WordPress site and anything with a custom app — and click around. Login, a search, an admin page that hits the DB.
• Tail the error log for a minute: tail -f /var/log/mysqld.log or /var/log/mariadb/mariadb.log, watching for warnings about deprecated syntax or failed table checks.

Common Post-Upgrade Symptoms and Fixes

Symptom: "Error Establishing a Database Connection" on WordPress Sites

Cause: almost always the MySQL service failed to restart cleanly, usually because of a my.cnf directive the new version rejects.

Fix: check the service status and error log first:

systemctl status mariadb
journalctl -xeu mariadb --no-pager | tail -50

If you see a line like unknown variable pointing at a specific config directive, comment it out in /etc/my.cnf, then restart the service. This is exactly why you reviewed the config before upgrading — but if you skipped that, the error log will tell you precisely what to remove.

Symptom: A Table Shows as "Marked as Crashed" After Upgrade

Cause: usually an interrupted mysql_upgrade run, or a table that was already slightly corrupted before you started and the version jump exposed it.

Fix: repair it directly:

mysqlcheck -u root -p --auto-repair --check --all-databases

Run this after any upgrade as a matter of course — it's a fast, safe pass that catches table-level issues before your customers do.

Symptom: A Custom App Can't Authenticate Anymore

Cause: a change in default authentication plugin behavior between versions, most commonly affecting connections from older client libraries (an old PHP mysqli extension, a legacy Python or Node connector).

Fix: reset the affected user's password to force it onto the current auth method:

ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'the-same-or-new-password';
FLUSH PRIVILEGES;

If the app connects from a specific host rather than localhost, make sure you're altering the matching 'user'@'host' entry — MariaDB treats those as distinct accounts.

Prevention for Next Time

• Subscribe to WHM's update notifications so you see an EOL warning months out, not the week it stops getting patches.
• Keep /etc/my.cnf lean. Every custom directive is one more thing that can break across a version boundary — comment why each one is there so future-you (or SkyServer support) knows if it's still needed.
• Test major version jumps on a staging server or a VPS snapshot first if you're running anything business-critical outside of standard shared hosting.
• Schedule the upgrade, don't let WHM auto-run it unattended on a production box you haven't backed up recently.

Frequently Asked Questions

Will upgrading MariaDB break my WordPress site?

Not if you back up first and follow the steps above. WordPress itself is compatible with a wide range of MariaDB versions — the risk is almost always in a stale my.cnf directive or a plugin doing something unusual with raw SQL, not WordPress core.

Do I need to upgrade PHP at the same time as MariaDB?

No, they're independent. MariaDB version and PHP version don't need to move together, though it's worth checking your PHP MySQL extension (mysqli/PDO) is reasonably current so it speaks the newer authentication protocol without issues.

How long does the upgrade actually take?

The WHM tool itself usually finishes in a few minutes for a small-to-medium server. The MySQL service restart is seconds. Budget extra time for your own verification pass afterward — that's the part people rush.

Can I roll back if something goes wrong?

There's no clean one-click rollback in WHM once the upgrade completes — this is exactly why the pre-upgrade backup and, ideally, a VPS snapshot matter. Restoring from a snapshot is far faster than trying to downgrade MariaDB packages by hand.

Does SkyServer handle this for me on shared hosting?

On shared and reseller hosting, SkyServer manages MariaDB upgrades as part of routine server maintenance, scheduled to minimize impact. If you're on a VPS with root access, the upgrade is in your hands using the steps above — open a support ticket if you'd like a second pair of eyes before you start.