Recuperação point-in-time com binlogs: encontrar e pular a transação errada

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

O que faz

Após restaurar o backup, reaplica os binlogs em ordem para levar o banco ao ponto desejado. Com GTID ligado, as transações que já estão no backup são puladas automaticamente; --exclude-gtids remove apenas a operação errada e mantém todas as mudanças posteriores.

Quando usar

Após um DROP / DELETE / UPDATE errado, para recuperar sem perder as mudanças feitas entre o backup e o incidente.

Atenção

Restaure em um servidor separado, não em produção; verifique e então mova apenas a tabela afetada. --start/--stop-datetime são interpretados no fuso horário da máquina que executa o mysqlbinlog. --stop-position se aplica apenas ao último arquivo informado; para vários arquivos, reaplique os anteriores por completo em um comando separado. --exclude-gtids só é seguro para uma operação independente; se transações posteriores gravarem na tabela removida, elas também falham. Os binlogs necessários não podem ter sido expurgados na source; mantenha a retenção de binlog maior que pelo menos um intervalo de backup.