MySQL or MariaDB won't start after a crash

What this is#

The database died and won't come back up. This is the guide where order of operations matters most: the wrong first move can convert a recoverable situation into data loss, so the sequence below is arranged to be safe at every step. The single rule: read before you write, diagnose from logs before changing anything, and take a copy before any risky action.

Step 0: read the error log#

Everything MySQL/MariaDB knows about why it won't start is in its error log:

journalctl -u mariadb -n 100        # or -u mysql
tail -100 /var/log/mysql/error.log  # location varies by distro

The last screen of output nearly always names the cause directly. Match it below.

Step 1: rule out the two usual killers#

• Full disk (or inodes). InnoDB refuses to start, or crashed in the first place, when it can't write: Disk full, errno 28, or just cryptic write failures. df -h && df -i, and if either is at 100%, fix that first, the disk-full guide, then start the service. This resolves a large share of "corrupt database" panics with zero database surgery.
• The OOM killer. If memory ran out, the kernel likely killed mysqld mid-write, and may kill it again on startup while it replays. On Linux VPS, OOM kills don't show in your own logs, run My VPS is Down, which reports them. If OOM is the story, shrink innodb_buffer_pool_size (the usual oversized culprit) or add memory before restart attempts, or you'll crash in a loop.

Step 2: let normal crash recovery run#

InnoDB is designed to survive crashes: on startup it replays its redo log and rolls back unfinished transactions on its own. On a large or busy database this can take many minutes while the service looks "stuck", watch the error log in a second terminal (journalctl -u mariadb -f); as long as recovery messages keep progressing, wait. Restarting it mid-recovery restarts the recovery.

Step 3: take a copy before anything risky#

If recovery genuinely fails (the log shows a crash during recovery itself, or names corrupted pages), stop. Before any forced measure, copy the raw data directory somewhere safe:

systemctl stop mariadb
cp -a /var/lib/mysql /root/mysql-datadir-copy

Every step after this point becomes reversible. (Check df -h first, you need the space.)

Step 4: innodb_force_recovery, the escape hatch, not a fix#

innodb_force_recovery starts InnoDB while skipping parts of its own safety machinery so you can get your data out. Understand the contract: it's a read-only rescue mode for dumping, not a setting that repairs anything, and higher levels can themselves corrupt data.

1. Add to the [mysqld] section of your config: innodb_force_recovery = 1, and try to start. If it won't, step up one level at a time, 2, 3, 4, using the lowest level that starts.
2. Once it starts, do not resume normal operation. Dump everything immediately: mysqldump --all-databases > /root/all.sql.
3. Treat levels 4 and above as data-affecting (they skip undo/redo application), only with your Step 3 copy in place, and if 1 to 3 didn't start it, this is the moment to consider asking for direction before going further.
4. Rebuild clean: stop the server, move the broken data directory aside, reinitialize (or reinstall the DB packages), start without force_recovery, and load /root/all.sql. Remove the setting from the config, leaving it on silently breaks the database later.

If you have backups, weigh them first#

A nightly dump or a Nightly Backups image from before the crash may cost you a day of data but zero surgery, often the better trade than hours of forced recovery for a database that was corrupted anyway. This is also the standing argument for the dump-nightly cron: dumps restore cleanly, always.

Prevent the rerun#

The crash had a cause: usually OOM (right-size the buffer pool against your plan's RAM), a full disk, or hard power-offs during writes. And make sure the service is enabled to start on boot while you're here.

Related questions#

• "MariaDB won't start after my VPS crashed, what's the safe order of steps?"
• "What is innodb_force_recovery and is it safe?"
• "How long does InnoDB crash recovery take?"
• "MySQL says disk full or errno 28 and won't start."
• "Should I restore a backup or repair the database?"