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가 source에서 purge되면 안 되므로 binlog 보존 기간을 최소 한 번의 백업 주기보다 길게 유지한다.