Mysql Dumps를 쓴 이유
위코드 2차 프로젝트를 진행하면서 내가 주로 맡은 부분은 기본적으로 데이터를 저장받아서 쓰는게 아닌 회원가입이나 이력서 작성, 지원 등 클라이언트 쪽에서 이벤트가 발생할 때 데이터가 생겨서 DB에 저장되는 파트였다.
그 때문인지 웹 크롤링을 따로 시간을 썼었던 1차 때와는 다르게 2차 때는 기능구현에 촛점을 맞출 수 있었는데, 여기엔 한 가지 문제점이 있었다.
유저가 회사정보를 본 후 '지원하기'를 클릭하면 지원한 회사의 간략한 정보가 저장되는 '지원현황 뷰'를 구현하기 위해서는 내가 만들어 놓은 데이터 테이블 외에 회사쪽 정보가 필요했다. GIT에서 pull과 merge기능을 통해 같은 팀이었던 건규님이 구현한 회사쪽 뷰와 모델을 얻을 순 있었지만, 크롤링을 통해 직접 DB에 넣은 데이터까진 얻을 수 없었다.
이 경우 우리가 생각했던 데이터 전송 방법은 세 가지 였다.
첫 번째, 크롤링한 데이터가 담긴 csv file과 DB upload용 scripts file을 같이 받아서 내가 직접 DB에 업로드 한다.
두 번째, Django Dumps를 활용해서 json 형식의 파일을 생성해서 한 번에 옮긴다.
세 번째, MySQL Dumps를 활용한다.
첫 번째의 경우는 csv파일이 여러개였고, script도 여러개여서 복잡하고 귀찮기도해서 두 번째, 세 번째 방법인 dumps를 활용하기로 했다.
하지만 Django Dumps는 다음과 같은 단점이 존재했다.
-
content type이나 model type등 미세하게 일일히 맞춰서 조정을 해주지 않으면 dumps download가 힘들다.
-
다 맞췄지만 그럼에도 에러발생이 잦다.
그러므로 결국 나는 마지막 방법을 쓰기로했다.
MySQL Dumps는 MYsql에서 직접 Dumps file을 만들기 때문에 Django에 있는 파일들의 영향을 많이 받지 않는다. 덮어쓰는 형식이기 때문에 세세하게 테이블 조정을 할 필요가 없다. 훨씬 간편하다고 할 수 있겠다.
물론 덮어쓰는 방식의 단점도 존재한다. 예를들면 Dumps파일이 스키마가 똑같더라도 안에 들어있는 데이터가 다르므로, 내쪽에 데이터는 모두 날아가고 덤프파일을 기준으로 데이터가 남게된다.
또한 테이블이 일치되지 않은 경우에 Dumps upload 완료 후 Django에 migration file이나 여러 쪽에서 결국 에러가 발생하긴 한다.
사용법
사용방법은 정말 간단하다
덤프파일을 저장할 디렉토리에서 다음과 같은 명령어를 치면 된다.
mysql -u -root -p "저장하고 싶은 DB명" > "저장하고싶은이름".sql
나같은 경우 DB이름이 wwe였으므로 다음과 같이 저장했다.
mysql -u -root -p wwe > backup_wwe.sql
물론 root가 아닌 사용자이름을 사용하는 경우 -root대신 사용자이름을 입력해주면 된다.
백업된 덤프파일을 내 DB에 load하고 싶은 경우
저장된 덤프파일이 있는 디렉토리에 접근해서
mysql -u -root -p wwe < backup_wwe.sql
화살표 방향만 반대로 해주면 된다.
