기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 대규모 MySQL 및 MariaDB 데이터베이스에 대한 마이그레이션 옵션
광범위한 옵션 중에서 선택하여 온프레미스 MySQL 또는 MariaDB 데이터베이스에서 Amazon Relational Database Service(Amazon RDS) 또는 Amazon Aurora MySQL 호환 버전 데이터베이스 인스턴스로 마이그레이션할 수 있습니다. 성공적인 마이그레이션을 위해서는 올바른 마이그레이션 접근 방식과 도구를 선택하는 것이 필수이며, 이 가이드에서는 사용성, 데이터 크기 및 가동 중지 시간 요구 사항에 따라 옵션을 평가합니다.
다음은 멀티테라바이트 규모의 자체 관리형 MySQL 데이터베이스를 Amazon RDS, Aurora 또는 Amazon Elastic Compute Cloud(Amazon EC2) 데이터베이스 인스턴스로 효율적으로 마이그레이션하는 데 사용할 수 있는 일반적인 마이그레이션 도구 및 접근 방식입니다.
+ [Percona XtraBackup](percona-xtrabackup.md)(물리적)
+ [MyDumper](mydumper.md)(논리적)
+ [mysqldump 및 mysqlpump](mysqldump-and-mysqlpump.md)(논리적)
+ [백업 분할](split-backup.md)(물리적, 논리적 또는 둘 다)
다음은 멀티테라바이트 규모의 MySQL 호환 데이터베이스(예: MariaDB)를 Amazon RDS, Aurora 또는 Amazon EC2 인스턴스로 효율적으로 마이그레이션하는 데 사용할 수 있는 일반적인 마이그레이션 도구 및 접근 방식입니다.
+ [MyDumper](mydumper.md)(논리적)
+ [mysqldump 및 mysqlpump](mysqldump-and-mysqlpump.md)(논리적)
+ [백업 분할](split-backup.md)(물리적, 논리적 또는 둘 다)
각 마이그레이션 도구에는 대용량 데이터베이스 백업 파일을 AWS 클라우드로 전송하는 데 사용할 수 있는 몇 가지 접근 방식이 있습니다. 각 도구에 대한 옵션이 제공되며, Amazon S3 File Gateway를 사용할 수도 있습니다. 자세한 내용은 이 안내서의 [Amazon S3 File Gateway를 사용하여 백업 파일 전송](amazon-s3-file-gateway.md) 섹션을 참조하세요.
# Percona XtraBackup
**중요**
Percona XtraBackup은 MariaDB 버전 10.3 이상에서는 지원되지 않으며 버전 10.1 및 10.2에서는 부분적으로만 지원됩니다.
[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html)은 MySQL 및 MariaDB에 대한 일반적인 오픈 소스 웜 백업 소프트웨어로, InnoDB 및 XtraDB 스토리지 엔진에 대해 비차단 백업을 수행합니다. MySQL 또는 MariaDB 서버에서 작동합니다. 도구 및 몇 가지 기능과 이점에 대한 자세한 내용은 Percona XtraBackup 설명서의 [About Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html)을 참조하세요.
이 도구는 물리적 마이그레이션 접근 방식을 사용합니다. MySQL 또는 MariaDB 데이터 디렉터리와 안에 있는 파일을 직접 복사합니다. 100GB보다 큰 데이터베이스와 같은 대규모 데이터베이스의 경우 다른 도구보다 훨씬 더 나은 복원 시간을 제공할 수 있습니다. 온프레미스 소스 데이터베이스의 백업을 생성하고 백업 파일을 클라우드로 마이그레이션한 다음 새 대상 데이터베이스 인스턴스에서 백업을 복원합니다.
다음 다이어그램에서는 Percona XtraBackup 백업 파일을 사용하여 데이터베이스를 마이그레이션하는 데 수반되는 상위 수준 단계를 보여줍니다. 백업 파일의 크기에 따라 AWS 클라우드의 Amazon Simple Storage Service(Amazon S3) 버킷으로 백업을 전송하는 데 사용할 수 있는 두 가지 옵션이 있습니다.
![\[Percona XtraBackup 파일을 마이그레이션하고 AWS DB 인스턴스에서 복원하는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
다음은 Percona XtraBackup을 사용하여 데이터베이스를 AWS 클라우드로 마이그레이션하는 단계입니다.
1. 온프레미스 서버에 Percona XtraBackup을 설치하세요. Amazon Aurora MySQL 버전 2 또는 Amazon RDS를 사용하는 경우 [Percona XtraBackup2.4 설치](https://docs.percona.com/percona-xtrabackup/2.4/installation.html)를 참조하세요. Amazon Aurora MySQL 버전 3을 사용하는 경우 Percona XtraBackup 설명서의 [Percona XtraBackup8.0](https://docs.percona.com/percona-xtrabackup/8.0/installation.html) 설치를 참조하세요.
1. 소스 MySQL 또는 MariaDB 데이터베이스의 전체 백업을 생성하세요. Percona XtraBackup 2.4에 대한 지침은 [Full backup](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html)을 참조하세요. Percona XtraBackup 8.0에 대한 지침은 [Create a full backup](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html)을 참조하세요.
1. 다음과 같이 조직에서 승인된 서비스 또는 도구를 사용하여 인터넷을 통해 백업 파일을 전송합니다.
+ [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html)
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ [Amazon S3 File Gateway](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html)(자세한 내용은 이 가이드의 [Amazon S3 File Gateway를 사용하여 백업 파일 전송](amazon-s3-file-gateway.md) 섹션을 참조하세요.)
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. Amazon S3 버킷에서 백업 파일을 대상 데이터베이스 인스턴스로 복원합니다. 지침은 다음을 참조하세요.
+ Aurora MySQL 호환 버전의 경우 Amazon RDS 설명서의 [Amazon S3 버킷을 사용하여 MySQL에서 데이터 마이그레이션](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)을 참조하세요.
+ Amazon RDS for MySQL 또는 Amazon EC2의 경우 [MySQL DB 인스턴스로 데이터 가져오기](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html)를 참조하세요.
+ Amazon RDS for MariaDB 또는 Amazon EC2의 경우 [MariaDB DB 인스턴스로 데이터 가져오기](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html)를 참조하세요.
1. (선택 사항) 소스 데이터베이스와 대상 데이터베이스 인스턴스 간 복제를 설정할 수 있습니다. 바이너리 로그(binlog) 복제를 사용하여 가동 중지 시간을 줄일 수 있습니다. 자세한 내용은 다음을 참조하세요.
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)(MySQL 설명서)
+ Amazon Aurora의 경우 다음을 참조하세요.
+ [복제를 사용하여 Amazon Aurora MySQL DB 클러스터를 MySQL 데이터베이스와 동기화](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)(Aurora 설명서)
+ [Amazon Aurora에서 binlog 복제 사용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)(Aurora 설명서)
+ Amazon RDS의 경우 다음을 참조하세요.
+ [MySQL 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)(Amazon RDS 설명서)
+ [MariaDB 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)(Amazon RDS 설명서)
+ Amazon EC2의 경우 다음을 참조하세요.
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)(MySQL 설명서)
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)(MySQL 설명서)
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)(MariaDB 설명서)
## 장점
+ Percona XtraBackup은 물리적 마이그레이션 접근 방식을 사용하기 때문에 복원 프로세스는 일반적으로 논리적 마이그레이션 접근 방식을 사용하는 도구보다 빠릅니다. 데이터 처리에 필요한 컴퓨팅 리소스가 아닌 디스크 또는 네트워크 처리량에 의해 성능이 제한되기 때문입니다.
+ 복원 프로세스는 S3 버킷에서 대상 데이터베이스 인스턴스로 파일을 직접 복사하기 때문에 Percona XtraBackup 파일은 일반적으로 다른 도구로 생성된 백업 파일보다 빠르게 복원됩니다.
+ Percona XtraBackup은 적응 가능합니다. 예를 들어 파일을 더 빠르게 복사할 수 있도록 여러 스레드를 지원하고 백업 크기를 줄이기 위해 압축을 지원합니다.
## 제한 사항
+ Percona XtraBackup은 소스 데이터베이스 서버에 액세스해야 하므로 오프라인 백업이 불가능합니다.
+ Percona XtraBackup은 시스템 아키텍처가 동일한 시스템에서만 사용할 수 있습니다. 예를 들어 Windows Server용 인텔에서 실행되는 소스 데이터베이스의 백업을 Linux용 ARM 대상 서버로 복원할 수 없습니다.
+ Percona XtraBackup은 MariaDB 버전 10.3 이상에서는 지원되지 않으며 MariaDB 버전 10.2 및 버전 10.1에서는 부분적으로만 지원됩니다. 자세한 내용은 MariaDB 지식 기반의 [Percona XtraBackup Overview: Compatibility with MariaDB](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb)를 참조하세요.
+ Percona XtraBackup을 사용하여 소스 MariaDB 데이터베이스를 Amazon RDS for MySQL 또는 Aurora MySQL 호환과 같은 대상 MySQL 데이터베이스 인스턴스로 복원할 수 없습니다.
+ S3 버킷에 저장할 수 있는 총 데이터 볼륨과 객체 수는 무제한이지만 최대 파일 크기는 5TB입니다. 백업 파일이 5TB를 초과하면 파일을 여러 개의 더 작은 파일로 분할할 수 있습니다.
+ `innodb_file_per_table` 설정이 꺼져 있으면 Percona XtraBackup은 `--tables`, `--tables-exclude`, `--tables-file`, `--databases` `--databases-exclude` 또는 `--databases-file`을 사용하는 부분 백업을 지원하지 않습니다. Percona XtraBackup 버전 2.4에 대한 자세한 내용은 [Partial backups](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html)를 참조하세요. Percona XtraBackup 버전 8.0에 대한 자세한 내용은 [Create a partial backup](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html)을 참조하세요.
## 모범 사례
+ 백업 프로세스의 성능을 개선하려면 다음을 수행합니다.
+ [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel)를 사용하여 병렬로 여러 파일 복사
+ [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads)를 사용하여 병렬로 여러 파일 압축
+ [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory)를 사용하여 메모리 증가
+ [--encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads)를 사용하여 병렬로 여러 파일 암호화
+ 소스 서버에 데이터베이스 백업 파일을 가져올 충분한 공간이 있는지 확인합니다.
+ Percona xbstream(.xbstream) 형식 파일을 사용하여 데이터베이스 백업을 생성합니다. 자세한 내용은 Percona XtraBackup 설명서의 [The xbstream binary overview](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html)를 참조하세요.
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub)는 다음 두 가지 유틸리티로 구성된 오픈 소스 논리적 마이그레이션 도구입니다.
+ MyDumper는 MySQL 데이터베이스의 일관된 백업을 내보냅니다. 사용 가능한 CPU 코어당 최대 하나의 스레드까지 여러 병렬 스레드를 사용하여 데이터베이스 백업을 지원합니다.
+ myloader는 MyDumper에서 생성한 백업 파일을 읽고 대상 데이터베이스 인스턴스에 연결한 다음 데이터베이스를 복원합니다.
다음 다이어그램에서는 MyDumper 백업 파일을 사용하여 데이터베이스를 마이그레이션하는 데 수반되는 상위 수준 단계를 보여줍니다. 이 아키텍처 다이어그램에는 백업 파일을 온프레미스 데이터 센터에서 AWS 클라우드의 EC2 인스턴스로 마이그레이션하는 세 가지 옵션이 포함되어 있습니다.
![\[MyDumper 백업 파일을 마이그레이션하고 myloader를 사용하여 AWS DB 인스턴스에서 복원하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
다음은 MyDumper를 사용하여 데이터베이스를 AWS 클라우드로 마이그레이션하는 단계입니다.
1. MyDumper 및 myloader를 설치하세요. 관련 지침은 [How to install mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader)(GitHub)를 참조하세요.
1. MyDumper를 사용하여 소스 MySQL 또는 MariaDB 데이터베이스의 백업을 생성하세요. 관련 지침은 [How to use MyDumper](https://github.com/mydumper/mydumper#how-to-use-mydumper)를 참조하세요.
1. 다음 방법 중 하나를 사용하여 백업 파일을의 EC2 인스턴스 AWS 클라우드 로 이동합니다.
**접근 방식 3A** - [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) 또는 [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) 파일 시스템을 데이터베이스 인스턴스를 실행하는 온프레미스 서버에 탑재합니다. AWS Direct Connect 또는 Site-to-Site VPN 를 사용하여 연결을 설정할 수 있습니다. 데이터베이스를 탑재된 파일 공유에 직접 백업하거나 데이터베이스를 로컬 파일 시스템에 백업한 다음 탑재된 FSx 또는 EFS 볼륨에 업로드하여 두 단계로 백업을 수행할 수 있습니다. 그런 다음 온프레미스 서버에도 탑재된 Amazon FSx 또는 Amazon EFS 파일 시스템을 EC2 인스턴스에 탑재하세요.
**접근 방식 3B** - AWS CLI, AWS SDK 또는 Amazon S3 REST API를 사용하여 백업 파일을 온프레미스 서버에서 S3 버킷으로 직접 이동합니다. 대상 S3 버킷이 데이터 센터와 멀리 떨어진에 AWS 리전 있는 경우 [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html)을 사용하여 파일을 더 빠르게 전송할 수 있습니다. [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) 파일 시스템을 사용하여 EC2 인스턴스에 S3 버킷을 탑재하세요.
**접근 방식 3C** - 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치한 다음 [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)를 사용하여 백업 파일을 Amazon S3 버킷으로 이동합니다. [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) 파일 시스템을 사용하여 EC2 인스턴스에 S3 버킷을 탑재하세요.
**참고**
Amazon S3 File Gateway를 사용하여 대용량 데이터베이스 백업 파일을 AWS 클라우드의 S3 버킷으로 전송할 수도 있습니다. 자세한 내용은 이 안내서의 [Amazon S3 File Gateway를 사용하여 백업 파일 전송](amazon-s3-file-gateway.md) 섹션을 참조하세요.
1. myloader를 사용하여 대상 데이터베이스 인스턴스에서 백업을 복원하세요. 관련 지침은 [myloader usage](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst)(GitHub)를 참조하세요.
1. (선택 사항) 소스 데이터베이스와 대상 데이터베이스 인스턴스 간 복제를 설정할 수 있습니다. 바이너리 로그(binlog) 복제를 사용하여 가동 중지 시간을 줄일 수 있습니다. 자세한 내용은 다음을 참조하세요.
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)(MySQL 설명서)
+ Amazon Aurora의 경우 다음을 참조하세요.
+ [복제를 사용하여 Amazon Aurora MySQL DB 클러스터를 MySQL 데이터베이스와 동기화](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)(Aurora 설명서)
+ [Amazon Aurora에서 binlog 복제 사용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)(Aurora 설명서)
+ Amazon RDS의 경우 다음을 참조하세요.
+ [MySQL 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)(Amazon RDS 설명서)
+ [MariaDB 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)(Amazon RDS 설명서)
+ Amazon EC2의 경우 다음을 참조하세요.
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)(MySQL 설명서)
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)(MySQL 설명서)
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)(MariaDB 설명서)
## 장점
+ MyDumper는 다중 스레드를 사용하여 병렬화를 지원하므로 백업 및 복원 작업 속도가 향상됩니다.
+ MyDumper는 비용이 많이 드는 문자 세트 변환 루틴을 방지하므로 코드가 매우 효율적입니다.
+ MyDumper는 테이블 및 메타데이터에 대해 별도의 파일을 덤핑하여 데이터 보기 및 구문 분석을 단순화합니다.
+ MyDumper는 모든 스레드에서 스냅샷을 유지 관리하고 기본 및 보조 로그의 정확한 위치를 제공합니다.
+ Perl 호환 정규 표현식(PCRE)을 사용하여 테이블 또는 데이터베이스를 포함할지, 제외할지를 지정할 수 있습니다.
## 제한 사항
+ 데이터 변환 프로세스에 SQL 형식 대신 플랫 형식의 중간 덤프 파일이 필요한 경우 다른 도구를 선택할 수 있습니다.
+ myloader는 데이터베이스 사용자 계정을 자동으로 가져오지 않습니다. Amazon RDS 또는 Aurora로 백업을 복원하는 경우 필요한 권한을 가진 사용자를 다시 생성합니다. 권한에 대한 자세한 내용은 MariaDB 설명서에서 [마스터 사용자 계정 권한](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html)을 참조하세요. 백업을 Amazon EC2 데이터베이스 인스턴스로 복원하는 경우 소스 데이터베이스 사용자 계정을 수동으로 내보내 EC2 인스턴스로 가져올 수 있습니다.
## 모범 사례
+ 각 테이블을 여러 세그먼트(예: 각 세그먼트의 10,000개 행)로 나누고 각 세그먼트를 별도의 파일에 기록하도록 MyDumper를 구성합니다. 이렇게 하면 나중에 데이터를 병렬로 가져올 수 있습니다.
+ InnoDB 엔진을 사용하는 경우 `--trx-consistency-only` 옵션을 사용하여 잠금을 최소화합니다.
+ MyDumper를 사용하여 데이터베이스를 내보내면 읽기 집약적 작업이 될 수 있으며 프로세스가 프로덕션 데이터베이스의 전반적인 성능에 영향을 미칠 수 있습니다. 복제본 데이터베이스 인스턴스가 있는 경우 복제본에서 내보내기 프로세스를 실행합니다. 복제본에서 내보내기를 실행하기 전에 복제 SQL 스레드를 중지합니다. 이렇게 하면 내보내기 프로세스를 더 빠르게 실행할 수 있습니다.
+ 피크 업무 시간에는 데이터베이스를 내보내지 마세요. 피크 시간을 피하면 데이터베이스 내보내기 중에 기본 프로덕션 데이터베이스의 성능이 안정화될 수 있습니다.
+ Amazon RDS for MySQL은 `keyring_aws` 플러그인을 지원하지 않습니다. 자세한 내용은 [Known issues and limitations](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing)를 참조하세요. 온프레미스 암호화된 테이블을 Amazon RDS 인스턴스로 마이그레이션하려면 백업 스크립트의 `CREATE TABLE` 구문에서 `ENCRYPTION` 또는 `DEFAULT ENCRYPTION`을 제거해야 합니다. 저장 시 암호화를 위해 AWS Key Management Service (AWS KMS) 키를 사용할 수 있습니다. 자세한 내용은 [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 섹션을 참조하십시오.
# mysqldump 및 mysqlpump
[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) 및 [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)는 MySQL용 네이티브 데이터베이스 백업 도구입니다. MariaDB는 mysqldump를 지원하지만 mysqlpump는 지원하지 않습니다. 이러한 두 도구 모두 논리적 백업을 생성하며 MySQL 클라이언트 프로그램의 일부입니다. mysqldump는 단일 스레드 처리를 지원합니다. mysqlpump는 데이터베이스 및 데이터베이스 내 객체의 병렬화를 지원하여 덤프 프로세스의 속도를 높입니다. MySQL 버전 5.7.8에 도입되었습니다. MySQL 버전 8.4에서는 mysqlpump가 제거되었습니다.
다음 다이어그램에서는 mysqldump 또는 mysqlpump 백업 파일을 사용하여 데이터베이스를 마이그레이션하는 데 수반되는 상위 수준 단계를 보여줍니다.
![\[mysqldump 또는 mysqlpump 백업 파일을 마이그레이션하고 AWS DB 인스턴스에서 복원하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
다음은 mysqldump 또는 mysqlpump를 사용하여 데이터베이스를 AWS 클라우드로 마이그레이션하는 단계입니다.
1. 온프레미스 서버에 MySQL Shell을 설치하세요. 관련 지침은 MySQL 설명서의 [Installing MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html)을 참조하세요. 그러면 mysqldump와 mysqlpump가 모두 설치됩니다.
1. mysqldump 또는 mysqlpump를 사용하여 소스 온프레미스 데이터베이스의 백업을 생성하세요. 관련 지침은 MySQL 설명서의 [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) 및 [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)를 참조하거나 MariaDB 설명서의 [Making Backups with mysqldump](https://mariadb.com/kb/en/making-backups-with-mysqldump/)를 참조하세요. MySQL 프로그램 간접 호출 및 옵션 지정에 대한 자세한 내용은[Using MySQL programs](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html)를 참조하세요.
1. 다음 방법 중 하나를 사용하여 백업 파일을의 EC2 인스턴스 AWS 클라우드 로 이동합니다.
**접근 방식** **3A** - [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) 또는 [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) 파일 시스템을 데이터베이스 인스턴스를 실행하는 온프레미스 서버에 탑재합니다. AWS Direct Connect 또는 Site-to-Site VPN 를 사용하여 연결을 설정할 수 있습니다. 데이터베이스를 탑재된 파일 공유에 직접 백업하거나 데이터베이스를 로컬 파일 시스템에 백업한 다음 탑재된 FSx 또는 EFS 볼륨에 업로드하여 두 단계로 백업을 수행할 수 있습니다. 그런 다음 온프레미스 서버에도 탑재된 Amazon FSx 또는 Amazon EFS 파일 시스템을 EC2 인스턴스에 탑재하세요.
**접근 방식 3B** - AWS CLI, AWS SDK 또는 Amazon S3 REST API를 사용하여 백업 파일을 온프레미스 서버에서 S3 버킷으로 직접 이동합니다. 대상 S3 버킷이 데이터 센터와 멀리 떨어진에 AWS 리전 있는 경우 [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html)을 사용하여 파일을 더 빠르게 전송할 수 있습니다. [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) 파일 시스템을 사용하여 EC2 인스턴스에 S3 버킷을 탑재하세요.
**접근 방식 3C** - 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치한 다음 [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)를 사용하여 백업 파일을 Amazon S3 버킷으로 이동합니다. [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) 파일 시스템을 사용하여 EC2 인스턴스에 S3 버킷을 탑재하세요.
**참고**
Amazon S3 File Gateway를 사용하여 대용량 데이터베이스 백업 파일을 AWS 클라우드의 S3 버킷으로 전송할 수도 있습니다. 자세한 내용은 이 안내서의 [Amazon S3 File Gateway를 사용하여 백업 파일 전송](amazon-s3-file-gateway.md) 섹션을 참조하세요.
1. 네이티브 복원 방법을 사용하여 대상 데이터베이스에서 백업을 복원하세요. 관련 지침은 MySQL 설명서의 [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html)를 참조하거나 MariaDB 설명서의 [Restoring Data from Dump Files](https://mariadb.com/kb/en/restoring-data-from-dump-files/)를 참조하세요.
1. (선택 사항) 소스 데이터베이스와 대상 데이터베이스 인스턴스 간 복제를 설정할 수 있습니다. 바이너리 로그(binlog) 복제를 사용하여 가동 중지 시간을 줄일 수 있습니다. 자세한 내용은 다음을 참조하세요.
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)(MySQL 설명서)
+ Amazon Aurora의 경우 다음을 참조하세요.
+ [복제를 사용하여 Amazon Aurora MySQL DB 클러스터를 MySQL 데이터베이스와 동기화](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)(Aurora 설명서)
+ [Amazon Aurora에서 binlog 복제 사용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)(Aurora 설명서)
+ Amazon RDS의 경우 다음을 참조하세요.
+ [MySQL 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)(Amazon RDS 설명서)
+ [MariaDB 복제 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)(Amazon RDS 설명서)
+ Amazon EC2의 경우 다음을 참조하세요.
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)(MySQL 설명서)
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)(MySQL 설명서)
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)(MariaDB 설명서)
## 장점
+ mysqldump 및 mysqlpump는 MySQL Server 설치에 포함됨
+ 이러한 도구에서 생성된 백업 파일은 더 읽기 쉬운 형식입니다.
+ 백업 파일을 복원하기 전에 표준 텍스트 편집기를 사용하여 결과 .sql 파일을 수정할 수 있습니다.
+ 특정 테이블, 데이터베이스 또는 특정 데이터 선택 항목을 백업할 수 있습니다.
+ mysqldump 및 mysqlpump는 시스템 아키텍처에 독립적입니다.
## 제한 사항
+ mysqldump는 단일 스레드 백업 프로세스입니다. 백업을 수행하는 성능은 작은 데이터베이스에서 적당하지만 백업 크기가 10GB보다 크면 비효율적일 수 있습니다.
+ 논리적 형식의 백업 파일은 특히 텍스트로 저장될 때 볼륨이 크며, 종종 생성 및 복원 속도가 느립니다.
+ 대상 DB 인스턴스에서 SQL 문을 다시 적용하려면 삽입, 인덱스 생성 및 참조 무결성 제약 조건 적용을 위해 집약적 디스크 I/O 및 CPU 처리가 필요하기 때문에 데이터 복원 속도가 느려질 수 있습니다.
+ mysqlpump 유틸리티는 MySQL 버전 5.7.8 이하 또는 버전 8.4 이상에서 지원되지 않습니다.
+ 기본적으로 mysqlpump는 `performance_schema` 또는 `sys`와 같은 시스템 데이터베이스를 백업하지 않습니다. 시스템 데이터베이스의 일부를 백업하려면 명령줄에 명시적으로 이름을 지정합니다.
+ mysqldump는 InnoDB `CREATE TABLESPACE` 문을 백업하지 않습니다.
**참고**
CREATE TABLESPACE 문 및 시스템 데이터베이스 백업은 MySQL 또는 MariaDB 데이터베이스 백업을 EC2 인스턴스로 복원하는 경우에만 유용합니다. 이러한 백업은 Amazon RDS 또는 Aurora에서 사용되지 않습니다.
## 모범 사례
+ 데이터베이스 백업을 복원하는 경우 대상 데이터베이스의 세션 수준에서 `FOREIGN_KEY_CHECKS`와 같은 키 검사를 비활성화합니다. 그러면 복원 속도가 빨라집니다.
+ 데이터베이스 사용자에게 백업을 생성하고 복원할 수 있는 충분한 [권한](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html)이 있는지 확인합니다.
# 백업 분할
*분할 백업* 전략은 백업을 여러 부분으로 나누어 대규모 데이터베이스 서버를 마이그레이션하는 방법입니다. 다양한 접근 방식을 사용하여 백업의 각 부분을 마이그레이션할 수 있습니다. 다음 사용 사례에 가장 적합한 옵션일 수 있습니다.
+ **대규모 데이터베이스 서버이지만 소규모 개별 데이터베이스** - 총 데이터베이스 서버의 크기가 TB 단위이지만 개별 독립 사용자 데이터베이스의 크기가 1TB 미만인 경우 바람직한 접근 방식입니다. 전체 마이그레이션 기간을 줄이기 위해 개별 데이터베이스를 개별적으로 병렬로 마이그레이션할 수 있습니다.
온프레미스 2TB 데이터베이스 서버에 대한 예제를 살펴봅니다. 이 서버는 각각 0.5TB인 4개의 데이터베이스로 구성됩니다. 각 개별 데이터베이스의 백업을 별도로 수행할 수 있습니다. 백업을 복원할 때 인스턴스의 모든 데이터베이스를 병렬로 복원하거나 독립된 데이터베이스인 경우 각 백업을 별도의 인스턴스에서 복원할 수 있습니다. 독립된 데이터베이스를 동일한 인스턴스에서 복원하는 대신 별도의 인스턴스에서 복원하는 것이 모범 사례입니다. 자세한 내용은 이 가이드의 모범 사례를 참조하세요.
+ **대규모 데이터베이스 서버이지만 작은 개별 데이터베이스 테이블** - 총 데이터베이스 서버의 크기가 TB 단위이지만 각 독립 데이터베이스 테이블의 크기가 1TB 미만인 경우 바람직한 접근 방식입니다. 전체 마이그레이션 기간을 줄이기 위해 독립된 테이블을 개별적으로 마이그레이션할 수 있습니다.
1TB인 단일 사용자 데이터베이스 예제를 사용해 보겠습니다. 이 데이터베이스는 온프레미스 데이터베이스 서버의 유일한 데이터베이스입니다. 데이터베이스에는 10개의 테이블이 있으며 각 테이블은 100GB입니다. 각 개별 테이블의 백업을 별도로 수행할 수 있습니다. 백업을 복원하는 경우 인스턴스의 모든 테이블을 병렬로 복원할 수 있습니다.
+ **데이터베이스에 트랜잭션 워크로드 테이블과 비트랜잭션 워크로드 테이블 모두 포함됨** - 이전 사용 사례와 마찬가지로 동일한 데이터베이스에 트랜잭션 워크로드 테이블과 비트랜잭션 워크로드 테이블이 모두 있는 경우 분할 백업 접근 방식을 사용할 수 있습니다.
온라인 트랜잭션 처리(OLTP)에 사용되는 0.5TB의 중요 워크로드 테이블과 이전 데이터를 아카이브하는 데 사용되는 단일 1.5TB 테이블로 구성된 2TB 데이터베이스 예제를 살펴보겠습니다. 아카이브 테이블을 제외한 모든 데이터베이스 객체의 백업을 단일 트랜잭션 및 일관된 백업으로 사용할 수 있습니다. 그런 다음 아카이브 테이블에 대한 다른 별도의 백업을 수행합니다. 아카이브 테이블 백업의 경우 조건을 사용하여 백업 파일의 행 수를 분할함으로써 여러 병렬 백업을 수행하는 방법도 고려할 수 있습니다. 다음은 예제입니다.
```
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql
```
백업 파일을 복원할 때 트랜잭션 워크로드 백업과 아카이브 테이블 백업을 병렬로 복원할 수 있습니다.
+ **컴퓨팅 리소스 제한 사항** - CPU, 메모리 또는 디스크 I/O와 같은 온프레미스 서버의 컴퓨팅 리소스가 제한된 경우 백업을 수행할 때 안정성과 성능에 영향을 미칠 수 있습니다. 전체 백업을 가져오는 대신 부분으로 나눌 수 있습니다.
예를 들어 온프레미스 프로덕션 서버는 워크로드가 많고 CPU 리소스가 제한적일 수 있습니다. 이 서버에서 멀티테라바이트 데이터베이스의 단일 실행 백업을 수행하는 경우 추가 CPU 리소스를 소비하고 프로덕션 서버에 부정적인 영향을 미칠 수 있습니다. 전체 데이터베이스 백업을 수행하는 대신 백업을 각각 2\$13개의 테이블과 같이 여러 부분으로 나눕니다.