PDU Features
Comprehensive MySQL data recovery capabilities explained in detail. Click on any feature below to learn more about how it works.
InnoDB Recovery
Extract readable records from a data directory or an individual IBD file. Recovery requires matching table definitions and the related files.
When MySQL reports data-file corruption but the table file and schema evidence remain available, use PDU to parse readable records from the file.
Key Highlights
- I. Initialization
- II. Add Data File to PDU
- III. Parse the Data File
- IV. Handling External Large Values
Use Cases
- 1Choose file extraction or surviving-page recovery using IBD and schema evidence.
Technical Details
01Preserve a stable IBD copy and one complete, matching CREATE TABLE statement.02Clustered-index identity, row format, partitions and encryption dependencies must match the source.03Important: 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.04Read-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.
Binlog-Based Recovery
Read row data from before DELETE and UPDATE operations in ROW Binlog. PDU records why column values are missing or transactions are incomplete.
This article explains how to use PDU to recover accidentally deleted records from MySQL Binlog. Recovery generates SQL without executing it automatically.
Key Highlights
- I. Initialization
- II. Scan for Deleted Records
- III. Restore Deleted Data
- IV. Transaction Recovery Mode
Use Cases
- 1Recover data from before DELETE using Binlog.
Technical Details
01Preserve complete Binlog covering the incident range and matching table definitions.02Old images, transaction boundaries and required fields must be evidenced by logs and observed row history.03Time parameters use UTC commit time with an inclusive start and exclusive end.04Finish the Binlog Check Before Scanning When logs or required row images are missing, retain errors and obtain the missing evidence. Do not change parameters to bypass missing sources.
Safe & Non-destructive
Use frozen source copies. Save task state and exported data in PDU's current working directory, outside the source files, to avoid writing to damaged data.
When a database incident occurs, protect the recovery scene before choosing a recovery method. The following sections describe the materials to preserve for startup failures, accidental DELETE/UPDATE and dropped tables.
Key Highlights
- Scenario 1: The Database Cannot Start or Data Files Are Damaged
- Scenario 2: Accidental DELETE or UPDATE
- Scenario 3: One or More Tables Were Dropped or Truncated
Use Cases
- 1Preserve data files, logs and disk sources before recovery.
Technical Details
01Do Not Repeatedly Restart the Database or Modify Original Data Files Preserve the original directory, error logs and version information first. Do not delete Redo/Undo, rebuild system tablespaces or repeatedly try to start the server before preserving the evidence.02Do Not Write to the Affected Disk Stop new writes immediately and have the incident engineer freeze a disk image or block source first. Keep PDU scan tasks and recovery output in a safe location without writing back to the original device.
Fragment Scanning
Use DropScan to scan surviving data pages, then select recovery candidates using their sources and matching table definitions.
When directories or table files are lost but disk images and scattered InnoDB pages survive, use DropScan to scan, bind definitions and export parseable records. The following sections describe sources, candidates and fragment supplementation in detail.
Key Highlights
- I. Initialize the Scan Task
- II. Obtain Schema and Source Evidence
- III. Bind Table Definitions
- IV. Parse Sparse Pages
Use Cases
- 1Use DropScan to scan surviving pages and record possible table definitions, object generations and dependencies for large values.
Technical Details
01Preserve stable read-only sources, explicit scan ranges and source domains/generations.02Clustered identity, definitions and physical layouts require independent evidence rather than guesses from filenames or space_id.03Important: Schema Compatibility and Business Attribution Successful trial decoding shows that a page can be parsed with the selected definition; it does not identify the business table. ATTRIBUTION_STATE may remain UNKNOWN, and trial batches cannot be unloaded directly. Select the source generation, clustered-index identity and table definition before exporting.
MyISAM & Non-table Objects
Extract active MyISAM records. Save view, trigger and routine definitions and their related information where supported.
When normal export of views, triggers, routines or events is unavailable but matching physical sources survive, use PDU to extract metadata. The following sections describe preparation and operations for each object type.
Key Highlights
- I. Prepare Original Evidence
- II. Read Object Information from Files
- III. Generate Trigger Creation Evidence
- IV. Generate View Creation Evidence
Use Cases
- 1Handle views, triggers, routines, events and sparse-dictionary object attributes separately.
Technical Details
01Important: Object Creation Scope The complete CREATE commands above are limited to corresponding MySQL 5.7.44 sources and contexts. Complete EVENT and 8.0 DD CREATE are outside this scope. Confirm accounts, privileges, dependency order and target execution separately. PDU does not execute GRANT or create business objects automatically.
Historical Values & Snapshots
PDU provides separate recovery methods for Undo, Redo and continuous ROW Binlog. Recoverable data depends on complete log or version chains and a known table definition at the target point.
When complete continuous ROW logs retain an empty-table origin and later changes, use PDU to reconstruct a table snapshot at a specified event boundary. The following sections describe schema configuration, scanning and output in detail.
Key Highlights
- I. Initialization
- II. Scan Complete History
- III. Export the Historical Snapshot
- IV. Using Recovered Data
Use Cases
- 1Reconstruct one table at a specified historical point using a CREATE/TRUNCATE starting point observed in the logs.
Technical Details
01Complete continuous ROW logs, an explicit primary key, DDL matching the target time, and an actual endpos.02An observed CREATE/TRUNCATE empty-table origin is required. A historical schema seed alone does not prove an empty table.
Need Help Using PDU?
Read the MySQL guide for operating steps, requirements and recovery limits.