WordPress Database Emergencies: Fix Disk Full, Crashed Tables & Random DB Connection Errors

WordPress database emergencies have a special talent for showing up at the worst possible time: during a launch, after a traffic spike, or right when you finally sit down to relax. One minute your site is fine, the next you’re staring at “Error establishing a database connection,” pages loading half-empty, or wp-admin refusing to cooperate.

This guide is a practical, “do this next” playbook for three of the most common database fire drills:

Disk full / “table is full” / “no space left on device”
Crashed tables
Random database connection errors (intermittent, hard-to-reproduce failures)

You’ll get a safe triage order, recovery steps that reduce the risk of making things worse, and prevention tactics so you’re not revisiting the same nightmare next week.

If you want a faster, hands-off cleanup after you recover, WP Fix It has a dedicated service for database health: WordPress database cleanup—useful when the emergency is over and you need to stop the underlying bloat and junk from building back up.

The 5-minute triage checklist (do this before “fixing” anything)

When you’re in a WordPress database emergency, it’s easy to thrash—random plugin deactivations, restoring old backups, “repairing” things blindly. Instead, do this quick sequence first:

1) Confirm the scope

Is the whole site down, or only wp-admin, or only specific pages?
Are you seeing a WordPress message (“Error establishing a database connection”) or a database-level message (“Table is marked as crashed,” “No space left on device”)?

If the error is intermittent, that’s already a clue: intermittent failures are often resource exhaustion (connections, CPU, disk I/O) or network/DB server instability, not just wrong credentials.

2) Make a backup snapshot (even if things are broken)

Before you repair tables or delete anything, grab what you can:

Database dump (preferred) or hosting “backup now” snapshot.
If you can’t dump, at least copy wp-config.php and capture error logs.

MySQL warns that repair operations can sometimes cause data loss, especially if the filesystem is unhappy—so treat repairs as “do after backup.” (MySQL)

3) Check disk space and quotas immediately

Disk pressure causes cascading failures that look like random WordPress problems. If disk is full, repairs may fail and WordPress may be unable to write cache, sessions, updates, or temp tables.

4) Identify whether you’re dealing with MyISAM vs InnoDB

Many modern WordPress sites are primarily InnoDB.
“Repair table” works differently depending on engine (and is often associated with MyISAM maintenance). MySQL documentation notes MyISAM-specific guidance for CHECK/REPAIR workflows. (MySQL)

5) Don’t change five things at once

Make one change, retest, and note results. In emergencies, change logs save hours.

Emergency #1: Disk full (and why it breaks WordPress in weird ways)

Common symptoms

WordPress shows database errors or “Error establishing a database connection”
MySQL errors like:
- Errcode: 28 – No space left on device
- The table ‘/tmp/#sql…’ is full
Admin actions fail (publishing posts, uploading media, updating plugins)
Repair attempts fail or hang

The “table is full” family of errors often points to disk space issues—sometimes not where you expect. It may be the partition holding /var/lib/mysql, or it may be the partition holding MySQL temp files (often /tmp). (Stack Overflow)

Step 1: Verify what’s actually full

On Linux servers, start with:

df -h to see which filesystem is full
du to see which directories are huge

If you need to quickly identify large culprits, common approaches include using du to narrow to big directories and find to locate very large files. (Unix & Linux Stack Exchange)

Where disk commonly disappears on WordPress hosts

/var/lib/mysql (database files)
/tmp (MySQL temp tables, PHP temp files)
wp-content/uploads (media growth)
wp-content/cache (cache plugins gone wild)
Backup directories (local backups accumulating)
Logs (web server logs, PHP logs, MySQL logs)

Step 2: Free space safely (triage actions)

Goal: free enough disk to stabilize DB writes, then do deeper cleanup.

Safe-ish quick wins:

Delete old compressed logs you’ve already archived
Remove ancient backup zips stored on the server
Clear cache plugin directories (if you know what you’re deleting)
Rotate/purge runaway logs

If MySQL is generating giant logs (binary logs), don’t randomly delete files—use DB-safe purge procedures. If you don’t have that comfort level, stop at “free space elsewhere” and get help.

Step 3: Check MySQL temp table pressure

When queries create large temp tables, MySQL may write them to disk—often under /tmp. If that partition is small, you get “table is full” even if the main disk has room. (Stack Overflow)

If you’re seeing errors referencing /tmp/#sql… specifically, suspect temp space.

Step 4: After stabilizing, address WordPress-side bloat

Once the site is back:

Clear post revisions bloat
Clean transient options bloat
Remove orphaned data from old plugins
Optimize tables carefully

A structured cleanup is exactly what WordPress database cleanup is meant for—especially if the disk full event was caused by slow database growth you didn’t notice until the cliff edge.

Prevention for disk-full database emergencies

Add monitoring/alerts for disk usage and inode usage
Keep backups off-server (or at least time-limited)
Schedule log rotation
Periodically audit large directories
Avoid unlimited debug logging in production

Emergency #2: Crashed tables (and what “repair” really means)

What it looks like

You might see:

“Table is marked as crashed and last repair failed”
Specific WordPress tables called out (often wp_options, wp_postmeta, etc.)
Admin may partially load, but key screens break

These messages are common in WordPress support threads where WordPress reports a table problem and attempts repair. (WordPress.org)

First: confirm your WordPress database details (without guessing)

During a WordPress database emergency, people waste time repairing the wrong database because of staging vs production confusion.

If you need a quick way to view DB info from inside WordPress admin (when accessible), WP Fix It has a walkthrough: WordPress database details. (WP Fix It)

Step 1: Backup before repair

This is not optional. MySQL documentation explicitly warns to back up tables before repair operations because repairs can cause data loss under some conditions. (MySQL)

Step 2: Use WordPress’s built-in repair tool (when appropriate)

WordPress can expose a repair screen when you set a constant in wp-config.php. The wp-config.php file is where core config (including database connection details) lives. (WordPress Developer Resources)

High-level flow:

Add the repair constant
Visit the repair endpoint in your browser
Run repair (and optionally optimize)
Remove the constant immediately afterward (it should not remain enabled)

Multiple guides emphasize removing the WP_ALLOW_REPAIR constant after using the tool, because leaving it enabled can expose repair operations publicly. (Kadence WP)

Step 3: If built-in repair fails, switch to database-level maintenance

If WordPress repair fails or reports “last repair failed,” you may need database-level tools like mysqlcheck, which can check/repair/optimize tables (locking tables during maintenance). (MySQL)

Important practical notes:

Repairs can lock tables—plan for downtime.
If you’re on shared hosting, you may have limited privileges.
Engine matters: InnoDB recovery strategies differ from MyISAM “repair table” habits.

Step 4: Don’t ignore the root cause

Tables “crash” due to underlying problems:

Disk full events (yes, these overlap)
Sudden power loss / host crashes
Filesystem issues
Hard kills during updates or heavy writes

So after repair, circle back to disk pressure, host stability, and plugin/database load.

Emergency #3: Random DB connection errors (the sneakiest one)

Symptoms

Site works… until it doesn’t
Errors appear during traffic spikes
wp-admin login loops or intermittent 500 errors
“Error establishing a database connection” appears randomly, then disappears on refresh

The classic “Error establishing a database connection” message is often either:

Wrong credentials in wp-config.php, or
WordPress cannot reliably reach the DB server (DB down, overloaded, network trouble). (WordPress.org)

Step 1: Confirm wp-config.php database values

Use the official WordPress developer documentation to understand what belongs in wp-config.php and where it lives. (WordPress Developer Resources)

Key things to verify (without changing blindly):

DB name/user/password
DB host (sometimes not localhost on managed hosts)
Any recent changes: host migrations, password rotations, staging pushes

If you recently migrated hosts or restored from backup, mismatched credentials are extremely common.

Step 2: Determine whether MySQL is intermittently unavailable

Intermittent connection errors often come from:

DB server restarting
Resource exhaustion (max connections hit)
Slow queries piling up
Disk I/O saturation
Network flakiness between web and DB tiers

If you have access:

Check MySQL uptime/restarts
Check error logs
Look for bursts of “Too many connections” or timeouts

Step 3: Look for “accidental denial of service” from your own WordPress site

Common WordPress patterns that overload DB:

Search or filter pages that do expensive queries
WooCommerce + heavy reporting
Badly-coded plugins hammering wp_options
Cron storms
Excessive autoloaded options

This is where cleanup and optimization become prevention, not just “performance tuning.” A periodic WordPress database cleanup can reduce load by removing junk rows, transients, and other leftovers that quietly degrade reliability over time.

Step 4: Reduce variables with controlled tests

If the error is random:

Temporarily disable heavy features (search, related posts, analytics plugins) one at a time
Check if failures correlate with scheduled tasks (cron) or backups
Test with a lightweight theme temporarily (only if you can do it safely)

Step 5: When you need help now

If you’re in an active outage and need the fastest path to recovery, use a dedicated emergency fix service like WordPress site repair and fix service. (WP Fix It)

If you prefer to describe the symptoms and have an expert guide the next steps, start here: contact WordPress experts. (WP Fix It)

A safe recovery order (when multiple issues hit at once)

In real life, these emergencies stack. Example: disk fills → MySQL can’t write → tables corrupt → then WordPress throws connection errors.

Use this order to avoid wasted effort:

Stabilize disk space first
If disk is full, repairs may fail and corruption may continue.
Restore DB connectivity second
Confirm MySQL is running and reachable, credentials are correct.
Repair corrupted tables third
Only after backup + stable disk + stable DB service.
Clean up WordPress bloat and fix the root cause last
Otherwise you’ll be back here soon.

Prevention playbook for WordPress database emergencies

1) Add monitoring that pages you before customers do

Minimum alerts:

Disk usage (warn at 70–80%, critical at 90%+)
MySQL uptime/restarts
HTTP error rate
Database connection errors in logs

2) Keep database maintenance routine (not a one-time “optimization”)

A good maintenance cadence:

Monthly cleanup of transients/revisions (depending on publishing volume)
Quarterly audit of largest tables
After removing big plugins, purge orphaned tables/options

3) Know your “largest tables” early

Even without deep DBA skills, simply identifying the biggest tables helps you:

Find which plugin is generating runaway data
Spot WooCommerce logs/order tables growth
Catch spam/commentmeta explosions

4) Treat `wp_options` autoload as a reliability risk

When wp_options autoload grows huge, every page load can drag. That increases DB load and makes intermittent failures more likely under traffic.

5) Keep wp-config.php changes disciplined

Use the official reference for what belongs in wp-config.php and document every change. (WordPress Developer Resources)
If you temporarily enable DB repair, remove it immediately afterward. (Kadence WP)

Quick “symptom → likely cause” mapping

“No space left on device” → disk/partition/quota full, sometimes /tmp specifically (Stack Overflow)
“The table ‘/tmp/#sql…’ is full” → temp filesystem full or temp table writing to disk (Stack Overflow)
“Table is marked as crashed” → corruption/engine issues, often after crash/disk issues (WordPress.org)
“Error establishing a database connection” → credentials wrong or DB server unreachable/unstable (DreamHost Knowledge Base)

When to stop DIY and escalate

You should strongly consider escalating if:

Repairs fail repeatedly (“last repair failed”)
Disk fills again within hours (runaway growth)
You suspect filesystem issues or host instability
You can’t safely take a backup
The site is revenue-critical and downtime is expensive

At that point, it’s less about “one trick” and more about doing a controlled recovery: stabilize resources, validate DB integrity, eliminate the trigger, and then harden.

Two practical next steps:

For an emergency fix: WordPress site repair and fix service (WP Fix It)
For ongoing DB health after the fire is out: WordPress database cleanup (WP Fix It)

Wrap-up

WordPress database emergencies usually aren’t mysterious—they’re just messy. Disk pressure, table corruption, and random connection failures tend to cascade into each other, which is why the recovery order matters: