🚨 MySQL Error: 'ERROR 144: Table is marked as crashed and last (automatic?) repair failed' — Cause, Fix, and Troubleshooting Guide

Overview

ERROR 144 is a MyISAM storage-engine error indicating a table is corrupt and the server’s automatic repair attempt already failed:

ERROR 144: Table './appdb/sessions' is marked as crashed and last (automatic?) repair failed

This is the more severe cousin of the “marked as crashed” message. Error 144 means MySQL tried to auto-repair on open (via myisam-recover-options) and could not fully fix the .MYI/.MYD files — usually because the damage is deep, the index is badly out of sync, or the disk filled during the repair. Manual, offline repair with myisamchk is typically required.

Symptoms

• Any query on the table fails with error 144; other tables are fine.
• The error log shows an auto-repair attempt that reported failures or ran out of space.
• Repeated REPAIR TABLE online does not clear it, or fixes it briefly before it recurs.
• Follows a crash, power loss, kill -9, or a full disk.

Common Root Causes

1. Severe MyISAM corruption after an unclean stop

A crash while writing left the index and data files badly inconsistent — beyond what auto-recover handles.

2. Auto-repair ran out of disk

myisam-recover needs temp space; if the volume was full (the same event that caused the crash), the repair itself failed.

3. Hardware / filesystem fault

A bad block in the .MYI or .MYD file prevents a clean rebuild.

4. Repeated writes racing an incomplete repair

Application writes hitting the table before repair completed re-marked it as crashed.

How to diagnose

Confirm the engine and inspect the damage (read-only):

SELECT ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA='appdb' AND TABLE_NAME='sessions';

CHECK TABLE appdb.sessions;

Verify there is free disk before any repair (repair needs a temp copy):

df -h /var/lib/mysql
journalctl -u mysql --no-pager | grep -iE "repair|crashed|error 144"

Fixes

Stop application writes, then attempt an online repair first — extended, which rebuilds the index thoroughly:

REPAIR TABLE appdb.sessions EXTENDED;

If that still fails, repair offline with myisamchk while mysqld is stopped (never against a running server’s files):

sudo systemctl stop mysql
sudo myisamchk --recover --sort-recover /var/lib/mysql/appdb/sessions.MYI
sudo systemctl start mysql

For the worst cases, force a rebuild from the data file (may drop unrecoverable rows):

sudo myisamchk --safe-recover /var/lib/mysql/appdb/sessions.MYI

Re-check after repair, then restore any missing rows from backup:

CHECK TABLE appdb.sessions;

The durable fix is to migrate the table to crash-safe InnoDB:

ALTER TABLE appdb.sessions ENGINE = InnoDB;

What to watch out for

• Never run myisamchk on files of a running server — stop mysqld first, or you deepen the corruption.
• Ensure free disk equal to the table size before repairing; a repair that runs out of space re-triggers error 144.
• --safe-recover/USE_FRM repairs can lose rows — always compare counts against a backup afterward.
• If the underlying cause is a bad disk block, repair will keep failing; check dmesg/SMART and move the datadir to healthy storage.
• Migrating to InnoDB eliminates this class of error entirely for that table.

Related

• ERROR 1194: Table is marked as crashed and should be repaired — the less-severe “crashed” state before auto-repair failed.
• ERROR 1114: The table is full — a capacity failure that can occur alongside a full-disk crash.
• ERROR 1146: Table doesn’t exist — what you see if repair drops the table files entirely.