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の後、バックアップとインシデントの間に行われた変更を失わずに復旧するため。

注意

本番ではなく別のサーバーでリストアし、検証してから影響を受けた表のみを移す。--start/--stop-datetimeはmysqlbinlogを実行するマシンのタイムゾーンで解釈される。--stop-positionは最後に指定したファイルにのみ適用されるため、複数ファイルの場合は前のファイルを別のコマンドで完全に再生する。--exclude-gtidsは独立した操作に対してのみ安全。後続のトランザクションが削除された表に書き込む場合、それらも失敗する。必要なbinlogがソースでパージされていてはならない。binlogの保存期間は少なくとも1回のバックアップ間隔より長くする。