[MySQL] RDS에서 RDS로 데이터 migration
최근에 진행중인 프로젝트에서 테스트 서버와 프로덕트 서버를 분리하고 있습니다.
그 과정에서 테스트 서버의 DB와 프로덕트 서버의 DB도 각각 존재해야했죠.
기존에 사용하던 DB는 AWS RDS MySQL이었고 이를 프로덕트 서버의 DB로 사용하고자 하였습니다.
테스트 서버의 DB는 마찬가지로 AWS RDS MySQL로 새로 만들어서 데이터를 migration하고자 하였습니다.
이 과정들과 그 과정 속에서 발생한 문제점들을 정리해보았습니다.
DB Dump
여러 방법이 있겠지만 dump를 하는 방법으로 방향을 잡았습니다.
dump란 현재 데이터를 insert query로 바꿔서 저장하는 방법입니다.
insert query로 치환되기 때문에 DBMS나 기타 버전 문제애도 크게 영향을 받지 않는다는 장점이 있습니다.
mysqldump 명령어를 통해서 CLI로 작업이 가능하지만 MySQL Workbench 를 통해 더 쉽게 GUI를 통해 진행하였습니다.
우선 test와 product에서 사용할 RDS와의 connection을 만들어주었습니다.
data export
data를 export 하기 위해서는 당연히 기존에 존재하던 DB인 product에 접속해야 합니다.
상단 메뉴바에 Data Export 를 해줍시다.
원하는 SCHEMA 를 골라줍니다.
sys 는 MySQL의 설정을 관리하는 파일이니 export할 필요없습니다.
Export to Dump Project Folder 를 통해 하나의 테이블마다 하나의 파일로 export 할 수 있습니다.
저는 Export to Self-Contained File 를 통해 전체를 하나의 파일로 export 해주었습니다.
오른쪽 아래 Start Export를 통해 이를 진행합니다.
버전 호환성의 문제로 경고창이 떴지만 별 문제가 없어 진행하였습니다.
결과적으로 sql파일이 생성되었습니다.
data import
export한 데이터를 가지고 test DB에 import를 하도록 하겠습니다.
test DB에 접속하여 Data Import를 진행합니다.
위에서 하나의 파일로 export 했으므로 파일로 import 하기 위해 Import from Self-Contained File을 선택하고 오른 쪽 아래에 Start Import를 진행합니다.
아쉽게도 import는 ERROR가 발생합니다.
SUPER 권한이 없기 때문에 발생하는 문제였습니다.
ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
하지만 RDS 인스턴스는 Amazon에서 관리합니다. 때문에 복제와 같은 사항을 위반하지 않도록 하려면 인스턴스를 만들 때 설정한 루트 사용자도 전체 SUPER 권한을 갖지 않습니다.
해당 오류를 해결 하기 위해 AWS 공식문서에서 두 가지 방법을 제시하였습니다.
첫 번째 방법은 import할 test DB에 파라미터 그룹의 global log_bin_trust_function_creators 값을 바꿔주는 것이었습니다.
log_bin_trust_function_creators 옵션은 MySQL이 function, trigger 생성에 대한 제약을 강제할 수 있는 기능이다.
default는 OFF이고 권한이 있더라도 trigger를 생성할 수 없고, function을 생성할 수 없다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/error-1227-mysqldump/
두 번째 방법은 export한 파일에서 DEFINER 에 대한 정보를 제거하는 것이었습니다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/definer-error-mysqldump/
하지만 두 가지 방법 모두 에러를 해결하지 못했고 다른 방법으로 접근하였습니다.
직접 쿼리 날리기
export된 sql파일의 쿼리들을 직접 날려주었습니다.
그 결과 어디서 에러가 발생하는지 확인할 수 있었습니다.
다음 코드들에서 로그를 설정하기 위한 SUPER 권한이 필요했고 이 부분을 주석처리하고 진행하였습니다.
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN
--set-gtid-purged=OFF 를 설정을 통해 해결할 수 있지만 workbench의 경우 이를 위해 설정파일을 직접 건드려야 하는 점이 꺼림직하여 주석으로 넘어갔습니다.
그 후 쿼리를 날린 결과, 데이터가 성공적으로 migrations 된 것을 확인할 수 있었습니다.