Восстановление на момент времени по binlog: найти и пропустить ошибочную транзакцию

Команда

# 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

Что делает

После восстановления бэкапа по порядку воспроизводит binlog, чтобы довести базу до нужной точки. При включённом GTID транзакции, уже содержащиеся в бэкапе, пропускаются автоматически; --exclude-gtids убирает только ошибочную операцию и сохраняет все изменения после неё.

Когда использовать

После ошибочного DROP / DELETE / UPDATE — чтобы восстановиться, не потеряв изменения, сделанные между бэкапом и инцидентом.

Внимание

Восстанавливайте на отдельном сервере, а не в production; проверьте, затем перенесите только затронутую таблицу. --start/--stop-datetime интерпретируются в часовом поясе машины, на которой запущен mysqlbinlog. --stop-position применяется только к последнему указанному файлу; при нескольких файлах воспроизведите предыдущие файлы полностью отдельной командой. --exclude-gtids безопасен только для независимой операции; если последующие транзакции пишут в удалённую таблицу, они тоже завершатся ошибкой. Нужные binlog не должны быть удалены на источнике; храните binlog дольше, чем как минимум один интервал между бэкапами.