Recuperación a un punto en el tiempo con binlogs: encontrar y omitir la transacción errónea

Comando

# 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

Qué hace

Tras restaurar el backup, reproduce los binlogs en orden para llevar la base de datos al punto deseado. Con GTID activado, las transacciones que ya están en el backup se omiten automáticamente; --exclude-gtids elimina solo la operación errónea y conserva todos los cambios posteriores.

Cuándo usarlo

Tras un DROP / DELETE / UPDATE erróneo, para recuperarse sin perder los cambios hechos entre el backup y el incidente.

Precaución

Restaure en un servidor aparte, no en producción; verifique y luego traslade solo la tabla afectada. --start/--stop-datetime se interpretan en la zona horaria de la máquina que ejecuta mysqlbinlog. --stop-position solo se aplica al último archivo indicado; con varios archivos, reproduzca por completo los anteriores en un comando aparte. --exclude-gtids solo es seguro para una operación independiente; si transacciones posteriores escriben en la tabla eliminada, también fallan. Los binlogs necesarios no deben purgarse en el origen; mantenga una retención de binlogs más larga que al menos un intervalo de backup.