Recover a Historical Binlog Snapshot

I. Initialization

param ddl /recovery-input/endpoint-schema.sql;
param binlog /recovery-input/mysql-bin.index;
param startbinlog mysql-bin.000005;
param endbinlog mysql-bin.000008;
param endpos <actual_event_end>;
use appdb;

Log names and positions are examples. The stopping point must be an event end and must not split a transaction. Current table definitions cannot replace the DDL for the target historical time.

II. Scan Complete History

param resmode history;
param restype all;
param restoretarget existing;
ckbinlog;
scan orders;

This method handles one table and requires a specified end position and complete observable history. It does not allow time/GTID filters or selection of just one TxID. PDU records the original causes of unknown origins, missing affected rows and conflicting row images.

III. Export the Historical Snapshot

restore hist all;

If the original table later undergoes DROP, TRUNCATE or schema changes, the endpoint must precede that operation with complete evidence to recover the observable row set. Unproven conversions and missing values remain rejected. Arbitrary DDL is not automatically reversed.

IV. Using Recovered Data

Prepare an isolated empty table matching the historical definition, avoiding triggers, foreign keys and concurrent writes. Generated SQL does not create or delete business tables and rejects a nonempty target. PDU does not connect to the target to execute it.

Output Files

Native records include HISTORY_ORIGIN, HISTORY_ROWS, SCAN_MODE, RESTORED_ROWS and OUTPUT. Completeness depends on log-source assumptions and does not prove that source writes were never filtered or bypassed.

After export, record native success and failure counts and original errors. Resume uses records and file metadata such as existence and size without rereading or validating exported data.