Troubleshooting·MySQL
MySQL Point-in-Time Recovery
A dump restores last night. The binary log holds everything since - including the rows a mistaken DELETE removed, with their values still readable. Finding the damage is the part that has to be right before any replay.
Backup and Restore Guide 25 of 45 Advanced
- OSUbuntu 26.04 LTS
- MySQL8.4.10-0ubuntu0.26.04.1
- BinlogROW format, enabled by default
- TimeAbout 18 min
--base64-output=DECODE-ROWS --verbose is what makes ROW-format events readable. Without both flags the output is base64 blobs.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| db-a01 | 192.168.0.81 | Ubuntu 26.04 LTS | Primary / Source / Replica Set Member 1 | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a dump gets you to last night and the damage happened this morning. This matters because the binary log holds everything since - so recovery is a restore plus a replay up to the moment before.
- causing damage with a DELETE that is valid, runs cleanly, and is entirely wrong
- finding the current log, and reading what it recorded
- locating the boundary you would replay up to
Before you start
- Binary logging enabled - see the previous guide.
- A dump to restore from, and the binary logs covering the period since.
-
Cause the damage
-
Find the current log and read what it recorded
-
Locate the boundary you would replay to