# Amazon RDS for MySQL DB 인스턴스로 데이터 가져오기
MySQL DB 인스턴스용 RDS로 데이터를 가져오는 기법에는 몇 가지가 있습니다. 가장 좋은 방법은 다음과 같은 여러 요인에 따라 달라집니다.
+ 데이터 원본
+ 데이터 분량
+ 일회성 혹은 지속적
+ 가동 중지 시간 길이
데이터와 함께 애플리케이션을 마이그레이션하는 경우라면 감당할 수 있는 가동 중지 시간도 고려해야 합니다.
다음 표에는 RDS for MySQL DB 인스턴스로 데이터를 가져오는 기법이 나와 있습니다.
| 소스 | 데이터 분량 | 일회성 혹은 지속적 | 애플리케이션 가동 중지 | 기술 | 추가 정보 |
| --- | --- | --- | --- | --- | --- |
| 온프레미스 또는 Amazon EC2에 있는 기존 MySQL 데이터베이스 | 모두 선택 | 한 번만 | 약간 | 온프레미스 데이터베이스의 백업을 만들어서 Amazon S3에 저장한 다음 MySQL을 실행하여 새로운 Amazon RDS DB 인스턴스에 백업 파일을 복원하십시오. | [Amazon RDS for MySQL DB 인스턴스로 백업 복원](MySQL.Procedural.Importing.md) |
| 온프레미스 또는 Amazon EC2에 있는 기존 MySQL 데이터베이스 | 모두 선택 | 지속적 | 최소화 | 기존 MySQL 데이터베이스가 복제 소스가 되도록 복제본을 구성합니다. | [외부 소스 인스턴스를 사용하여 이진 로그 파일 위치 복제 구성](MySQL.Procedural.Importing.External.Repl.md) [가동 중지 시간을 줄이면서 Amazon RDS for MySQL 데이터베이스로 데이터 가져오기](mysql-importing-data-reduced-downtime.md) |
| 기존의 모든 데이터베이스 | 모두 선택 | 일회성 혹은 지속적 | 최소화 | AWS Database Migration Service을 사용하면 가동 중지 시간을 최소화하면서 데이터베이스를 마이그레이션할 수 있으며 대부분의 DB 엔진에서는 지속적으로 복제를 계속할 수 있습니다. | [AWS Database Migration Service란?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) 및 *AWS Database Migration Service 사용 설명서*의 [AWS DMS에서 MySQL 호환 데이터베이스를 대상으로 사용](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) |
| 기존 MySQL DB 인스턴스 | 모두 선택 | 일회성 혹은 지속적 | 최소화 | 지속적인 복제를 위한 읽기 전용 복제본을 생성합니다. 새 DB 인스턴스를 한 번만 생성하도록 읽기 전용 복제본을 승격시킵니다. | [DB 인스턴스 읽기 전용 복제본 작업](USER_ReadRepl.md) |
| 기존 MySQL 데이터베이스 | 스몰 | 한 번만 | 약간 | 명령줄 유틸리티를 사용하여 MySQL DB 인스턴스에 바로 데이터를 복제합니다. | [외부 MySQL 데이터베이스에서 Amazon RDS for MySQL DB 인스턴스로 데이터 가져오기](mysql-importing-data-external-database.md) |
| 기존 데이터베이스에 저장되지 않은 데이터 | Medium | 한 번만 | 약간 | 플랫 파일을 만들고 MySQL LOAD DATA LOCAL INFILE 문을 이용하여 가져옵니다. | [원하는 소스에서 Amazon RDS for MySQL DB 인스턴스로 데이터 가져오기](mysql-importing-data-any-source.md) |
**참고**
`mysql` 시스템 데이터베이스에는 DB 인스턴스에 로그인하고 데이터에 액세스하는 데 필요한 인증 및 권한 부여 정보가 포함되어 있습니다. DB 인스턴스에 있는 `mysql` 데이터베이스의 각종 테이블, 데이터 또는 기타 콘텐츠를 삭제하거나 변경하거나 이름을 바꾸거나 자르면 오류가 발생하여 DB 인스턴스와 데이터에 액세스할 수 없게 될 수 있습니다. 이 문제가 발생할 경우 AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) 명령을 사용하여 DB 인스턴스를 스냅샷에서 복원할 수 있습니다. AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) 명령을 사용하여 DB 인스턴스를 복원할 수 있습니다.
# MySQL에 대한 데이터 가져오기 고려 사항
다음 내용에는 MySQL로 데이터를 로드하는 것과 관련된 기술 정보가 포함되어 있습니다. 이 콘텐츠는 MySQL 서버 아키텍처에 익숙한 사용자를 대상으로 합니다.
## 이진 로깅
이진 로깅을 활성화하면 로깅을 비활성화했을 때와 비교해 데이터 로드 성능이 저하되고 최대 4배의 추가 디스크 공간이 필요합니다. 데이터를 로드하는 데 사용되는 트랜잭션 크기는 시스템 성능 및 디스크 공간 요구 사항에 직접적인 영향을 미칩니다. 트랜잭션이 클수록 더 많은 리소스가 필요합니다.
## 트랜잭션 크기
트랜잭션 크기는 MySQL 데이터 로드의 다음 측면에 영향을 미칩니다.
+ 리소스 소비
+ 디스크 공간 사용률
+ 프로세스 재개
+ 복구 시간
+ 입력 형식(플랫 파일 또는 SQL)
이 섹션에서는 트랜잭션 크기가 이진 로깅에 미치는 영향을 설명하고 큰 데이터를 로드하는 중에 이진 로깅을 비활성화하는 이유를 논증합니다. Amazon RDS 자동 백업 보존 기간을 설정하여 이진 로깅을 활성화 및 비활성화할 수 있습니다. 0이 아닌 값으로 설정하면 이진 로깅이 활성화되고 0으로 설정하면 비활성화됩니다. 자세한 내용은 [백업 보존 기간](USER_WorkingWithAutomatedBackups.BackupRetention.md) 섹션을 참조하세요.
이 섹션에서는 대규모 트랜잭션이 InnoDB에 미치는 영향과 트랜잭션 크기를 작게 유지하는 것이 중요한 이유도 설명합니다.
### 작은 트랜잭션
작은 트랜잭션의 경우, 이진 로깅을 사용하면 데이터 로드에 필요한 디스크 쓰기 작업 수가 배가됩니다. 이 결과 다른 데이터베이스 세션의 성능이 심각하게 저하되고 데이터 로딩 시간이 증가할 수 있습니다. 발생하는 성능 저하는 부분적으로 다음 요인에 따라 달라집니다.
+ 업로드 속도
+ 로드 중에 발생하는 기타 데이터베이스 활동
+ Amazon RDS DB 인스턴스의 용량
또한, 이진 로그는 로그가 백업 및 제거될 때까지 로드된 데이터의 양과 대략적으로 같은 양의 디스크 공간을 사용합니다. Amazon RDS는 이진 로그를 자주 백업하고 제거하는 방법으로 이 문제를 최소화합니다.
### 대규모 트랜잭션
대규모 트랜잭션의 경우 다음과 같은 이유로 이진 로깅이 사용하는 IOPS 및 디스크가 3배로 늘어납니다.
+ 이진 로그 캐시는 트랜잭션 데이터를 일시적으로 디스크에 저장합니다.
+ 이 캐시는 디스크 공간을 소비하는 트랜잭션 크기에 따라 증가합니다.
+ 트랜잭션(커밋 또는 롤백)이 완료되면 시스템은 캐시를 이진 로그에 복사합니다.
이 프로세스는 다음과 같은 데이터 복사본 세 개를 만듭니다.
+ 원본 데이터
+ 디스크의 캐시
+ 최종 이진 로그 항목
각 쓰기 작업에는 추가 IO가 발생하여 성능에 더욱 영향을 미칩니다.
따라서 이진 로깅에는 로깅을 비활성화했을 때에 비해 디스크 공간이 3배 필요합니다. 예를 들어 10GiB의 데이터를 단일 트랜잭션으로 로드하면 다음과 같은 세 개의 복사본이 만들어집니다.
+ 테이블 데이터 10GiB
+ 이진 로그 캐시 10GiB
+ 이진 로그 파일 10GiB
필요한 총 임시 디스크 공간은 30GiB입니다.
중요한 디스크 공간 고려 사항:
+ 캐시 파일은 세션이 종료되거나 새 트랜잭션이 다른 캐시를 만들 때까지 유지됩니다.
+ 이진 로그는 백업될 때까지 유지되며, 잠재적으로 20GiB(캐시 및 로그)를 장기간 차지할 수 있습니다.
`LOAD DATA LOCAL INFILE`을 사용하여 데이터를 로드하는 경우 데이터 복구는 로드 전에 수행된 백업에서 데이터베이스를 복구해야 하는 경우를 대비하여 네 번째 복사본을 만듭니다. 복원 중에 MySQL이 이진 로그에서 플랫 파일로 데이터를 추출합니다. 그런 다음 MySQL은 `LOAD DATA LOCAL INFILE`을 실행합니다. 이전 예시의 내용을 바탕으로 봤을 때, 이 복구를 수행하려면 테이블, 캐시, 로그 및 로컬 파일에 대해 각각 10GiB씩 총 40GiB의 임시 디스크 공간이 필요합니다. 최소 40GiB의 여유 디스크 공간이 없으면 복구가 실패합니다.
### 대규모 데이터 로드 최적화
대규모 데이터 로드의 경우 이진 로깅을 비활성화하여 오버헤드 및 디스크 공간 요구 사항을 줄입니다. 백업 보존 기간을 0으로 설정하여 이진 로깅을 비활성화할 수 있습니다. 로드가 완료되면 백업 보존 기간을 0이 아닌 적절한 값으로 복원합니다. 자세한 정보는 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 및 설정 표의 [백업 보존 기간](USER_ModifyInstance.Settings.md)을 참조하세요.
**참고**
DB 인스턴스가 읽기 전용 복제본의 원본 DB 인스턴스인 경우에는 백업 보존 기간을 0으로 설정할 수 없습니다.
데이터를 로드하기 전에 DB 스냅샷을 만드는 것이 좋습니다. 자세한 내용은 [수동 백업 관리](USER_ManagingManualBackups.md) 섹션을 참조하세요.
## InnoDB
실행 취소 로깅 및 복구 옵션에 대한 다음 정보는 데이터베이스 성능을 최적화하기 위해 InnoDB 트랜잭션을 작게 유지하는 데 도움이 됩니다.
### InnoDB 실행 취소 로깅 이해
실행 취소는 트랜잭션 롤백을 활성화하고 다중 버전 동시성 제어(MVCC)를 지원하는 로깅 메커니즘입니다.
MySQL 5.7 이하 버전의 경우 실행 취소 로그는 InnoDB 시스템 테이블스페이스(일반적으로 ibdata1)에 저장되며 제거 스레드가 로그를 제거할 때까지 유지됩니다. 따라서 대규모 데이터 로드 트랜잭션은 시스템 테이블스페이스가 상당히 커지는 원인이 될 수 있고, 이때 사용되는 디스크 공간은 데이터베이스를 다시 만들어야 회수할 수 있습니다.
모든 MySQL 버전에서 제거 스레드는 가장 오래된 활성 트랜잭션이 커밋되거나 롤백될 때까지 실행 취소 로그를 제거할 수 없습니다. 데이터베이스가 로드 중에 다른 트랜잭션을 처리 중인 경우, 이들 트랜잭션의 실행 취소 로그 역시 누적되며 트랜잭션이 커밋되고 MVCC에 대해 실행 취소 로그가 필요한 다른 트랜잭션이 없더라도 실행 취소 로그를 제거할 수 없습니다. 이 경우 읽기 전용 트랜잭션을 포함한 모든 트랜잭션이 느려집니다. 이 속도 저하는 로드 트랜잭션뿐만 아니라 모든 트랜잭션이 변경하는 모든 행에 모든 트랜잭션이 액세스하기 때문에 발생합니다. 실제로 트랜잭션은 장기 실행 로드 트랜잭션으로 인해 실행 취소 로그 정리 중에 제거되지 않는 실행 취소 로그를 검사해야 합니다. 이는 수정된 행에 액세스하는 모든 작업의 성능에 영향을 줍니다.
### InnoDB 트랜잭션 복구 옵션
InnoDB는 커밋 작업을 최적화하지만 대규모 트랜잭션 롤백은 느립니다. 더 빠른 복구를 위해 시점 복구를 수행하거나 DB 스냅샷을 복원합니다. 자세한 내용은 [시점 복구](USER_PIT.md) 및 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md)(을)를 참조하세요.
## 데이터 가져오기 형식
MySQL은 플랫 파일과 SQL이라는 두 가지 데이터 가져오기 형식을 지원합니다. 각 형식에 대한 정보를 검토하여 요구 사항에 가장 적합한 옵션을 결정합니다.
### 플랫 파일
소규모 트랜잭션의 경우 `LOAD DATA LOCAL INFILE`을 사용하여 플랫 파일을 로드합니다. 이 데이터 가져오기 형식은 SQL 사용에 비해 다음과 같은 이점을 제공할 수 있습니다.
+ 더 낮은 네트워크 트래픽
+ 데이터 전송 비용 절감
+ 데이터베이스 처리 오버헤드 감소
+ 더 빠른 처리
`LOAD DATA LOCAL INFILE`은 전체 플랫 파일을 하나의 트랜잭션으로 로드합니다. 다음과 같은 이점을 위해 개별 파일의 크기를 작게 유지합니다.
+ **재개 기능** – 로드된 파일을 추적할 수 있습니다. 로드 중에 문제가 발생하면 중단된 부분부터 다시 시작할 수 있습니다. 일부 데이터를 Amazon RDS로 다시 전송해야 할 수도 있지만, 파일이 작으면 재전송되는 양이 최소화됩니다.
+ **병렬 데이터 로드** - 단일 파일 로드에 충분한 IOPS와 네트워크 대역폭이 있는 경우 병렬로 로드하면 시간이 절약될 수 있습니다.
+ **로드 속도 제어** - 데이터 로드가 다른 프로세스에 부정적인 영향을 미치는 경우 파일 간 간격을 늘려 로드 속도를 제어할 수 있습니다.
대규모 트랜잭션은 `LOAD DATA LOCAL INFILE`을 사용하여 데이터를 가져올 때의 이점을 줄입니다. 대량의 데이터를 더 작은 파일로 나눌 수 없는 경우 SQL을 사용하는 것을 고려하세요.
### SQL
SQL은 플랫 파일에 비해 한 가지 중요한 장점이 있는데, 그것은 바로 트랜잭션 크기를 작게 유지하기 쉽다는 점입니다. 그러나 SQL은 플랫 파일보다 로드하는 데 훨씬 더 오래 걸릴 수 있습니다. 또한 장애 발생 후 재개 위치를 결정하기 어려울 수 있으며, mysqldump 파일을 다시 시작할 수 없습니다. mysqldump 파일을 로드하는 동안 오류가 발생하는 경우 이 파일을 수정하거나 바꾸어야 로드를 재개할 수 있습니다. 또는 장애의 원인을 수정한 후 파일을 로드하고 재전송하기 전의 특정 시점으로 복원할 수 있습니다. 자세한 내용은 [시점 복구](USER_PIT.md) 섹션을 참조하세요.
## 데이터베이스 체크포인트에 Amazon RDS DB 스냅샷 사용
이진 로깅 없이 몇 시간 또는 며칠 등의 긴 기간 동안 데이터를 로드하는 경우 DB 스냅샷을 사용하여 데이터 안전을 위한 주기적 체크포인트를 제공하세요. 각 DB 스냅샷은 시스템 장애 또는 데이터 손상 이벤트 중에 복구 시점 역할을 하는 데이터베이스 인스턴스의 일관된 사본을 만듭니다. DB 스냅샷은 빠르기 때문에 체크포인트를 자주 제공해도 로드 성능에 미치는 영향이 최소화됩니다. 데이터베이스 내구성이나 복구 기능에 영향을 주지 않고 이전 DB 스냅샷을 삭제할 수 있습니다. DB 스냅샷에 대한 자세한 내용은 [수동 백업 관리](USER_ManagingManualBackups.md) 섹션을 참조하세요.
## 데이터베이스 로드 시간 단축
다음 항목은 로드 시간을 줄이기 위한 추가 팁입니다.
+ MySQL 데이터베이스로 데이터를 로드하기 전에 모든 보조 인덱스를 만듭니다. 다른 데이터베이스 시스템과 달리 MySQL은 보조 인덱스를 추가하거나 수정할 때 전체 테이블을 다시 빌드합니다. 이 프로세스는 인덱스 변경 사항이 있는 새 테이블을 만들고, 모든 데이터를 복사하고, 원본 테이블을 삭제합니다.
+ 프라이머리 키 순서로 데이터를 로드합니다. InnoDB 테이블의 경우 이렇게 하면 로드 시간을 75%\$180% 줄이고 데이터 파일 크기를 50% 줄일 수 있습니다.
+ `foreign_key_checks`를 `0`으로 설정하여 외래 키 제약 조건을 비활성화합니다. `LOAD DATA LOCAL INFILE`을 통해 로드되는 플랫 파일의 경우 이 단계는 많은 경우에 필수입니다. 모든 로드에서 외래 키 검사를 비활성화하면 데이터 로드가 가속화됩니다. 로드가 완료된 후 `foreign_key_checks`를 `1`로 설정하고 데이터를 확인하여 제약 조건을 다시 활성화합니다.
+ 리소스 한도가 가까워지지 않은 한 데이터를 병렬로 로드합니다. 여러 테이블 세그먼트에서 동시 로드를 활성화하기 위해 적절한 경우 파티셔닝된 테이블을 사용합니다.
+ SQL 실행 오버헤드를 줄이려면 여러 `INSERT` 문을 단일 다중 값 `INSERT` 작업으로 결합합니다.`mysqldump`는 이 최적화를 자동으로 구현합니다.
+ `innodb_flush_log_at_trx_commit`을 `0`으로 설정하여 InnoDB 로그 IO 작업을 줄입니다. 로드가 완료되면 `innodb_flush_log_at_trx_commit`을 `1`로 복원합니다.
**주의**
`innodb_flush_log_at_trx_commit`을 `0`으로 설정하면 InnoDB가 커밋이 발생할 때마다가 아닌 1초마다 로그를 플러시합니다. 이 설정은 성능을 높이지만 시스템 장애 발생 시 트랜잭션이 손실될 위험이 있습니다.
+ 읽기 전용 복제본이 없는 DB 인스턴스로 데이터를 로드하는 경우 `sync_binlog`를 `0`으로 설정합니다. 로드가 완료되면 `sync_binlog parameter`를 `1`로 복원합니다.
+ DB 인스턴스를 다중 AZ 배포로 변환하기 전에 단일 AZ DB 인스턴스로 데이터를 로드합니다. DB 인스턴스가 이미 다중 AZ 배포를 사용하는 경우 데이터 로드를 위해 단일 AZ 배포로 전환하지 않는 것이 좋습니다. 이렇게 해도 아주 작은 부분만이 개선됩니다.
# Amazon RDS for MySQL DB 인스턴스로 백업 복원
Amazon RDS는 백업 파일을 사용한 MySQL 데이터베이스 가져오기를 지원합니다. 데이터베이스의 백업을 만들어 Amazon S3에 저장한 다음 MySQL을 실행하는 새로운 Amazon RDS DB 인스턴스에 백업 파일을 복원할 수 있습니다. Amazon RDS는 모든 AWS 리전의 Amazon S3에서 백업 파일 가져오기를 지원합니다.
이 단원에서 설명하는 시나리오는 온프레미스 데이터베이스의 백업을 복원합니다. 데이터베이스에 액세스할 수 있는 한, 이 기법을 다른 위치(예: Amazon EC2 또는 다른 클라우드 서비스)의 데이터베이스에 사용할 수 있습니다.
다음 다이어그램은 지원되는 시나리오를 보여 줍니다.
![\[S3에서 백업 파일을 가져오는 MySQL.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png)
백업 파일을 만들고, 복사하고, 복원하는 동안 온프레미스 데이터베이스를 오프라인 상태로 둘 수 있다면 백업 파일을 사용하여 데이터베이스를 Amazon RDS로 가져오는 것이 좋습니다. 데이터베이스를 오프라인으로 둘 수 없는 경우 다음 방법 중 하나를 사용할 수 있습니다.
+ **이진 로그** - 먼저 이 주제에 설명된 대로 Amazon S3에서 Amazon RDS로 백업 파일을 가져옵니다. 그런 다음 이진 로그(binlog) 복제를 사용하여 데이터베이스를 업데이트합니다. 자세한 내용은 [외부 소스 인스턴스를 사용하여 이진 로그 파일 위치 복제 구성](MySQL.Procedural.Importing.External.Repl.md) 섹션을 참조하세요.
+ **AWS Database Migration Service** - AWS Database Migration Service를 사용하여 데이터베이스를 Amazon RDS로 마이그레이션합니다. 자세한 내용은 [AWS Database Migration Service란 무엇입니까?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)를 참조하세요.
## Amazon S3에서 Amazon RDS로 백업 파일을 가져오는 설정 개요
Amazon S3에서 Amazon RDS로 백업 파일을 가져오려면 다음 구성 요소가 필요합니다.
+ 백업 파일을 저장할 Amazon S3 버킷.
Amazon S3 버킷이 이미 있다면 해당 버킷을 사용할 수 있습니다. Amazon S3 버킷이 없는 경우에는 새 버킷을 만들 수 있습니다. 자세한 내용은 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html) 섹션을 참조하세요.
+ Percona XtraBackup이 생성한 온프레미스 데이터베이스 백업.
자세한 내용은 [데이터베이스 백업 생성](#MySQL.Procedural.Importing.Backup) 섹션을 참조하세요.
+ Amazon RDS가 S3 버킷에 액세스할 수 있도록 허용하는 AWS Identity and Access Management(IAM) 역할입니다.
이미 IAM 역할이 있는 경우 해당 역할을 사용하고 신뢰 및 권한 정책을 연결할 수 있습니다. 자세한 내용은 [수동으로 IAM 역할 만들기](#MySQL.Procedural.Importing.Enabling.IAM) 섹션을 참조하세요.
IAM 역할이 없는 경우 다음의 두 가지 옵션이 있습니다.
+ 새 IAM 역할을 수동으로 만들 수 있습니다. 자세한 내용은 [수동으로 IAM 역할 만들기](#MySQL.Procedural.Importing.Enabling.IAM) 섹션을 참조하세요.
+ Amazon RDS에서 새 IAM 역할을 만들도록 선택할 수 있습니다. Amazon RDS에서 새 IAM 역할을 만들도록 하려면 [Amazon S3에서 새 MySQL DB 인스턴스로 데이터 가져오기](#MySQL.Procedural.Importing.PerformingImport) 섹션에서 AWS Management Console을 사용하는 절차를 따르세요.
## 데이터베이스 백업 생성
백업을 생성하려면 Percona XtraBackup 소프트웨어를 사용하십시오. 최신 버전의 Percona XtraBackup을 사용하는 것이 좋습니다. Percona XtraBackup은 Percona 웹 사이트의 [Software Downloads](https://www.percona.com/downloads/)에서 설치할 수 있습니다.
**주의**
데이터베이스 백업을 만들 때 Xtrabackup은 xtrabackup\$1info 파일에 자격 증명을 저장할 수 있습니다. xtrabackup\$1info 파일의 `tool_command` 설정에 민감한 정보가 포함되어 있지 않은지 확인합니다.
사용하는 Percona XtraBackup 버전은 백업하는 MySQL 버전에 따라 다릅니다.
+ **MySQL 8.4** - Percona XtraBackup 버전 8.4를 사용합니다.
+ **MySQL 8.0** - Percona XtraBackup 버전 8.0을 사용합니다.
**참고**
Percona XtraBackup 8.0.12 이상 버전은 모든 MySQL 8.0 버전의 마이그레이션을 지원합니다. RDS for MySQL 8.0.32 이상으로 마이그레이션하는 경우, Percona XtraBackup 8.0.12 이상을 사용해야 합니다.
+ **MySQL 5.7** - Percona XtraBackup 버전 2.4를 사용합니다.
Percona XtraBackup을 사용하여 MySQL 데이터베이스 파일의 전체 백업을 생성할 수 있습니다. 또는 이미 Percona XtraBackup을 사용하여 MySQL 데이터베이스 파일을 백업 중인 경우 기존의 전체 및 증분 백업 디렉터리 및 파일을 업로드할 수 있습니다.
Percona XtraBackup을 사용한 데이터베이스 백업에 관한 자세한 내용은 Percona 웹 사이트의 [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)을 참조하세요.
### Percona XtraBackup을 사용한 전체 백업 생성
Amazon RDS가 Amazon S3에서 복원할 수 있는 MySQL 데이터베이스 파일의 전체 백업을 만들려면 Percona XtraBackup 유틸리티(`xtrabackup`)를 사용합니다.
예를 들어, 다음 명령을 실행하면 MySQL 데이터베이스 백업을 만들고 `/on-premises/s3-restore/backup` 폴더에 파일을 저장합니다.
```
xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup
```
백업을 파일 하나로 압축하려는 경우(필요한 경우 나중에 여러 파일로 분할할 수 있음) MySQL 버전에 따라 다음 형식 중 하나로 백업을 저장할 수 있습니다.
+ **Gzip(.gz)** - MySQL 5.7 이하 버전의 경우
+ **tar(.tar)** - MySQL 5.7 이하 버전의 경우
+ **Percona xbstream(.xbstream) **- 모든 MySQL 버전의 경우
**참고**
Percona XtraBackup 8.0 이상은 압축에 Percona xbstream만 지원합니다.
**MySQL 5.7 이하 버전**
다음 명령을 실행하면 Gzip 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. 값을 실제 정보로 바꿉니다.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar.gz
```
**MySQL 5.7 이하 버전**
다음 명령을 실행하면 tar 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. 값을 실제 정보로 바꿉니다.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar
```
**모든 MySQL 버전**
다음 명령을 실행하면 xbstream 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. 값을 실제 정보로 바꿉니다.
```
xtrabackup --backup --user=myuser --password=password --stream=xbstream \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.xbstream
```
**참고**
다음 오류가 표시되는 경우 명령에서 파일 형식이 혼합된 것이 원인일 수 있습니다.
```
ERROR:/bin/tar: This does not look like a tar archive
```
### Percona XtraBackup을 사용한 증분 백업 사용
이미 Percona XtraBackup을 사용하여 MySQL 데이터베이스 파일의 전체 및 증분 백업을 수행 중인 경우 전체 백업을 만들고 백업 파일을 Amazon S3로 업로드할 필요가 없습니다. 대신, 기존 백업 디렉터리 및 파일을 Amazon S3 버킷으로 복사하여 시간을 절약할 수 있습니다. Percona XtraBackup을 사용한 증분 백업 만들기에 대한 자세한 내용은 Percona 웹 사이트의 [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html)을 참조하세요.
기존의 전체 및 증분 백업 파일을 Amazon S3 버킷으로 복사할 때 기본 디렉터리의 콘텐츠를 반복적으로 복사해야 합니다. 이러한 콘텐츠에는 전체 백업과 모든 증분 백업 디렉터리 및 파일이 모두 포함됩니다. 이 복사본은 Amazon S3 버킷의 디렉터리 구조를 보존해야 합니다. Amazon RDS는 모든 파일과 디렉터리를 반복합니다. Amazon RDS는 각 증분 백업에 포함된 `xtrabackup-checkpoints` 파일을 사용하여 기본 디렉터리를 식별하고 로그 시퀀스 번호(LSN) 범위별로 증분 백업을 정렬합니다.
### Percona XtraBackup의 백업 고려 사항
Amazon RDS은 파일 이름을 기준으로 백업 파일을 사용합니다. 파일 형식에 따라 적절한 파일 확장명으로 백업 파일의 이름을 지정합니다. 예를 들어 Percona xbstream 형식을 사용하여 저장된 파일에 `.xbstream`을 사용합니다.
Amazon RDS는 알파벳 순서뿐 아니라 자연수 순서로도 백업 파일을 사용합니다. `xtrabackup` 명령을 실행할 때는 `split` 옵션을 사용하여 적절한 순서로 백업 파일을 쓰고 이름을 지정해야 합니다.
Amazon RDS는 Percona XtraBackup을 사용하여 생성되는 부분 백업을 지원하지 않습니다. 데이터베이스의 소스 파일을 백업할 때 다음 옵션을 사용하여 부분 백업을 만들 수 없습니다.
+ `--tables`
+ `--tables-exclude`
+ `--tables-file`
+ `--databases`
+ `--databases-exclude`
+ `--databases-file`
## 수동으로 IAM 역할 만들기
IAM 역할이 없는 경우에는 수동으로 새 역할을 만들 수 있습니다. 그러나 AWS Management Console를 사용하여 데이터베이스를 복원하는 경우에는 Amazon RDS가 이 새 IAM 역할을 만들도록 선택하는 것이 좋습니다. Amazon RDS에서 이 역할을 자동으로 생성하도록 하려면 [Amazon S3에서 새 MySQL DB 인스턴스로 데이터 가져오기](#MySQL.Procedural.Importing.PerformingImport) 섹션의 절차를 따릅니다.
Amazon S3에서 데이터베이스를 가져오기 위해 새 IAM 역할을 수동으로 만들려면 Amazon RDS에서 Amazon S3 버킷으로 권한을 위임하기 위한 역할을 만듭니다. IAM 역할을 만들 때 신뢰 및 권한 정책을 연결합니다. Amazon S3에서 백업 파일을 가져오려는 경우 다음 예제와 비슷한 신뢰 및 권한 정책을 사용합니다. 역할을 만드는 방법에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
신뢰 및 권한 정책에 따라 ARN(Amazon 리소스 이름)을 제공해야 합니다. ARN 형식에 대한 자세한 내용은 [ARN(Amazon 리소스 이름) 및 AWS 서비스 네임스페이스](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)를 참조하세요.
**Example Amazon S3에서 가져오기 위한 신뢰 정책**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleForBackup",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example Amazon S3에서 가져오기 위한 권한 정책 - IAM 사용자 권한**
다음 예제에서는 *iam\$1user\$1id*를 자신의 값으로 바꿉니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3AccessRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/S3Access"
}
]
}
```
**Example Amazon S3에서 가져오기 위한 권한 정책 - 역할 권한**
다음 예제에서는 *amzn-s3-demo-bucket*과 *접두사*를 고유한 값으로 바꿉니다.
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action":
[
"s3:GetObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*"
},
{
"Effect": "Allow",
"Action":
[
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_id*"
]
}
]
}
```
파일 이름 접두사를 포함하는 경우 접두사 다음에 별표(\$1)를 포함합니다. 접두사를 지정하지 않으려면 별표만 지정하면 됩니다.
## Amazon S3에서 새 MySQL DB 인스턴스로 데이터 가져오기
AWS Management Console, AWS CLI 또는 RDS API를 사용하여 새로운 MySQL DB 인스턴스로 Amazon S3의 데이터를 가져올 수 있습니다.
### 콘솔
**Amazon S3에서 새 MySQL DB 인스턴스로 데이터를 가져오려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. Amazon RDS 콘솔의 오른쪽 상단에서 DB 인스턴스를 만들려는 AWS 리전을 선택합니다. 데이터베이스 백업이 포함된 Amazon S3 버킷과 동일한 AWS 리전을 선택합니다.
1. 탐색 창에서 **Databases**(데이터베이스)를 선택합니다.
1. **S3에서 복원(Restore from S3)**을 선택합니다.
**S3에서 복원하여 데이터베이스 생성(Create database by restoring from S3)** 페이지가 나타납니다.
![\[S3에서 DB 인스턴스를 복원하기 위한 세부 정보를 지정하는 S3에서 복원하여 데이터베이스 생성 페이지.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png)
1. **S3 소스**에서 다음을 수행합니다.
1. 백업이 포함된 **S3 버킷**을 선택합니다.
1. (선택 사항) **S3 접두사**에 Amazon S3 버킷에 저장되는 파일의 파일 경로 접두사를 입력합니다.
접두사를 지정하지 않는 경우, Amazon RDS는 S3 버킷의 루트 폴더에 있는 모든 파일과 폴더를 사용하여 DB 인스턴스를 만듭니다. 접두사를 지정하는 경우 Amazon RDS는 파일의 경로가 지정된 접두사로 시작하는 S3 버킷의 파일과 폴더를 사용하여 DB 인스턴스를 만듭니다.
예를 들어 이름이 backups인 S3의 하위 폴더의 백업 파일을 저장했고 여러 세트의 백업 파일이 각각 자체 디렉터리(gzip\$1backup1, gzip\$1backup2 등)에 들어 있다고 가정해봅시다. 이 경우 gzip\$1backup1 폴더의 파일에서 복원하려면 backups/gzip\$1backup1의 접두사를 지정합니다.
1. **엔진 옵션(Engine options)**에서 다음을 수행합니다.
1. **엔진 유형(Engine type)**에서 **MySQL**을 선택합니다.
1. **소스 엔진 버전(Source engine version)**에서 소스 데이터베이스의 MySQL 메이저 버전을 선택합니다.
1. **엔진 버전**의 경우 AWS 리전에서 MySQL 메이저 버전의 기본 마이너 버전을 선택합니다.
AWS Management Console에서 기본 마이너 버전만 사용할 수 있습니다. 가져오기가 완료되면 DB 인스턴스를 업그레이드할 수 있습니다.
1. **IAM 역할**의 경우, Amazon RDS가 Amazon S3 버킷에 액세스할 수 있도록 허용하는 필수 신뢰 정책 및 권한 정책으로 IAM 역할을 만들거나 선택합니다. 다음 조치 중 하나를 취하세요.
+ (권장) **새 역할 생성**을 선택하고 **IAM 역할 이름**을 입력합니다. 이 옵션을 사용하면 Amazon RDS가 자동으로 신뢰 정책 및 사용 권한 정책을 사용하여 역할을 만듭니다.
+ 기존 IAM 역할을 선택합니다. 이 역할이 [수동으로 IAM 역할 만들기](#MySQL.Procedural.Importing.Enabling.IAM)의 모든 기준을 충족하는지 확인하세요.
1. DB 인스턴스 정보를 지정합니다. 각 설정에 대한 자세한 내용은 [DB 인스턴스에 대한 설정](USER_CreateDBInstance.Settings.md) 섹션을 참조하십시오.
**참고**
새 DB 인스턴스에 충분한 스토리지를 할당해야 복원 작업이 성공할 수 있습니다.
향후 자동 확장을 허용하려면 **추가 스토리지 구성**에서 **스토리지 자동 조정 활성화**를 선택합니다.
1. 필요에 따라 추가 설정을 선택합니다.
1. **데이터베이스 생성**을 선택합니다.
### AWS CLI
AWS CLI를 사용하여 Amazon S3에서 데이터를 새 MySQL DB 인스턴스로 가져오려면 다음 옵션을 사용하여 [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) 명령을 실행합니다. 각 설정에 대한 자세한 내용은 [DB 인스턴스에 대한 설정](USER_CreateDBInstance.Settings.md) 섹션을 참조하세요.
**참고**
새 DB 인스턴스에 충분한 스토리지를 할당해야 복원 작업이 성공할 수 있습니다.
스토리지 자동 크기 조정을 활성화하고 향후 자동 확장을 허용하려면 또한 `--max-allocated-storage` 옵션을 사용합니다.
+ `--allocated-storage`
+ `--db-instance-identifier`
+ `--db-instance-class`
+ `--engine`
+ `--master-username`
+ `--manage-master-user-password`
+ `--s3-bucket-name`
+ `--s3-ingestion-role-arn`
+ `--s3-prefix`
+ `--source-engine`
+ `--source-engine-version`
**Example**
대상 LinuxmacOS, 또는Unix:
```
1. aws rds restore-db-instance-from-s3 \
2. --allocated-storage 250 \
3. --db-instance-identifier my_identifier \
4. --db-instance-class db.m5.large \
5. --engine mysql \
6. --master-username admin \
7. --manage-master-user-password \
8. --s3-bucket-name amzn-s3-demo-bucket \
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \
10. --s3-prefix bucket_prefix \
11. --source-engine my_sql \
12. --source-engine-version 8.0.32 \
13. --max-allocated-storage 1000
```
Windows의 경우:
```
1. aws rds restore-db-instance-from-s3 ^
2. --allocated-storage 250 ^
3. --db-instance-identifier my_identifier ^
4. --db-instance-class db.m5.large ^
5. --engine mysql ^
6. --master-username admin ^
7. --manage-master-user-password ^
8. --s3-bucket-name amzn-s3-demo-bucket ^
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^
10. --s3-prefix bucket_prefix ^
11. --source-engine mysql ^
12. --source-engine-version 8.0.32 ^
13. --max-allocated-storage 1000
```
### RDS API
Amazon RDS API를 사용하여 Amazon S3에서 새 MySQL DB 인스턴스로 데이터를 가져오려면 [RestoreDBInstanceFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html) 작업을 호출하세요.
## Amazon S3에서 Amazon RDS로 백업 파일 가져오기에 대한 제한 및 고려 사항
Amazon S3에서 RDS for MySQL DB 인스턴스로 백업 파일을 가져오는 경우 다음과 같은 제한 및 고려 사항이 적용됩니다.
+ 기존 DB 인스턴스가 아닌 새 DB 인스턴스로만 데이터를 마이그레이션할 수 있습니다.
+ Percona XtraBackup을 사용하여 Amazon S3에 데이터를 백업해야 합니다. 자세한 내용은 [데이터베이스 백업 생성](#MySQL.Procedural.Importing.Backup) 섹션을 참조하세요.
+ Amazon S3 버킷과 RDS for MySQL DB 인스턴스는 같은 AWS 리전에 있어야 합니다.
+ 다음의 소스에서는 복원할 수 없습니다.
+ Amazon S3로의 DB 인스턴스 스냅샷 내보내기. DB 인스턴스 스냅샷 내보내기에서 S3 버킷으로 데이터를 마이그레이션할 수 없습니다.
+ 암호화된 소스 데이터베이스. 그러나 마이그레이션 중인 데이터를 암호화할 수 있습니다. 또한 데이터를 마이그레이션 프로세스 동안 암호화하지 않은 상태로 유지할 수도 있습니다.
+ MySQL 5.5 또는 5.6 데이터베이스.
+ Percona Server for MySQL은 `mysql schema`에 `compression_dictionary*` 테이블을 포함할 수 있으므로 RDS for MySQL은 소스 데이터베이스로 이를 지원하지 않습니다.
+ RDS for MySQL은 메이저 버전 또는 마이너 버전에서 역방향 마이그레이션을 지원하지 않습니다. 예를 들어, MySQL 버전 8.0에서 RDS for MySQL 5.7로 마이그레이션할 수 없으며, MySQL 버전 8.0.32에서 RDS for MySQL 버전 8.0.26으로 마이그레이션할 수 없습니다.
+ Amazon RDS는 db.t2.micro DB 인스턴스 클래스에서 Amazon S3로부터의 가져오기를 지원하지 않습니다. 그러나 다른 DB 인스턴스 클래스로 복원한 다음 나중에 DB 인스턴스 클래스를 변경할 수 있습니다. 인스턴스 클래스에 대한 자세한 내용은 [ DB 인스턴스 클래스의 하드웨어 사양](Concepts.DBInstanceClass.Summary.md) 섹션을 참조하십시오.
+ Amazon S3는 Amazon S3 버킷에 업로드되는 파일 크기를 5TB로 제한합니다. 백업 파일이 5TB를 초과하면 해당 백업 파일을 더 작은 크기의 파일들로 나누어야 합니다.
+ Amazon RDS는 Amazon S3 버킷에 업로드되는 파일을 100만 개로 제한합니다. 모든 전체 및 증분 백업을 포함하여 데이터베이스에 대한 백업 데이터가 100만 개의 파일을 초과하는 경우 Gzip(.gz), tar(.tar.gz) 또는 Percona xbstream(.xbstream) 파일을 사용하여 전체 및 증분 백업 파일을 Amazon S3 버킷에 저장합니다. Percona Xtrabackup 8.0은 압축에 Percona xbstream만 지원합니다.
+ 각 DB 인스턴스에 관리 서비스를 제공하기 위해 Amazon RDS는 DB 인스턴스를 만들 때 `rdsadmin` 사용자를 만듭니다. `rdsamin`은 Amazon RDS에서 예약된 사용자이므로 다음과 같은 제한 사항이 적용됩니다.
+ Amazon RDS는 `'rdsadmin'@'localhost'`를 정의자로 사용하는 함수, 프로시저, 뷰, 이벤트 및 트리거를 가져올 수 없습니다. 자세한 내용은 ['rdsamin'@'localhost'를 정의자로 사용하여 저장된 객체](#MySQL.Procedural.Importing.StoredObjects) 및 [마스터 사용자 계정 권한](UsingWithRDS.MasterAccounts.md)(을)를 참조하세요.
+ DB 인스턴스를 만들 때 Amazon RDS는 지원되는 최대 권한이 있는 마스터 사용자를 만듭니다. 백업에서 복원하는 동안 Amazon RDS는 가져오는 사용자에게 할당된 지원되지 않는 권한을 자동으로 제거합니다.
이로 인해 영향을 받을 수 있는 사용자를 식별하려면 [지원되지 않는 권한을 지닌 사용자 계정](#MySQL.Migrating.ExtMySQL.Prechecks.Users) 섹션을 참조하세요. RDS for MySQL에서 지원되는 권한에 대한 자세한 내용은 [RDS for MySQL에 대한 역할 기반 권한 모델](Appendix.MySQL.CommonDBATasks.privilege-model.md) 섹션을 참조하세요.
+ Amazon RDS는 `mysql` 스키마에서 사용자가 만든 테이블을 마이그레이션하지 않습니다.
+ `innodb_data_file_path` 파라미터는 기본 데이터 파일 이름 `ibdata1:12M:autoextend`를 사용하는 데이터 파일 하나만 사용하여 구성해야 합니다. 이 방법을 사용하여 두 개의 데이터 파일이 있거나 다른 이름의 데이터 파일이 있는 데이터베이스를 마이그레이션할 수 있습니다.
다음 예제는 Amazon RDS에서 허용하지 않는 파일 이름입니다.
+ `innodb_data_file_path=ibdata1:50M`
+ `ibdata2:50M:autoextend`
+ `innodb_data_file_path=ibdata01:50M:autoextend`
+ 기본 MySQL 데이터 디렉터리 외부에서 정의된 테이블이 있는 원본 데이터베이스에서 마이그레이션할 수 없습니다.
+ 이 방법을 사용할 때 압축되지 않은 백업에 지원되는 최대 크기는 64TiB로 제한됩니다. 압축 백업의 경우 압축되지 않은 공간 관련 요구 사항을 고려하여 이 제한 수준이 낮게 적용됩니다. 이 경우 지원되는 최대 백업 크기는 `64 TiB - compressed backup size`입니다.
RDS for MySQL에서 지원하는 최대 데이터베이스 크기에 대한 자세한 내용은 [범용 SSD 스토리지](CHAP_Storage.md#Concepts.Storage.GeneralSSD) 및 [프로비저닝된 IOPS SSD 스토리지](CHAP_Storage.md#USER_PIOPS) 섹션을 참조하세요.
+ Amazon RDS는 MySQL 및 기타 외부 구성 요소와 플러그인 가져오기를 지원하지 않습니다.
+ Amazon RDS는 데이터베이스에서 모든 것을 복원하지 않습니다. 소스 MySQL 시스템 데이터베이스에서 다음 항목의 데이터베이스 스키마와 값을 저장한 다음, 복원한 RDS for MySQL DB 인스턴스가 만들어지면 여기에 추가하는 것이 좋습니다.
+ 사용자 계정
+ Functions
+ 저장 프로시저
+ 시간대 정보. 시간대 정보는 RDS for MySQL DB 인스턴스의 로컬 운영 체제에서 로드됩니다. 자세한 내용은 [MySQL DB 인스턴스의 현지 시간대](MySQL.Concepts.LocalTimeZone.md) 섹션을 참조하세요.
### 'rdsamin'@'localhost'를 정의자로 사용하여 저장된 객체
Amazon RDS는 `'rdsadmin'@'localhost'`를 정의자로 사용하는 함수, 프로시저, 뷰, 이벤트 및 트리거를 가져올 수 없습니다.
소스 MySQL 데이터베이스에서 다음 SQL 스크립트를 사용하면 지원되지 않는 정의자가 있는 저장된 객체를 나열할 수 있습니다.
```
-- This SQL query lists routines with `rdsadmin`@`localhost` as the definer.
SELECT
ROUTINE_SCHEMA,
ROUTINE_NAME
FROM
information_schema.routines
WHERE
definer = 'rdsadmin@localhost';
-- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer.
SELECT
TRIGGER_SCHEMA,
TRIGGER_NAME,
DEFINER
FROM
information_schema.triggers
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists events with `rdsadmin`@`localhost` as the definer.
SELECT
EVENT_SCHEMA,
EVENT_NAME
FROM
information_schema.events
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists views with `rdsadmin`@`localhost` as the definer.
SELECT
TABLE_SCHEMA,
TABLE_NAME
FROM
information_schema.views
WHERE
DEFINER = 'rdsadmin@localhost';
```
### 지원되지 않는 권한을 지닌 사용자 계정
RDS for MySQL에서 지원되지 않는 권한을 지닌 사용자 계정의 경우, 가져올 때 지원되지 않는 권한은 제외됩니다. 지원되는 권한 목록은 [RDS for MySQL에 대한 역할 기반 권한 모델](Appendix.MySQL.CommonDBATasks.privilege-model.md) 섹션을 참조하세요.
소스 데이터베이스에서 다음 SQL 쿼리를 실행하여 지원되지 않는 권한이 있는 사용자 계정을 나열할 수 있습니다.
```
SELECT
user,
host
FROM
mysql.user
WHERE
Shutdown_priv = 'y'
OR File_priv = 'y'
OR Super_priv = 'y'
OR Create_tablespace_priv = 'y';
```
# 외부 MySQL 데이터베이스에서 Amazon RDS for MySQL DB 인스턴스로 데이터 가져오기
기존 MySQL 데이터베이스에서 RDS for MySQL DB 인스턴스로 데이터를 가져올 수 있습니다. 이렇게 하려면 [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)를 사용하여 데이터베이스를 복사하고 RDS for MySQL DB 인스턴스에 바로 파이핑합니다. `mysqldump` 명령줄 유틸리티는 한 MySQL 서버에서 다른 MySQL 또는 MariaDB 서버로 데이터를 전송하고 백업본을 만드는 데 흔히 사용됩니다. 이 유틸리티는 MySQL 클라이언트 소프트웨어와 함께 포함되어 있습니다.
**참고**
MySQL DB 인스턴스에 많은 양의 데이터를 가져와서 내보내는 경우 `xtrabackup` 백업 파일 및 Amazon S3를 사용하여 Amazon RDS 내부 및 외부로 데이터를 더 빠르고 안정적으로 이동할 수 있습니다. 자세한 내용은 [Amazon RDS for MySQL DB 인스턴스로 백업 복원](MySQL.Procedural.Importing.md) 섹션을 참조하세요.
외부 데이터베이스에서 Amazon RDS DB 인스턴스로 데이터를 이동하는 일반적인 `mysqldump` 명령은 다음 예와 같습니다. 값을 실제 정보로 바꿉니다.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**중요**
`-p` 옵션과 입력한 암호 사이에 공백이 없어야 합니다.
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
다음 권장 사항과 고려 사항을 잘 파악하고 있어야 합니다.
+ 덤프 파일에서 다음 스키마를 제외합니다.
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` 유틸리티는 기본적으로 이러한 스키마를 제외합니다.
+ 사용자 및 권한을 마이그레이션해야 하는 경우 이를 다시 생성하는 데이터 제어 언어(DCL)를 생성하는 도구 사용을 고려합니다. 예를 들어 [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) 유틸리티가 있습니다.
+ 가져오기를 수행하려면 사용자가 DB 인스턴스에 액세스할 수 있어야 합니다. 자세한 내용은 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 섹션을 참조하세요.
사용되는 파라미터는 다음과 같습니다.
+ `-u local_user` – 사용자 이름을 지정하기 위해 사용합니다. 이 파라미터를 처음 사용할 때, 로컬 MySQL 데이터베이스에서 `--databases` 파라미터로 식별되는 사용자 계정 이름을 지정합니다.
+ `--databases database_name` – 로컬 MySQL 인스턴스에서 Amazon RDS로 가져오려는 데이터베이스 이름을 지정합니다.
+ `--single-transaction` – 로컬 데이터베이스에서 로드한 모든 데이터가 단일 시점에서 일치하는지 확인하기 위해 사용합니다. `mysqldump`가 데이터를 읽는 동안 데이터를 변경하는 다른 프로세스가 있는 경우, 이 파라미터를 사용하여 데이터 무결성을 유지합니다.
+ `--compress` – 데이터를 Amazon RDS로 전송하기 전에 로컬 데이터베이스에서 데이터를 압축하여 네트워크 대역폭 사용을 줄이기 위해 사용합니다.
+ `--order-by-primary` – 기본 키를 기준으로 각 테이블의 데이터를 정렬하여 로드 시간을 줄이기 위해 사용합니다.
+ `--routines` - 복사하려는 데이터베이스에 저장 프로시저 또는 함수와 같은 루틴이 있는 경우 사용합니다. 파라미터를 `0`으로 설정하면 가져오기 프로세스 중에 루틴이 제외됩니다. 그런 다음 나중에 Amazon RDS 데이터베이스에서 루틴을 수동으로 다시 만듭니다.
+ `--triggers` - 복사 중인 데이터베이스에 트리거가 있는 경우 사용합니다. 파라미터를 `0`으로 설정하면 가져오기 프로세스 중에 트리거가 제외됩니다. 그런 다음 Amazon RDS 데이터베이스에서 트리거를 수동으로 다시 만듭니다.
+ `--events` - 복사하려는 데이터베이스에 이벤트가 있는 경우 사용합니다. 파라미터를 `0`으로 설정하면 가져오기 프로세스 중에 이벤트가 제외됩니다. 그런 다음 Amazon RDS 데이터베이스에서 이벤트를 수동으로 다시 만듭니다.
+ `-plocal_password` – 암호를 지정하기 위해 사용합니다. 이 파라미터를 처음 사용할 때, 첫 번째 `-u` 파라미터로 식별되는 사용자 계정 암호를 지정합니다.
+ `-u RDS_user` – 사용자 이름을 지정하기 위해 사용합니다. 이 파라미터를 두 번째로 사용할 때, `--host` 파라미터로 식별되는 MySQL DB 인스턴스에 대한 기본 데이터베이스의 사용자 계정 이름을 지정합니다.
+ `--port port_number` - MySQL DB 인스턴스의 포트를 지정하기 위해 사용합니다. DB 인스턴스를 만들 때 값을 변경하지 않는 한, 기본값은 3306입니다.
+ `--host host_name` - Amazon RDS DB 인스턴스 엔드포인트의 도메인 이름 시스템(DNS) 이름을 지정하기 위해 사용합니다(예:)`myinstance.123456789012.us-east-1.rds.amazonaws.com`. Amazon RDS 콘솔의 인스턴스 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.
+ `-pRDS_password` – 암호를 지정하기 위해 사용합니다. 이 파라미터를 두 번째로 사용할 때, 두 번째 `-u` 파라미터로 식별되는 사용자 계정 암호를 지정합니다.
Amazon RDS 데이터베이스에서 저장 프로시저, 트리거, 함수 또는 이벤트를 수동으로 만들어야 합니다. 복사 중인 데이터베이스에 이런 객체가 하나라도 있는 경우에는 `mysqldump`를 실행할 때 이런 객체를 제외합니다. 그렇게 하면 `mysqldump` 명령을 사용하여 다음과 같은 파라미터를 포함합니다.
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**예제**
다음 예제에서는 로컬 호스트에 있는 `world` 샘플 데이터베이스를 RDS for MySQL DB 인스턴스로 복사합니다. 값을 실제 정보로 바꿉니다.
대상 LinuxmacOS, 또는Unix:
```
sudo mysqldump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Windows의 경우:
다음 명령은 Windows 프로그램 메뉴에서 **명령 프롬프트**를 마우스 오른쪽 버튼으로 클릭하고 **관리자 권한으로 실행**을 선택하여 열린 명령 프롬프트에서 실행해야 합니다. 값을 실제 정보로 바꿉니다.
```
mysqldump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mysql -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
# 가동 중지 시간을 줄이면서 Amazon RDS for MySQL 데이터베이스로 데이터 가져오기
라이브 애플리케이션을 지원하는 외부 MySQL 데이터베이스에서 RDS for MySQL DB 인스턴스 또는 RDS for MySQL 다중 AZ DB 클러스터로 데이터를 가져와야 할 경우가 있습니다. 다음 절차를 통해 애플리케이션 가용성에 미치는 영향을 최소화하세요. 이 절차는 대규모 데이터베이스로 작업하는 경우에도 유용합니다. 이 절차를 통해 네트워크를 거쳐 AWS로 전달되는 데이터의 양을 줄여 가져오기 비용을 줄일 수 있습니다.
이 절차에서는 데이터베이스 데이터의 복사본을 Amazon EC2 인스턴스로 전송하고 데이터를 새 Amazon RDS 데이터베이스로 가져옵니다. 그런 다음, 애플리케이션을 Amazon RDS 데이터베이스로 리디렉션하기 전에 복제를 사용하여 Amazon RDS 데이터베이스를 라이브 외부 인스턴스에 맞춰 최신 상태로 업데이트합니다. 이진 로그 좌표를 기반으로 복제를 구성합니다.
**참고**
RDS for MySQL DB 인스턴스에 데이터를 가져오고자 하며 시나리오가 이 방법을 지원하는 경우 백업 파일 및 Amazon S3를 사용하여 Amazon RDS 내부 및 외부로 데이터를 이동하는 것이 좋습니다. 자세한 내용은 [Amazon RDS for MySQL DB 인스턴스로 백업 복원](MySQL.Procedural.Importing.md) 섹션을 참조하세요.
다음 다이어그램은 외부 MySQL 데이터베이스를 Amazon RDS의 MySQL 데이터베이스로 가져오는 것을 보여 줍니다.
![\[외부 MySQL 데이터베이스를 Amazon RDS의 MySQL 데이터베이스로 가져오는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_1.png)
## 작업 1: 기존 데이터베이스의 복사본 만들기
최소한의 가동 중지 시간으로 대량의 데이터를 RDS for MySQL 데이터베이스로 마이그레이션하는 프로세스에서 첫 번째 단계는 원본 데이터의 복사본을 만드는 것입니다.
다음 다이어그램은 MySQL 데이터베이스의 백업을 만드는 방법을 보여 줍니다.
![\[MySQL 데이터베이스의 백업 만드는 방법을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png)
`mysqldump` 유틸리티를 사용하여 SQL 또는 구분 기호로 분리된 텍스트 형식으로 데이터베이스 백업본을 만들 수 있습니다. 비프로덕션 환경에서 각각의 형식으로 테스트 실행을 통해 어떤 방법을 사용해야 `mysqldump` 실행 시간이 최소화되는지 확인하는 것을 권장합니다.
또한, 로드를 위해 구분 기호로 분리된 텍스트 형식을 사용할 때의 이점에 대해 `mysqldump` 성능상의 이점을 비교 검토하는 것을 권장합니다. 구분 기호로 분리된 텍스트 형식을 사용하는 백업에서는 덤프되는 각 테이블에 대해 탭으로 구분된 텍스트 파일이 생성됩니다. 데이터베이스를 가져오는 데 필요한 시간을 줄이기 위해 `LOAD DATA LOCAL INFILE` 명령을 사용하여 이런 파일을 병렬로 로드할 수 있습니다. 자세한 내용은 모든 소스에서 데이터 가져오기 절차의 [5단계: 데이터 로드](mysql-importing-data-any-source.md#mysql-importing-data-any-source-load-data) 섹션을 참조하세요.
백업 작업을 시작하기 전에 Amazon RDS로 복사할 MySQL 데이터베이스에서 복제 옵션을 설정해야 합니다. 복제 옵션에는 이진 로깅 활성화와 고유한 서버 ID 설정이 포함됩니다. 이러한 옵션을 설정하면 서버가 데이터베이스 트랜잭션 로깅을 시작하고 이 프로세스의 후반부에 소스 복제 인스턴스가 되도록 서버를 준비시킵니다.
다음 권장 사항과 고려 사항을 잘 파악하고 있어야 합니다.
+ 데이터베이스의 일관된 상태를 덤프하기 때문에 `--single-transaction`와 함께 `mysqldump` 옵션을 사용하세요. 덤프 파일이 올바른지 확인하려면 `mysqldump`가 실행되는 동안 데이터 정의 언어(DDL) 문을 실행하지 마시기 바랍니다. 이러한 작업에 대한 유지 관리 기간을 예약할 수 있습니다.
+ 덤프 파일에서 다음 스키마를 제외합니다.
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` 유틸리티는 기본적으로 이러한 스키마를 제외합니다.
+ 사용자 및 권한을 마이그레이션해야 하는 경우 이를 다시 생성하는 데이터 제어 언어(DCL)를 생성하는 도구 사용을 고려합니다. 예를 들어 [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) 유틸리티가 있습니다.
### 복제 옵션을 설정하려면
1. `my.cnf` 파일을 편집합니다. 이 파일은 보통 `/etc` 아래에 있습니다.
```
sudo vi /etc/my.cnf
```
`log_bin` 및 `server_id` 옵션을 `[mysqld]` 섹션에 추가합니다. `log_bin` 옵션은 이진 로그 파일에 대한 파일 이름 식별자를 제공합니다. `server_id` 옵션은 소스-복제본 관계에서 서버의 고유 식별자를 제공합니다.
다음 예제에서는 `my.cnf` 파일의 업데이트된 `[mysqld]` 섹션을 보여줍니다.
```
[mysqld]
log-bin=mysql-bin
server-id=1
```
자세한 내용은 MySQL 설명서의 [Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html)을 참조하세요.
1. 다중 AZ DB 클러스터를 사용한 복제의 경우 `ENFORCE_GTID_CONSISTENCY` 및 `GTID_MODE` 파라미터를 `ON`으로 설정합니다.
```
mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
```
```
mysql> SET @@GLOBAL.GTID_MODE = ON;
```
DB 인스턴스를 사용한 복제에는 이러한 설정이 필요하지 않습니다.
1. `mysql` 서비스를 다시 시작합니다.
```
sudo service mysqld restart
```
### 기존 데이터베이스의 백업 복사본을 만들려면
1. SQL 또는 구분 기호로 분리된 텍스트 형식을 지정하는 `mysqldump` 유틸리티를 사용하여 데이터 백업을 만듭니다.
MySQL 8.0.25 이하 버전에서는 서버 간 복제를 시작할 때 사용할 수 있는 백업 파일을 만들려면 `--master-data=2`를 지정합니다. MySQL 8.0.26 이상 버전에서는 서버 간 복제를 시작할 때 사용할 수 있는 백업 파일을 만들려면 `--source-data=2`를 지정합니다. 자세한 내용은 MySQL 설명서의 [mysqldump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html)을 참조하세요.
성능을 개선하고 데이터 무결성을 보장하려면 `mysqldump`에 `--order-by-primary` 및 `--single-transaction` 옵션을 사용합니다.
백업에 MySQL 시스템 데이터베이스가 포함되지 않도록 하려면 `mysqldump`에 `--all-databases` 옵션을 사용하지 마세요. 자세한 내용은 MySQL 설명서의 [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html)를 참조하세요.
필요한 경우 `chmod`를 사용하여 백업 파일이 만들어질 디렉터리가 쓰기 가능한 디렉터리가 되도록 하세요.
**중요**
Windows에서는 명령 창을 관리자 권한으로 실행하십시오.
+ SQL 출력을 표시하려면 다음 명령을 사용합니다.
대상 LinuxmacOS, 또는Unix:
```
sudo mysqldump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
Windows의 경우:
```
mysqldump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
+ 구분 기호로 분리된 텍스트 출력을 표시하려면 다음 명령을 사용합니다.
대상 LinuxmacOS, 또는Unix:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Windows의 경우:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
Amazon RDS 데이터베이스에서 저장 프로시저, 트리거, 함수 또는 이벤트를 수동으로 만들어야 합니다. 복사 중인 데이터베이스에 이런 객체가 하나라도 있는 경우에는 `mysqldump`를 실행할 때 이런 객체를 제외합니다. 이렇게 하려면 `mysqldump` 명령에 다음 인수를 포함하세요.
`--routines=0`
`--triggers=0`
`--events=0`
MySQL 8.0.22 이하 버전의 경우 `mysqldump`를 실행하고 구분된 텍스트 형식을 지정하면 `CHANGE MASTER TO` 설명이 반환됩니다. 이 설명에는 마스터 로그 파일 이름과 위치가 포함됩니다. MySQL 8.0.23 이상 버전의 경우 구분된 텍스트 형식을 사용하여 `mysqldump`를 실행하면 `CHANGE REPLICATION SOURCE TO` 설명이 반환됩니다. 이 설명에는 소스 로그 파일 이름과 위치가 포함됩니다. 외부 인스턴스가 MySQL 8.0.23 이상 버전인 경우 `MASTER_LOG_FILE` 및 `MASTER_LOG_POS`의 값을 기록해 둡니다. 복제를 설정할 때 이러한 값이 필요합니다.
MySQL 8.0.22 이하 버전에 대해 다음 출력이 반환됩니다.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
MySQL 8.0.23 이상 버전에 대해 다음 출력이 반환됩니다.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107;
```
MySQL 8.0.22 이하 버전에서 SQL 형식을 사용하는 경우 백업 파일의 `CHANGE MASTER TO` 설명에서 마스터 로그 파일 이름 및 위치를 가져올 수 있습니다. MySQL 8.0.23 이상 버전에서 SQL 형식을 사용하는 경우 백업 파일의 `CHANGE REPLICATION SOURCE TO` 설명에서 소스 로그 파일 이름 및 위치를 가져올 수 있습니다.
1. 복사된 데이터를 압축하여 데이터를 Amazon RDS 데이터베이스로 복사하는 데 필요한 네트워크 리소스의 양을 줄입니다. 백업 파일의 크기를 기록해 둡니다. Amazon EC2 인스턴스를 얼마나 크게 만들지 결정할 때 이 정보가 필요합니다. 모두 완료되었으면, GZIP 또는 선호하는 압축 유틸리티를 사용하여 백업 파일을 압축합니다.
+ SQL 출력을 압축하려면 다음 명령을 사용합니다.
```
gzip backup.sql
```
+ 구분 기호로 분리된 텍스트 출력을 압축하려면 다음 명령을 사용합니다.
```
tar -zcvf backup.tar.gz target_directory
```
## 작업 2: Amazon EC2 인스턴스 만들기 및 압축된 데이터베이스 복사
압축된 데이터베이스 백업 파일을 Amazon EC2 인스턴스로 복사할 때는 데이터베이스 인스턴스 사이에서 압축되지 않은 데이터를 직접 복사할 때보다 네트워크 리소스를 덜 사용합니다. 데이터가 Amazon EC2에 있으면 MySQL 데이터베이스로 바로 데이터를 복사할 수 있습니다. 네트워크 리소스의 비용을 절약하려면 Amazon EC2 인스턴스가 Amazon RDS DB 인스턴스와 같은 AWS 리전에 있어야 합니다. Amazon EC2 인스턴스를 Amazon RDS 데이터베이스와 같은 AWS 리전에 두면 가져오기 도중의 네트워크 대기 시간도 줄어듭니다.
다음 다이어그램은 데이터베이스 백업을 Amazon EC2 인스턴스로 복사하는 것을 보여줍니다.
![\[Amazon EC2 인스턴스에 데이터베이스 백업을 복사하는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_3.png)
### Amazon EC2 인스턴스를 만들고 데이터를 복사하려면
1. Amazon RDS 데이터베이스를 만들려는 AWS 리전에서 가상 프라이빗 클라우드(VPC), VPC 보안 그룹 및 VPC 서브넷을 만듭니다. VPC 보안 그룹의 인바운드 규칙에서 애플리케이션에 필요한 IP 주소가 AWS에 연결하도록 허용하는지 확인합니다. IP 주소의 범위(예: `203.0.113.0/24`) 또는 다른 VPC 보안 그룹을 지정할 수 있습니다. [Amazon VPC 콘솔](https://console.aws.amazon.com/vpc)을 사용하여 VPC, 서브넷 및 보안 그룹을 만들고 관리할 수 있습니다. 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [Getting started with Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started)를 참조하세요.
1. [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2)을 열고 Amazon EC2 인스턴스와 Amazon RDS 데이터베이스를 모두 포함하는 AWS 리전을 선택합니다. 1단계에서 만든 VPC, 서브넷 및 보안 그룹을 사용하여 Amazon EC2 인스턴스를 시작합니다. 데이터베이스 백업 파일이 압축되어 있지 않을 때는 이 파일을 위한 충분한 스토리지 공간을 가진 인스턴스 유형을 선택해야 합니다. Amazon EC2 인스턴스에 관한 세부 정보는 *Amazon Elastic Compute Cloud 사용 설명서*의 [Getting started with Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)를 참조하세요.
1. Amazon EC2 인스턴스에서 Amazon RDS 데이터베이스로 연결하려면 VPC 보안 그룹을 편집하세요. EC2 인스턴스의 프라이빗 IP 주소를 지정하는 인바운드 규칙을 추가합니다. EC2 콘솔 창에 있는 **인스턴스** 창의 **세부 정보** 탭에서 프라이빗 IP 주소를 찾을 수 있습니다. VPC 보안 그룹을 편집하고 인바운드 규칙을 추가하려면 EC2 콘솔 탐색 창에서 **보안 그룹(Security Groups)**를 선택하고 보안 그룹을 선택한 다음 EC2 인스턴스의 프라이빗 IP 주소를 지정하는 MySQL 또는 Aurora에 대한 인바운드 규칙을 추가합니다. 인바운드 규칙을 VPC 보안 그룹에 추가하는 방법을 알아보려면 *Amazon Virtual Private Cloud 사용 설명서*의 [Security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)를 참조하세요.
1. 로컬 시스템에서 Amazon EC2 인스턴스로 압축된 데이터베이스 백업 파일을 복사합니다. 필요한 경우 `chmod`를 사용하여 Amazon EC2 인스턴스의 대상 디렉터리에 대해 쓰기 권한이 있는지 확인하세요. `scp` 또는 Secure Shell(SSH) 클라이언트를 사용하여 파일을 복사할 수 있습니다. 다음은 예제 `scp` 명령입니다.
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**중요**
민감한 데이터는 반드시 보안 네트워크 전송 프로토콜을 사용하여 복사해야 합니다.
1. Amazon EC2 인스턴스에 연결하고 다음 명령을 사용하여 최신 업데이트와 MySQL 클라이언트 도구를 설치합니다.
```
sudo yum update -y
sudo yum install mysql -y
```
자세한 내용은 *Amazon Elastic Compute Cloud 사용 설명서*의 [Connect to your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)를 참조하세요.
**중요**
이 예제에서는 Amazon Linux AMI 배포의 Amazon Machine Image(AMI)에 MySQL 클라이언트를 설치합니다. 이 예제에서는 Ubuntu 또는 Red Hat Enterprise Linux 등 다른 배포에 MySQL 클라이언트를 설치하지 않습니다. MySQL 설치에 대한 자세한 내용은 MySQL 설명서의 [Installing MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html)을 참조하세요.
1. Amazon EC2 인스턴스에 연결되어 있는 상태에서 데이터베이스 백업 파일의 압축을 풉니다. 다음 명령은 예시입니다.
+ SQL 출력을 압축 해제하려면 다음 명령을 사용합니다.
```
gzip backup.sql.gz -d
```
+ 구분 기호로 분리된 텍스트 출력을 압축 해제하려면 다음 명령을 사용합니다.
```
tar xzvf backup.tar.gz
```
## 작업 3: MySQL 데이터베이스 만들기 및 Amazon EC2 인스턴스에서 데이터 가져오기
Amazon EC2 인스턴스와 같은 AWS 리전에 RDS for MySQL DB 인스턴스 또는 RDS for MySQL 다중 AZ DB 클러스터를 만들면 인터넷에서 가져오는 것보다 빠른 속도로 Amazon EC2에서 데이터베이스 백업 파일을 가져올 수 있습니다.
다음 다이어그램은 Amazon EC2 인스턴스에서 MySQL 데이터베이스로 백업을 가져오는 것을 보여줍니다.
![\[EC2 인스턴스에서 MySQL 데이터베이스로 백업을 가져오는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png)
### MySQL 데이터베이스를 만들고 데이터 가져오기
1. 이 Amazon RDS 데이터베이스에 대해 예상되는 워크로드를 지원하기 위해 필요한 DB 인스턴스 클래스와 스토리지 공간의 양을 결정합니다. 이 프로세스의 일환으로 데이터 로드 절차를 위해 충분한 공간과 처리 용량이 어느 정도인지 결정합니다. 또한 프로덕션 워크로드를 처리하는 데 필요한 사항을 결정합니다. 원본 MySQL 데이터베이스의 크기와 리소스를 바탕으로 평가할 수 있습니다. 자세한 내용은 [DB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요.
1. Amazon EC2 인스턴스가 포함된 AWS 리전에서 DB 인스턴스 또는 다중 AZ DB 클러스터를 만듭니다.
RDS for MySQL 다중 AZ DB 클러스터를 만들려면 [Amazon RDS용 다중 AZ DB 클러스터 생성](create-multi-az-db-cluster.md) 섹션의 지침을 따르세요.
RDS for MySQL DB 인스턴스를 생성하려면 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md)의 지침과 다음 지침을 따르세요.
+ 소스 DB 인스턴스와 호환되는 DB 엔진 버전을 지정합니다.
+ Amazon EC2 인스턴스에서와 동일한 Virtual Private Cloud(VPC) 및 VPC 보안 그룹을 지정합니다. 이 접근 방식에서는 Amazon EC2 인스턴스와 Amazon RDS 인스턴스가 네트워크를 통해 서로를 볼 수 있습니다. DB 인스턴스가 공개적으로 액세스 가능한지 확인합니다. 다음 섹션에 설명한 대로 소스 데이터베이스를 사용하여 복제를 설정하려면 DB 인스턴스에 공개적으로 액세스할 수 있어야 합니다.
+ 데이터베이스 백업을 가져온 후에만 여러 가용 영역, 백업 보존 또는 읽기 전용 복제본을 구성해야 합니다 가져오기가 완료되면 프로덕션 인스턴스에 대해 다중 AZ 및 백업 보존을 설정할 수 있습니다.
1. Amazon RDS 데이터베이스에 대한 기본 구성 옵션을 검토합니다. 데이터베이스에 대한 기본 파라미터 그룹에 원하는 구성 옵션이 없는 경우, 원하는 구성 옵션이 있는 다른 파라미터 그룹을 찾거나 새 파라미터 그룹을 생성합니다. 파라미터 그룹을 생성하는 것에 대한 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요.
1. 마스터 사용자로 Amazon RDS 데이터베이스에 연결합니다. DB 인스턴스에 액세스해야 하는 서비스, 애플리케이션 및 관리자를 지원하는 데 필요한 사용자를 만듭니다. Amazon RDS 데이터베이스의 호스트 이름은 포트 번호를 포함하지 않은 DB 인스턴스의 **엔드포인트** 값입니다(예: `mysampledb.123456789012.us-west-2.rds.amazonaws.com`). Amazon RDS 콘솔의 데이터베이스 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.
1. Amazon EC2 인스턴스에 연결합니다. 자세한 내용은 *Amazon Elastic Compute Cloud 사용 설명서*의 [Connect to your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)를 참조하세요.
1. `mysql` 명령을 사용하여 Amazon EC2 인스턴스에서 원격 호스트로 Amazon RDS 데이터베이스에 연결합니다. 다음 명령은 예제입니다.
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name*은 Amazon RDS 데이터베이스 엔드포인트입니다.
1. `mysql` 프롬프트에서 `source` 명령을 실행하고 데이터베이스 덤프 파일의 이름을 전달합니다. 이 명령은 데이터를 Amazon RDS DB 인스턴스로 로드합니다.
+ SQL 형식인 경우 다음 명령을 사용합니다.
```
mysql> source backup.sql;
```
+ 구분 기호로 분리된 텍스트 형식의 경우 Amazon RDS 데이터베이스를 설정할 때 만든 기본 데이터베이스가 아니라면 먼저 데이터베이스를 만듭니다.
```
mysql> create database database_name;
mysql> use database_name;
```
그런 다음, 테이블을 생성합니다.
```
mysql> source table1.sql
mysql> source table2.sql
etc...
```
그런 다음, 데이터를 가져옵니다.
```
mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
mysql> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
성능을 개선하려면 여러 연결에서 이들 작업을 병렬로 수행하여 모든 테이블이 만들어진 다음에 동시에 로드되도록 할 수 있습니다.
**참고**
처음에 테이블을 덤프할 때 `mysqldump`와 함께 데이터 서식 옵션을 사용했다면, `LOAD DATA LOCAL INFILE`과 같은 옵션을 사용하여 데이터 파일 내용을 올바로 해석해야 합니다.
1. 가져온 데이터베이스에 있는 테이블 중 1개 또는 2개에 대해 간단한 `SELECT` 쿼리를 실행하여 가져오기에 성공했는지 확인합니다.
이 절차에 사용되는 Amazon EC2 인스턴스가 더 이상 필요하지 않은 경우 EC2 인스턴스를 종료하여 AWS 리소스 사용량을 줄여야 합니다. EC2 인스턴스를 종료하려면 *Amazon Elastic Compute Cloud 사용 설명서*의 [Terminate an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)를 참조하세요.
## 작업 4: 외부 데이터베이스에서 새 Amazon RDS 데이터베이스로 데이터 복제
MySQL 데이터베이스로 데이터를 복사하고 전송하는 데 걸린 시간 중에 원본 데이터베이스가 업데이트되었을 것입니다. 따라서 복제를 사용하여 복사된 데이터베이스를 원본 데이터베이스에 맞춰 최신 상태로 업데이트합니다.
![\[외부 MySQL 데이터베이스에서 Amazon RDS의 데이터베이스로 데이터를 복제하는 것을 보여주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_5.png)
Amazon RDS 데이터베이스에서 복제를 시작하는 데 필요한 권한은 제한되고 Amazon RDS 마스터 사용자는 사용할 수 없습니다. 따라서 메이저 엔진 버전에 적합한 다음의 Amazon RDS 저장 프로시저를 사용합니다.
+ [mysql\$1rds\$1set\$1external\$1master(RDS for MySQL 메이저 버전 8.0 이하)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source(RDS for MySQL 메이저 버전 8.4 이상)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
+ 복제를 구성하려면 [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md), 복제를 시작하려면 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)
### 복제를 시작하려면
작업 1에서 [복제 옵션을 설정](#mysql-importing-data-reduced-downtime-set-replication-options)할 때 이진 로깅을 활성화하고 소스 데이터베이스의 고유한 서버 ID를 설정합니다. 이제 라이브 데이터베이스를 소스 복제 인스턴스로 포함하고 있는 복제본으로서 Amazon RDS 데이터베이스를 설정할 수 있습니다.
1. Amazon RDS 콘솔에서 Amazon RDS 데이터베이스에 대한 VPC 보안 그룹에 원본 데이터베이스를 호스팅하는 서버의 IP 주소를 추가합니다. VPC 보안 그룹 구성에 관한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [Configure security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)를 참조하세요.
원본 인스턴스와 통신할 수 있도록, Amazon RDS 데이터베이스 IP 주소에서의 연결을 허용하도록 로컬 네트워크를 구성해야 할 수도 있습니다. Amazon RDS 데이터베이스의 IP 주소를 확인하려면 `host` 명령을 사용합니다.
```
host host_name
```
*host\$1name*은 Amazon RDS 데이터베이스 엔드포인트의 DNS 이름입니다(예: `myinstance.123456789012.us-east-1.rds.amazonaws.com`). Amazon RDS 콘솔의 인스턴스 세부 정보에서 엔드포인트 값을 찾을 수 있습니다.
1. 선택한 클라이언트를 사용하여 원본 인스턴스에 연결하고 복제에 사용될 사용자를 만듭니다. 이 계정은 오직 복제용으로만 사용되며 보안 향상을 위해 사용자의 도메인으로 제한되어야 합니다. 다음 명령은 예제입니다.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 보안 인증 정보를 지정하는 것이 좋습니다.
1. 원본 인스턴스의 경우 복제 사용자에게 `REPLICATION CLIENT` 및 `REPLICATION SLAVE` 권한을 부여합니다. 예를 들어 도메인의 '`REPLICATION CLIENT`' 사용자를 위해 모든 데이터베이스에서 `REPLICATION SLAVE` 및 `repl_user` 권한을 부여하려면 다음 명령을 실행합니다.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Amazon RDS 데이터베이스를 복제본으로 만듭니다. 마스터 사용자로 Amazon RDS 데이터베이스에 연결하고 적절한 Amazon RDS 저장 프로시저를 사용하여 소스 데이터베이스를 소스 복제 인스턴스로 식별합니다.
+ [mysql\$1rds\$1set\$1external\$1master(RDS for MySQL 메이저 버전 8.0 이하)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source(RDS for MySQL 메이저 버전 8.4 이상)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
SQL 형식 백업 파일이 있는 경우 4단계에서 확인한 마스터 로그 파일 이름과 마스터 로그 위치를 사용합니다. 구분 기호로 분리된 텍스트 형식을 사용한 경우 백업 파일을 만들 때 확인한 이름과 위치를 사용합니다. 다음 명령은 예시입니다.
**MySQL 8.4 이상 버전**
```
CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MySQL 8.0 이하 버전**
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 보안 인증 정보를 지정하는 것이 좋습니다.
1. Amazon RDS 데이터베이스에서 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 저장 프로시저를 사용하는 다음 명령을 실행하여 복제를 시작합니다.
```
CALL mysql.rds_start_replication;
```
1. Amazon RDS 데이터베이스에서 [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) 명령을 실행하여 복제본이 소스 복제 인스턴스에 맞게 최신 상태가 되는 시점을 파악합니다. `SHOW REPLICA STATUS` 명령의 결과에는 `Seconds_Behind_Master` 필드가 포함됩니다. `Seconds_Behind_Master` 필드가 0을 반환하면 복제본이 소스 복제 인스턴스에 맞게 최신 상태인 것입니다.
**참고**
이전 버전의 MySQL에는 `SHOW SLAVE STATUS` 대신 `SHOW REPLICA STATUS`가 사용되었습니다. 8.0.23 이전 MySQL 버전을 사용하는 경우 `SHOW SLAVE STATUS`를 사용합니다.
1. Amazon RDS 데이터베이스가 최신 상태로 업데이트된 후, 필요할 경우 그 데이터베이스를 복원할 수 있도록 자동 백업을 켭니다. [Amazon RDS 콘솔](https://console.aws.amazon.com/rds/)을 사용하여 Amazon RDS 데이터베이스에 대한 자동 백업을 켜거나 수정할 수 있습니다. 자세한 내용은 [백업 소개](USER_WorkingWithAutomatedBackups.md) 섹션을 참조하세요.
## 작업 5: 라이브 애플리케이션을 Amazon RDS 인스턴스로 리디렉션
MySQL 데이터베이스가 소스 복제 인스턴스에 맞게 최신 상태로 업데이트되면 라이브 애플리케이션을 업데이트하여 Amazon RDS 인스턴스를 사용할 수 있습니다.
![\[복제를 중지하고 라이브 애플리케이션을 Amazon RDS 데이터베이스로 리디렉션하는 것을 보여주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_6.png)
### 라이브 애플리케이션을 MySQL 데이터베이스로 리디렉션하고 복제 중지
1. Amazon RDS 데이터베이스에 대한 VPC 보안 그룹을 추가하려면 애플리케이션을 호스팅하는 서버의 IP 주소를 추가합니다. VPC 보안 그룹 수정에 대한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [Configure security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)를 참조하세요.
1. [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) 명령 결과에서 `Seconds_Behind_Master` 필드가 0인지 확인합니다. 이는 복제본이 소스 복제 인스턴스에 맞게 최신 상태라는 의미입니다.
```
SHOW REPLICA STATUS;
```
**참고**
이전 버전의 MySQL에는 `SHOW SLAVE STATUS` 대신 `SHOW REPLICA STATUS`가 사용되었습니다. 8.0.23 이전 MySQL 버전을 사용하는 경우 `SHOW SLAVE STATUS`를 사용합니다.
1. 트랜잭션이 완료되면 소스에 대한 모든 연결을 닫습니다.
1. Amazon RDS 데이터베이스를 사용할 수 있도록 애플리케이션을 업데이트합니다. 이 업데이트에는 일반적으로 Amazon RDS 데이터베이스의 호스트 이름과 포트, 연결할 사용자 계정과 암호, 사용할 데이터베이스를 식별하기 위해 연결 설정을 변경하는 과정이 포함됩니다.
1. DB 인스턴스에 연결합니다.
다중 AZ DB 클러스터의 경우에는 라이터 DB 인스턴스에 연결합니다.
1. [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 저장된 프로시저를 사용하는 다음 명령을 실행하여 Amazon RDS 인스턴스에 대한 복제를 중지합니다.
```
CALL mysql.rds_stop_replication;
```
1. Amazon RDS 데이터베이스에서 적절한 Amazon RDS 저장 프로시저를 사용하여 이 인스턴스가 더 이상 복제본으로 식별되지 않도록 복제 구성을 재설정합니다.
+ [mysql\$1rds\$1reset\$1external\$1master(RDS for MySQL 메이저 버전 8.0 이하)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source(RDS for MySQL 메이저 버전 8.4 이상)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source)
**MySQL 8.4 이상 버전**
```
CALL mysql.rds_reset_external_source;
```
**MySQL 8.0 이하 버전**
```
CALL mysql.rds_reset_external_master;
```
1. 다중 AZ 지원 및 읽기 전용 복제본과 같은 Amazon RDS 기능을 추가로 활성화합니다. 자세한 내용은 [Amazon RDS에 대한 다중 AZ 배포 구성 및 관리](Concepts.MultiAZ.md) 및 [DB 인스턴스 읽기 전용 복제본 작업](USER_ReadRepl.md) 섹션을 참조하세요.
# 원하는 소스에서 Amazon RDS for MySQL DB 인스턴스로 데이터 가져오기
Amazon RDS를 사용하면 기존 MySQL 데이터를 모든 소스에서 RDS for MySQL DB 인스턴스로 마이그레이션할 수 있습니다. 온프레미스 데이터베이스, 기타 클라우드 공급자 또는 기존 RDS for MySQL DB 인스턴스에서 대상 RDS for MySQL DB 인스턴스로 데이터를 전송할 수 있습니다. 이 기능을 사용하면 데이터베이스를 통합하거나, 재해 복구 솔루션을 구현하거나, 자체 관리형 데이터베이스에서 전환할 수 있습니다. 일반적인 시나리오로는 자체 호스팅 MySQL 서버에서 완전 관리형 Amazon RDS DB 인스턴스로 이동하거나, 여러 MySQL 데이터베이스를 단일 DB 인스턴스로 통합하거나, 프로덕션 데이터를 사용하여 테스트 환경을 생성하는 것이 있습니다. 다음 섹션에서는 `mysqldump`, 백업 파일 또는 복제와 같은 방법을 사용하여 MySQL 데이터를 가져오기 위한 단계별 지침을 제공합니다.
## 1단계: 로드할 데이터를 포함한 플랫 파일 만들기
쉼표로 구분된 값(CSV)과 같은 일반적인 형식을 사용하여 로드할 데이터를 저장합니다. 각 테이블에는 자체 파일이 있어야 하며, 여러 테이블에 대한 데이터를 같은 파일에 결합할 수 없습니다. 각 파일의 이름은 그에 상응하는 테이블과 같은 이름으로 지정합니다. 파일 확장명은 원하는 대로 정할 수 있습니다. 예를 들어, 테이블 이름이 `sales`인 경우 파일 이름은 `sales.csv` 또는 `sales.txt`일 수 있습니다.
가능하면 로드되는 테이블의 프라이머리 키를 기준으로 데이터를 정렬하세요. 그러면 로드 시간이 대폭 단축되고 데이터 스토리지 요구 사항이 최소화됩니다.
이 절차의 수행 속도와 효율성은 파일의 크기를 작게 유지하느냐에 좌우됩니다. 개별 파일의 압축되지 않은 크기가 1GiB보다 큰 경우에는 파일을 여러 개의 파일로 분할하고 각각 하나씩 따로 로드합니다.
Unix와 같은 시스템(Linux 포함)에서는 `split` 명령을 사용합니다. 예를 들어 다음 명령을 실행하면 `sales.csv` 파일이 1GiB 미만의 여러 파일로 분할되며, 줄 바꿈에서만 분할됩니다(-C 1024m). 새 파일의 이름에는 오름차순 숫자 접미사가 포함됩니다. 다음 명령은 `sales.part_00` 및 `sales.part_01`과 같은 이름의 파일을 생성합니다.
```
split -C 1024m -d sales.csv sales.part_
```
다른 운영 체제에서는 이와 유사한 유틸리티를 사용할 수 있습니다.
플랫 파일은 어디에나 저장할 수 있습니다. 그러나 [5단계](#mysql-importing-data-any-source-load-data)에서 데이터를 로드할 때는 파일이 있는 위치와 동일한 위치에서 `mysql` 쉘을 간접적으로 호출하거나 `LOAD DATA LOCAL INFILE`을 실행할 때 파일의 절대 경로를 사용해야 합니다.
## 2단계: 대상 DB 인스턴스에 액세스 중인 애플리케이션을 모두 중지
대량 로드를 시작하기 전에 로드하려는 대상 DB 인스턴스에 액세스하는 모든 애플리케이션의 활동을 중단합니다. 로드 중인 테이블 혹은 참조 테이블을 다른 세션이 수정하는 경우에는 더욱 더 중단해야 합니다. 그러면 로드 중에 발생하는 제약 조건 위반의 위험이 줄어들고 로드 성능이 향상됩니다. 또한 로드에 관여하지 않는 프로세스에 의한 변경 내용이 손실되지 않고 로드 직전의 시점으로 DB 인스턴스를 복원할 수 있습니다.
물론, 이것이 가능하지 않거나 유용하지 않을 수도 있습니다. 로드 전에 애플리케이션이 DB 인스턴스에 액세스하지 못하게 막을 수 없다면, 데이터의 가용성과 무결성을 보장하기 위한 일련의 단계를 수행하세요. 필요한 구체적인 단계는 특정 사용 사례와 사이트 요구 사항에 따라 크게 달라집니다.
## 3단계: DB 스냅샷 만들기
아무런 데이터도 없는 새 DB 인스턴스로 데이터를 로드할 경우에는 이 단계를 건너뛰어도 됩니다. 아니면 데이터 로드 전후에 대상 Amazon RDS DB 인스턴스의 DB 스냅샷을 만드는 것이 좋습니다. Amazon RDS DB 스냅샷은 DB 인스턴스를 알려진 상태로 복원하는 데 사용할 수 있는 DB 인스턴스의 완전한 백업입니다. DB 스냅샷을 시작하면 데이터베이스가 백업되는 동안 DB 인스턴스에 대한 I/O 작업이 일시 중단됩니다.
필요한 경우 로드 직전에 DB 스냅샷을 만들면 데이터베이스를 로드 이전의 상태로 복원할 수 있습니다. 로드 직후에 생성된 DB 스냅샷은 사고 발생 시 데이터를 다시 로드하지 않아도 됩니다. 또한 로드 후 DB 스냅샷을 사용하여 데이터를 새 데이터베이스 인스턴스로 가져올 수 있습니다.
아래 예시에서는 AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) 명령을 실행하여 `AcmeRDS` 인스턴스의 DB 스냅샷을 만들고 DB 스냅샷에 `"preload"` 식별자를 지정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows의 경우:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
DB 스냅샷 기능에서 복원하는 기능을 사용하여 테스트 실행을 위한 테스트 DB 인스턴스를 만들거나 로드 중의 변경 사항을 실행 취소할 수도 있습니다.
DB 스냅샷에서 데이터베이스를 복원하면 모든 DB 인스턴스와 마찬가지로 고유 식별자와 엔드포인트가 있는 새 DB 인스턴스가 생성된다는 점을 꼭 명심해야 합니다. 엔드포인트를 변경하지 않고 DB 인스턴스를 복원해야 한다면, 우선 엔드포인트를 다시 사용할 수 있도록 DB 인스턴스를 삭제해야 합니다.
예를 들어 테스트 실행 또는 다른 테스트를 위한 DB 인스턴스를 만들려면 DB 인스턴스에 고유 식별자를 지정합니다. 예제에서 `AcmeRDS-2`"는 식별자입니다. 이 예제는 `AcmeRDS-2`와 연결된 엔드포인트를 사용하여 DB 인스턴스에 연결합니다. 자세한 정보는 [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)을 참조하세요.
대상 LinuxmacOS, 또는Unix:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Windows의 경우:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
기존 엔드포인트를 재사용하려면 우선 DB 인스턴스를 삭제한 다음, 복원된 데이터베이스에 같은 식별자를 지정해야 합니다. 자세한 내용은 [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html)를 참조하세요.
다음 예제에서는 또한 DB 인스턴스의 최종 DB 스냅샷을 생성한 후에 삭제합니다. 이 단계는 선택 사항이지만 권장됩니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows의 경우:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## 4단계(선택 사항): Amazon RDS 자동 백업 끄기
**주의**
시점 복구를 수행할 필요가 있는 경우에는 자동 백업을 끄지 마세요.
자동 백업을 끄는 것은 성능 최적화 수단이며 데이터 로드에 필수적이지는 않습니다. 자동 백업을 끄면 기존 백업이 모두 지워집니다. 따라서 자동 백업을 끈 후에는 시점 복구를 수행할 수 없습니다. 자동 백업을 비활성화해도 수동 DB 스냅샷에는 영향을 주지 않습니다. 기존의 모든 수동 DB 스냅샷을 계속 복원 작업에 사용할 수 있습니다.
자동 백업을 비활성화하면 로드 시간이 약 25% 단축되고 로드 중에 필요한 스토리지 공간의 양이 줄어듭니다. 아무런 데이터도 없는 새 DB 인스턴스로 데이터를 로드할 경우에는 백업을 비활성화하는 것이 로드 속도를 높이고 백업에 필요한 추가 스토리지의 사용을 피하는 손쉬운 방법입니다. 하지만 이미 데이터가 있는 DB 인스턴스로 로드할 경우도 있습니다. 그렇다면 특정 시점으로 복구를 수행할 능력을 상실하는 데 따른 영향에 비해 백업을 해제할 때의 이점을 비교합니다.
DB 인스턴스에서는 기본적으로 자동 백업이 활성화되어 있습니다(보존 기간은 하루). 자동 백업을 비활성화하기 위해 백업 보존 기간을 0으로 설정합니다. 로드 후에는 백업 보존 기간을 0이 아닌 값으로 설정하여 백업을 다시 활성화할 수 있습니다. 백업을 켜거나 끄기 위해 Amazon RDS가 DB 인스턴스를 종료했다가 다시 시작하여 MySQL 로깅을 켜거나 끕니다.
AWS CLI `modify-db-instance` 명령을 실행하여 백업 보존 기간을 0으로 설정하고 변경 사항을 즉시 적용합니다. 보존 기간을 0으로 설정하려면 DB 인스턴스를 다시 시작해야 하므로, 다시 시작 프로세스가 완료될 때까지 기다린 후 계속 진행합니다. 자세한 내용은 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 참조하세요.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) 명령으로 DB 인스턴스의 상태를 확인할 수 있습니다. 다음 예제에서는 `AcmeRDS` DB 인스턴스의 DB 인스턴스 상태를 표시합니다.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
DB 인스턴스 상태가 `available`이면 다음 단계로 계속할 준비가 된 것입니다.
## 5단계: 데이터 로드
플랫 파일의 행을 데이터베이스 테이블로 읽어들이려면 MySQL `LOAD DATA LOCAL INFILE` 문을 사용합니다.
**참고**
플랫 파일이 있는 위치와 동일한 위치에서 `mysql` 쉘을 호출하거나 `LOAD DATA LOCAL INFILE`을 실행할 때 파일의 절대 경로를 사용해야 합니다.
다음 예시는 이름이 `sales.txt`인 파일에서 데이터베이스의 `Sales` 테이블로 데이터를 로드하는 방법을 보여줍니다.
```
mysql> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
`LOAD DATA` 문에 대한 자세한 내용은 MySQL 설명서의 [LOAD DATA Statement](https://dev.mysql.com/doc/refman/8.4/en/load-data.html)를 참조하세요.
## 6단계: Amazon RDS 자동 백업 다시 켜기
[4단계](#mysql-importing-data-any-source-turn-off-automated-backups)에서 Amazon RDS 자동 백업을 껐다면 로드가 완료된 후 백업 보존 기간을 로드 이전의 값으로 다시 설정하여 자동 백업을 켭니다. 4단계에서 언급한 것처럼, Amazon RDS가 DB 인스턴스를 다시 시작하므로 잠시 작동이 중단되는 상황에 대비하세요.
다음 예시에서는 AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 명령을 실행하여 `AcmeRDS` DB 인스턴스에서 자동 백업을 켜고 보존 기간을 1일로 설정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```