Recover Deleted Records

I. Initialization

1.1 Preserve the Data Files and Binlog Source

Copy complete numbered logs, the .index list, data directory and table definitions. Logs must be closed; confirm CRC checks, rotation continuity and transaction completeness before scanning.

1.2 Configure pdu.ini

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

If only one table definition remains, use param ddl to specify a matching CREATE TABLE file.

1.3 Start PDU, Initialize, and Check Binlog

b;
use appdb;
param binlog /recovery-input/mysql/binlog;
ckbinlog;

II. Scan for Deleted Records

2.1 Navigate to the Target Table

Use use database_name; to select the database and \dt; to view tables. When initialization has identified the table, use its name directly.

use appdb;
\dt;

2.2 Execute the Scan Command

param restype delete;
param resmode tx;
scan orders;

2.3 Understanding the Scan Output

The TxID reported by this scan is the committed XID. Preserve log ranges, schema versions and native counts; do not confuse it with an InnoDB physical transaction ID.

III. Restore Deleted Data

Use restore del all; to export the scanned range, or replace all with an actual TxID reported by the scan.

restore del all;

IV. Transaction Recovery Mode

4.1 Switch to Transaction Mode

param resmode tx;

4.2 Scan Again to See Transaction Details

scan orders;

Use the committed XID reported by the scan as TxID.

4.3 Restore Specific Transaction

Replace the example ID with an actual TxID.

restore del 12345;

Using the Recovered Data

After confirming the target definitions and recovery scope, execute recovery SQL in an isolated target database. UPDATE recovery procedures require routine privileges and are not executed automatically by PDU.

Scan Phase Notes

startwal/endwal restrict the log range. startpos/endpos apply only to event boundaries in the first and last logs. Time selection uses UTC commit time [starttime,endtime).

When complete Binlog is missing, assess resmode undo, redo or dead separately. They use different sources and commit evidence; dead records do not directly establish committed business deletion.

Recover by Time Range or Target Historical Time

Time filtering uses UTC commit time and retains complete transactions. Historical snapshots use resmode history, restype all, ENDPOS and the DDL for the target time. They require continuous ROW logs with an observed CREATE/TRUNCATE starting point. Replace the example ranges and positions with actual source values.

param resmode time;
param starttime "2026-09-08 00:00:00";
param endtime "2026-09-09 00:00:00";
scan orders;

Output Files

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.

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.