Back to Scenarios

Database Won’t Start?

Recover from Corrupted Instance

Scenario Description

A damaged system tablespace, dictionary or data file prevents MySQL from starting. Clients cannot connect and mysqldump cannot export. Surviving InnoDB files and schema evidence may still contain readable records even when the instance is unavailable.

Possible Causes

  • Power loss or storage faults damaged pages.
  • System tablespaces, Redo, Undo or dictionary evidence are missing.
  • An incomplete directory copy omitted external tablespaces or partitions.

Challenges

Conventional recovery often requires complete files, a running instance or a usable backup. In these situations, choose a method based on the evidence that survives.

Common Errors and Symptoms

  • - mysqld fails to start or exits while reading InnoDB files.
  • - Clients cannot connect and normal logical export is unavailable.
  • - Tablespace or dictionary information cannot be read completely.

Why Traditional Methods Fail

  • - mysqldump requires a running instance that can read the target tables.
  • - Repeated startup or modification changes the recovery evidence.
  • - Forced startup cannot supply missing definitions, pages or external values.

PDU Solution

PDU reads a MySQL directory copy that is no longer being written, using matching 5.7 FRM/ibdata1 or 8.0 SDI to identify metadata. Select the database and tables, then export definitions and readable records separately. The damaged instance does not need to start.

Recovery Principle

  1. Copy Failed Directory
  2. Identify Database and Table Definitions
  3. Select Target Tables
  4. Export Data and DDL

PDU Core Capabilities

  • Read physical files independently of mysqld.
  • List identified databases and tables after initialization.
  • Export individual tables or a selected database.
  • Save definitions separately from data.
  • Resolve physical layouts against source metadata.
  • Retain original reasons for unavailable tables and parse failures.

Recovery Steps

  1. 1

    Initialization

    Fill in MYSQL_DATADIR in pdu.ini, i.e., the database directory. Launch PDU in a result directory outside the sources; the launch directory is fixed as the working and output location for the run.

    Enter the pdu directory and execute b; to complete initialization. Version 5.7 uses FRM/system dictionaries; version 8.0 uses SDI and physical dictionaries to identify tables.

  2. 2

    View Current Databases

    Use \l; to view selectable databases. After initialization, also review READY and UNAVAILABLE counts in the table inventory.

  3. 3

    Enter Database and Export Table Definitions

    Use use database_name; to select and enter the corresponding database. Use \dt; to view tables and unload ddl database_name; to export table definitions.

  4. 4

    How to Use Exported Data

    Use the corresponding command example below, replacing paths, objects and identity parameters with evidence from this run.

  5. 5

    Components of Exported Data

    PDU uses its current directory at startup for tasks and output. Exported SQL files are written directly there, and internal task records are stored in .pdu-work. Export table definitions separately with unload ddl. Recovery commands generate SQL without writing to the target database. The records in .pdu-work retain the program's success and failure counts, original errors and checkpoints.

  6. 6

    Paths of Exported Data

    Exported SQL is written directly to PDU's launch directory. Internal tasks are stored in .pdu-work beneath it. Use the paths reported by PDU; existing output is not overwritten.

    After export, record the native success and failure counts and original errors reported by PDU, and retain the checkpoint. Resume uses native records and file metadata such as existence and size without rereading exported data.

Quick Command Examples

Preserve frozen sources and launch PDU outside them. Write configuration snippets to pdu.ini and execute PDU commands after startup. Replace example paths, versions, times and task identities with actual evidence.

# Initialization

MYSQL_DATADIR=/recovery-input/mysql/data
BINLOG=/recovery-input/mysql/binlog
RESMODE=tx
RESTYPE=delete

# Initialization

./pdu

b;

# View Current Databases

\l;

# Enter Database and Export Table Definitions

use appdb;
\dt;
\d orders;
unload ddl appdb;

Export Results

Table Data SQL

Exported data is saved directly in the directory where PDU was started, for example orders.sql. Larger results are split into orders_2.sql and subsequent files.

Table Definitions

Use unload ddl for directory-mode definitions; preserve the matching original DDL for single-file recovery.

Native Recovery Records

Internal tasks are stored in .pdu-work beneath the launch directory, retaining success, failure, errors and checkpoints.

After export, record PDU’s native success and failure counts and original errors, retaining checkpoints. Resume uses native records and file metadata without rereading exported data or automatic trial import.

Prerequisites

  • The MySQL instance cannot start or connect due to corruption or misconfiguration.
  • Database files and matching metadata are still accessible on disk.
  • Use a complete, consistent offline copy with external tablespaces and required keys preserved.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • Recovery depends on surviving files, definitions and required external values; it does not guarantee that the damaged instance can restart.
  • Database export preflights selected tables; unavailable tables prevent a whole-database success claim.
  • Source profiles cover 5.7.44, 8.0.28 and 8.0.46; confirm other versions and special layouts.
View Detailed Steps for This Recovery Method
MySQL 场景案例