실수로 DROP DATABASE 쿼리를 입력하거나 WHERE문을 빼먹었다면 눈앞이 캄캄해질 것이다. 과연 데이터를 복구할 수 있을지 여부를 알아보자.
복구 방법 등에 대해서는 본 글에서 다루지 않는다.
우선 아래부터 확인해보자
- 저장 방식이 하드디스크인지
- 바이너리 로그가 켜져 있는지
- MySQL 버전이 8.4 이후인지
- 백업 파일이 있는지
바이너리 로그 방식
바이너리 로그는 세가지 방식이 있다.
- STATEMENT: 쿼리만 저장.
- ROW: 변경된 Row의 정보까지 저장. MySQL 8.4 이후 기본값이다.
- MIXED: 일부 쿼리에만 ROW 방식으로 저장. 일반적으로 사용되지 않고 이 옵션을 사용할 정도라면 이미 백업 자동화를 진행한 사용자일 것이므로 본 글에서는 설명하지 않음.
복원 가능 여부
하드디스크인 경우
즉시 서버 전원을 강제 종료하고, 글을 읽도록 하자. 이 글을 읽는 중에도 데이터가 덮어씌어져 복구가 어려워질 가능성이 있다.
바이너리 로그 방식이 STATEMENT인 경우
백업 파일과 백업 시점부터 복원하려는 시점까지의 바이너리 로그가 있다면 파괴적 명령어 입력 전으로 되돌릴 수 있다.
만약 백업 파일이 없다면 복원이 불가능하다.
일부 바이너리 로그가 손실되었다면 어느정도 복구는 가능하나 완벽하게 복구는 불가능하다.
이 시점에서 하드디스크를 사용중이라면 용산에 하드디스크를 맡겨서 복구를 시도해 볼 수도 있을 것이다. SSD라면 포기하자.
바이너리 로그 방식이 ROW인 경우
당신이 MySQL 8.4 이상을 사용한다면 다행이다! ROW가 기본값이다.
변경 내역까지 기록이 되므로 바이너리 로그 파일만 확보한다면 백업 파일 유무와 관계 없이 복원이 가능하다.
무조건 ROW가 좋은 것 아닌가요?
ROW는 모든 변경사항을 다 기록하는 방식이라 용량이 크기에 실제 프로덕션에서 사용하기는 부적절하다. 따라서 정기적인 데이터베이스 백업과 STATEMENT 방식의 바이너리 로그를 조합해서 사용하는 것이 가장 적절할 것이다.
마치며
자료를 날려먹고 이 글을 보는 중이라면, 지금 당장 바이너리 로그와 데이터베이스 백업 파일을 즉시 확보해두도록 하자. 이 파일들은 용량이 부족하거나 며칠이 지나면 자동으로 삭제된다.
항상 백업은 철저히 하도록 하자.