Skip to content
Website Rescue Rescue

MySQL and Database Errors

WordPress Database Needs Repair

Intermediate Risk: high

Last reviewed

Hosting access may not be needed Database access often needed

Graphic options · pick what to keep

decisionTree

serverRack

requestTimeline

statusBadge

Direct answer

WordPress detected damaged or inconsistent database tables—often after a crash, disk-full event, or bad import. Back up first, then run repair via wp-admin/maint/repair.php (with WP_ALLOW_REPAIR temporarily enabled) or your host’s phpMyAdmin repair tools, and restore from a clean dump if repair fails.

The “WordPress database needs repair” notice means core found table-level problems during bootstrap, not necessarily that your whole database is gone. Posts and settings may still be recoverable if you repair before forcing more writes. This guide covers safe backups, the built-in repair screen, host-side table checks, and when to restore instead of repeating repair.

Intermediate

What the error means

WordPress stores posts, users, options, and plugin data in MySQL or MariaDB tables prefixed with wp_ (or your custom prefix). On each load it checks whether key tables respond cleanly. After an unclean shutdown, disk exhaustion, failed migration import, or storage engine glitch, tables can be marked crashed or return checksum errors—WordPress may then show “One or more database tables are unavailable… the database may need to be repaired.” That is a data-integrity warning inside an otherwise working connection, different from “Error establishing a database connection.” Repair tools rebuild indexes and fix minor corruption; they do not replace a missing database or wrong credentials. Running repair on production without a backup can make a bad situation worse if a table is already partially overwritten.

Common symptoms

  • Admin or front-end banner: “One or more database tables are unavailable… the database may need to be repaired”
  • wp-admin/maint/repair.php lists tables with errors or “Already repaired” after a prior attempt
  • phpMyAdmin or host database UI marks tables as crashed, in use, or needing repair
  • Intermittent missing widgets, options, or menus that return after cache clears then fail again
  • MySQL error log mentions “Table … is marked as crashed”, “Incorrect key file”, or repair warnings
  • Site worked until a host move, power loss, disk-full alert, or interrupted backup restore

Most likely causes

  1. 01 Unclean MySQL/MariaDB shutdown after server crash, OOM kill, or forced reboot
  2. 02 Disk full on the database volume—InnoDB or MyISAM cannot complete writes cleanly
  3. 03 Interrupted migration import or partial database restore leaving mixed old/new table states
  4. 04 Plugin or theme running heavy ALTER TABLE operations that failed mid-way
  5. 05 Hardware or filesystem issues on VPS storage (bad sectors, degraded RAID)
  6. 06 Repeated failed repair attempts or manual SQL edits on corrupted tables without a backup

What changed before the problem started

  • Host migration or database import that stopped halfway
  • Server reboot, maintenance window, or MySQL upgrade the night before
  • Disk space warning or inode exhaustion on the hosting account
  • Large plugin update that altered custom tables during activation
  • Manual phpMyAdmin edits, bulk search-replace, or cleanup scripts on production

Troubleshooting steps

  1. 01

    Take a full database backup before any repair

    Export the entire WordPress database from phpMyAdmin, the host backup tool, or WP-CLI (wp db export) while you can still connect. Store the .sql file off-server. Do not run repair as your first action on a live store without that dump. Success signal: you have a timestamped backup file and can open it to confirm it contains wp_posts and wp_options.

  2. 02

    Enable WP_ALLOW_REPAIR and open the repair screen

    Edit wp-config.php and add define('WP_ALLOW_REPAIR', true); above the “That’s all, stop editing!” line. Visit https://yoursite.com/wp-admin/maint/repair.php (replace domain). Click “Repair Database” first; use “Repair and Optimize Database” only if repair alone reports remaining issues. Remove WP_ALLOW_REPAIR immediately when finished. Success signal: the repair page lists tables as OK and the site banner disappears.

  3. 03

    Repair crashed tables in the host database panel

    If wp-admin is unreachable, open phpMyAdmin or the host’s MySQL repair UI, select the WordPress database, and run Repair on tables flagged crashed—often wp_options, wp_postmeta, or wp_usermeta. Note which tables failed twice. Success signal: table status shows OK in phpMyAdmin and the front end loads without the repair notice.

  4. 04

    Free disk space and confirm MySQL is healthy

    Check hosting disk usage; MySQL cannot recover reliably on a full volume. Clear old logs, oversized backups, and spam revisions only after your DB dump is safe elsewhere. Restart MySQL only per host guidance after space is freed. Success signal: free space is comfortably above host limits and new connections succeed without “disk full” in MySQL logs.

  5. 05

    Verify site behavior after repair—not just the admin notice

    Load the homepage, wp-admin login, permalinks (/sample-page/), and one critical plugin feature (forms, cart, membership). Flush page cache and object cache if used. Success signal: content, menus, and login persist across several reloads with no repair banner returning.

  6. 06

    Restore from the last clean backup if repair errors persist

    When the same tables stay crashed, repair multiplies errors, or content is clearly missing, import the most recent known-good database dump to staging first, validate posts and orders, then restore production during a maintenance window. Success signal: restored site matches backup timestamp and repair UI shows all tables healthy without rerunning repair.

When to stop troubleshooting

Stop if repair reports the same tables failing twice, phpMyAdmin cannot open the database, you lack a verified backup, disk is still full, or InnoDB logs mention severe recovery modes. Forcing repair on a live WooCommerce or membership database without a restore path can destroy orders and user meta—escalate with backup timestamps, table names, and MySQL error snippets.

Information to collect before requesting help

  • 01 Exact repair banner text and whether wp-admin still loads
  • 02 List of tables flagged on repair.php or phpMyAdmin
  • 03 Recent migration, import, disk-full alert, or host maintenance timing
  • 04 Hosting provider, plan type, and MySQL/MariaDB version
  • 05 Whether “Error establishing a database connection” appears separately
  • 06 Age and location of the latest verified database backup
  • 07 MySQL error log lines mentioning crashed tables, InnoDB, or disk full

How a professional repairs the problem

We confirm the database still accepts connections, then capture a restorable dump before touching tables. From there we use the WordPress repair screen or host tools on the specific crashed tables, correlate failures with recent imports or plugin migrations, and validate front-end, admin, and commerce flows. If repair is insufficient we restore from the newest clean backup on staging, prove parity, then cut production over with caching flushed and monitoring in place. You get a short root-cause note—disk, import, plugin schema, or host outage—and a backup cadence so the next corruption is a scheduled restore, not a panic repair loop.

Frequently asked questions

Is “database needs repair” the same as a connection error? +
No. Connection errors mean WordPress cannot log into MySQL at all—usually credentials or service status. The repair notice means WordPress connected but found damaged or unavailable tables. Fix connectivity first if both messages appear at different times.
Will repair delete my posts or orders? +
Standard WordPress repair rebuilds table structure and indexes; it is not designed to wipe content. Severely corrupted rows can still be lost if repair cannot read them. That is why a full backup precedes any repair on production.
How long can I leave WP_ALLOW_REPAIR enabled? +
Only for the minutes you run repair. Anyone who can reach /wp-admin/maint/repair.php can trigger repairs while that constant is true. Remove it from wp-config.php immediately afterward.
Should I run “Repair and Optimize” every month? +
Routine optimize on large InnoDB tables can lock sites unnecessarily. Run repair when WordPress or MySQL reports corruption, after confirmed crashes, or when advised by support—not on a casual schedule without symptoms.
Can a plugin cause this message? +
Plugins rarely corrupt tables without a underlying storage problem, but heavy custom tables, failed migrations, or runaway cron can stress MySQL until a crash marks tables damaged. After repair, investigate the plugin on staging before re-enabling aggressive features on production.
What if repair says OK but the site still breaks? +
Look for separate issues: wrong siteurl/home, broken serialized options, object cache serving stale options, or a different plugin fatal. Export wp_options key rows to staging and compare against backup; restore options carefully rather than repeating repair.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.