Point-in-Time Recovery mit Binlogs: fehlerhafte Transaktion finden und überspringen

Befehl

# 1) Find the bad event's GTID and position (narrow by time range)
mysqlbinlog --base64-output=DECODE-ROWS -vv --start-datetime='2026-10-08 20:00:00' --stop-datetime='2026-10-08 20:30:00' /var/lib/mysql/binlog.000003 | grep -B12 -iE '^(DROP|TRUNCATE)' | grep -E 'GTID_NEXT|^# at|^#[0-9]{6}|^DROP|^TRUNCATE'

# 2) Restore the backup on a separate server (the dump sets GTID_PURGED)
zcat /backup/full_2026-10-08_0200.sql.gz | mysql -h restore-db -u root -p

# 3a) Replay all binlogs skipping only the bad transaction
mysqlbinlog --exclude-gtids='af6bc361-c353-11f1-8f12-f69e63ad6c0e:23' /binlogs/binlog.000003 /binlogs/binlog.000004 | mysql -h restore-db -u root -p
# 3b) Or stop right before the bad event's GTID event
mysqlbinlog --stop-position=537205 /binlogs/binlog.000003 | mysql -h restore-db -u root -p

Was es tut

Spielt nach dem Restore des Backups Binlogs der Reihe nach ein, um die Datenbank auf den gewünschten Punkt zu bringen. Mit aktivem GTID werden bereits im Backup enthaltene Transaktionen automatisch übersprungen; --exclude-gtids entfernt nur die fehlerhafte Operation und behält jede Änderung danach.

Wann einsetzen

Nach einem fehlerhaften DROP / DELETE / UPDATE, um wiederherzustellen, ohne Änderungen zwischen Backup und Vorfall zu verlieren.

Vorsicht

Auf einem separaten Server wiederherstellen, nicht in der Produktion; prüfen und dann nur die betroffene Tabelle übertragen. --start/--stop-datetime werden in der Zeitzone des Rechners interpretiert, auf dem mysqlbinlog läuft. --stop-position gilt nur für die zuletzt angegebene Datei; bei mehreren Dateien die früheren in einem separaten Befehl vollständig einspielen. --exclude-gtids ist nur bei einer unabhängigen Operation sicher; schreiben spätere Transaktionen in die gelöschte Tabelle, schlagen auch sie fehl. Die benötigten Binlogs dürfen auf der Quelle nicht gelöscht sein; die Binlog-Aufbewahrung länger als mindestens ein Backup-Intervall halten.