MySQL 데이터 복구기

프로젝트를 가오픈 후 테스트 진행 중에 사수가 table을 truncate 해 버렸다.

데이터 베이스는 현재 운영중인 데이터 베이스이고 분당 약 2000회 이상의 업데이트가 진행 중 이었습니다.

select 쿼리인줄 알고 truncate 문을 작동 시킨게 화근이었다.

 

나도 안해본 실수 인데 사수분이 실수하여 처음으로 심장 떨리는 일이 생겼다.

 

https://hudi.blog/mysql-pit-recover/

실수로 MySQL 데이터를 삭제했을 때 바이너리 로그를 통해 복구하기 😱 (PIT 복구)

 

바이너리 데이터의 총 크기는 약 4기가 정도였으며 위 블로그 링크에 나온 것 처럼 진행 하였습니다.

 

사용한 데이터  베이스 주요 명령어

SHOW BINARY LOGS;
FLUSH LOGS;

사용한 쉘 명령어

mysqlbinlog /var/lib/mysql/binlog.000001 > binlog.000001.sql

mysql -u 유저이름 -p -f < recover.sql

정도를 사용하였습니다.

 

하지만 !! 두둔!! 바이너리 데이터의 변환과정 후  truncate를 찾던 중에 Out Of Memory로인하여 서버가 터져버렸습니다!

원래 2코어 4기가 였던 데이터 베이스를 급한대로 4코어 8기가로 스케일 업 한 뒤 진행하게 되었습니다.

 

우선 위에 있는 예제 처럼 진행하려고 했으나 우리는 데이터들이 최신 바이너리 데이터는 있었지만 처음 만들어졌을때 바이너리 데이터가 존재하지 않았기 때문에 바로 데이터 베이스에 바로 부울 수 있는 상황이 아니었습니다.

 

그래서 작업 계획은 우선 바이너리 로그에서 truncate 부분을 찾고 그 이후의 바이너리 로그들은 삭제 후 스키마를 한개 더 만들어서 거기다 부으려고 했습니다. 

 

하지만 호락호락하게 생각대로 되지 않고 바이너리 데이터들이 스키마명.테이블명 이런식으로 작성이 되어 있어서 불가능 하였습니다.

 

하지만 현재 사용중인 데이터베이스는 현재 서비스 중인 데이터 베이스여서 여기다 하기에는 좀 위험한 것 같아서 바이너리 로그를 다운 후 로컬에서 다운 후 진행하기로 결정하였습니다.

 

로컬 MySQL 서버를 한개 뛰운 후 현재 db 데이터를 dump 후 진행을 하였습니다.

 

두손을 공손히 모으고 진행 하였고 그 결과 우리가 원하는 데이터들을 찾아 낼 수 있었습니다.

 

저는 절대 복구 안될 거라고 생각했는데 생각보다  MySQL이 더욱 성숙한 오픈소스 데이터 베이스인 것을 알 수 있었습니다.

 

사수랑 둘이 진행을 하였고, 사수는 싱싱미역 상태가 되어서 제가 주가 되어서 진행 하였는데 개발하면서 이보다 더 손이 떨리고 다시는 경험해보고 싶지 않은 경험이었다. 또한 내가 실수한게 아니라 참으로 다행이라는 생각이 들었습니다.

 

데이터 날려먹고 서버도 터트리고 덕분에 집에 도착하니까 11시 30분이 넘어있었지만 처음 격는 일이다 보니 정신이 너무 없었던 것 같다.

 

다시는 이 게시물을 볼 일이 없었으면 좋을 것 같다.

 

++ 테이블 삭제 후 발주처 있는 실무자한테 db 날려먹은 것을 보고 하였고 본청에 계신 실무자 분께서 발주처에 보고 하였는데 전환 시기에 일어난 일이라고 괜찮다고 그랬었다는 후일담이 있었다.