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
| Operation | Scan Type | Output |
|---|---|---|
| DELETE | restype=delete | SQL restoring deleted rows |
| UPDATE | restype=update | Reverse-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=updateIf 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.