MySQL 나빠요

zunzero·2022년 12월 5일
0

개발 이모저모

목록 보기
7/7

MySQL 덤프 떠서 import 하기

테스트 서버에 연동된 데이터베이스를 덤프 떠서 각자 로컬 디비로 옮긴 다음, 로컬 디비로 연동해서 작업하자는 이야기가 나왔다.

우리는 Nest.js에 ORM으로 Prisma를 사용한다.
prisma를 사용하면 스키마가 변경될 때마다 migration 해주는 작업을 거치는데, 이게 여간 귀찮은 일이 아니더라.
(내가 초짜라 그렇게 느낄지도 모른다. ㅋㅋ)

이전까지는 테스트 디비에 모두 연결해서 (그래봐야 2명) 마이그레이션 해야할 일이 발생할 때마다 작업을 중단하고 마이그레이션 먼저 진행해서 각자 pull 땡겨받아와서 진행했다.
이번에는 각자 로컬 디비에서 알아서 스키마 조작하다가 마지막에 한 번에 마이그레이션 하자라는 이야기가 나오면서 작업이 시작되었다.

MySQL data export

우선 MySQL 덤프 뜨는 것부터가 문제였다.
테스트 서버 디비는 AWS의 RDS MySQL을 사용했는데, 덤프 뜨는 과정에서 권한 문제로 인한 접속 오류를 경험했다.
그래서 MySQL Workbench에서 직접 data export를 했다.

data export 관련 설정에서도 애를 먹었는데, 이건 그냥 아래 사진으로 첨부하겠다.

여기서 가장 중요했던 것은 'Include Create Schema' 부분이었다.

처음에 'Include Create Schema' 항목을 체크하지 않아 문제가 발생했다.

mysql -u root -p < dumps/Dump20221205.sql

위의 명령어로 덤프 파일을 내 로컬 디비에 Import 하려고 했다.
그런데 모든 데이터베이스를 import 할 것이기 때문에 나는 데이터베이스명을 지정하지 않았다.

mysql -u root -p [이미 만들어진 데이터베이스명] < dumps/Dump20221205.sql

이런 식으로 원래는 미리 만들어놓은 데이터베이스명을 지정해주는 경우가 많다.
그런 경우라면 'Include Create Schema' 항목을 체크하지 않아도 된다.

'Include Create Schema' 항목을 체크하면 덤프 파일에 데이터베이스가 존재하면 drop 시키고 create 하는 sql 문이 추가가 된다.
그래서 위와 같이 데이터베이스를 지정하지 않고, 복수 개의 데이터베이스를 Import 할 수 있는 것이다.

어쨌든 핵심은 'Include Create Schema' 항목을 추가해야 한다는 것이다.

MySQL 버전 문제

MySQL 덤프는 이제 떴고 import 명령어를 입력했다.

mysql -u root -p < dumps/Dump20221205.sql

그러면 이제 에러가 발생한다.

Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' Operation failed with exitcode 1

MySQL 5버전부터 존재하던 'NO_CREATE_USER'라는 sql_mode는 8버전부터 없어졌다.
내 로컬 MySQL은 최신 버전이었고, 회사 MySQL은 몇 버전인지는 모르겠지만 NO_CREATE_USER라는 sql_mode가 존재하는 버전인 모양이다.
어쨌든 회사의 MySQL이 정확히 몇 버전인지는 모르지만 아무튼 버전 문제인 것만은 확실하다.

이에 대한 해결책으로 몇 개의 글을 봤지만 dump file을 수정하는 해결책이 가장 좋은 것 같아서 소개하려 한다.

관련 에러로 구글링을 하면 가장 먼저 뜨는 페이지가 다음의 Stackoverflow 였다. (나 뿐만 아니라 대게 그랬을 것이라 생각한다.)

https://stackoverflow.com/questions/50336378/variable-sql-mode-cant-be-set-to-the-value-of-no-auto-create-user

해당 글에는 다음과 같은 해결책이 제시되어 있다.
하지만 저 명령어를 iterm에 입력해도 오류가 발생한다.

찾아보니 sed 명령어는 Unix 계열인 mac의 터미널에서의 사용법이 다르다고 한다.

https://velog.io/@june20516/AWS-RDS%EC%9D%98-Data-base%EB%A5%BC-dump%ED%95%98%EA%B8%B0

sed -i '' 's/NO_AUTO_CREATE_USER//' `path/for/dumped.sql`

위의 명령어를 통해 NO_AUTO_CREATE_USER 설정을 지울 수 있다고 한다.

그렇게 해서 다시 덤프 파일을 import 하면?
그래도 문제가 발생한다.

NO_AUTO_CREATE_USER 에러와 상당히 유사하고, 같은 이유의 에러이다.
MySQL 버전 문제
그래서 이것도 sed 명령어를 통해 해결했다.

하지만 그렇다고 해서 모든 문제가 해결된 것은 아니다.

MySQL 버전 차이로 인한 문제가 또 발생했지만 이에 대한 해결책은 찾지 못했다.

Docker

앞선 글에 소개했을런지 모르겠지만, 동료분은 이와 같은 문제를 Docker를 띄워 해결하셨다고 한다.
구체적인 설명을 듣기에는 동료 분이 바쁘고 해서 못들었지만 나도 Docker를 공부해야겠다는 생각이 들었다.

profile
나만 읽을 수 있는 블로그

0개의 댓글