Back to Scenarios

Damaged IBD Files Make a Table Unreadable?

Recover from Corrupted Data File

Scenario Description

A table cannot be queried or exported, but its IBD file survives. Only some pages may be damaged, or the file may be detached from the original directory. Preserve matching CREATE TABLE SQL, then analyze the file and extract readable records directly.

Possible Causes

  • Some page checksums or physical records are damaged.
  • Only one tablespace file was recovered.
  • DDL, clustered-index identity or historical layouts do not match the file.

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

  • - Access to the target table fails while other tables may still work.
  • - The IBD is readable but has damaged pages, missing pages or LOB dependencies.
  • - Native IMPORT requirements for version or layout are not met.

Why Traditional Methods Fail

  • - Logical export may stop at a damaged page.
  • - Creating a table with the same name does not prove a matching physical layout.
  • - INSTANT layouts, partitions and external values require matching evidence.

PDU Solution

PDU checks that the IBD and DDL match, then exports the file using its clustered-record layout. Normal exports read parseable active records. Damaged pages, delete marks and missing dependencies are recorded separately and are not included as complete current data.

Recovery Principle

  1. Preserve IBD and DDL
  2. Inspect File Layout
  3. Parse Clustered Records
  4. Save Readable Data

PDU Core Capabilities

  • Parse a single file without starting the instance.
  • Inspect IBD pages and matching DDL.
  • Parse the corresponding page size and record format.
  • Specify clustered-index identity explicitly when required.
  • Retain external LOB dependencies and error locations.
  • Resume native tasks from the original launch directory.

Recovery Steps

  1. 1

    Configure pdu.ini

    Launch PDU in a result directory outside the sources and preserve the original table file and schema. Use a separate copy rather than files from a running instance.

    Launch PDU in a result directory outside the sources; this launch directory is the working and output location for the run.

  2. 2

    Copy the Corrupted Data File

    Preserve the IBD, matching DDL, available SDI/FRM and external dependencies. Place output in another directory.

  3. 3

    Specify the Table File and Definition

    Use scan ibd to inspect file information and meta ddl to inspect schema evidence. If multiple indexes exist, confirm the clustered-index ID from matching metadata.

    Important: Table Definition Must Match

    Identical schema text does not prove identical INSTANT history, hidden columns or physical layouts. Do not force a DDL match without layout evidence.

  4. 4

    Parse the Data File

    Output contains data only. Normal file export skips delete-marked records. Missing pages and unsupported physical layouts retain original errors and are not treated as a complete export.

    Read-Only Diagnosis

    To assess readable ranges first, execute diagnose ibd RAW_FILE PROFILE;. Diagnosis reports sources and recovery paths without guaranteeing a bootable instance or replacing IMPORT eligibility checks.

  5. 5

    Handling External Large Values

    Large values depend on complete LOB pages or compressed LOB chains. A surviving main record does not guarantee that every external value remains complete. Retain separate reasons for missing pages, keys and broken chains.

    For scattered surviving pages, specify matching table definitions in DropScan and supply the required files. If additional fragments change the pages used for recovery, create a new internal task. SQL is still exported to the launch directory without modifying earlier results.

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.

# Specify the Table File and Definition

scan ibd /recovery-input/orders.ibd;
meta ddl /recovery-input/orders.sql;

# Parse the Data File

unload ibd /recovery-input/orders.ibd /recovery-input/orders.sql;

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

  • Preserve a stable IBD copy and one complete, matching CREATE TABLE statement.
  • Clustered-index identity, row format, partitions and encryption dependencies must match the source.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • Single-file export requires matching DDL; normal export does not treat delete-marked rows as current rows.
  • Missing external-value pages cannot be represented as complete data using null values.
  • The launch directory is fixed as the result directory for the run; OUTPUT_DIR and param output cannot change it.
View Detailed Steps for This Recovery Method
MySQL 场景案例