Recover Updated Records

This article explains how to use PDU to recover accidentally updated records from MySQL Binlog. Recovery generates SQL without executing it automatically.


Comparison with Deleted Records Recovery

OperationScan TypeOutput
DELETErestype=deleteSQL restoring deleted rows
UPDATErestype=updateReverse-order UPDATE SQL

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=update

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. Switch Recovery Type to Update

param restype update;

UPDATE recovery uses before and after images and generates recovery SQL in reverse order. The generated recovery procedure rejects the complete batch when after images conflict or match multiple rows.


III. Scan for Updated Records

3.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;

3.2 Execute the Scan Command

param restype update;
param resmode tx;
scan orders;

IV. Restore Updated Data

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

restore upd all;

4.1 Restore All Updated Records

restore upd all;

4.2 Transaction Mode for Precise Recovery

Switch to transaction mode and scan again, then use the reported TxID to recover a selected transaction. Replace the example ID with an actual TxID.

param resmode tx;
scan orders;
restore upd 12345;

V. 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.

Option 1: Direct UPDATE Back

After confirming the target scope, execute the generated reverse-order UPDATE recovery procedure in an isolated target. It requires routine privileges and after-image matching.

Option 2: Import to Temporary Table

To inspect old values first, import independently exported old rows into an isolated table. Determine applicable records from business rules and task sources without automatically comparing production data.

Option 3: Replace Entire Table

Consider whole-table replacement only after snapshot completeness and schema matching are established and the user explicitly authorizes it. Ordinary UPDATE before-images are not a complete table snapshot.


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.

MySQL 文档