MySQL Crashed? 5 Fixes That Actually Work (2026)

What Does “MySQL Crashed” Actually Mean?

A crash means the MySQL daemon terminated unexpectedly. Not a clean shutdown. Not a restart you triggered. The process just died. Symptoms vary: clients lose connections, websites throw database errors, and monitoring goes red. In the host’s error log—usually /var/log/mysql/error.log—you’ll find a telltale line like “mysqld got signal 11” or “Fatal error: cannot allocate memory”.

Crashes fall into a few common buckets. Resource starvation. Corrupted data files. Buggy server code. Or misconfigured limits. Knowing which bucket you’re in changes everything. A blind restart might buy you an hour. Or it might do nothing. That’s why a side-by-side comparison of recovery methods saves your weekend.

The Five Recovery Methods at a Glance

We’ll compare five go‑to fixes. Immediate restart. Table repair. Configuration tuning. Backup restore. Version upgrade. Each one targets a different failure mechanism, and the risk profile varies wildly.

Here’s the high‑level trade‑off: Restart is fast but masks root cause. Repair fixes data corruption but only for the tables you explicitly target. Tuning addresses resource limits but requires understanding your workload. Restore is bulletproof when you have a backup—and catastrophic when you don’t. Upgrade kills bugs but may introduce new ones. The rest of this article walks through each method, including the exact commands, failure patterns, and when to pick one over the others.

Method 1: Restart MySQL — Fast but Blind

Sometimes the crash is a one‑off. A spike in connections exhausted a limit. The OOM killer struck. A restart gets you back online in under a minute. On systemd‑based hosts, it’s just:

`systemctl restart mysql`

If you’re on an older init system, use `service mysql restart` or `/etc/init.d/mysql restart`. After it comes up, tail the error log for 10–15 minutes. If it stays quiet, you might be fine.

But don’t trust it. The root cause is still lurking. I’ve seen instances where a restart fixes things for exactly 23 hours, then crashes again because a cron job runs at 3 a.m. and fills a tmpdir. So use this method only when downtime is unacceptable and you’re able to investigate immediately afterward. Never rely on a restart as the permanent fix—schedule a maintenance window to dig deeper.

• Downtime: < 1 minute
• Risk: Low, but crash may recur
• Best when: Crash was plainly transient (e.g., OOM kill, momentary disk full)

Method 2: Repair Corrupted Tables — Data Salvation

Corrupted MyISAM or InnoDB tables are a classic crash trigger. One damaged index, and a SELECT can bring the server down. MySQL tries to recover InnoDB automatically on startup, but sometimes the redo logs are so broken that it gives up. That’s when you need repair tools.

For MyISAM tables, `myisamchk` is your friend. Run it from the command line while MySQL is stopped:

`myisamchk --silent --force --fast --update-state /var/lib/mysql/*/*.MYI`

For InnoDB, you’re mostly at MySQL’s mercy. If InnoDB recovery fails, start MySQL with `innodb_force_recovery` from 1 to 6 in my.cnf. Level 1 is the gentlest; level 6 is desperate. After it starts, dump all databases with `mysqldump --all-databases`, remove innodb_force_recovery, restore the dump. Messy. Time‑consuming. But it pulls data back from truly mangled system tablespaces.

So what if the table repair returns errors? That means file‑level corruption. Skip to Method 4. And always take a file‑level backup before running any repair tool. You might make things worse.

• Downtime: Minutes to hours, depending on data size
• Risk: Medium (repair can fail or corrupt data further)
• Best when: Error log points to specific table corruption

Method 3: Tune MySQL Configuration — Starvation Sucks

Memory exhaustion crashes are depressingly common. A host with 2 GB RAM and a default innodb_buffer_pool_size of 128 MB might seem fine. Then a reporting query sorts 1 GB of data in a temporary table. Boom. Signal 11.

Check the error log for “cannot allocate memory” or “Fatal error”. Then examine your my.cnf. Lower `innodb_buffer_pool_size` to 50–70% of physical RAM. Raise `tmp_table_size` and `max_heap_table_size` if temp tables spill to disk and cause I/O storms. Bump `open_files_limit` if you see “Too many open files” in the log.

Here’s the catch: tuning blindly can trigger new crashes. A buffer pool that’s too small leads to furious disk reads and lock contention. So monitor with `SHOW ENGINE INNODB STATUS` and `vmstat 1` for a few hours. The goal is a config that matches your workload. If you can’t get it stable, consider vertical scaling first—more RAM or faster storage—before attempting exotic parameter tweaks.

This method fixes the root cause when resource limits are the trigger. But it only works if you correctly diagnose the limit. And it requires a restart to apply most memory-related changes.

• Downtime: Minutes (restart required)
• Risk: Low–Medium (misconfiguration can make things worse)
• Best when: Logs indicate memory, file descriptor, or connection limit exhaustion

Method 4: Restore from Backup — Last Resort, Real Safety

When MySQL refuses to start, or starts but crashes on any query, the nuclear option is a backup restore. I keep my last good backup on a separate machine. `mysqldump` dumps are easiest. `Percona XtraBackup` restores are faster for huge datasets.

The process is straightforward: stop MySQL, move the corrupt datadir aside (`mv /var/lib/mysql /var/lib/mysql.corrupt`), create a fresh datadir, restore the backup, fix permissions, start MySQL. If you have binary logs, you can replay to the point just before the crash. That’s point-in-time recovery—golden, but delicate.

The risk? Your backup is stale. Or corrupted. Test backups weekly. I’ve seen teams restore a backup from three hours ago and lose revenue-critical orders because the transaction logs were on the now‑dead server. Always test a backup on a staging clone before trusting it in production. And keep at least two recent backups on different physical media.

This method is the only guarantee against file‑level corruption that survives table repair and forced recovery. It’s also the most disruptive. Plan for hours of downtime and customer communication.

• Downtime: Hours (depending on backup size and restore method)
• Risk: Low for data safety, high for business continuity
• Best when: File-level corruption, failed repair attempts, or total inability to start MySQL

Method 5: Upgrade MySQL Version — Bug Escape

Occasionally, the crash is a known bug fixed in a later release. You check the MySQL bug tracker, find a match, and realize your 8.0.27 has a full‑text search crash fixed in 8.0.32. Upgrading is the cure.

Don’t leap without looking. Upgrades can break replication, change optimizer behavior, and deprecate variables. I test the upgrade on a staging clone first. Dump the production schema, load it into the clone, run the upgrade, and hammer it with load tests. Only then schedule production downtime.

For minor upgrades (8.0.27 → 8.0.32), in‑place upgrade is usually safe: stop MySQL, replace binaries, run `mysql_upgrade`, start. For major versions (5.7 → 8.0), you’ll want a logical dump and restore. The upgrade method itself can trigger a crash if you’re not careful. So read the release notes. The “Upgrading MySQL” chapter of the reference manual is not optional reading.

This fix is slow but permanent for bug‑induced crashes. It’s also the only method that future‑proofs you if multiple crashes share the same root bug.

• Downtime: 30 minutes to several hours
• Risk: Medium (version incompatibilities, new bugs)
• Best when: Error log stack traces match a known MySQL bug report

How to Choose: A Decision Framework

No single method fits all crashes. Use this quick decision tree based on what you see in the error log and how urgently you need to be online.

If downtime is burning money and the error suggests a transient condition (OOM, disk full), restart first. Then investigate. If the log points to a specific table in myisamchk or InnoDB recovery failure, repair that table. If it’s a resource limit you can measure—memory, files, connections—tune the config. If the server flat‑out refuses to start after forced recovery, restore the backup. And if the crash is reproducible and matches a known MySQL bug, schedule an upgrade.

You’ll often combine methods. A restart gets you running; a config tune prevents the next crash; a repair fixes the data that triggered it. The order matters. Always fix immediate availability, then root cause, then data integrity. And never touch a production database without a verified backup.

• Restart: first response when the crash looks transient
• Repair: when error log names a specific table and you need data preservation
• Tune: when resource usage metrics align with crash timing
• Restore: when everything else fails
• Upgrade: when the bug report says your version is doomed