[EAT-SSU / 잇슈] RDS 데이터 다른 AWS 계정으로 이전하기

✏️ 개요

최근 EAT-SSU 프로젝트에서 AWS 프리티어 만료로 인해 새로운 AWS 계정으로 서버를 이전해야 하는 상황이 발생했습니다.

EAT-SSU는 PROD 서버와 DEV 서버, 총 2개의 서버를 운영하고 있었는데, 며칠 전 DEV 서버를 먼저 이전하면서 문제가 생겼습니다. 당시에는 DataGrip에서 DDL과 DML 파일을 일일이 Export한 뒤, 새로 생성한 RDS에 쿼리를 직접 입력하는 방식으로 진행했는데, 과정이 번거롭고 실수할 가능성이 있었습니다.(다행히 실수는 하지 않았음)

이번에 PROD 서버를 이전하면서는 더 나은 방법을 찾아보게 되었고, mysqldump를 활용하면 전체 데이터를 한 번에 덤프하고 복원할 수 있다는 것을 알게 되었습니다. 이번 포스팅에서는 RDS 데이터 이전을 위한 두 가지 방법(AWS 스냅샷 공유 방식 vs mysqldump 방식)을 비교하고, DataGrip + mysqldump를 이용해 실제로 이전하는 과정을 단계별로 정리해보겠습니다.

✏️ 두 가지 방법 비교

RDS 데이터를 다른 계정으로 이전하는 방법은 크게 두 가지입니다.

방법 1: AWS 스냅샷 공유 방식

AWS 콘솔에서 기존 RDS의 스냅샷을 생성한 뒤, 새 계정에 스냅샷을 공유하고 복원하는 방식입니다.

 

진행 순서

1. 기존 계정 RDS → 스냅샷 생성
2. 스냅샷 → 새 AWS 계정 ID로 공유
3. 새 계정에서 공유된 스냅샷 수락
4. 스냅샷으로 새 RDS 인스턴스 복원

장점

• 데이터 용량이 커도 빠르게 이전 가능
• AWS 내부에서 처리되므로 네트워크 부하 없음
• DB 설정(파라미터 그룹, 엔진 버전 등)까지 그대로 복원됨

단점

• 계정 간 공유 설정이 복잡함
• 스냅샷 저장 비용 발생
• 복원 시 새 RDS 인스턴스가 생성되므로 기존 인스턴스에 덮어쓰기 불가
• VPC, 서브넷, 보안 그룹 등 네트워크 설정을 별도로 맞춰줘야 함
• 암호화된 스냅샷은 KMS 키까지 공유해야 해서 더 복잡함

방법 2: mysqldump 방식 

DataGrip을 통해 기존 RDS의 데이터를 .sql 파일로 추출한 뒤, 새 RDS에 적용하는 방식입니다.

 

진행 순서

1. DataGrip으로 기존 RDS 접속 → .sql 덤프 파일 추출
2. 덤프 파일 일부 수정 (RDS 권한 이슈 해결)
3. DataGrip으로 새 RDS 접속 → 덤프 파일 복원

장점

• 설정이 단순하고 AWS 콘솔 조작 거의 불필요
• 추가 비용 없음
• 특정 테이블만 선택해서 이전 가능
• DB 엔진 버전이 달라도 대부분 호환됨

단점

• 데이터 용량이 크면 시간이 오래 걸림
• 로컬을 거쳐서 이전하므로 네트워크 속도에 영향받음
• RDS 권한 이슈로 덤프 파일 수동 수정 필요

방법 선택 기준

학부 프로젝트나 소규모 서비스라면 데이터 용량이 크지 않으므로 mysqldump 방식이 훨씬 편하다고 생각합니다.

상황	추천 방식
DB 용량이 수십 GB 이상	스냅샷 방식
빠르게 간단하게 이전하고 싶음	mysqldump 방식
일부 테이블만 이전하고 싶음	mysqldump 방식
AWS 설정에 익숙하지 않음	mysqldump 방식
완전히 동일한 RDS 환경 복제 필요	스냅샷 방식

✏️ 본인 환경

• OS: macOS(m3 Pro)
• DB: MySQL 8.0
• Tool: DataGrip
• mysqldump 경로: /opt/homebrew/bin/mysqldump

✏️ 전체 흐름

기존 RDS 접속
    ↓
DataGrip으로 덤프 추출 (.sql 파일 생성)
    ↓
덤프 파일에서 GTID_PURGED 줄 제거
    ↓
새 RDS 접속
    ↓
DataGrip으로 덤프 복원

1단계: mysqldump 경로 확인

DataGrip에서 mysqldump를 실행하려면 로컬에 설치된 mysqldump의 정확한 경로를 알아야 합니다. 터미널을 열고 아래 명령어를 실행합니다. => which mysqldump 
mysqldump가 설치되어 있지 않다면 해당 명령어로 설치합니다. =>brew install mysql-client

 

환경	경로
M1/M2 Mac (Homebrew)	/opt/homebrew/bin/mysqldump
Intel Mac (Homebrew)	/usr/local/bin/mysqldump
MySQL 공식 설치	/usr/local/mysql/bin/mysqldump

 

2단계: 기존 RDS에서 덤프 추출

DataGrip에서 기존 RDS에 연결된 상태에서 진행합니다.

1. 좌측 DB 목록에서 기존 RDS의 데이터베이스 우클릭
2. Import/Export → Export with 'mysqldump' 클릭
3. 아래와 같이 설정
4. RUN 클릭

항목	값
Where to run	Locally
Path to executable	/opt/homebrew/bin/mysqldump
Output result to	원하는 경로
Databases to dump	덤프할 DB 이름

정상적으로 실행되면 지정한 경로에 .sql 파일이 생성됩니다. 파일을 열어보면 아래와 같이 DDL과 실제 데이터가 모두 포함되어 있습니다.

-- 테이블 구조 생성 (DDL)
CREATE TABLE `college` (
  `college_id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`college_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 실제 데이터 삽입
INSERT INTO `college` VALUES (1,'인문대학'),(2,'자연과학대학'),(3,'법과대학'),...

3단계: 덤프 파일 수정 (GTID_PURGED 제거)

덤프 파일을 그대로 새 RDS에 복원하면 아래 에러가 발생합니다.

ERROR 1227 (42000) at line 24: Access denied; 
you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation

원인

덤프 파일 상단에 아래 구문이 포함되어 있기 때문입니다. 
GTID(Global Transaction Identifier)는 MySQL 복제 환경에서 트랜잭션을 고유하게 식별하기 위한 값입니다. mysqldump는 기본적으로 이 값을 덤프 파일에 포함시키는데, 이를 설정하려면 SUPER 또는 SYSTEM_VARIABLES_ADMIN 권한이 필요합니다.

그런데 AWS RDS는 관리형 서비스 특성상 보안상의 이유로 SUPER 권한을 사용자에게 부여하지 않습니다. 따라서 이 구문을 그대로 실행하면 권한 오류가 발생합니다.

SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';

해결 방법

해당 줄을 덤프 파일에서 제거하면 됩니다. 직접 파일을 열어서 해당 줄을 찾아 지워도 되고, 터미널 명령어로 한 번에 제거할 수도 있습니다.

 

터미널 명령어로 제거 (권장)

sed -i '' '/GTID_PURGED/d' /Users/yourname/dump파일명.sql

 

직접 파일 수정

.sql 파일을 텍스트 에디터로 열어서 아래 줄을 찾아 삭제합니다.

SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';

4단계: 새 RDS에 덤프 복원

DataGrip에서 새 AWS 계정의 RDS에 연결된 상태에서 진행합니다.

1. 좌측 DB 목록에서 새 RDS의 데이터베이스 우클릭
2. Import/Export → Restore with 'mysql' 클릭
3. 아래와 같이 설정
4. Path to executable은 반드시 mysql로 설정해야 합니다. mysqldump로 설정하면 unknown variable 'database=prod' 에러가 발생합니다 Export(추출)은 mysqldump 사용하고 Import(복원)은 mysql로 사용하시면 됩니다.

항목	값
Where to run	Locally
Path to executable	/opt/homebrew/bin/mysql
Database	복원할 DB 이름
Path to dump	3단계에서 수정한 .sql 파일 경로

✏️ 트러블슈팅

Path to executable is wrong

DataGrip에서 mysqldump 경로가 틀렸을 때 발생합니다. 터미널에서 which mysqldump로 실제 경로를 확인 후 입력하세요.

unknown variable 'database=prod'

Restore with 'mysql' 실행 시 Path to executable에 mysqldump를 입력했을 때 발생합니다. mysql로 변경하세요.

[2026-05-03 15:08:06] /opt/homebrew/bin/mysqldump --database=prod --user=admin --host=127.0.0.1 --port=51991 < /Users/pooreum/_-2026_05_03_15_02_50-dump.sql
mysqldump: [ERROR] unknown variable 'database=prod'.

Access denied; SUPER privilege

3단계에서 설명한 GTID_PURGED 구문 때문입니다. sed 명령어로 해당 줄을 제거하세요.

ERROR 1227 (42000) at line 24: Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation

sed -i '' '/GTID_PURGED/d' /Users/pooreum/_-2026_05_03_15_02_50-dump.sql // 해결

 

✏️  마무리

스냅샷 방식은 대용량 DB 이전이나 완전한 환경 복제가 필요할 때 적합하고, mysqldump 방식은 소규모 프로젝트나 빠른 이전이 필요할 때 훨씬 간편합니다. 특히 학부 프로젝트처럼 데이터 양이 많지 않은 경우라면 DataGrip으로 클릭 몇 번이면 해결되니 적극 활용하시면 좋을 것 같습니다!