메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

MySQL DB 인스턴스에서 데이터 가져오기 및 내보내기

MySQL DB 인스턴스로 데이터를 가져오거나 이 인스턴스에서 데이터를 내보내려면 이 섹션에서 설명하는 절차에 따르는 것이 좋습니다. 이런 절차에 따라 다른 MySQL DB 인스턴스, Amazon RDS 외부에서 실행 중인 MySQL 인스턴스 및 기타 유형의 데이터 소스에서 데이터를 가져올 수 있습니다. 복제를 사용하여 Amazon RDS 외부에서 실행 중인 MySQL의 인스턴스로 데이터를 내보내려면 복제를 사용하여 MySQL 데이터 내보내기에서 설명하는 절차에 따르는 것이 좋습니다.

개요

아래에서 설명하는 것과 같은 상황에서 MySQL DB 인스턴스로 데이터를 가져오려면 다음 절차에 따르는 것이 좋습니다.

  • AWS Database Migration Service를 사용하여 가장 효율적인 방법으로 데이터를 마이그레이션할 수 있습니다. AWS DMS는 가동 중지 시간을 최소화하면서 데이터베이스를 마이그레이션할 수 있으며 대부분의 데이터베이스 엔진에서는 MySQL DB 인스턴스로 전환할 준비가 될 때까지 지속적으로 복제를 계속할 수 있습니다. AWS DMS를 사용하여 MySQL이 아닌 데이터베이스 엔진에서 Amazon RDS MySQL DB 인스턴스로 마이그레이션하거나 MySQL 데이터베이스를 부분적으로 마이그레이션할 수 있습니다. 다른 데이터베이스 엔진에서 MySQL로 마이그레이션하는 경우 AWS Schema Conversion Tool을 사용하여 AWS DMS를 통해 마이그레이션되지 않는 스키마 객체를 마이그레이션할 수 있습니다. AWS DMS에 대한 자세한 내용은 AWS Database Migration Service란 무엇입니까?을(를) 참조하십시오.

    다음 조건이 모두 충족되는 경우 AWS DMS를 사용하지 말고 그 대신 MySQL 데이터베이스 마이그레이션 도구를 사용하는 것이 좋습니다.

    • 같은 유형의 마이그레이션을 수행합니다. 이 경우 MySQL 데이터베이스에서 Amazon RDS MySQL DB 인스턴스로 마이그레이션합니다.

    • 전체 데이터베이스를 마이그레이션합니다.

      AWS DMS는 하위 데이터 세트를 MySQL 데이터베이스에서 Amazon RDS로 마이그레이션하는 경우에 효과적인 옵션입니다. 하지만 전체 데이터베이스를 마이그레이션하는 경우 AWS DMS는 테이블과 기본 키를 생성하고 경우에 따라 고유 인덱스도 생성하지만, 소스의 데이터를 효율적으로 마이그레이션하는 데 필요하지 않은 다른 객체를 생성하지 않습니다. 예를 들어 보조 인덱스, 기본이 아닌 키 제약 조건 또는 데이터 기본값을 생성하지 않습니다. 전체 데이터베이스를 마이그레이션하는 경우, 스키마를 RDS MySQL DB 인스턴스로 복사한 다음 AWS DMS를 사용하여 데이터를 마이그레이션하거나, 이 주제에서 나중에 다루는 기본 MySQL 마이그레이션 도구를 사용할 수 있습니다.

    • MySQL 데이터베이스 마이그레이션 도구를 사용하면 데이터베이스를 마이그레이션하는 데 필요한 가중 중지 시간이 단축됩니다. 예제는 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기을(를) 참조하십시오.

  • MySQL DB 인스턴스에 있는 기존 데이터베이스에서 데이터를 가져오려면 읽기 전용 복제본을 만든 후 읽기 전용 복제본을 승격하면 됩니다. 자세한 내용은 PostgreSQL, MySQL 및 MariaDB 읽기 전용 복제본 작업을(를) 참조하십시오.

  • 소량의 MySQL 데이터를 이동하려는 경우 또는 원본 MySQL 데이터베이스에서 발생하는 서비스 중단이 문제가 되지 않는 경우에는 명령줄 유틸리티를 사용하여 Amazon RDS MySQL DB 인스턴스로 데이터를 직접 복사하는 간단한 절차에 따르면 됩니다. 자세한 내용은 MySQL 또는 MariaDB DB에서 Amazon RDS MySQL 또는 MariaDB DB 인스턴스로 데이터 가져오기 섹션을 참조하십시오.

  • 대량의 MySQL 데이터를 이동하려는 경우 또는 외부 MySQL 인스턴스를 사용하는 라이브 사이트 또는 애플리케이션에 대한 서비스 중단을 최소화하려는 경우에는 데이터를 백업하고, Amazon Elastic Compute Cloud(Amazon EC2)에 복사하고, Amazon RDS MySQL DB 인스턴스로 가져올 수 있습니다. 그러면 복제를 사용하여 두 인스턴스를 Amazon EC2로 복사한 이후로 원본 시스템에 추가된 데이터에 맞춰 동기화할 수 있습니다. 자세한 정보는 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기을(를) 참조하십시오.

  • 기존 MySQL 데이터베이스 이외의 소스에 있는 데이터의 경우, mysqlimport 유틸리티를 사용하여 플랫 파일을 만들어 가져올 수 있습니다. 자세한 내용은 임의의 소스에서 MySQL 또는 MariaDB DB 인스턴스로 데이터 가져오기을(를) 참조하십시오.

  • 기존 MySQL DB 인스턴스를 복제 마스터로 사용하여 복제를 설정하려면 Amazon RDS 외부에서 실행 중인 MySQL 또는 MariaDB 인스턴스를 사용한 복제을(를) 참조하십시오.

참고

'mysql' 시스템 데이터베이스에는 DB 인스턴스에 로그인하고 데이터에 액세스하는 데 필요한 인증 및 권한 부여 정보가 들어 있습니다. DB 인스턴스에 있는 'mysql' 데이터베이스의 각종 테이블, 데이터 또는 기타 콘텐츠를 삭제하거나 변경하거나 이름을 바꾸거나 자르면 오류가 발생하여 DB 인스턴스와 데이터에 액세스할 수 없게 될 수 있습니다. 이러한 경우, DB 인스턴스는 AWS CLI restore-db-instance-from-db-snapshot 명령을 사용하여 스냅샷으로부터 복원하거나 AWS CLI restore-db-instance-to-point-in-time 명령을 사용하여 복구할 수 있습니다.

데이터 가져오기 고려 사항

이 섹션에는 MySQL로 데이터를 로드하는 것과 관련된 추가적인 기술 정보가 수록되어 있습니다. 이는 MySQL Server 아키텍처를 익히 잘 알고 있는 고급 사용자를 위한 것입니다. LOAD DATA LOCAL INFILE과 관련된 모든 설명은 mysqlimport에도 적용됩니다.

이진 로그

데이터 로드는 성능 저하를 초래하며, 이진 로깅을 비활성화한 상태에서 똑같은 데이터를 로드하는 데 비해 이진 로깅을 활성화하면 사용 가능한 디스크 공간이 추가로(최대 4배 더) 필요합니다. 성능 저하의 심각도와 사용 가능한 디스크 공간의 요구량은 데이터 로드에 사용되는 트랜잭션의 크기에 정비례합니다.

트랜잭션 크기

트랜잭션 크기는 MySQL 데이터 로드에서 중요한 역할을 합니다. 트랜잭션 크기는 리소스 소비, 디스크 공간 사용률, 재개 프로세스, 복구 시간 및 입력 형식(플랫 파일 또는 SQL)에 중대한 영향을 미칩니다. 이 섹션에서는 트랜잭션 크기가 이진 로깅에 미치는 영향을 설명하고 큰 데이터를 로드하는 중에 이진 로깅을 비활성화하는 이유를 논증합니다. 앞서 언급한 바와 같이, 이진 로깅은 Amazon RDS 자동 백업 보존 기간을 설정하여 활성화 및 비활성화합니다. 0이 아닌 값으로 설정하면 이진 로깅이 활성화되고 0으로 설정하면 비활성화됩니다. 대규모 트랜잭션이 InnoDB에 미치는 영향과 트랜잭션 크기를 작게 유지하는 것이 중요한 이유도 설명합니다.

작은 트랜잭션

작은 트랜잭션의 경우, 이진 로깅을 사용하면 데이터 로드에 필요한 디스크 쓰기 작업 수가 배가됩니다. 업로드 속도, 로드 중에 발생하는 다른 데이터베이스 작업, Amazon RDS DB 인스턴스의 용량에 따라, 이는 다른 데이터베이스 세션의 성능을 심각하게 저해하고 데이터 로드 소요 시간을 대폭 늘릴 수 있습니다.

또한, 이진 로그는 백업 및 제거될 때까지 로드된 데이터의 양과 대략적으로 같은 양의 디스크 공간을 사용합니다. 다행히도, Amazon RDS는 이진 로그를 자주 백업하고 제거하는 방법으로 이 문제를 최소화합니다.

큰 트랜잭션

큰 트랜잭션의 경우, 이진 로깅이 활성화되어 있으면 IOPS와 디스크 사용량이 3배나 늘어납니다. 이는 이진 로그 캐시가 디스크로 유출되어 디스크 공간을 사용하고 각 쓰기 작업을 위해 IO가 추가로 발생하기 때문입니다. 트랜잭션이 커밋하거나 롤백해야 binlog에 캐시를 쓸 수 있으므로, 캐시는 로드되는 데이터의 양에 비례하여 디스크 공간을 사용합니다. 트랜잭션이 커밋할 때 캐시가 binlog로 복사되어야 하며, 이에 따라 디스크에 제3의 데이터 복사본이 생성됩니다.

이 때문에, 이진 로깅을 비활성화한 상태에서 로드할 때에 비해 데이터를 로드하기 위해 사용 가능한 디스크 공간이 3배 이상 많아야 합니다. 예를 들어 단일 트랜잭션으로 로드되는 10GB의 데이터는 로드 중에 30GB 이상의 디스크 공간을 사용하게 됩니다(테이블에 10GB + 이진 로그 캐시에 10GB + 이진 로그 자체에 10GB). 캐시 파일을 만든 세션이 종료되거나 세션이 또 다른 트랜잭션 중에 이진 로그 캐시를 다시 채울 때까지 캐시 파일은 디스크 상에 그대로 남습니다. 이진 로그는 백업 시까지 디스크에 남아 있어야 하므로, 추가로 20GB의 디스크 공간을 사용할 수 있게 되기까지 약간의 시간이 필요할 수 있습니다.

더구나 LOAD DATA LOCAL INFILE을 사용하여 데이터를 로드한 경우, 로드 이전에 만든 백업에서 데이터베이스를 복구해야 한다면 데이터의 또 다른 복사본이 생성됩니다. 복구 중에 MySQL은 이진 로그에서 플랫 파일로 데이터를 추출한 후 원래 트랜잭션과 마찬가지로 LOAD DATA LOCAL INFILE을 실행하는데, 이번만은 입력 파일이 데이터베이스 서버의 로컬 위치에 있습니다. 위 예제를 계속 진행할 때, 40GB 이상의 사용 가능한 디스크 공간이 없으면 복구에 실패하게 됩니다.

이진 로깅 비활성화

가능하다면 항상 큰 데이터 로드 중에는 이진 로깅을 비활성화하여 리소스 오버헤드와 추가 디스크 공간이 필요한 상황을 피하십시오. Amazon RDS에서는 백업 보존 기간을 0으로 설정하기만 하면 이진 로깅이 비활성화됩니다. 이때 필요한 경우 로드 중에 변경된 사항을 빠르고 쉽게 실행 취소할 수 있도록 로드 직전에 데이터베이스 인스턴스의 DB 스냅샷을 만드는 것이 좋습니다.

로드 후에는 백업 보존 기간을 다시 (0이 아닌) 적당한 값으로 설정합니다.

DB 인스턴스가 읽기 전용 복제본의 원본 DB 인스턴스인 경우에는 백업 보조 기간을 0으로 설정할 수 없습니다.

InnoDB

이 섹션에서는 InnoDB를 사용할 때 트랜잭션 크기를 작은 상태로 유지하기 위한 강력한 인수에 대해 설명합니다.

실행 취소

InnoDB는 트랜잭션 롤백 및 MVCC와 같은 기능을 지원하기 위해 실행 취소를 생성합니다. 실행 취소는 InnoDB 시스템 테이블스페이스(보통 ibdata1)에 저장되고 제거 스레드로 제거될 때까지는 보존됩니다. 제거 스레드가 가장 오래된 활성 트랜잭션의 실행 취소보다 앞설 수는 없으므로, 실제로는 트랜잭션이 롤백을 커밋하거나 완료할 때까지는 차단됩니다. 데이터베이스가 로드 중에 다른 트랜잭션을 처리 중인 경우, 이들 트랜잭션의 실행 취소 역시 시스템 테이블스페이스에 누적되며 트랜잭션이 커밋하고 MVCC에 대해 실행 취소할 필요가 있는 다른 트랜잭션이 전혀 없더라도 누적된 실행 취소를 제거할 수 없습니다. 이런 상황에서는 장시간 실행 중인 로드 트랜잭션을 위한 것이 아니라면 제거되었을 수도 있는 실행 취소를 모두 검사하게 되므로 (로드 트랜잭션뿐 아니라) 어떤 트랜잭션에서든 변경된 행에 액세스하는 모든 트랜잭션(읽기 전용 트랜잭션 포함)이 느려집니다.

실행 취소는 시스템 테이블스페이스에 저장되고 시스템 테이블스페이스는 크기가 결코 축소되지 않으므로, 큰 데이터 로드 트랜잭션은 시스템 테이블스페이스가 상당히 커지는 원인이 될 수 있고, 이때 사용되는 디스크 공간은 데이터베이스를 처음부터 다시 만들어야 회수할 수 있습니다.

롤백

InnoDB는 커밋에 최적화되어 있습니다. 큰 트랜잭션을 롤백하려면 시간이 엄청나게 오래 걸릴 수 있습니다. 경우에 따라서는 특정 시점으로 복구를 수행하거나 DB 스냅샷을 복원하는 것이 오히려 더 빠를 수도 있습니다.

입력 데이터 형식

MySQL은 플랫 파일과 SQL의 두 가지 형식 중 하나로 수신 데이터를 허용할 수 있습니다. 이 섹션에서는 각 형식의 몇몇 주요 장점과 단점을 지적합니다.

플랫 파일

트랜잭션이 비교적 작은 크기로 유지되는 한, LOAD DATA LOCAL INFILE로 플랫 파일을 로드하는 것이 가장 빠르고 최소의 비용으로 데이터를 로드하는 방법일 수 있습니다. SQL로 같은 데이터를 로드하는 것에 비해, 플랫 파일은 보통 네트워크 트래픽이 덜 소요되어 데이터베이스에서 오버헤드가 감소되므로 전송 비용이 절감되고 훨씬 더 빠르게 로드됩니다.

하나의 대형 트랜잭션

LOAD DATA LOCAL INFILE은 전체 플랫 파일을 하나의 트랜잭션으로 로드합니다. 이것이 꼭 나쁜 것은 아닙니다. 개발 파일의 크기를 작게 유지할 수 있다면, 이 방법은 다음과 같은 여러 가지 장점이 있습니다.

  • 재개 기능 - 로드된 파일을 계속 손쉽게 추적할 수 있습니다. 로드 중에 문제가 발생하면 약간의 노력만으로 로드에 문제가 생긴 부분을 정확히 파악할 수 있습니다. 일부 데이터를 Amazon RDS로 다시 전송해야 할 수도 있지만, 파일이 작으면 재전송되는 양이 최소한으로 국한됩니다.

  • 데이터 병렬 로드 - 단일 파일 로드와 함께 따로 남겨둘 IOP와 네트워크 대역폭이 있는 경우 병렬로 로드하면 시간을 절약할 수 있습니다.

  • 로드 속도 조절 - 데이터 로드가 다른 프로세스에 영향을 미칩니까? 파일 간의 간격을 늘려 로드를 조절할 수 있습니다.

주의 사항

LOAD DATA LOCAL INFILE의 장점은 트랜잭션 크기가 증가함에 따라 빠르게 희석됩니다. 큰 데이터 집합을 여러 개의 작은 데이터 집합으로 나눌 수 없는 경우에는 SQL을 선택하는 것이 더 나을 수 있습니다.

SQL

SQL은 플랫 파일에 비해 한 가지 중요한 장점이 있는데, 그것은 바로 트랜잭션 크기를 작게 유지하기 쉽다는 점입니다. 하지만 SQL은 플랫 파일보다 로드하는 데 상당히 더 오랜 시간이 걸릴 수 있어 오류 발생 후 로드를 재개할 위치를 판단하기 어려울 수 있습니다. 예를 들어 mysqldump 파일은 다시 시작할 수 없습니다. mysqldump 파일을 로드하는 동안 오류가 발생하는 경우 이 파일을 수정하거나 바꾸어야 로드를 재개할 수 있습니다. 그 대안은 일단 오류의 원인이 수정되었으면 파일을 로드하고 재생하기 전의 특정 시점으로 복원하는 것입니다.

Amazon RDS 스냅샷을 사용하여 검사적 선택

여러 시간, 심지어 며칠씩 걸릴 정도의 로드 작업을 실행해야 할 경우, 주기적인 체크포인트를 선택할 수 없다면 이진 로깅 없이 로드하는 것은 그다지 좋은 방법이 아닙니다. 바로 이럴 때 매우 편리하게 이용할 수 있는 것이 Amazon RDS DB 스냅샷 기능입니다. DB 스냅샷은 충돌이나 다른 사고 후의 특정 시점으로 데이터베이스를 복원하는 데 사용할 수 있는 데이터베이스 인스턴스의 특정 시점과 일치하는 복사본을 만듭니다.

체크포인트를 만들려면 단순히 DB 스냅샷을 만들기만 하면 됩니다. 체크포인트를 위해 이전에 생성된 DB 스냅샷은 내구성이나 복원 시간에 영향을 주지 않고 제거할 수 있습니다.

스냅샷 역시 빠르므로, 체크포인트를 자주 사용해도 로드 시간이 크게 늘지는 않습니다.

로드 시간 감소

다음은 로드 시간을 단축하기 위한 몇 가지 추가 팁입니다.

  • 모든 보조 인덱스를 만든 후에 로드하십시오. 이는 다른 데이터베이스에 익숙한 사용자에게는 직관에 반하는 팁입니다. 보조 인덱스를 추가하거나 수정하면 MySQL이 인덱스 변경에 따라 새 테이블을 만들고, 기존 테이블에서 새 테이블로 데이터를 복사하고, 원래 테이블은 삭제하게 됩니다.

  • PK 순서대로 데이터를 로드하십시오. 이는 로드 시간을 75~80% 줄이고 데이터 파일 크기를 절반으로 줄일 수 있는 InnoDB 테이블에 특히 유용합니다.

  • 외래 키 제약 조건 foreign_key_checks=0을 비활성화하십시오. LOAD DATA LOCAL INFILE과 함께 로드되는 플랫 파일에 대해, 이는 많은 경우에 필수 사항입니다. 어떤 로드에 대해서든, FK 검사를 비활성화하면 상당한 성능상의 이득이 생깁니다. 제약 조건을 반드시 활성화하고 로드 후 데이터를 확인하십시오.

  • 이미 거의 리소스 제한에 근접하지 않았다면 병렬로 로드하십시오. 상황상 적절할 때는 분할된 테이블을 사용하십시오.

  • SQL을 사용하여 로드할 때는 다중 값 삽입을 사용하여 문 실행 오버헤드를 최소화하십시오. mysqldump를 사용할 때는 이 작업이 자동으로 수행됩니다.

  • InnoDB 로그 IO innodb_flush_log_at_trx_commit=0을 줄이십시오.

참고

innodb_flush_log_at_trx_commit=0을 사용하면 InnoDB가 매번 커밋할 때가 아니라 1초마다 로그를 플러시합니다. 이는 상당한 속도상의 이점을 제공하지만, 충돌 중에 데이터 손실로 이어질 수 있습니다. 따라서 주의해서 사용하십시오.