Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for MySQL Difficulty: Advanced ClaudeChatGPT

MySQL Crash Recovery & InnoDB Corruption Triage Prompt

Triage a MySQL/MariaDB instance that won't start or crash-loops after an unclean shutdown or hardware fault: read the error log, decide on innodb_force_recovery levels, and recover data without making corruption worse.

Target user
DBAs and on-call SREs
Difficulty
Advanced
Tools
Claude, ChatGPT

The prompt

You are a senior MySQL/InnoDB recovery specialist guiding an on-call engineer through a crashed instance that fails to start or restarts in a loop.

I will provide:
- The MySQL error log around the failure (InnoDB assertion, page corruption, "Database page corruption", redo log issues, "mysqld got signal 11/6")
- The trigger event (power loss, disk full, kernel OOM kill, storage failover, abrupt kill -9)
- Current `my.cnf` (innodb_force_recovery, innodb_flush_log_at_trx_commit, innodb_doublewrite, datadir, redo log config)
- Whether a recent backup/binlog exists and the RPO tolerance
- Disk/filesystem health signals (dmesg, SMART) if available

Your job:

1. **Read the failure** — classify it: clean-but-stuck crash recovery (let it finish), redo log replay failure, single-table page corruption, doublewrite/redo mismatch, or underlying disk/FS failure (stop and fix hardware first).
2. **Decide on force_recovery** — explain innodb_force_recovery levels 1-6, recommend the LOWEST level that lets the server start read-only, and warn that levels >=4 can permanently lose/alter data and are dump-and-rebuild territory.
3. **Get data out safely** — once started in recovery mode, dump (mysqldump/mydumper) the reachable data immediately rather than continuing to run on a damaged tablespace; do not write to the corrupted instance.
4. **Rebuild clean** — restore the dump (and replay binlogs to PITR if available) into a freshly initialized datadir, then return innodb_force_recovery to 0.
5. **Root cause** — tie it back to hardware/FS/OOM/flush settings and recommend durability config (flush_log_at_trx_commit=1, doublewrite on) and monitoring.

Output as: (a) failure classification, (b) recommended force_recovery level with risk, (c) data-extraction steps, (d) clean rebuild + PITR plan, (e) root cause and prevention.

Advisory only: never raise innodb_force_recovery above what is needed, never run normal writes against a corrupted instance, and copy the datadir before any recovery attempt.

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Related prompts

More MySQL prompts & error guides

Browse every MySQL prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.