# Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기
RDS for MariaDB DB 인스턴스로 데이터를 가져오는 기법에는 몇 가지가 있습니다. 가장 좋은 방법은 다음과 같은 여러 요인에 따라 달라집니다.
+ 데이터 원본
+ 데이터 분량
+ 일회성 혹은 지속적
+ 가동 중지 시간 길이
데이터와 함께 애플리케이션을 마이그레이션하는 경우라면 감당할 수 있는 가동 중지 시간도 고려해야 합니다.
다음 표에는 RDS for MariaDB DB 인스턴스로 데이터를 가져오는 기법이 나와 있습니다.
**참고**
Amazon RDS는 `mariadb-backup` 또는 Amazon S3 for MariaDB에서 가져오기를 지원하지 않습니다.
| 소스 | 데이터 분량 | 일회성 혹은 지속적 | 애플리케이션 가동 중지 | 기술 | 추가 정보 |
| --- | --- | --- | --- | --- | --- |
| 온프레미스 또는 Amazon EC2에 있는 기존 MariaDB 데이터베이스 | 임의 | 지속적 | 최소화 | 기존 MariaDB 데이터베이스가 복제 소스가 되도록 복제본을 구성합니다. 외부 인스턴스가 MariaDB 버전 10.0.24 이상인 경우 MariaDB 글로벌 트랜잭션 식별자(GTID)를 사용하거나 10.0.24 이전 버전의 MariaDB 인스턴스인 경우 바이너리 로그 좌표를 사용하여 MariaDB DB 인스턴스로의 복제를 구성할 수 있습니다. MariaDB GTID는 MySQL GTID와 다르게 구현되며, MySQL GTID는 Amazon RDS에서 지원되지 않습니다. | [외부 소스 인스턴스를 사용하여 이진 로그 파일 위치 복제 구성](MySQL.Procedural.Importing.External.ReplMariaDB.md) [가동 중지 시간을 줄이면서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기](mariadb-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) |
| 기존 MariaDB DB 인스턴스 | 임의 | 일회성 혹은 지속적 | 최소화 | 지속적인 복제를 위한 읽기 전용 복제본을 생성합니다. 새 DB 인스턴스를 한 번만 생성하도록 읽기 전용 복제본을 승격시킵니다. | [DB 인스턴스 읽기 전용 복제본 작업](USER_ReadRepl.md) |
| 기존 MariaDB 데이터베이스 | 스몰 | 한 번만 | 약간 | 명령줄 유틸리티를 사용하여 MariaDB DB 인스턴스에 바로 데이터를 복제합니다. | [외부 MariaDB 데이터베이스에서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기](mariadb-importing-data-external-database.md) |
| 기존 데이터베이스에 저장되지 않은 데이터 | Medium | 한 번만 | 약간 | 플랫 파일을 만들고 MariaDB `LOAD DATA LOCAL INFILE` 문을 이용하여 가져옵니다. | [원하는 소스에서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기](mariadb-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 인스턴스를 스냅샷에서 복원할 수 있습니다. [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 인스턴스를 복구할 수 있습니다.
# MariaDB에 대한 데이터 가져오기 고려 사항
다음 내용에는 MariaDB로 데이터를 로드하는 것과 관련된 기술 정보가 포함되어 있습니다. 이 콘텐츠는 MariaDB 서버 아키텍처에 익숙한 사용자를 대상으로 합니다.
## 이진 로깅
이진 로깅을 활성화하면 로깅을 비활성화했을 때와 비교해 데이터 로드 성능이 저하되고 최대 4배의 추가 디스크 공간이 필요합니다. 데이터를 로드하는 데 사용되는 트랜잭션 크기는 시스템 성능 및 디스크 공간 요구 사항에 직접적인 영향을 미칩니다. 트랜잭션이 클수록 더 많은 리소스가 필요합니다.
## 트랜잭션 크기
트랜잭션 크기는 MariaDB 데이터 로드의 다음 측면에 영향을 미칩니다.
+ 리소스 소비
+ 디스크 공간 사용률
+ 프로세스 재개
+ 복구 시간
+ 입력 형식(플랫 파일 또는 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`을 사용하여 데이터를 로드하는 경우 데이터 복구는 로드 전에 수행된 백업에서 데이터베이스를 복구해야 하는 경우를 대비하여 네 번째 복사본을 만듭니다. 복원 중에 MariaDB가 이진 로그에서 플랫 파일로 데이터를 추출합니다. 그런 다음 MariaDB는 `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)를 지원하는 로깅 메커니즘입니다.
MariaDB 10.11 이하 버전의 경우 실행 취소 로그는 InnoDB 시스템 테이블스페이스(일반적으로 ibdata1)에 저장되며 제거 스레드가 로그를 제거할 때까지 유지됩니다. 따라서 대규모 데이터 로드 트랜잭션은 시스템 테이블스페이스가 상당히 커지는 원인이 될 수 있고, 이때 사용되는 디스크 공간은 데이터베이스를 다시 만들어야 회수할 수 있습니다.
모든 MariaDB 버전에서 제거 스레드는 가장 오래된 활성 트랜잭션이 커밋되거나 롤백될 때까지 실행 취소 로그를 제거할 수 없습니다. 데이터베이스가 로드 중에 다른 트랜잭션을 처리 중인 경우, 이들 트랜잭션의 실행 취소 로그 역시 누적되며 트랜잭션이 커밋되고 MVCC에 대해 실행 취소 로그가 필요한 다른 트랜잭션이 없더라도 실행 취소 로그를 제거할 수 없습니다. 이 경우 읽기 전용 트랜잭션을 포함한 모든 트랜잭션이 느려집니다. 이 속도 저하는 로드 트랜잭션뿐만 아니라 모든 트랜잭션이 변경하는 모든 행에 모든 트랜잭션이 액세스하기 때문에 발생합니다. 실제로 트랜잭션은 장기 실행 로드 트랜잭션으로 인해 실행 취소 로그 정리 중에 제거되지 않는 실행 취소 로그를 검사해야 합니다. 이는 수정된 행에 액세스하는 모든 작업의 성능에 영향을 줍니다.
### InnoDB 트랜잭션 복구 옵션
InnoDB는 커밋 작업을 최적화하지만 대규모 트랜잭션 롤백은 느립니다. 더 빠른 복구를 위해 시점 복구를 수행하거나 DB 스냅샷을 복원합니다. 자세한 내용은 [시점 복구](USER_PIT.md) 및 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md)(을)를 참조하세요.
## 데이터 가져오기 형식
MariaDB는 플랫 파일과 SQL이라는 두 가지 데이터 가져오기 형식을 지원합니다. 각 형식에 대한 정보를 검토하여 요구 사항에 가장 적합한 옵션을 결정합니다.
### 플랫 파일
소규모 트랜잭션의 경우 `LOAD DATA LOCAL INFILE`을 사용하여 플랫 파일을 로드합니다. 이 데이터 가져오기 형식은 SQL 사용에 비해 다음과 같은 이점을 제공할 수 있습니다.
+ 더 낮은 네트워크 트래픽
+ 데이터 전송 비용 절감
+ 데이터베이스 처리 오버헤드 감소
+ 더 빠른 처리
`LOAD DATA LOCAL INFILE`은 전체 플랫 파일을 하나의 트랜잭션으로 로드합니다. 다음과 같은 이점을 위해 개별 파일의 크기를 작게 유지합니다.
+ **재개 기능** – 로드된 파일을 추적할 수 있습니다. 로드 중에 문제가 발생하면 중단된 부분부터 다시 시작할 수 있습니다. 일부 데이터를 Amazon RDS로 다시 전송해야 할 수도 있지만, 파일이 작으면 재전송되는 양이 최소화됩니다.
+ **병렬 데이터 로드** - 단일 파일 로드에 충분한 IOPS와 네트워크 대역폭이 있는 경우 병렬로 로드하면 시간이 절약될 수 있습니다.
+ **로드 속도 제어** - 데이터 로드가 다른 프로세스에 부정적인 영향을 미치는 경우 파일 간 간격을 늘려 로드 속도를 제어할 수 있습니다.
대규모 트랜잭션은 `LOAD DATA LOCAL INFILE`을 사용하여 데이터를 가져올 때의 이점을 줄입니다. 대량의 데이터를 더 작은 파일로 나눌 수 없는 경우 SQL을 사용하는 것을 고려하세요.
### SQL
SQL은 플랫 파일에 비해 한 가지 중요한 장점이 있는데, 그것은 바로 트랜잭션 크기를 작게 유지하기 쉽다는 점입니다. 그러나 SQL은 플랫 파일보다 로드하는 데 훨씬 더 오래 걸릴 수 있습니다. 또한 장애 발생 후 재개 위치를 결정하기 어려울 수 있으며, mariadb-dump 파일을 다시 시작할 수 없습니다. mariadb-dump 파일을 로드하는 동안 오류가 발생하는 경우 이 파일을 수정하거나 바꾸어야 로드를 재개할 수 있습니다. 또는 장애의 원인을 수정한 후 파일을 로드하고 재전송하기 전의 특정 시점으로 복원할 수 있습니다. 자세한 내용은 [시점 복구](USER_PIT.md) 섹션을 참조하세요.
## 데이터베이스 체크포인트에 Amazon RDS DB 스냅샷 사용
이진 로깅 없이 몇 시간 또는 며칠 등의 긴 기간 동안 데이터를 로드하는 경우 DB 스냅샷을 사용하여 데이터 안전을 위한 주기적 체크포인트를 제공하세요. 각 DB 스냅샷은 시스템 장애 또는 데이터 손상 이벤트 중에 복구 시점 역할을 하는 데이터베이스 인스턴스의 일관된 사본을 만듭니다. DB 스냅샷은 빠르기 때문에 체크포인트를 자주 제공해도 로드 성능에 미치는 영향이 최소화됩니다. 데이터베이스 내구성이나 복구 기능에 영향을 주지 않고 이전 DB 스냅샷을 삭제할 수 있습니다. DB 스냅샷에 대한 자세한 내용은 [수동 백업 관리](USER_ManagingManualBackups.md) 섹션을 참조하세요.
## 데이터베이스 로드 시간 단축
다음 항목은 로드 시간을 줄이기 위한 추가 팁입니다.
+ MariaDB 데이터베이스로 데이터를 로드하기 전에 모든 보조 인덱스를 만듭니다. 다른 데이터베이스 시스템과 달리 MariaDB는 보조 인덱스를 추가하거나 수정할 때 전체 테이블을 다시 빌드합니다. 이 프로세스는 인덱스 변경 사항이 있는 새 테이블을 만들고, 모든 데이터를 복사하고, 원본 테이블을 삭제합니다.
+ 프라이머리 키 순서로 데이터를 로드합니다. InnoDB 테이블의 경우 이렇게 하면 로드 시간을 75%\$180% 줄이고 데이터 파일 크기를 50% 줄일 수 있습니다.
+ `foreign_key_checks`를 `0`으로 설정하여 외래 키 제약 조건을 비활성화합니다. `LOAD DATA LOCAL INFILE`을 통해 로드되는 플랫 파일의 경우 이 단계는 많은 경우에 필수입니다. 모든 로드에서 외래 키 검사를 비활성화하면 데이터 로드가 가속화됩니다. 로드가 완료된 후 `foreign_key_checks`를 `1`로 설정하고 데이터를 확인하여 제약 조건을 다시 활성화합니다.
+ 리소스 한도가 가까워지지 않은 한 데이터를 병렬로 로드합니다. 여러 테이블 세그먼트에서 동시 로드를 활성화하기 위해 적절한 경우 파티셔닝된 테이블을 사용합니다.
+ SQL 실행 오버헤드를 줄이려면 여러 `INSERT` 문을 단일 다중 값 `INSERT` 작업으로 결합합니다.`mariadb-dump`는 이 최적화를 자동으로 구현합니다.
+ `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 배포로 전환하지 않는 것이 좋습니다. 이렇게 해도 아주 작은 부분만이 개선됩니다.
# 외부 MariaDB 데이터베이스에서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기
기존 MariaDB 데이터베이스에서 RDS for MariaDB DB 인스턴스로 데이터를 가져올 수 있습니다. 이렇게 하려면 [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) 또는 [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/)를 사용하여 데이터베이스를 복사하고 RDS for MariaDB 인스턴스에 바로 파이핑합니다. `mysqldump` 또는 `mariadb-dump` 명령줄 유틸리티는 한 MariaDB 서버에서 다른 MariaDB 서버로 데이터를 전송하고 백업본을 만드는 데 흔히 사용됩니다. 이 유틸리티는 MariaDB 클라이언트 소프트웨어와 함께 포함되어 있습니다.
MariaDB 11.0.1부터 `mysqldump` 대신 `mariadb-dump`를 사용해야 합니다.
외부 데이터베이스에서 Amazon RDS DB 인스턴스로 데이터를 이동하는 일반적인 `mysqldump` 명령은 다음 예와 같습니다. 값을 실제 정보로 바꿉니다. MariaDB 11.0.1 이상 버전의 경우 `mysqldump`를 `mariadb-dump`로 교체하세요.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**중요**
`-p` 옵션과 입력한 암호 사이에 공백이 없어야 합니다.
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
다음 권장 사항과 고려 사항을 잘 파악하고 있어야 합니다.
+ 덤프 파일에서 다음 스키마를 제외합니다.
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` 및 `mariadb-dump` 유틸리티는 기본적으로 이러한 스키마를 제외합니다.
+ 사용자 및 권한을 마이그레이션해야 하는 경우 이를 다시 생성하는 데이터 제어 언어(DCL)를 생성하는 도구 사용을 고려합니다. 예를 들어 [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) 유틸리티가 있습니다.
+ 가져오기를 수행하려면 사용자가 DB 인스턴스에 액세스할 수 있어야 합니다. 자세한 내용은 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 섹션을 참조하세요.
사용되는 파라미터는 다음과 같습니다.
+ `-u local_user` – 사용자 이름을 지정하기 위해 사용합니다. 이 파라미터를 처음 사용할 때, 로컬 MariaDB 데이터베이스에서 `--databases` 파라미터로 식별되는 사용자 계정 이름을 지정합니다.
+ `--databases database_name` – 로컬 MariaDB 인스턴스에서 Amazon RDS로 가져오려는 데이터베이스 이름을 지정합니다.
+ `--single-transaction` – 로컬 데이터베이스에서 로드한 모든 데이터가 단일 시점에서 일치하는지 확인하기 위해 사용합니다. `mysqldump` 또는 `mariadb-dump`가 데이터를 읽는 동안 데이터를 변경하는 다른 프로세스가 있는 경우, 이 파라미터를 사용하여 데이터 무결성을 유지합니다.
+ `--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` 파라미터로 식별되는 MariaDB 인스턴스에 대한 기본 데이터베이스의 사용자 계정 이름을 지정합니다.
+ `--port port_number` - MariaDB 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` 또는 `mariadb-dump`를 실행할 때 이런 객체를 제외합니다. 이렇게 하려면 `mysqldump` 또는 `mariadb-dump` 명령에 다음 파라미터를 포함합니다.
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**예제**
다음 예제에서는 로컬 호스트에 있는 `world` 샘플 데이터베이스를 RDS for MariaDB DB 인스턴스로 복사합니다. 값을 실제 정보로 바꿉니다.
대상 LinuxmacOS, 또는Unix:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Windows의 경우:
다음 명령은 Windows 프로그램 메뉴에서 **명령 프롬프트**를 마우스 오른쪽 버튼으로 클릭하고 **관리자 권한으로 실행**을 선택하여 열린 명령 프롬프트에서 실행해야 합니다. 값을 실제 정보로 바꿉니다.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
# 가동 중지 시간을 줄이면서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기
라이브 애플리케이션을 지원하는 외부 MariaDB 데이터베이스에서 RDS for MariaDB 인스턴스로 데이터를 가져와야 할 경우가 있습니다. 다음 절차를 통해 애플리케이션 가용성에 미치는 영향을 최소화하세요. 이 절차는 대규모 데이터베이스로 작업하는 경우에도 유용합니다. 이 절차를 통해 네트워크를 거쳐 AWS로 전달되는 데이터의 양을 줄여 가져오기 비용을 줄일 수 있습니다.
이 절차에서는 데이터베이스 데이터의 복사본을 Amazon EC2 인스턴스로 전송하고 데이터를 새 Amazon RDS 데이터베이스로 가져옵니다. 그런 다음, 애플리케이션을 Amazon RDS 데이터베이스로 리디렉션하기 전에 복제를 사용하여 Amazon RDS 데이터베이스를 라이브 외부 인스턴스에 맞춰 최신 상태로 업데이트합니다. 외부 인스턴스가 MariaDB 10.0.24 이상이고 대상 인스턴스가 RDS for MariaDB일 경우에는 글로벌 트랜잭션 식별자(GTID)를 기반으로 MariaDB 복제를 구성합니다. 그렇지 않으면 이진 로그 좌표를 기반으로 복제를 구성합니다. GTID 기반 복제가 더욱 신뢰성이 높은 방법이므로 외부 데이터베이스에서 지원된다면 GTID 기반 복제를 사용하는 것이 좋습니다. 자세한 내용은 MariaDB 설명서에서 [Global Transaction ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/) 섹션을 참조하세요.
다음 다이어그램은 외부 MariaDB 데이터베이스를 Amazon RDS의 MariaDB 데이터베이스로 가져오는 것을 보여 줍니다.
![\[외부 MariaDB 데이터베이스를 Amazon RDS의 MariaDB 데이터베이스로 가져오는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## 작업 1: 기존 데이터베이스의 복사본 만들기
최소한의 가동 중지 시간으로 대량의 데이터를 RDS for MariaDB 데이터베이스로 마이그레이션하는 프로세스에서 첫 번째 단계는 원본 데이터의 복사본을 만드는 것입니다.
다음 다이어그램은 MariaDB 데이터베이스의 백업을 만드는 방법을 보여 줍니다.
![\[MariaDB 데이터베이스의 백업 만드는 방법을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
`mysqldump` 또는 `mariadb-dump` 유틸리티를 사용하여 SQL 또는 구분 기호로 분리된 텍스트 형식으로 데이터베이스 백업본을 만들 수 있습니다. MariaDB 10.5에서는 이 클라이언트를 [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/)라고 합니다. MariaDB 11.0.1부터 `mysqldump` 대신 `mariadb-dump`를 사용해야 합니다. 비프로덕션 환경에서 각각의 형식으로 테스트 실행을 통해 어떤 방법을 사용해야 `mysqldump` 또는 `mariadb-dump` 실행 시간이 최소화되는지 확인하는 것을 권장합니다.
또한, 로드를 위해 구분 기호로 분리된 텍스트 형식을 사용할 때의 이점에 대해 `mysqldump` 또는 `mariadb-dump` 성능상의 이점을 비교 검토하는 것을 권장합니다. 구분 기호로 분리된 텍스트 형식을 사용하는 백업에서는 덤프되는 각 테이블에 대해 탭으로 구분된 텍스트 파일이 생성됩니다. 데이터베이스를 가져오는 데 필요한 시간을 줄이기 위해 `LOAD DATA LOCAL INFILE` 명령을 사용하여 이런 파일을 병렬로 로드할 수 있습니다. 자세한 내용은 모든 소스에서 데이터 가져오기 절차의 [5단계: 데이터 로드](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data) 섹션을 참조하세요.
백업 작업을 시작하기 전에 Amazon RDS로 복사할 MariaDB 데이터베이스에서 복제 옵션을 설정해야 합니다. 복제 옵션에는 이진 로깅 활성화와 고유한 서버 ID 설정이 포함됩니다. 이러한 옵션을 설정하면 서버가 데이터베이스 트랜잭션 로깅을 시작하고 이 프로세스의 후반부에 소스 복제 인스턴스가 되도록 서버를 준비시킵니다.
다음 권장 사항과 고려 사항을 잘 파악하고 있어야 합니다.
+ 데이터베이스의 일관된 상태를 덤프하기 때문에 `mysqldump` 또는 `mariadb-dump`와 함께 `--single-transaction` 옵션을 사용하세요. 덤프 파일이 올바른지 확인하려면 `mysqldump` 또는 `mariadb-dump`가 실행되는 동안 데이터 정의 언어(DDL) 문을 실행하지 마시기 바랍니다. 이러한 작업에 대한 유지 관리 기간을 예약할 수 있습니다.
+ 덤프 파일에서 다음 스키마를 제외합니다.
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` 및 `mariadb-dump` 유틸리티는 기본적으로 이러한 스키마를 제외합니다.
+ 사용자 및 권한을 마이그레이션해야 하는 경우 이를 다시 생성하는 데이터 제어 언어(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` 파일의 업데이트된 `[mariadb]` 섹션을 보여줍니다.
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
자세한 내용은 MariaDB 설명서의 [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication)을 참조하세요.
1. 다중 AZ DB 클러스터를 사용한 복제의 경우 `gtid_strict_mode`를 활성화합니다. 자세한 내용은 MariaDB 설명서의 [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode)를 참조하세요.
DB 인스턴스를 사용한 복제에는 `gtid_strict_mode` 활성화가 필요하지 않습니다.
1. `mariadb` 서비스를 다시 시작합니다.
```
sudo service mariadb restart
```
### 기존 데이터베이스의 백업 복사본 만들기
1. SQL 또는 구분 기호로 분리된 텍스트 형식을 지정하는 `mysqldump` 또는 `mariadb-dump` 유틸리티를 사용하여 데이터 백업을 만듭니다.
성능을 개선하고 데이터 무결성을 보장하려면 `mysqldump` 및 `mariadb-dump`에 `--order-by-primary` 및 `--single-transaction` 옵션을 사용합니다.
백업에 MySQL 시스템 데이터베이스가 포함되지 않도록 하려면 `mysqldump` 또는 `mariadb-dump`에 `--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 출력을 표시하려면 다음 명령을 사용합니다. MariaDB 10.11 이하 버전의 경우 `mariadb-dump`를 `mysqldump`로 바꿉니다.
대상 LinuxmacOS, 또는Unix:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
Windows의 경우:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**참고**
보안 모범 사례로 예시에 표시된 프롬프트 이외의 자격 증명을 지정하는 것이 좋습니다.
+ 구분 기호로 분리된 텍스트 출력을 표시하려면 다음 명령을 사용합니다. MariaDB 11.01 이상 버전의 경우 `mysqldump`를 `mariadb-dump`로 교체하세요.
대상 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` 또는 `mariadb-dump`를 실행할 때 이런 객체를 제외합니다. 이렇게 하려면 `mysqldump` 또는 `mariadb-dump` 명령에 다음 인수를 포함하세요.
`--routines=0`
`--triggers=0`
`--events=0`
`mysqldump`를 사용하고 구분 기호로 분리된 텍스트 형식을 지정하면 `CHANGE MASTER TO` 설명이 반환됩니다. 이 설명에는 마스터 로그 파일 이름과 위치가 포함됩니다. 외부 인스턴스가 MariaDB 버전 10.0.23 이상이면 `MASTER_LOG_FILE` 및 `MASTER_LOG_POS`의 값을 기록해 둡니다. 복제를 설정할 때 이러한 값이 필요합니다.
MariaDB 버전에 대해 다음 출력이 반환됩니다.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. 사용하는 외부 인스턴스가 MariaDB 버전 10.0.24 이상일 경우 GTID 기반 복제를 사용합니다. 외부 MariaDB 인스턴스에서 `SHOW MASTER STATUS`를 실행하여 이진 로그 파일 이름 및 위치를 가져온 다음, 외부 MariaDB 인스턴스에서 `BINLOG_GTID_POS`를 실행하여 GTID로 변환합니다.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
반환된 GTID를 기록해 둡니다. 복제를 구성하는 데 GTID가 필요합니다.
1. 복사된 데이터를 압축하여 데이터를 Amazon RDS 데이터베이스로 복사하는 데 필요한 네트워크 리소스의 양을 줄입니다. 백업 파일의 크기를 기록해 둡니다. Amazon EC2 인스턴스를 얼마나 크게 만들지 결정할 때 이 정보가 필요합니다. 모두 완료되었으면, GZIP 또는 선호하는 압축 유틸리티를 사용하여 백업 파일을 압축합니다.
+ SQL 출력을 압축하려면 다음 명령을 사용합니다.
```
gzip backup.sql
```
+ 구분 기호로 분리된 텍스트 출력을 압축하려면 다음 명령을 사용합니다.
```
tar -zcvf backup.tar.gz target_directory
```
## 작업 2: Amazon EC2 인스턴스 만들기 및 압축된 데이터베이스 복사
압축된 데이터베이스 백업 파일을 Amazon EC2 인스턴스로 복사할 때는 데이터베이스 인스턴스 사이에서 압축되지 않은 데이터를 직접 복사할 때보다 네트워크 리소스를 덜 사용합니다. 데이터가 Amazon EC2에 있으면 MariaDB 데이터베이스로 바로 데이터를 복사할 수 있습니다. 네트워크 리소스의 비용을 절약하려면 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/MigrateMariaDBToRDS_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 인스턴스에 연결하고 다음 명령을 사용하여 최신 업데이트와 MariaDB 클라이언트 도구를 설치합니다.
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
자세한 내용은 *Amazon Elastic Compute Cloud 사용 설명서*의 Linux 인스턴스용 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) 및 MariaDB 설명서의 [MariaDB 커넥터](https://mariadb.com/docs/connectors)를 참조하세요.
1. Amazon EC2 인스턴스에 연결되어 있는 상태에서 데이터베이스 백업 파일의 압축을 풉니다. 다음 명령은 예시입니다.
+ SQL 출력을 압축 해제하려면 다음 명령을 사용합니다.
```
gzip backup.sql.gz -d
```
+ 구분 기호로 분리된 텍스트 출력을 압축 해제하려면 다음 명령을 사용합니다.
```
tar xzvf backup.tar.gz
```
## 작업 3: MariaDB 데이터베이스 만들기 및 Amazon EC2 인스턴스에서 데이터 가져오기
Amazon EC2 인스턴스와 같은 AWS 리전에 RDS for MariaDB DB 인스턴스를 만들면 인터넷보다 빠른 속도로 Amazon EC2에서 데이터베이스 백업 파일을 가져올 수 있습니다.
다음 다이어그램은 Amazon EC2 인스턴스에서 MariaDB 데이터베이스로 백업을 가져오는 것을 보여 줍니다.
![\[EC2 인스턴스에서 MariaDB 데이터베이스로 백업을 가져오는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### MariaDB 데이터베이스를 만들고 데이터 가져오기
1. 이 Amazon RDS 데이터베이스에 대해 예상되는 워크로드를 지원하기 위해 필요한 DB 인스턴스 클래스와 스토리지 공간의 양을 결정합니다. 이 프로세스의 일환으로 데이터 로드 절차를 위해 충분한 공간과 처리 용량이 어느 정도인지 결정합니다. 또한 프로덕션 워크로드를 처리하는 데 필요한 사항을 결정합니다. 원본 MariaDB 데이터베이스의 크기와 리소스를 바탕으로 평가할 수 있습니다. 자세한 내용은 [DB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요.
1. Amazon EC2 인스턴스가 포함된 AWS 리전에서 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 형식인 경우 다음 명령을 사용합니다.
```
MariaDB [(none)]> source backup.sql;
```
+ 구분 기호로 분리된 텍스트 형식의 경우 Amazon RDS 데이터베이스를 설정할 때 만든 기본 데이터베이스가 아니라면 먼저 데이터베이스를 만듭니다.
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
그런 다음, 테이블을 생성합니다.
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
그런 다음, 데이터를 가져옵니다.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
성능을 개선하려면 여러 연결에서 이들 작업을 병렬로 수행하여 모든 테이블이 만들어진 다음에 동시에 로드되도록 할 수 있습니다.
**참고**
처음에 테이블을 덤프할 때 `mysqldump` 또는 `LOAD DATA LOCAL INFILE`와 함께 데이터 서식 옵션을 사용했다면, `mariadb-dump`와 같은 옵션을 사용하여 데이터 파일 내용을 올바로 해석해야 합니다.
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 데이터베이스로 데이터 복제
MariaDB 데이터베이스로 데이터를 복사하고 전송하는 데 걸린 시간 중에 원본 데이터베이스가 업데이트되었을 것입니다. 복제를 사용하여 복사된 데이터베이스를 원본 데이터베이스에 맞춰 최신 상태로 업데이트합니다.
![\[외부 MariaDB 데이터베이스에서 Amazon RDS의 데이터베이스로 데이터를 복제하는 것을 보여 주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Amazon RDS 데이터베이스에서 복제를 시작하는 데 필요한 권한은 제한되고 Amazon RDS 마스터 사용자는 사용할 수 없습니다. 따라서 다음의 적절한 Amazon RDS 저장 프로시저를 사용합니다.
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ 복제를 구성하려면 [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에서 [복제 옵션을 설정](#mariadb-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. SQL 형식을 사용하여 백업 파일을 만들었고 외부 인스턴스가 MariaDB 10.0.24 이상이 아닌 경우 다음 명령을 실행하여 해당 파일의 내용을 살펴봅니다.
```
cat backup.sql
```
이 파일에는 마스터 로그 파일 이름과 위치를 포함한 `CHANGE MASTER TO` 설명이 포함됩니다. 이 설명은 `--master-data`와 함께 `mysqldump` 옵션을 사용할 때 백업 파일에 포함됩니다. `MASTER_LOG_FILE` 및 `MASTER_LOG_POS`에 대한 값을 확인합니다.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
구분 기호로 분리된 텍스트 형식을 사용하여 백업 파일을 만들었고 외부 인스턴스가 MariaDB 10.0.24 이상이 아닌 경우, 작업 1 [존재하는 데이터베이스의 백업 복사본을 생성한 경우](#mariadb-importing-data-reduced-downtime-create-backup)의 1단계에서 바이너리 로그 좌표를 이미 확보했을 것입니다.
외부 인스턴스가 MariaDB 10.0.24 이상인 경우, 작업 1 [기존 데이터베이스의 백업 사본을 생성한 경우](#mariadb-importing-data-reduced-downtime-create-backup)의 2단계에서 복제를 시작할 GTID를 이미 확보했을 것입니다.
1. Amazon RDS 데이터베이스를 복제본으로 만듭니다. 외부 인스턴스가 MariaDB 10.0.24 이상이 아닌 경우 마스터 사용자로 Amazon RDS 데이터베이스에 연결하고 [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 저장된 프로시저를 사용하여 소스 데이터베이스를 소스 복제 인스턴스로 식별합니다.
SQL 형식 백업 파일이 있는 경우 4단계에서 확인한 마스터 로그 파일 이름과 마스터 로그 위치를 사용합니다. 구분 기호로 분리된 텍스트 형식을 사용한 경우 백업 파일을 만들 때 확인한 이름과 위치를 사용합니다. 다음 명령은 예제입니다.
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 보안 인증 정보를 지정하는 것이 좋습니다.
외부 인스턴스가 MariaDB 10.0.24 이상인 경우 마스터 사용자로 Amazon RDS 데이터베이스에 연결하고 [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) 저장된 프로시저를 사용하여 소스 데이터베이스를 소스 복제 인스턴스로 식별합니다. 작업 1의 [기존 데이터베이스의 백업 복사본을 생성한 경우](#mariadb-importing-data-reduced-downtime-create-backup)의 2단계에서 확보한 GTID를 사용합니다. 다음 명령은 예제입니다.
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address`는 소스 복제 인스턴스의 IP 주소입니다. EC2 프라이빗 DNS 주소는 현재 지원되지 않습니다.
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 보안 인증 정보를 지정하는 것이 좋습니다.
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을 반환하면 복제본이 원본 복제 인스턴스로 업데이트됩니다.
MariaDB 10.5, 10.6, 10.11, 11.4 또는 11.8 DB 인스턴스의 경우 MySQL 명령을 실행하는 대신 [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) 저장 프로시저를 실행합니다.
1. Amazon RDS 데이터베이스가 최신 상태로 업데이트된 후, 필요할 경우 그 데이터베이스를 복원할 수 있도록 자동 백업을 활성화합니다. [Amazon RDS 콘솔](https://console.aws.amazon.com/rds/)을 사용하여 Amazon RDS 데이터베이스에 대한 자동 백업을 켜거나 수정할 수 있습니다. 자세한 내용은 [백업 소개](USER_WorkingWithAutomatedBackups.md) 섹션을 참조하세요.
## 작업 5: 라이브 애플리케이션을 Amazon RDS 인스턴스로 리디렉션
MariaDB 데이터베이스가 소스 복제 인스턴스에 맞게 최신 상태로 업데이트되면 라이브 애플리케이션을 업데이트하여 Amazon RDS 인스턴스를 사용할 수 있습니다.
![\[복제를 중지하고 라이브 애플리케이션을 Amazon RDS 데이터베이스로 리디렉션하는 것을 보여주는 워크플로\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### 라이브 애플리케이션을 MariaDB 데이터베이스로 리디렉션하고 복제 중지
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인지 확인합니다. 이 필드가 0이라는 것은 복제본이 소스 복제 인스턴스를 통해 최신 상태가 된 것을 나타냅니다.
```
SHOW REPLICA STATUS;
```
MariaDB 10.5, 10.6, 10.11, 11.4 또는 11.8 DB 인스턴스의 경우 MySQL 명령을 실행하는 대신 [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) 프로시저를 실행합니다.
1. 트랜잭션이 완료되면 소스에 대한 모든 연결을 닫습니다.
1. Amazon RDS 데이터베이스를 사용할 수 있도록 애플리케이션을 업데이트합니다. 이 업데이트에는 일반적으로 Amazon RDS 데이터베이스의 호스트 이름과 포트, 연결할 사용자 계정과 암호, 사용할 데이터베이스를 식별하기 위해 연결 설정을 변경하는 과정이 포함됩니다.
1. 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 데이터베이스의 [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) 저장 프로시저를 사용하는 다음 명령을 실행하여 이 인스턴스가 더 이상 복제본으로 식별되지 않도록 복제 구성을 재설정합니다.
```
CALL mysql.rds_reset_external_master;
```
1. 다중 AZ 지원 및 읽기 전용 복제본과 같은 Amazon RDS 기능을 추가로 활성화합니다. 자세한 내용은 [Amazon RDS에 대한 다중 AZ 배포 구성 및 관리](Concepts.MultiAZ.md) 및 [DB 인스턴스 읽기 전용 복제본 작업](USER_ReadRepl.md) 섹션을 참조하세요.
# 원하는 소스에서 Amazon RDS for MariaDB DB 인스턴스로 데이터 가져오기
Amazon RDS를 사용하면 기존 MariaDB 데이터를 모든 소스에서 RDS for MariaDB DB 인스턴스로 마이그레이션할 수 있습니다. 온프레미스 데이터베이스, 기타 클라우드 공급자 또는 기존 RDS for MariaDB DB 인스턴스에서 대상 RDS for MariaDB DB 인스턴스로 데이터를 전송할 수 있습니다. 이 기능을 사용하면 데이터베이스를 통합하거나, 재해 복구 솔루션을 구현하거나, 자체 관리형 데이터베이스에서 전환할 수 있습니다. 일반적인 시나리오로는 자체 호스팅 MariaDB 서버에서 완전 관리형 Amazon RDS DB 인스턴스로 이동하거나, 여러 MariaDB 데이터베이스를 단일 DB 인스턴스로 통합하거나, 프로덕션 데이터를 사용하여 테스트 환경을 생성하는 것이 있습니다. 다음 섹션에서는 `mariadb-dump`, 백업 파일 또는 복제와 같은 방법을 사용하여 MariaDB 데이터를 가져오기 위한 단계별 지침을 제공합니다.
## 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단계](#mariadb-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 인스턴스를 종료했다가 다시 시작하여 MariaDB 로깅을 켜거나 끕니다.
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단계: 데이터 로드
플랫 파일의 행을 데이터베이스 테이블로 읽어들이려면 MariaDB `LOAD DATA LOCAL INFILE` 문을 사용합니다.
**참고**
플랫 파일이 있는 위치와 동일한 위치에서 `mariadb` 쉘을 호출하거나 `LOAD DATA LOCAL INFILE`을 실행할 때 파일의 절대 경로를 사용해야 합니다.
다음 예시는 이름이 `sales.txt`인 파일에서 데이터베이스의 `Sales` 테이블로 데이터를 로드하는 방법을 보여줍니다.
```
MariaDB [(none)]> 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` 문에 대한 자세한 내용은 MariaDB 설명서의 [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile)을 참조하세요.
## 6단계: Amazon RDS 자동 백업 다시 켜기
[4단계](#mariadb-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
```