MariaDB Won't Start After Upgrade: Fix It Now

I Know This Error Is Infuriating

You upgraded MariaDB (maybe from 10.5 to 10.6, or 10.6 to 10.11), and now it won't start. You see something like mariadb.service: main process exited, code=exited, status=1/FAILURE in journalctl -u mariadb. It's happened to me more times than I'd like to admit. Let's get it running.

The Fix: Bypass the Broken Plugin

Most of the time, the culprit is an incompatible plugin — often unix_socket or auth_socket if you're on Ubuntu, or a third-party plugin that didn't survive the upgrade. MariaDB is strict: if a plugin fails to load, the whole service crashes.

1. Start MariaDB with plugin loading disabled. This lets you get in and remove the bad plugin.

   systemctl set-environment MYSQLD_OPTS="--skip-plugin-load"
   systemctl start mariadb

   If it starts, you're in. If not, check the logs: journalctl -u mariadb -n 50 — look for Can't open shared library or Plugin 'XXX' is disabled.
2. Drop the problematic plugin. Connect to MariaDB:

   mysql -u root

   Then run:

   UNINSTALL SONAME 'unix_socket';
   -- Or whatever plugin name you see in the error, e.g. 'auth_socket'

   If you see ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded, don't panic — that means the plugin wasn't loaded, so skip this step.
3. Restart normally.

   systemctl unset-environment MYSQLD_OPTS
   systemctl restart mariadb

   If it starts, you're done. If not, move to the next section.

Why This Works

When MariaDB upgrades, it often ships with new plugin versions. If an old plugin binary stays in the plugin directory (/usr/lib/mysql/plugin/ on most systems), MariaDB tries to load it and fails. The --skip-plugin-load flag tells MariaDB to skip all plugin loading, including the built-in ones like mysql_native_password — that's why you need to unset it after fixing. Bypassing plugins is the cleanest, fastest recovery. It's not a permanent solution, but it's how you get back on your feet.

Less Common Variations

InnoDB Corruption or Version Mismatch

Sometimes the issue isn't a plugin — it's an InnoDB log file from an older version. Starting MariaDB with --innodb-force-recovery=1 can help:

systemctl set-environment MYSQLD_OPTS="--innodb-force-recovery=1"
systemctl start mariadb

Missing MySQL System Tables

On a few rare occasions (I've seen this with MariaDB 10.6 on Gentoo), the mysql system tables get corrupted. Run mysql_upgrade to rebuild them:

mysql_upgrade --force

Config File Syntax Error

Check /etc/mysql/mariadb.conf.d/ or /etc/my.cnf.d/ for typos. A missing semicolon or a wrong value can crash the service. Run:

mariadbd --verbose --help 2>&1 | head -20

Prevention: Don't Let This Happen Again

• Test upgrades in a staging environment first. Especially if you're jumping major versions (e.g., 10.3 to 10.11). MariaDB's upgrade guide recommends stepping through each major version, but I've done direct upgrades that worked fine — until they didn't.
• Backup your plugin directory. Before upgrading, copy /usr/lib/mysql/plugin/ somewhere safe. If the upgrade breaks, you can restore the old plugins and start with --skip-plugin-load to remove them gracefully.
• Check the plugin list before upgrading. Run SHOW PLUGINS; in MySQL. If you see third-party plugins (like ha_rocksdb or custom auth plugins), note them. They're the most likely to break.
• Keep your config minimal. I've seen people load a dozen plugins they don't use. The fewer you load, the fewer things can break. Comment out any plugin-load-add lines in configs that you don't actually need.

That's it. You should be back up in under five minutes. If you're still stuck after all this, check your full error log with journalctl -u mariadb -n 200 and look for the first error — that's almost always the real cause. Good luck.