MySQL 데이터 이관 (with mysqldump)
- 서론
- 개발 서버에서 운영 서버로의 배포가 미뤄져 간극이 더 생기기 전에 db라도 둘을 맞춰주기로 했다
- 따라서 운영 서버 db 데이터를 개발 서버 db로 이관하는 작업을 하게되었다.
- 본론
- 사실 정말 많은 삽질을 했는데,,,,,, copy 기능을 사용하면 각종 제약조건들이 넘겨지지 않아서 불편했고, 스키마만 복제한 후 데이터를 직접 import 하려 했을 땐 스키마의 외래키 제약조건들끼리 충돌이 일어나서 외래키 설정은 따로 해줘야 하는 불편함이 존재했다.
- tables 오른쪽 클릭 > Import/Export > Copy tables to..
- target schema를 원하는 스키마로 맞춰준 후 Import 클릭
- 이때, keys, indexes, foreign keys는 복사 안되는 게 맞다. 그리고 이게 오히려 편하다.
- 왜냐하면 외래키는 특히나 다른 스키마 가르키게 꼬일 수 있으니 복사할 땐 빼고 추후 alter table로 적용해주는 게 낫다.
- SQL Scripts > Generate DDL to clipboard
- 결과로 나온 create문에서 keys, indexex, foreign keys 부분만 남기고 전부 제거한 후 남은 부분을 alter문으로 변경
- 2000개 까지만 데이터 복사가 된다,,ㅋㅋ 그래서 패킷 전송 실패라고 떴다. 우리 db에 40000개짜리 데이터가진 테이블이 있어서 그러했다,,, 해당 테이블만 따로 작업 해주니 성공적으로 복사할 수 있었다.
- 참고
- 개발 서버에서 운영 서버로의 배포가 미뤄져 간극이 더 생기기 전에 db라도 둘을 맞춰주기로 했다
- 따라서 운영 서버 db 데이터를 개발 서버 db로 이관하는 작업을 하게되었다.
- 운영 서버엔 몇 만개 짜리 데이터도 있고 해서 대규모 데이터 이관 관련해 검색해보았다.
- 많이 사용하는 방식은 mysqldump 인 거 같다.
- 이 방식은 아예 다른 환경으로 배포할 때 특히 도움될 거 같다. rds를 교체한다던가 하는.
- 우리는, 사실 개발 서버 db와 운영 서버 db가 하나의 rds에 존재한다. 스키마로 분리된 채로 말이다.
- 따라서, 굳이 mysqldump를 이용해 통신을 할 필욘 없어보였다.
- 우린 데이터그립의 sqldump란 기능을 이용해보기로 했다.
- 이 방식도 사실 하나의 rds에서 스키마만 교체할 때 크게 도움이 되는진 잘 모르겠지만 드는 리소스가 적어보였다.
- 결론적으로 mysqldump를 사용한 방법이 가장 편하고 빠르고 정확했다.
- 제약조건들까지 한 번에 옮겨지고
- 사용 방법을 아래 적겠다.
- mysqlworkbench 깔기 →
brew install --cask mysqlworkbench - 데이터그립에서 원하는 스키마 혹은 테이블의 오른쪽 클릭 >
Import/Export>Export with mysqldump클릭 - Path to mysqldump에 아래 경로 입력
/Applications/MySQLWorkbench.app/Contents/MacOS/mysqldump- 생성된 dump.sql 파일을 데이터그립으로 드래그 앤 드랍
- dump.sql 파일에서 아래 코드들 지워주기
- 혹시 나처럼 데이터그립에서 파일 크기가 너무 커서 읽기 전용 모드라 수정이 안된다 하면 vsc로 여는 걸 추천한다. 위 4줄을 각각 검색해서 지워줬다.
- 데이터그립에서 dump.sql 파일 오른쪽 클릭해서 Run 클릭 (실행 시 스키마 지정해주기)
- 더 디테일하게 보고 싶으신 분은 아래 글을 참고해주면 좋을 거 같다,
삽질 : 간단하게 데이터그립의 copy table 기능을 사용해보았다. 제약조건 옮기는 게 너무하다.

삽질 : 패킷 전송 실패,,,, 나눠서 하자
삽질 : mysqldump 잘 모를 때 쓴 정보 글,,, 틀린 말도 있으니 무시하자,,





적용 시 발생한 에러 로그 → Access denied 뜨는 세 줄을 지워줘서 해결해줬다
- 결론
- mysqldump를 이용해서 데이터를 전부 이관하는 데 1분 9초 정도 걸렸다.
- 가장 데이터가 많은 테이블은 40000건 정도 가졌었다.
- 처음엔 40000건이면 대용량인가 생각했는데 직접 옮겨보고 40000건은 대용량이 아님을 깨달았다.
- 보통 1억건 이상부터 대용량으로 처리해야 하는 거 같다.
- 그래서 우리 서비스에선 쉽게 데이터 이관을 해줄 수 있었다.
- 이번에 추가로 든 생각은 dev에만 추가된 테이블을 prod에도 반영해주는 걸 지금까진 실제 배포 시점에 수동으로 해왔는데 flyway를 사용하면 이 역시 자동화할 수 있겠단 생각이 들었다. 이 부분은 추후 작업해줘야겠다.



.png?table=block&id=49752e1f-bcf7-4715-a16f-53cadd5c9d53&cache=v2)

