Contents

[1] 배경

작업 배경
- 고객사의 요청으로 2개의 DB를 하나로 통합을 진행하고자 합니다. 향후 하나로 통합된 DB는 이중화(Multi-AZ)로 변경할 예정(사용 리소스: AWS RDS for MySQL 8.0.23)
- DB #01 안에 특정 ams라는 스키마를 DB #02 안으로 마이그레이션(복원)하는 것으로 스키마 용량이 약 2GB 미만인 간소한 작업입니다.

최소 필수 조건
- 백업 및 복원을 수행하기 전에 RDS 인스턴스에 충분한 스토리지 공간이 있는 지 확인 -> Checked!
- 백업 및 복원 시 DB 스키마의 데이터의 크기가 크지 않은 지 확인 (데이터가 큰 경우 다른 방법을 고려... DMS 마이그레이션을 통한 복제 인스턴스가 생성될 수 있으며 추가적인 작업 필요)
- 작업 간 임시로 전달 받은 admin(혹은 dba권한) 사용자 id/pw 정보, endpoint(dbhost), local client 에서 접속 가능 여부
- 작업을 수행하기 전에 백업 가능한지 여부

[2] 작업 내용

2-1. 목표

MYSQL RDS간 Database scheme 이관 작업
즉, mysqldb1의 스키마 example1db -> mysqldb2의 스키마 example1db 로 이관

2-2. Database Backup

1) 백업 대상 DB인스턴스 정보

AWS RDS for MySQL DB #01: mysqldb1
db-scheme: dbscheme1
dbauser: example1dbadmin
db-host(endpoint): mysqldb1.example.aws (Internal, db-host)
db-scheme-backupName: example1db-scheme-backup-yyyymmdd-mm.sql

2) Scheme Backup 진행

#
# MySQL DB #01(mysqldb1) ssh 세션 접속 (localPort: 3307), tunneluser 패스워드 인증 필요
ssh -f -N -L 3307:mysqldb1.example.aws:3306 tunneluser@BastionHostIp

# MySQL DB #01 > dbscheme1 의 dumpfile(.sql) 추출
mysqldump -h 127.0.0.1 -P 3307 -u example1dbadmin -p --set-gtid-purged=OFF --single-transaction dbscheme1 > example1db-scheme-backup-yyyymmdd-mm.sql

# ssh 세션 종료
ps -aux |grep ssh
kill -9 <PID>

3) mysqldump 시 참고해야 하는 사항

set-gtid-purged=OFF
- GTID가 포함된 서버로부터의 부분적인 덤프는 기본적으로 모든 트랜잭션의 GTID를 포함
- 이 옵션을 사용하여 스키마 복원(Restore)시 GTID를 제외함
single-transaction
- 이 옵션은 InnoDB 테이블에 대한 일관된 스냅샷을 생성하기 위해 사용됨
- 트랜잭션이 시작되면 mysqldump는 FLUSH TABLES WITH READ LOCK 명령을 수행하지 않음
- 이로 인해 읽기 잠금이 필요 없는 테이블에 대해 다른 연결들이 계속 변경을 수행할 수 있음
triggers
- 덤프에 트리거를 포함함
routines
- 덤프에 저장된 프로시저와 함수를 포함함
events
- 덤프에 이벤트 스케줄러 이벤트를 포함함

2-3. Data Restore

1) 복원 대상 DB인스턴스 정보

AWS RDS for MySQL DB #02: mysqldb2
db-scheme: dbscheme2
dbauser: example2dbadmin
db-host(endpoint): mysqldb2.example.aws (Internal, db-host)

2) Scheme Restore 작업 진행

#
# MySQL DB #02(mysqldb2) ssh 세션 접속 (localPort: 3308), tunneluser 패스워드 인증 필요
# ssh Sessions PID 를 제거하였으나 혹시나 모를 위험에 대비하여 localport 를 3308로 변경함
ssh -f -N -L 3308:mysqldb2.example.aws:3306 tunneluser@BastionHostIp

# mysql 접속
mysql -h 127.0.0.1 -P 3308 -u example2dbadmin -p

# dbscheme1 스키마 DB 생성 및 검증
CREATE DATABASE dbscheme2;
SHOW DATABASES;
SHOW TABLES;

# example2dbadmin에 복원하는 dbscheme1 DB 스키마에 전체 권한 부여
GRANT ALL PRIVILEGES ON dbscheme1* TO 'example2dbadmin'@'%';
FLUSH PRIVILEGES;

# dbscheme1  DB 스키마 선택 및 복원
USE dbscheme1;
source /sqlbackup/path/example1db-scheme-backup-yyyymmdd-mm.sql;

백업 및 복원 작업이 완료되면 테이블 별 엔진, 크기, 갯수 등등을 판단하여 복원에 관한 검증을 시도해볼 수 있습니다.

[3] 결론

MySQL 데이터베이스를 한 RDS 인스턴스에서 다른 RDS 인스턴스로 Scheme 를 마이그레이션하는 이유는 여러 가지가 있을 수 있습니다.

일반적인 이유들은 다음과 같습니다:

스케일링: 현재 RDS 인스턴스의 성능이나 저장 공간이 충분하지 않을 경우, 더 큰 인스턴스나 다른 스토리지 옵션을 갖춘 인스턴스로 마이그레이션 할 수 있습니다.
비용 절감: 비용을 줄이기 위해 더 저렴한 RDS 인스턴스로 이동할 수 있습니다.
리전 변경: 데이터를 다른 리전의 RDS 인스턴스로 이동시키는 것은 더 빠른 액세스 시간을 제공하거나 법규 준수 이유 (예: 데이터 주거성) 때문일 수 있습니다.
백업 및 복구: 현재 RDS 인스턴스에 문제가 발생한 경우, 백업된 데이터를 다른 RDS 인스턴스로 복원할 수 있습니다.
통합 및 분할: 여러 데이터베이스나 스키마를 하나의 RDS 인스턴스로 통합하거나, 반대로 하나의 큰 데이터베이스를 여러 인스턴스로 분할할 수 있습니다.
테스트 및 개발: 프로덕션 데이터를 테스트나 개발 환경의 RDS 인스턴스로 복제하여 실제 데이터로 테스트나 개발 작업을 진행할 수 있습니다.
버전 업그레이드: MySQL의 새로운 버전을 사용하려는 경우, 새 버전을 실행하는 새 RDS 인스턴스에 데이터를 마이그레이션 할 수 있습니다.

이 외에도 특정 비즈니스나 기술적 요구 사항에 따라 다양한 이유로 RDS 인스턴스 간의 데이터 마이그레이션이 필요할 수 있습니다.

특히 전체 DB를 수동 복원하지 않고, 테이블만 이관할 때 주로 사용되는 방법입니다.