티스토리 뷰

개요

  • 오래된 레거시 시스템의 리뉴얼 프로젝트를 진행하다보면 데이터베이스 마이그레이션 작업은 필연적으로, 특별한 이유가 없다면 1순위로 관리가 편리한 Amazon Aurora로의 이전을 고려하게 된다. 이번 글에서는 온프라미스 환경에서의 MySQL/MariaDB 데이터베이스를 Amazon Aurora 인스턴스로 이전하는 방법을 설명하고자 한다. 첫번째로 MySQL 데이터베이스의 이전 방법, 두번째로 MariaDB 데이터베이스의 이전 방법을 정리하였다.

MySQL/MariaDB 이전 방법 종류

  • 가장 편리한 방법은 원본 데이터베이스의 innobackupex 백업 파일을 생성한 후, Amazon S3에 업로드하고 바로 Amazon Aurora 인스턴스를 생성하는 것이다. (원본 데이터베이스로 MySQL만 지원하며 MariaDB는 지원하지 않는다.) 짧은 다운 타임을 가진다.
  • 다른 방법은 mysqldump 덤프 파일을 이용하여 mysql로 직접 복원하는 것이다. 시간은 제일 오래 걸리지만 가장 확실하고 안전하다. 긴 다운 타임을 필요로 한다. (원본 데이터베이스는 MySQL, MariaDB 모두 가능하다.)
  • 마지막 방법은 Amazon DMS을 이용하는 것이다. 추가 비용이 존재하지만 원본 데이터베이스 조건이 일치하면 시도해볼만 하다. (MySQL은 5.5부터, MariaDB는 10.0.24부터 가능하다.) 이 방법의 경우 원활한 마이그레이션을 위해 원본 데이터베이스 스키마에 변경이 발생할 수 있다는 점을 숙지해야 한다. 이론적으로는 다운 타임 없이 마이그레이션이 가능하다.

MySQL 데이터테이스 이전 순서

  • 원본 MySQL 인스턴스에서 innobackupex를 실행하여 현재 데이터베이스에 대한 백업 파일을 생성한다.
  • 생성한 백업 파일을 Amazon S3의 버킷에 업로드한다.
  • Amazon RDS 콘솔에서 백업 파일을 이용해 새로운 Amazon Aurora을 생성한다.

MySQL 데이터베이스 이전 유의사항

  • 원본 데이터베이스는 MySQL 엔진 만을 지원한다. 또한 5.5, 5.6, 5.7 버전 만을 지원한다. (MariaDB는 지원하지 않는다.)
  • 원본 데이터베이스에 MyISAM 스토리지 엔진이 사용된 테이블이 존재해서는 안된다. Amazon AuroraInnoDB 스토리지 엔진 만을 지원한다.
  • 대상 데이터베이스에 S3 접근과 관련된 적절한 IAM 역할이 부여되어 있어야 한다.

innobackupex 백업 파일 생성

  • innobackupex 명령어를 이용한 백업 방법은 본 블로그의 이 글을 참고한다.

Amazon S3 버킷 생성 및 백업 파일 업로드

  • Amazon S3에 데이터베이스 백업 파일을 복사하려면 먼저 Bucket을 생성해야 한다. Amazon S3 콘솔에 접속하여 아래와 같이 생성한다.
S3 콘솔 페이지 접속 → [버킷 만들기] 클릭 → 버킷 이름: some-database-backup → 다음 → 다음 → 다음 → 버킷 만들기
  • 이제 생성한 버킷에 innobackupex로 생성한 데이터베이스 백업 파일을 업로드할 차례이다.
콘솔에서 앞서 생성한 버킷 이름인 [some-database-backup] 클릭 → 업로드 → 파일 추가 → 업로드

IAM 정책 생성 및 허용

  • IAM 콘솔에 접속하여 아래와 같이 정책을 생성한다.
IAM 콘솔 페이지 접속 → [정책] 클릭 → [정책 생성] 클릭 → 서비스 선택: S3
→ 작업 선택: 모든 S3 작업 → [정책 검토] 클릭
→ 이름: AmazonS3AccessRole → [정책 생성] 클릭
  • 다음으로 생성한 정책을 적용할 IAM 역할을 생성할 차례이다. 아래와 같이 생성한다.
IAM 콘솔 페이지 접속 → [역할] 클릭 → [역할 만들기] 클릭 → [AWS 서비스] 클릭 → [RDS - Add Role to Database] → [다음 권한] 클릭
→ AmazonS3AccessRole 체크 → [다음 태그] 클릭 → [다음 검토] 클릭 
→ 역할 이름: AmazonS3AccessRole → [역할 만들기] 클릭

S3 백업 파일로부터 데이터베이스 생성

  • 이제 앞서 S3에 업로드한 백업 파일로부터 데이터베이스를 생성할 차례이다. Amazone RDS 콘솔에서 아래와 같이 생성한다.
Amazon RDS 콘솔 페이지 접속 → [Dashboard] 클릭 → [S3에서 Aurora DB 클러스터 복원] 클릭
→ 엔진 선택 → 엔진 옵션: Amazon Aurora
→ 엔진 선택 → 엔진 옵션 → 에디션: MySQL 5.6과 호환
→ [다음 단계] 클릭

→ 원본 백업 세부 정보 지정 → 원본 데이터베이스 사양 → 소스 엔진 버전: 5.5
→ 원본 백업 세부 정보 지정 → S3 버킷 → S3 버킷: some-database-backup
→ 원본 백업 세부 정보 지정 → IAM 역할 → 새 역할 생성: 아니오
→ 원본 백업 세부 정보 지정 → IAM 역할 → IAM 역할: AmazonRDSS3AccessRole
→ [다음 단계] 클릭

→ DB 세부 정보 지정 → DB 엔진 버전: Aurora (MySQL)-5.6.10a
→ DB 세부 정보 지정 → DB 인스턴스 클래스: db.r5-large
→ DB 세부 정보 지정 → 다중 AZ 배포: 아니요
→ [다음 단계] 클릭

→ 고급 설정 구성 → 네트워크 및 보안 → 퍼블릭 액세스 가능성: 예
→ 고급 설정 구성 → 데이터베이스 옵션 → 포트: 3306
→ 고급 설정 구성 → 암호화 → [암호사 비활성화] 선택
→ 고급 설정 구성 → 유지 관리 → 자동 마이너 버전 업그레이드 → [마이너 버전 자동 업그레이드 사용] 선택
→ [데이터베이스 생성] 클릭

생성된 데이터베이스 연결

  • 생성된 데이터베이스는 온프라미스와 동일한 방법으로 로컬에서 원격 연결이 가능하다.
  • Windows 운영체제에서도 MySQL Shell을 이용하면 원격 쉘 연결이 가능하다. [다운로드 링크] 다른 방법으로 MySQL Workbench를 설치해도 mysql.exemysqldump.exe를 제공하여 사용할 수 있다. 이 방법을 추천한다. [다운로드 링크]
  • MySQL Workbench을 설치했다면 환경 변수의 PathC:\Program Files\MySQL\MySQL Workbench 8.0 CE 경로를 추가하면 어디에서도 편하게 mysqlmysqldump 명령어를 실행할 수 있다.

트러블 슈팅: S3 접근 권한 미부여

  • 대상 데이터베이스 인스턴스에 위에 설명한 S3 접근 권한을 미부여하면 데이터베이스 생성 시도시 아래와 같은 오류가 발생한다.
The specified Amazon S3 bucket cannot be found. Make sure that you have created an AWS Identity and Access Management (IAM) role that lets Amazon RDS access Amazon S3 for you. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 0257a3ba-d8f2-482f-a3ea-8fd03e3b9bbc)

트러블 슈팅: 복원 호환 장애

  • 원본 데이터베이스 인스턴스가 MyISAM 또는 Aria 스토리지 엔진을 사용한 테이블이 존재하면 데이터베이스 생성 시도시 복원 호환 장애가 발생한다. Amazon AuroraInnoDB 스토리지 엔진 만을 지원한다. 이전에 앞서 원본 데이터베이스에서 아래와 같이 스토리지 변경을 실행해야 한다.
ALTER TABLE <schema>.<table_name> ENGINE=innodb, ALGORITHM=copy;

MariaDB 데이터베이스 이전

  • 앞서 MariaDB는 이 방식을 이용한 데이터베이스 이전이 불가능하다고 언급했었다. 이 경우 mysqldump 명령을 이용하여 직접 원본 데이터페이스 덤프 파일을 생성한 후, mysql 명령 또는 MySQL Workbench에서 복원하는 방법을 사용하면 된다. (시간이 상당히 소요되지만 가장 확실하고 안전한 방법이다.)
  • 원본 데이터베이스에서 덤프를 생성하는 방법은 아래와 같다. (작업할 수행할 로컬 운영 체제가 Windows이고 MySQL Workbench가 설치된 상황을 가정했다. 아웃바운드 트래픽 과금을 피하기 위해 로컬 대신 EC2 인스턴스를 생성하여 작업하기도 한다.)
# 작업을 수행할 로컬(또는 원격)에서 원본 디비 연결 확인
$ mysql -P 3306 -h {source_db_host} -u root -p
Enter password: *****

# 작업을 수행할 로컬(또는 원격)에서 원본 디비 덤프 내려 받기 실행
$ mysqldump --column-statistics=0 --flush-privileges --routines --all-databases --single-transaction --set-gtid-purged=OFF -P 3306 -h {source_db_host} -u root -p > dump.sql

# 복원시 권한 부족 오류를 예방하기 위해 불필요한 문장 제거
$ sed -i "s|DEFINER=[^ ]\+| |g" "dump.sql"
  • --all-databases 옵션을 명시하면 사용자 및 권한 정보를 포함한 모든 데이터베이스를 덤프한다. --flush-privileges 옵션을 같이 명시해야 대상 데이터베이스에서 덤프 복원이 완료된 후 사용자 및 권한 정보를 올바르게 구성한다.
  • --single-transaction 옵션은 매우 중요하다. 이 옵션이 없을 경우, 덤프 중에 전체 테이블에 락이 발생하여 운영 서비스에 경우 큰 영향을 미칠 수 있다. 이 옵션을 명시하면 덤프 시작 시점의 데이터베이스 스냅샷을 기준으로 덤프를 생성하기 때문에 락이 발생하지 않는다. 추가로 --max_allowed_packet 옵션을 명시하면 네트워크 전송 대역폭을 제한할 수 있다. [관련 링크]
  • 생성된 덤프 파일로 대상 데이터베이스에 복원하는 방법은 아래와 같다. (당연히 대상 데이터베이스의 Amazon Aurora 인스턴스가 미리 생성되어 실행 중인 상태이어야 한다.)
# 대상 디비에 덤프 파일 적용
$ mysql -P 3306 -h {destination_db_host} -u admin -p
Enter password: *****
> source dump.sql
  • 덤프 파일을 이용한 복원은 생성보다 훨씬 많은 시간이 소요된다. (테스트 결과 생성이 1시간 30분 정도였다면, 복원은 5시간 정도가 소요되었다.)

스냅샷 생성 및 복원

  • 위의 이전 작업으로 온프라미스 데이터베이스가 Amazon Aurora 생태계로 진입했다. 이제 이 생태계의 이점을 살려 빠르고 쉽게 스냅샷 생성 및 복원이 가능하다.
  • 스냅샷 생성 방법은 아래와 같다. 스냅샷 생성 속도는 굉장히 빠른 편이다. 79GB 기준 약 3분이 소요된다.
Amazon RDS 콘솔 페이지 접속 → [스냅샷] 클릭 → [스냅샷 만들기] 클릭
 → DB 인스턴스: 스냅샷을 생성할 인스턴스 선택 → 스냅샷 이름: 스냅샷 이름 입력 → [스냅샷 만들기] 클릭
  • 생성한 스냅샷의 복원 방법은 아래와 같다. 스냅샷을 통해 새로운 인스턴스를 생성할 수 있다. 79GB 기준 약 20분이 소요된다.
Amazon RDS 콘솔 페이지 접속 → [스냅샷] 클릭 → 복원할 스냅샷 클릭 → [스냅샷 작업] 클릭 → [스냅샷 복원] 클릭
→ 새로운 인스턴스 정보 입력 → [DB 인스턴스 복원] 클릭
  • 인스턴스 복원 후에는 다시 클러스터 및 인스턴스의 이름을 재정의해야 한다.
Amazon RDS 콘솔 페이지 접속 → [데이터베이스] 클릭 → 클러스터 이름 클릭 → [수정] 클릭
→ [DB 클러스터 식별자 이름] 뒤의 -cluster 접미어를 제거해야 한다.
→ [보안 그룹]을 default에서 사전 지정한 것으로 변경한다.
Amazon RDS 콘솔 페이지 접속 → [데이터베이스] 클릭 → 디비 이름 클릭 → [수정] 클릭
→ [DB 식별자 이름] 뒤에 -1을 붙인다.

참고 글

댓글
댓글쓰기 폼