MySQL throws ER_CRASHED_ON_REPAIR (error 1195) when a table that was marked crashed could not be fixed by an automatic REPAIR TABLE operation.
MySQL Error 1195: ER_CRASHED_ON_REPAIR means the server tried to auto-repair a crashed table but failed. Run a manual REPAIR TABLE or myisamchk offline, restore from backup if needed, and switch to crash-safe storage engines to resolve the issue.
ER_CRASHED_ON_REPAIR
Error 1195 appears when MySQL detects that a table is corrupted, attempts an automatic repair, and that repair fails. The storage engine then marks the table as still crashed and unreadable until a manual fix is completed.
The error is returned with SQLSTATE HY000 and halts any query that tries to read or modify the affected table.
Timely resolution is critical to avoid data loss and restore application availability.
Most cases involve MyISAM tables because MyISAM is not crash-safe. Sudden power loss, server crashes, or forced shutdowns can leave pages out of sync and mark the table as crashed.
If the automatic repair cannot rebuild the index files, MySQL raises 1195.
Disk failures, full disks, file-system permission changes, and large tables that exceed tmpdir capacity also block the automatic repair routine and trigger ER_CRASHED_ON_REPAIR.
First, back up the .frm, .MYD, and .MYI files. Then run REPAIR TABLE tbl_name QUICK; from the MySQL client.
If that fails, stop MySQL and execute myisamchk --recover /path/to/tbl_name.MYI from the shell.
If myisamchk cannot recover the data, restore the table from a recent backup.
After recovery, consider converting the table to InnoDB for crash safety.
Automatic nightly maintenance crashes: configure skip-automatic-repair and schedule controlled REPAIR TABLE during low traffic windows.
Large tables on limited tmpdir: point myisamchk to a larger disk with the --tmpdir option or enlarge tmpdir to ensure enough space for sorting indexes.
Migrate legacy MyISAM tables to InnoDB, which is transactional and crash-safe by design.
In Galaxy’s SQL editor you can generate ALTER TABLE statements quickly and test them in a sandbox before production rollout.
Enable reliable power supplies, perform graceful shutdowns, and schedule regular CHECK TABLE operations to catch corruption early. Keep validated backups and monitor error logs for warnings.
Error 1194 (ER_CRASHED) signals a crashed table but before repair is attempted. Run REPAIR TABLE or myisamchk similarly.
Error 145 (Table was marked as crashed and should be repaired) is a generic corruption alert.
The recovery workflow is identical: backup, repair, or restore.
.
Hard reboots, kernel panics, or mysqld segmentation faults leave MyISAM tables in an inconsistent state the automatic repair cannot fix.
Sudden power loss during writes corrupts index pages and forces MySQL to mark the table as crashed.
If tmpdir or the data partition runs out of space, the automatic REPAIR TABLE operation cannot create temporary files and aborts.
Bad sectors, inode problems, or permission changes prevent MySQL from reading or writing the .MYI and .MYD files required for repair.
.
Run SHOW TABLE STATUS WHERE Comment LIKE '%%crashed%%'; to list all tables requiring repair.
Data may still be intact; the error only means automatic repair failed. Manual recovery or backup restore often retrieves most or all rows.
For large MyISAM tables, consider creating a replica, fixing the replica offline, then swapping it in to minimize production downtime.
Galaxy’s versioned SQL workspace lets you test REPAIR TABLE commands safely and share recovery scripts, reducing human error during urgent fixes.
.avif)
.avif){kind=logo}
