Back to Scenarios

Data Changed Incorrectly, with Only Undo or Redo Left?

Recover Data from Undo and Redo

Scenario Description

Incident-range Binlog is incomplete, but frozen Undo or a pre-incident base snapshot with later Redo survives. Undo may contain history not yet purged. Redo advances matching base pages to an explicit log boundary before history is handled using the available evidence.

Possible Causes

  • Binlog is unavailable, but Undo history has not been purged.
  • A base checkpoint and subsequent continuous Redo survive.
  • A provable historical state must be reconstructed from a complete offline snapshot.

Challenges

Conventional recovery often requires complete files, a running instance or a usable backup. In these situations, choose a method based on the evidence that survives.

Common Errors and Symptoms

  • - Original values changed, with sources differing from normal Binlog recovery.
  • - Recovery requires matching base LSNs, complete MTR end boundaries and Undo chains.
  • - Commit evidence is missing or active transactions remain.

Why Traditional Methods Fail

  • - Redo replays physical pages and is not directly business rollback SQL.
  • - Purged or incomplete Undo cannot supply all original values.
  • - LSNs and commit sequences are different ordering evidence.

PDU Solution

PDU provides separate recovery methods for Undo and Redo. Undo uses surviving version chains and confirmed commit states to analyze old values. Redo replays matching base pages in an offline view. Rebuilding a complete snapshot also requires consistent data directories and transaction files; unrelated copies cannot be mixed.

Recovery Principle

  1. Confirm Base and Logs
  2. Process Page Views or Undo
  3. Confirm Commit State
  4. Export Selected Results

PDU Core Capabilities

  • Scan retained history in Undo mode.
  • Specify Redo sources and base LSNs explicitly.
  • Stop at a verified complete MTR end boundary.
  • Use replayed pages for initialization and data export.
  • Distinguish existing recovery from full-snapshot rebuild.
  • Reject unconfirmed active or prepared transactions.

Recovery Steps

  1. 1

    Initialization

    Provide external Undo and system-tablespace files with spacepaths and systemfiles. Retain original rejection reasons for missing sources without substituting files from another instance.

  2. 2

    Scan Undo History

    Recovery requires surviving physical old values and transaction records. Purged values cannot be recreated from current records alone. ACTIVE/PREPARED or unknown states cannot be treated as committed accidental operations.

  3. 3

    Replay a Redo Page View

    Replace bracketed parameters with verified LSN values. The target must lie in retained logs at a complete MTR boundary. Base pages cannot be newer than the target, and a newer current directory cannot substitute for an older base copy.

    Important: Physical Stop Points and Transaction Commits

    MTR is a physical page-operation unit. A complete MTR end does not automatically equal a business transaction commit. Undo transaction evidence remains necessary. Version 5.7 requires FRM matching the target time, which metadatadir can provide.

  4. 4

    Generate Offline Reconstruction SQL

    rebuild requires a complete consistent snapshot matching the log endpoint and all persistent Undo. Binlog or an isolated IBD cannot construct a current snapshot alone. Retain E_REBUILD_PENDING and stop when persistent ACTIVE/PREPARED transactions remain.

    PDU generates SQL only. Database creation, snapshot loading and index creation are outside a single rollback scope for inverse transactions. The user arranges execution separately in an isolated target.

Quick Command Examples

Preserve frozen sources and launch PDU outside them. Write configuration snippets to pdu.ini and execute PDU commands after startup. Replace example paths, versions, times and task identities with actual evidence.

# Initialization

param datadir /recovery-input/mysql/data;
b;
use appdb;

# Scan Undo History

param resmode undo;
param restype all;
scan orders;
restore tx all;

# Replay a Redo Page View

param datadir /recovery-input/base-before;
param redo /recovery-input/redo-after;
param redobaselsn <verified_base_lsn>;
param redoendlsn <verified_complete_mtr_end>;
param resmode redo;
b;
use appdb;
unload db appdb;

# Generate Offline Reconstruction SQL

param restoretarget rebuild;
param restype all;
scan all;
restore tx all;

Export Results

Recovery SQL

Saved by table and recovery type in the directory where PDU was started. Use the filenames reported by PDU.

Transactions and Sources

Retain scanned transactions, selected ranges, row-image evidence and original errors.

Tasks and Checkpoints

.pdu-work retains native task state; recovery SQL is not executed automatically.

After export, record PDU’s native success and failure counts and original errors, retaining checkpoints. Resume uses native records and file metadata without rereading exported data or automatic trial import.

Prerequisites

  • Preserve complete system tablespaces, Undo, external tablespaces and definitions.
  • Redo requires a verified base checkpoint, logs covering later changes and a matching frozen copy.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • rebuild requires a complete consistent snapshot and persistent Undo; ACTIVE/PREPARED is not a committed state.
  • Encrypted sources require matching keys; purged history and missing chains retain unresolved reasons.
  • These paths do not establish automatic rollback across arbitrary DDL.
View Detailed Steps for This Recovery Method
MySQL 场景案例