최근 운영하던 서비스에 테스트 서버를 구축하던 중 테스트 서버용 데이터베이스를 (이하 DB) 어떻게 운영할지 고민하게 되었다.
사실 테스트 서버 운영은 서비스 배포를 시작할 때 이미 고민했던 부분이였지만 당장은 배포 환경을 분기할 정도의 필요성은 없다고 판단했기 때문에 구축하지 않았었다.
현재 테스트 서버를 구축하려는 목적이 서비스의 규모가 커졌기 때문은 아니지만 최근 서비스를 운영하면서 DB 설계에 대한 고민과 배포 단계를 위한 브랜치 전략(Git flow)의 필요성을 느끼게 되었고, 운영 DB와 테스트 DB를 분리함으로써 스키마의 추가 및 변경, Push 기능 등과 같은 운영 서버에서 할 수 없는 테스트를 안정적으로 하기 위해 구축을 결정하게 되었다.
그리고 기존 운영중인 DB 데이터를 기반으로 테스트 서버를 운영하기 위해 AWS RDS를 이관하면서 겪은 문제들과 해결 방법을 작성한다.
삽질
먼저 필자가 운영중인 서비스의 DB는 AWS RDS를 사용중이기 때문에 테스트 서버도 동일한 DB 인스턴스를 사용하기로 결정했다.
그리고 데이터를 이관하는 방법은 여러가지가 존재하지만 MySQL 버전에 상관없이 안정적으로 할 수 있는 방법으로 테이블 단위의 데이터를 sql 파일로 Export 한 후 새로운 DB에 Import하는 방법을 사용하기로 결정했다.
얼마 전에 회사에서 테스트를 위해 운영중인 DB의 일부를 sql 파일로 받아 MySQL Workbench (이하 워크벤치)를 이용하여 데이터를 Dump 해 본 경험이 있었기 때문에 금방 끝낼 수 있다고 생각했지만 당황스럽게도 워크벤치에서 버전 문제가 나타났다.
먼저 경고문에 써있는 mysqldump는 MySQL의 백업 프로그램으로 데이터를 Export 하기 위한 툴이라고 생각하면 된다.
그리고 해당 경고는 워크벤치에서 사용하는 mysqldump의 버전과 AWS RDS에 올라가 있는 MySQL Server의 버전 (5.7.22) 사이에서 일어나는 문제였다.
필자가 이관하려는 DB는 외래키나 트리거 등의 참조가 복잡하게 얽혀 있는 DB가 아니기 때문에 Export된 데이터들만 잘 뽑혔는지만 확인하면 상관없다고 생각해서 일단 Continue Anyway를 눌렀다. 하지만 안타깝게도 정상적으로 실행되지 않았다.
그리고 검색을 통해 해당 이슈를 해결할 수 있는 여러 방법들을 찾아 적용해봤지만 여전히 똑같은 에러가 발생했다.
그래서 결국 워크벤치가 사용하는 mysqldump가 아닌 로컬에 설치된 MySQL의 mysqldump를 사용해 데이터를 꺼내기로 했다.
(검색을 통해 얻은 해결법도 결국 워크벤치에서 로컬에 설치된 MySQL의 mysqldump를 사용하게 하는 것인데 이상하게도 동작하지 않았다.)
mysqldump로 Export/Import 하기
필자의 로컬에 설치된 MySQL 버전을 (5.7.22) 기준으로 진행했기 때문에 상위 버전에서는 위와 비슷한 에러가 발생할 수 있다.
(사실 MySQL 8점대 버전은 운영에서 사용하기에 문제가 많다고 알고 있기 때문에 실제 운영에서는 5점대 버전을 사용하는 것을 추천한다.)
1. AWS RDS 데이터 Export
> mysqldump -u <userName> -p -h <host> -v <dbName> <dbTable> > <exportFile.sql>
먼저 -h 옵션에는 DB 인스턴스의 엔드포인트를 적어준다. (로컬의 경우 localhost를 적어주면 된다.)
-v에는 Export할 DB의 이름과 테이블 명, Export 할 파일의 이름을 .sql 확장자로 적어준다. (테이블 단위가 아닌 DB 단위로 데이터를 통째로 Export 하고 싶을 경우 <dbTable>을 생략하면 된다.)
그리고 화살표 기호(?)를 주의하자.
">"는 해당 DB의 테이블을 sql 파일로 Export 한다는 의미이고, Import 할 때는 "<" 기호를 사용해야 한다.
2. Export한 데이터를 Import 할 DB 생성
> mysqladmin -u <username> -p create newDB
3. 새로 생성한 DB에 Export 한 sql 파일 Import
> mysql -u <username> -p <newDB> <newTable> < <fileName.sql>
테이블 단위로 데이터를 이관할 경우 1, 3번의 과정을 반복하면 된다.
그리고 Import된 DB에 문제가 없는 것을 확인한 후 이전 DB를 삭제하면 이관 작업은 끝이 난다.
마치며
사실 크지 않은 데이터를 이관하는 작업은 어렵지 않다.
특히 워크벤치를 사용할 경우 클릭 몇 번 만으로 쉽게 데이터를 옮길 수 있기 때문에 필자와 같이 DB의 구조가 복잡하기 않고, 데이터가 많지 않은 경우에는 금방 끝낼 수 있지만 언제나 그렇듯 쉬운 작업도 예상치 못한 에러를 만나게 되면 상당히 많은 시간을 쓰게 되는 것 같다.
하지만 설계가 복잡하거나 데이터 양이 많은 경우 또는 RDB에서 NoSQL, NoSQL에서 RDB로 이관하는 작업은 굉장히 긴 시간을 갖고, 신중하게 접근해야 한다. (최근 인턴중인 회사에서 MongoDB -> MariaDB 이관이 마무리 되었는데 필자가 입사하기 전 부터 진행되던 긴 작업이였고, 이관이 끝난 이후에도 완전히 안정화가 될 때 까지 끊임 없이 발생하는 이슈에 대한 Troubleshooting이 필요한 것을 지켜보면서 이관의 필요성이 존재하더라도 쉽게 결정할 수 있는 부분이 아니라는 것을 느꼈다.)
최근 필자는 DB 작업과 간단한 이관 작업 등을 하면서 워크벤치의 편리함을 느낀 후 자주 사용하고 있다.
하지만 자주 사용하다 보니 어느 순간 툴에 의존해 개발하는 것 같다는 느낌을 받았다.
워크벤치는 MySQL GUI 툴로서 DB의 생성부터 스키마 변경을 포함한 테이블 작업을 편리하게 할 수 있게 도와주고, 특히 ERD를 생성해주는 등의 장점은 확실하지만 툴을 사용함으로써 오히려 스스로 DB에 대한 고민을 하지 않게 되는 것 같았기 때문이다. (특히 이번 이관 작업을 하면서 워크벤치 에러를 해결하려고만 하다 보니 쉘에서 해보려는 생각을 하지 않았고, 최근 Trigger 작업을 하며, 구글에 워크벤치로 Trigger 설정하는 방법을 먼저 찾아보는 스스로의 모습에 흠칫했다.)
물론 필자만 느낀 점 일수도 있지만 최근엔 이러한 이유로 시각적으로 보는 것 이외에 무조건적인 툴 사용은 지양하려고 하고 있다. (사실 필자는 컴맹이라 원래 툴을 잘 쓰지 않아서 쉘을 통해 작업하는 것이 더 편한 이유도 있다. 하지만 잘 모르는건 함정..)
하지만 어디까지나 개발하면서 툴에 의존하게 되는 것 때문에 사용을 지양하려는 것이지 툴이 나쁘다는 것은 아니기 때문에 맹목적이지 않다면 툴 사용은 언제나 옳다. (크라켄, 워크벤치 짱! :>)
마치며 최근 회사 업무와 더불어 토이 프로젝트로 운영 중인 서비스에서도 DB 관련 작업할 내용이 많아지고 있는데 당분간은 최근 서비스를 운영하며 겪었던 DB 문제들과 앞으로 작업할 내용들을 중점으로 블로그 글을 작성할 예정이다. (RDB의 Connection Pool과 Transaction 그리고 Trigger에 대한 글을 차례로 작성할 예정이다.)
안녕하세요. 평범한 대학생 개발자 yorr입니다.
포스팅을 읽고 궁금한 점 또는 문의가 있으신 분은 메일 또는 댓글을 남겨주세요.
Mail: twysg@likelion.org
Github: https://github.com/sangyeol-kim