Last Updated on 1월 3, 2024 by Jade(정현호)
안녕하세요
이번 포스팅에서는 On-premises의 MySQL을 클라우드(AWS) 또는 다른 서버로의 마이그레이션(또는 복제를 위한 이관) 시에 사용 가능한 방법 및 마이그레이션 소요 시간 등에 대한 내용을 다루고 있습니다.
Motivation
On-premises 환경의 MySQL을 AWS 클라우드의 RDS로의 이관 또는 복제 Replica 로 구성하기 위한 이관을 할 때에 몇 가지 방법에 대해서 특징 등을 살펴보고자 합니다.
On-premises의 MySQL을 클라우드 환경으로 이관하거나 Replica 인스턴스로 구성할 경우에 데이터 마이그레이션 관련된 고민 중에서 먼저 생각되는 부분은 용량이 클 수록 마이그레이션에 많은 시간이 소요되는 부분일 것입니다.
일반적으로 사용할 수 있는 방법인 mysqldump 의 경우 사용이 간편하고 익숙하지만, 속도는 빠르지 못한 것이 사실입니다.
그렇기 때문에 용량이 큰 DB의 경우 클라우드로 마이그레이션시 소요시간 관련하여 여러가지 고민이 있을 수 있습니다.
AWS RDS 에서는 S3 오브젝트 스토리지와 Xtrabackup 생성한 백업을 활용한 마이그레이션이 가능함에 따라서 mysqldump 와 Xtrabackup 그리고 다른 방법인 MySQL Shell 을 사용에 대해서 확인해보도록 하겠습니다.
On-premises의 MySQL 에서 AWS RDS 로 이전하는 시나리오임에 따라 AWS RDS 환경에서 진행하였습니다.
해당 내용은 On-premises to On-premises 에서도 유사(동일) 합니다.
테스트 환경 정보
다음은 포스팅에서 진행한 테스트 환경 정보입니다.
• OS : Rocky Linux 8.6
• MySQL: 8.0.28
• AWS RDS for MySQL : 8.0.28
• AWS RDS for MySQ Class : db.t3.medium
vcpu :2 / Mem : 4gb
• Xtrabackup : 8.0.32-25
• mysql shell : 8.0.32
• 테스트 데이터: 테이블수 50개 이며, 스키마 사이즈는 50GB, 테이블별 사이즈(건수)는 동일
• parallel : MySQL Shell 과 Xtrabackup 에서 병렬처리는 6 으로 설정하고 진행하였음
RDS for MySQL 에서 사용한 파라미터 그룹의 경우 default parameter group 차이점은 다음과 같습니다.
• lower_case_table_names = 1
• max_allowed_packet = 1073741824
위의 파라미터는 Source MySQL 에서도 동일하게 설정하였습니다.
네트워크로 파일을 전송하기 때문에 Linux의 네트워크(TCP/UDP, Packet) 관련된 커널 파라미터 값을 충분히 설정 후 진행하였습니다.
mysqldump
mysqldump는 여러 환경에서 공통적으로 손쉽고 익숙하게 사용할 수 있는, 오래전부터 사용하던 유틸리티입니다.
여전히 많이 사용하고 있으며, 용량이 크지 않거나 특별히 작업 시간의 제약이 크지 않다면 많이 사용하고 있습니다.
다만 익히 알려진 것처럼 mysqldump의 속도는 상대적으로 빠르지 않습니다.
테스트 환경에서 이관할 대상 50GB 사이즈의 스키마에 대해서 mysqldump 를 이용하였을 경우 185분이 소요 되었습니다.
테스트의 수행 소요 시간은 제한적인 테스트 환경으로 인하여 CPU 및 네트워크 속도가 실제 Production 환경에 비해서 상대적으로 부족할 수 있습니다.
그러므로 글에서의 소요시간 자체 보다는 동일한 조건에서 마이그레이션 유틸리티(방법) 별로 시간의 차이를 확인해주시면 됩니다.
mysqldump를 수행할 때에는 RDS for MySQL 에서는 Disable Redo Log 수행 후 진행하였으며, named pipe 를 생성하여 데이터를 추출과 입력을 동시에 진행하였습니다.
named pipe에 대한 추가적인 내용은 아래 포스팅을 참조하시면 됩니다.
참고로 named pipe 를 사용할 경우 디스크에 데이터를 저장하지 않음으로 디스크 용량을 사용하지 않습니다.
Xtrabackup
Xtrabackup는 percorna 에서 개발 백업 복구 솔루션으로 MySQL 및 MySQL용 Percona Server의 모든 버전을 위한 완벽한 무료 오픈 소스 온라인 백업 솔루션입니다.
Xtrabackup는 mysqldump와는 다른 방식인 물리적인 파일을 복사하는 방식으로 백업을 진행하며 mysqldump 에 비해 상대적으로 백업 속도와 복원속도가 빠르며, increment backup 및 parallel 등의 다양한 기능을 지원합니다.
AWS RDS 에서는 Xtrabackup 을 통해 생성된 백업본을 S3에 업로드 후에 Restore 을 통한 RDS 생성을 지원합니다.
[Restoring a backup into a MySQL DB instance]
Restore 하는 대상이 RDS for MySQL 또는 Aurora MySQL 인지에 따라서 Source MySQL 버전의 지원 차이가 있습니다.
- Aurora MySQL : Source MySQL 5.5, 5.6, or 5.7
- RDS for MySQL : Source MySQL 5.7, 8.0
마이그레이션 하고자 하는 Source MySQL 버전에 따라서 RDS 선택 및 버전에 대한 부분이 확인이 필요 합니다.
또한 Source DB에서의 주요하게 설정이 필요한 부분이 innodb_data_file_path 파라미터에 대해서 기본값 형태로 사용해야 한다는 점입니다.
관련 문서)
• Aurora MySQL - 문서링크
• RDS for MySQL - 문서링크
포스팅에서는 Source MySQL 을 8.0.28을 사용하였으며 마이그레이션 Target DB는 RDS for MySQL 8.0.28을 사용하였습니다.
Xtrabackup 수행 과 AWS S3 전송을 |(파이프) 를 사용하여 같이 진행하였습니다.
< ... 중략 ... > --backup --stream=xbstream | \ aws s3 cp - s3://....
Xtrabackup 및 AWS S3 로 업로드가 완료 되었다면 RDS 웹 콘솔에서 아래의 메뉴를 통해서 RDS 생성(Restore) 를 진행 할 수 있습니다.
테스트 시스템에서의 소요시간은 다음과 같습니다.
- Xtrabackup 을 통한 백업 및 S3로의 업로드 소요 시간 : 101분
- RDS 웹 콘솔에서 restore from s3 를 통해서 RDS 생성 소요시간 : 50분
- 해당 시간은 "Successfully restored database from S3" 메세지 출력까지의 시간임
- Successfully restored database from S3 단계에서 RDS 로 접속은 가능하나, 추가적으로 Performance Insights Enable 및 백업이 수행 됨
- 백업 완료 시간은 데이터 사이즈에 따라서 차이가 있음, 다만 해당 시간에 DB는 사용가능
- 해당 시간은 "Successfully restored database from S3" 메세지 출력까지의 시간임
백업 및 RDS 생성 소요시간을 합쳐서 작업시간은 약 151분가량 소요되었습니다.
RDS 생성 완료 이후 Replication 설정을 하여 Replica(slave) 인스턴스로 구성하려면 먼저 RDS 콘솔에서 아래와 같이 binlog 파일 정보와 pos 정보를 확인 합니다.
해당 정보를 통해서 CALL mysql.rds_set_external_source 또는 CALL mysql.rds_set_external_master 사용하여 External Replication 을 설정합니다.
MySQL Shell
MySQL Shell 은 MySQL 용 고급 클라이언트 및 코드 편집기입니다 mysql 클라이언트 와 유사한 SQL 기능 외에도 MySQL Shell은 JavaScript 및 Python에 대한 스크립팅 기능을 제공하고 MySQL 작업을 위한 API를 포함합니다.
MySQL Shell의 여러 기능 중에 Utility 기능이 있으며 그중에서도 Dump 와 Load utility 를 통해서 테스트를 진행하였습니다.
MySQL은 이와 같은 Dump 와 Load 기능이외에 InnoDB Cluster 의 구성 및 설정 변경을 지원하며, CSV, TSV 로 파일을 생성 및 Loading 할 수 있는 Table Export/Import Utility 기능도 지원합니다.
Oracle Cloud Infrastructure(OCI) 에서는 MySQL Shell 을 통해 Dump 및 Object Storage 로 업로드 된 파일을 통해서 MDS 생성을 할 수 있는 연계적인 기능을 제공합니다.
[migrating-from-a-live-on-premises-mysql-80]
MySQL Shell은 MySQL Server 5.7 과 8.0 버전에서 사용 가능 합니다.
MySQL Dump와 Load 은 tsv 형식으로 파일을 생성 및 Load 하며 병렬(Parallel)처리를 지원하며, loadDump시 waitDumpTimeout 옵션을 통해서 데이터 Unload 와 Load 를 동시에 진행할 수 있습니다.
[waitDumpTimeout 사용한 입력 매커니즘]
Dump 디렉토리의 데이터 Unload 상태를 모니터링하면서 Load 할 수 있는 데이터를 찾는 즉시 데이터 Load가 수행되게 됩니다.
가져올 수 있는 데이터를 찾을 때까지 waitDumpTimeout 옵션에서 지정한 초 수 만큼을 기다리게 됩니다.
옵션에서 지정한 시간 초과하면 Load 프로세스가 종료됩니다.
이 프로세스(매커니즘) 사용하면 데이터를 Unload 시작 후에 동시에 데이터 Load 작업을 병렬로 수행할 수 있으므로 마이그레이션 작업 시간을 단축할 수 있습니다.
테스트시에도 waitDumpTimeout 를 사용하여 추출과 입력을 동시에 진행하였으며, MySQL(RDS)의 Disable RedoLog 후에 입력하였습니다.
MySQL 8.0.21 부터는 Redo Log 기록에 대해서 Disable 할 수 있습니다.
[내용 업데이트] RDS for MySQL 에서도 가능하였으나 RDS for MySQL 8.0.28버전까지만 가능하고 그 이후 버전에서는 Disable RedoLog 불가합니다.
포스팅에서는 RDS for MySQL 8.0.28 버전을 사용하였기 때문에 Disable RedoLog를 사용하였으나 그 이후 버전에서는 Disable RedoLog는 불가합니다.
## REDO 비활성화 ALTER INSTANCE DISABLE INNODB REDO_LOG; ## REDO 활성화 ALTER INSTANCE ENABLE INNODB REDO_LOG;
MySQL Shell 을 통해서 마이그레이션 진행하였을 때 87분 소요되었습니다.
MySQL Shell을 사용할 경우 mysqldump 와 Xtrabackup 과는 달리 Master 서버의 binlog 파일정보 와 Log Pos 정보 등을 별도로 남기지는 않습니다. 그래서 Simple Migration 이라면 바로 Unload/Load 를 해도 되지만 마이그레션 이후에 Replication 을 설정하여 Replica 인스턴스(Slave 서버) 로 구성하려고 할 경우 2가지 방법을 선택하여 진행할 수 있습니다.
1. GTID 사용
2. binlog file 및 pos 정보 사용
GTID 를 사용하지 않고 binlog 파일정보와 pos 정보로 복제를 설정하기 위해서는 MySQL Shell Dump을 Replica(Slave) 서버에서 수행해야 하며 아래와 같은 절차를 따라서 진행하시면 됩니다.
1) 복제 중지(Replica 인스턴스에서 수행)
stop replica;
또는
stop slave;
2) Master(Primary) 정보 확인
show replica status\G
또는
show slave status\G
마이그레이션 된 클라우드의 서버에서 Master 서버로 설정할 서버의 binlog 파일과 pos 번호를 확인합니다.
복제 대상(Master) 서버를 현재 사용중인 Replica(slave) 서버로 연결하려고 할 경우에는 Replica(slave) 서버에서 아래의 명령어를 통해서 정보를 확인합니다.
show master status\G
3) MySQL Shell Dump/Load 을 통한 Migration 수행
접속 및 실행 대상 : Replica(Slave)
4) 마이그레이션 완료 후 복제 설정
CALL mysql.rds_set_external_source 또는 CALL mysql.rds_set_external_master 사용하여 External Replication 을 설정합니다.
5) 중지하였던 복제를 재개
start replica;
또는
start slave;
MySQL Shell Dump/Load 를 통해 마이그레이션시 버전의 차이가 있을 경우 ignoreVersion 옵션을 사용합니다.
ignoreVersion:true
Summary
테스트 결과 아래와 같이 마이그레이션에 소요 되었습니다.
- MySQL Shell : 87분
- Xtrabackup : 151분
- mysqldump : 181분
가능한 방법내에서 가장 빠르게 처리될 수 있도록 테스트를 진행하였으며, mysqldump 의 경우 데이터 추출과 입력을 동시에 하기 위해 named pipe를 사용하였습니다.
위의 그래프에서 Xtrabackup 의 경우 주황색은 Xtrabackup 및 S3 로 전송에 소요시간이며, 파란색은 RDS 생성에 소요된 시간입니다.
Xtrabackup 을 사용한 restore from s3 방법과 달리 MySQL Shell 과 mysqldump 에서는 RDS 인스턴스를 미리 생성해 둘 수 있기 때문에 버전 8.0.21 이상이라면 REDO LOG 를 비활성화(DISABLE) 후에 입력할 수도 있는 장점도 있었으나 RDS for MySQL 8.0.28 버전까지만 Disable RedoLog가 가능하고 그 이후 버전에서는 불가능 부분으로 변경되었습니다. (내용 업데이트)
REDO LOG 비활성화와 활성화는 성능적인 차이가 체감할 수 있을 정도로 차이가 있다고 할 수 있습니다.
다만 REDO LOG 비활성화는 이러한 마이그레이션 작업시에만 한 시적으로 사용해야 하며, 마이그레이션이 완료된 다음에는 꼭 다시 활성화(ENABLE) 를 해야 합니다.
(위에서 설명한 것처럼 RDS for MySQL 8.0.28 버전 이후로는 불가능 합니다.)
테스트에서는 3가지 수행 방법의 시간 차이 등을 확인하고자 RDS 파라미터 그룹을 최대한 기본 파라미터를 사용하였으나, 실제로 마이그레이션시에는 sync_binlog , RDS for MySQL 의 경우 innodb_flush_log_at_trx_commit 파라미터를 조정하여 데이터 로딩 시 시간을 단축시킬 수도 있습니다.
이전에는 innodb_flush_log_at_trx_commit는 Aurora MySQL 의 경우 2 버전에서만 조정 가능하였으나 최근에는 개선되어 Aurora MySQL 3 버전에서도 innodb_flush_log_at_trx_commit 파라미터 변경이 가능 해졌습니다. 자세한 사항은 아래 포스팅에서 확인하시면 됩니다.
RDS for MySQL 버전 8.0.30 이상으로 마이그레이션을 한다면 Amazon RDS Optimized Writes 기능을 사용하여 더 빠른 데이터 로딩을 기대할 수 있기 때문에 마이그레이션 시간을 조금 더 단축할 수도 있을 것으로 예상됩니다.
MySQL Shell을 사용하여 마이그레이션을 한다면 다음과 같은 장점이 있습니다.
- Source DB에 여러 스키마가 있는 환경에서 특정 스키마만 마이그레이션 하려고 할 경우
- Xtrabackup 을 통해서 마이그레이션의 제약사항(버전 등으로)으로 사용이 어려울 경우 사용할 수 있음
- 여러 Sourece DB에 있는 다수의 스키마를 1개의 RDS로 이관이 필요할 경우
스키마 단위 또는 테이블 단위로도 Dump/Load 가 가능하기 때문에 Xtrabackup 에 비해서 조금 더 유연할 수 있으며, innodb_data_file_path 파라미터와 관련되어 있거나 DB버전에 대한 제약에서도 자유롭기 때문에 더 수월하게 사용할 수 있다는 점이 있습니다.
Xtrabackup 이나 mysqldump 에 비해서 고려해야 할 부분으로 Dump 후 Load 순으로 진행되기 때문에 일단 백업 받을 공간에 대한 준비가 필요합니다. 마이그레이션 할 대상의 용량이 클수록 이 부분은 고민이 될 수 있는 부분이긴 합니다.
compress 옵션을 사용한다면 백업 받는 용량은 줄일 수도 있으나 그 만큼의 시간 소요가 더 될 수 있습니다.
MySQL Shell 에서는 Option for Cloud을 사용하여 Cloud Object Storage 에 파일 저장할 수 있으며, MySQL Shell 8.0.32 버전 부터 AWS S3 를 지원함에 따라서 Dump 파일을 AWS S3에 바로 저장할 수 있습니다.
It is now possible to configure MySQL Shell's AWS S3 support with AWS environment variables. For more information, see S3-compatible Storage.
다만 Load 할 때에는 S3에서 저장된 데이터를 불러와서 다시 Load 형태이기 때문에 Network의 Input/Output 이 모두 발생하게 되어 시간이 오히려 더 소요될 수도 있습니다.
테스트에서는 사용한 50개의 테이블 모두 동일한 사이즈이기 때문에, 실제 운영환경에서 처럼 특정 몇 개의 테이블이 매우 큰 형태 등과 같이 마이그레이션 하려는 DB의 테이블의 조건에 따라서 방법 별로 시간의 차이(%) 는 달라질 수 있습니다.
그리고 테스트 환경은 실제 Production 환경에 비해 CPU 및 네트워크 속도의 환경적인 부분에서 차이가 많으므로 글에서 확인된 소요시간 보다는 각 수행 방법 별 차이의 % 를 참고하시면 됩니다.
Reference
Reference URL
• mysql.com/doc/mysql-shell-dump
• mysql.com/mysql-shell-load-dump
• amazon.com/Migrating.ExtMySQL.S3
• amazon.com/MySQL.Procedural.Importing
• amazon.com/percona-xtrabackup
• amazon.com/migrate-on-amazon-s3
Special thanks to
카카오페이 김진현님
카카오게임즈 이수민님
테스트 진행에 있어서 도움 감사합니다.
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
안녕하세요
사용하시는 버전이 어떻게 되시나요?
감사합니다.
관련내용 메일 전송 드렸습니다!
감사합니다!
안녕하세요
해당 내용 이전에 업데이트 정리를 했어야 했는데 업데이트가 늦었습니다.
RDS for MySQL 8.0.28 버전까지는 가능하며, 이후 버전 부터는 불가능한 부분으로 변경 되었습니다.
해당 내용에 대해서 본문에 내용 업데이트 해두었습니다.
감사합니다.