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
-
MySQL Disk Full & Tablespace Reclaim Prompt
Recover a MySQL/MariaDB instance from a full data disk and reclaim space from bloated InnoDB tablespaces, binary logs, undo, and temp files without corrupting data or triggering more downtime.
-
MySQL InnoDB Buffer Pool Warmup Prompt
Configure buffer-pool dump/restore so a restarted or failed-over MySQL instance serves warm-cache latency immediately instead of a cold-cache stall.
-
MySQL Durability & Flush Settings Tuning Prompt
Balance InnoDB durability against throughput by reviewing flush, sync, and doublewrite settings for a given workload and hardware.
-
MySQL Errant GTID Transaction Reconciliation Prompt
Detect and safely reconcile errant transactions (GTIDs on a replica the source never had) that block failover or break GTID replication.
More MySQL prompts & error guides
Browse every MySQL prompt and troubleshooting guide in one place.
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.