MySQL Crashed Table Error: How to Diagnose and Repair It

Overview

A MySQL crashed table error means one or more database tables have become corrupted and can no longer be read or written to correctly. You’ll usually see this surface as a WordPress white screen, a PHP error like Table './yourdb/wp_options' is marked as crashed and should be repaired, or a web app that suddenly returns 500 errors. The MySQL crashed table problem is almost always recoverable — but how you fix it depends on your storage engine and how the crash happened.

Crashes most commonly happen after an unexpected server shutdown (power loss, OOM killer, a hard reboot), a failed MySQL upgrade, or disk I/O errors. MyISAM tables are particularly vulnerable because they don’t support crash-safe transactions the way InnoDB does. If you’re running older WordPress plugins, legacy PHP apps, or anything built before ~2015, there’s a decent chance some of your tables are still MyISAM.

This article covers the full repair process for both MyISAM and InnoDB tables, using tools available in cPanel, WHM, and directly from the command line on any Linux VPS or dedicated server.

Prerequisites

• SSH access to your server, or access to phpMyAdmin via cPanel
• Your MySQL/MariaDB root credentials, or a database user with REPAIR privileges on the affected database
• MySQL 5.7+, MySQL 8.0, or MariaDB 10.4+ (commands in this article apply to all)
• A current database backup — take one before touching anything
• If you’re on shared hosting without SSH, you’ll need phpMyAdmin access (covered in Step 3)

Step-by-Step Instructions

Step 1: Confirm Which Table Is Crashed

Before running any repair, identify exactly which table is affected. Check your PHP error log or MySQL error log first.

On cPanel servers, the MySQL error log is typically at:

/var/lib/mysql/$(hostname).err

Or check it directly from the command line:

sudo tail -n 100 /var/log/mysql/error.log

You’re looking for lines like:

Table './mysite_db/wp_posts' is marked as crashed and should be repaired

Make note of the database name and table name — you’ll need both.

Step 2: Back Up the Database Before You Do Anything

⚠ Warning: Repair operations can occasionally make corruption worse if the underlying disk has issues. Always dump a copy first.

mysqldump -u root -p your_database_name > /root/your_database_name_backup_$(date +%F).sql

Replace your_database_name with the actual database name from Step 1. If mysqldump fails because the crashed table blocks the dump, add --ignore-table=your_database_name.crashed_table to skip just that table temporarily.

Step 3: Repair Using mysqlcheck (Recommended First Step)

mysqlcheck is the safest starting point. It connects to the live MySQL server and runs a repair without you needing to stop the service. This works on both MyISAM and InnoDB tables.

To repair a single database:

mysqlcheck -u root -p --repair your_database_name

To repair all databases on the server (useful after a crash that may have hit multiple DBs):

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

To repair a single table specifically:

mysqlcheck -u root -p --repair your_database_name wp_posts

📝 Note: mysqlcheck --repair only works on MyISAM, ARCHIVE, and CSV tables. If the output says note: The storage engine for the table doesn't support repair, your table is InnoDB — skip to Step 5.

Step 4: Repair Using SQL (phpMyAdmin or MySQL CLI)

If you don’t have SSH or prefer a SQL-based approach, the REPAIR TABLE statement works directly in phpMyAdmin or the MySQL shell.

Via MySQL CLI:

USE your_database_name;
REPAIR TABLE wp_posts;
REPAIR TABLE wp_options;

Via phpMyAdmin (cPanel):

1. Log into cPanel and open phpMyAdmin
2. Select your database from the left sidebar
3. Check the box next to the crashed table (or select all tables)
4. In the With selected dropdown at the bottom, choose Repair table
5. Click Go

You’ll see a status row — a result of OK means the repair succeeded. If it says error: Corrupt, the table may have deeper physical damage and you’ll need the approach in Step 5.

Step 5: Repair Offline with myisamchk (Severe MyISAM Corruption)

For heavily corrupted MyISAM tables that REPAIR TABLE can’t fix, myisamchk works directly on the table files. This requires stopping MySQL first.

⚠ Warning: Don’t run myisamchk while MySQL is running. It can make corruption unrecoverable. Stop the service first.

# Stop MySQL
sudo systemctl stop mysql

# Navigate to the database directory
cd /var/lib/mysql/your_database_name

# Check the table
myisamchk -c wp_posts.MYI

# Safe repair
myisamchk -r wp_posts.MYI

# If safe repair fails, try the extended repair
myisamchk -o wp_posts.MYI

# Start MySQL again
sudo systemctl start mysql

📝 Note: MyISAM table files live as three files per table: .frm (structure), .MYD (data), and .MYI (index). The myisamchk tool operates on the .MYI index file. If the .MYD data file itself is corrupt, data loss is possible — this is where that backup from Step 2 becomes critical.

Step 6: Handle InnoDB Crashed Tables

InnoDB doesn’t support REPAIR TABLE, but it does have its own recovery mechanism. If you’re seeing InnoDB errors after a crash, MySQL often recovers automatically on the next start via its crash recovery process.

If the database won’t start at all, enable forced recovery in /etc/mysql/my.cnf or /etc/my.cnf:

[mysqld]
innodb_force_recovery = 1

Start with 1 and increase to a maximum of 6 if MySQL still won’t start. Each level is more aggressive about skipping corrupted data to let the server boot. Once MySQL is running, dump the database immediately and restore from that dump into a clean instance.

⚠ Warning: innodb_force_recovery = 4 or higher can cause data loss. Use the lowest value that gets MySQL running. Remove this setting from my.cnf after recovery is complete — leaving it in degrades performance and disables write operations at levels 4+.

Step 7: WHM — Repair Databases via the GUI (cPanel Servers)

If you manage a cPanel/WHM server, WHM has a built-in repair tool:

1. Log into WHM as root
2. Navigate to SQL Services > Repair a MySQL Database
3. Select the cPanel account and database from the dropdowns
4. Click Repair Database

This runs mysqlcheck --repair in the background. It’s convenient but not a replacement for CLI access when you’re dealing with InnoDB issues or severe corruption.

Common Issues and Troubleshooting

REPAIR TABLE returns “Storage engine doesn’t support repair”

Your table is InnoDB. REPAIR TABLE only works on MyISAM. For InnoDB, use the forced recovery method in Step 6, or if the data is accessible, dump and re-import the table:

-- Dump just the one table
-- (run from shell, not MySQL prompt)
-- mysqldump -u root -p your_db crashed_table > crashed_table.sql

-- Drop and recreate
DROP TABLE crashed_table;
SOURCE /root/crashed_table.sql;

mysqlcheck fails with “Can’t create/write to file”

The MySQL data directory is likely full or has permission problems. Check disk space first:

df -h /var/lib/mysql

If the disk is full, that may also be what caused the crash in the first place. Free up space, then re-run the repair. On a VPS SSD Hosting plan, you can resize your disk or add block storage without downtime in most cases.

MySQL won’t start after a crash, even with innodb_force_recovery

If MySQL fails to start even at innodb_force_recovery = 6, the InnoDB system tablespace (ibdata1) may be beyond repair. At this point, restore from your most recent backup. This is a situation where automated backups via WHM or an off-server backup service are the only way out. I’d recommend checking your backup schedule immediately after any recovery event.

Table repaired successfully, but the site still throws errors

Run a full check on all tables in the database, not just the one that surfaced in the logs:

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

A single crash event can mark multiple tables as corrupted. The first error you see in the PHP log isn’t always the only problem.

Repair works, but the table keeps crashing

Recurring crashes point to an underlying cause: bad RAM, a failing disk, or a runaway process triggering the OOM killer. Check dmesg for hardware errors and review /var/log/syslog for OOM kills targeting mysqld. Also consider migrating critical tables from MyISAM to InnoDB — InnoDB’s transaction log makes it dramatically more resilient to sudden shutdowns:

ALTER TABLE wp_posts ENGINE=InnoDB;
ALTER TABLE wp_options ENGINE=InnoDB;

In my experience, converting MyISAM tables to InnoDB is the single most effective thing you can do to prevent this problem from recurring on production databases.

FAQ