MySQL DB 인스턴스로 데이터 가져오기
MySQL DB 인스턴스용 RDS로 데이터를 가져오는 기법에는 몇 가지가 있습니다. 데이터의 유형, 데이터의 양, 가져오기 작업이 일시적인지 지속적인지 등에 따라 바람직한 접근 방법이 달라집니다. 데이터와 함께 애플리케이션을 마이그레이션하는 경우라면 감당할 수 있는 작업 중단 시간도 고려해야 합니다.
개요
MySQL DB 인스턴스용 RDS로 데이터를 가져오는 기법을 다음 표에서 찾아보세요.
| 소스 | 데이터 분량 | 일회성 혹은 지속적 | 애플리케이션 가동 중지 | 기술 | 추가 정보 |
|---|---|---|---|---|---|
|
온프레미스 또는 Amazon EC2에 있는 기존 MySQL 데이터베이스 |
모두 선택 |
한 번만 |
약간 |
온프레미스 데이터베이스의 백업을 만들어서 Amazon S3에 저장한 다음 MySQL을 실행하여 새로운 Amazon RDS DB 인스턴스에 백업 파일을 복원하십시오. |
|
|
기존의 모든 데이터베이스 |
모두 선택 |
일회성 혹은 지속적 |
최소화 |
AWS Database Migration Service을 사용하면 가동 중지 시간을 최소화하면서 데이터베이스를 마이그레이션할 수 있으며 대부분의 DB 엔진에서는 지속적으로 복제를 계속할 수 있습니다. |
AWS Database Migration Service란? 및 AWS Database Migration Service 사용 설명서의 AWS DMS에서 MySQL 호환 데이터베이스를 대상으로 사용 |
|
기존 MySQL DB 인스턴스 |
모두 선택 |
일회성 혹은 지속적 |
최소화 |
지속적인 복제를 위한 읽기 전용 복제본을 생성합니다. 새 DB 인스턴스를 한 번만 생성하도록 읽기 전용 복제본을 승격시킵니다. |
|
|
기존 MariaDB 또는 MySQL 데이터베이스 |
스몰 |
한 번만 |
약간 |
명령줄 유틸리티를 사용하여 MySQL DB 인스턴스에 바로 데이터를 복제합니다. |
외부 MariaDB 또는 MySQL 데이터베이스에서 RDS for MariaDB 또는 MySQL 또는 RDS for MySQL DB 인스턴스로 데이터 가져오기 |
|
기존 데이터베이스에 저장되지 않은 데이터 |
Medium |
한 번만 |
약간 |
플랫 파일을 만들고 MySQL LOAD DATA LOCAL
INFILE 문을 이용하여 가져옵니다. |
|
|
온프레미스 또는 Amazon EC2에 있는 기존 MySQL 또는 MariaDB 데이터베이스 |
모두 |
지속적 |
최소화 |
기존 MariaDB 또는 MySQL 데이터베이스가 복제 소스가 되도록 복제본을 구성합니다. |
참고
'mysql' 시스템 데이터베이스에는 DB 인스턴스에 로그인하고 데이터에 액세스하는 데 필요한 인증 및 권한 부여 정보가 포함되어 있습니다. DB 인스턴스에 있는 'mysql' 데이터베이스의 각종 테이블, 데이터 또는 기타 콘텐츠를 삭제하거나 변경하거나 이름을 바꾸거나 자르면 오류가 발생하여 DB 인스턴스와 데이터에 액세스할 수 없게 될 수 있습니다. 이 문제가 발생할 경우 AWS CLI restore-db-instance-from-db-snapshot 명령을 사용하여 DB 인스턴스를 스냅샷에서 복원할 수 있습니다. AWS CLI restore-db-instance-to-point-in-time 명령을 사용하여 DB 인스턴스를 복원할 수 있습니다.
데이터 가져오기 고려 사항
다음은 MySQL로 데이터를 로드하는 것과 관련된 추가적인 기술 정보입니다. 이 정보는 MySQL 서버 아키텍처를 익히 잘 알고 있는 고급 사용자를 위한 것입니다.
이진 로그
데이터 로드는 성능 저하를 초래하며, 이진 로깅을 비활성화한 상태에서 똑같은 데이터를 로드하는 데 비해 이진 로깅을 활성화하면 사용 가능한 디스크 공간이 추가로(최대 4배 더) 필요합니다. 성능 저하의 심각도와 사용 가능한 디스크 공간의 요구량은 데이터 로드에 사용되는 트랜잭션의 크기에 정비례합니다.
트랜잭션 크기
트랜잭션 크기는 MySQL 데이터 로드에서 중요한 역할을 합니다. 트랜잭션 크기는 리소스 소비, 디스크 공간 사용률, 재개 프로세스, 복구 시간 및 입력 형식(플랫 파일 또는 SQL)에 중대한 영향을 미칩니다. 이 섹션에서는 트랜잭션 크기가 이진 로깅에 미치는 영향을 설명하고 큰 데이터를 로드하는 중에 이진 로깅을 비활성화하는 이유를 논증합니다. 앞서 언급한 바와 같이, 이진 로깅은 Amazon RDS 자동 백업 보존 기간을 설정하여 활성화 및 비활성화합니다. 0이 아닌 값으로 설정하면 이진 로깅이 활성화되고 0으로 설정하면 비활성화됩니다. 대규모 트랜잭션이 InnoDB에 미치는 영향과 트랜잭션 크기를 작게 유지하는 것이 중요한 이유도 설명합니다.
작은 트랜잭션
작은 트랜잭션의 경우, 이진 로깅을 사용하면 데이터 로드에 필요한 디스크 쓰기 작업 수가 배가됩니다. 이 결과 다른 데이터베이스 세션의 성능이 심각하게 저하되고 데이터 로딩 시간이 증가할 수 있습니다. 부분적으로는 업로드 속도, 로드 중에 발생하는 다른 데이터베이스 작업, Amazon RDS DB 인스턴스의 용량에 따라 저하 수준이 좌우됩니다.
또한, 이진 로그는 백업 및 제거될 때까지 로드된 데이터의 양과 대략적으로 같은 양의 디스크 공간을 사용합니다. 다행히도, Amazon RDS는 이진 로그를 자주 백업하고 제거하는 방법으로 이 문제를 최소화합니다.
큰 트랜잭션
큰 트랜잭션의 경우, 이진 로깅이 활성화되어 있으면 IOPS와 디스크 사용량이 3배나 늘어납니다. 이는 이진 로그 캐시가 디스크로 유출되어 디스크 공간을 사용하고 각 쓰기 작업을 위해 IO가 추가로 발생하기 때문입니다. 트랜잭션이 커밋하거나 롤백해야 binlog에 캐시를 쓸 수 있으므로, 캐시는 로드되는 데이터의 양에 비례하여 디스크 공간을 사용합니다. 트랜잭션이 커밋할 때 캐시가 binlog로 복사되어야 하며, 이에 따라 디스크에 제3의 데이터 복사본이 생성됩니다.
이 때문에, 이진 로깅을 비활성화한 상태에서 로드할 때에 비해 데이터를 로드하기 위해 사용 가능한 디스크 공간이 3배 이상 많아야 합니다. 예를 들어 10GiB 데이터를 단일 트랜잭션으로 로드하면 로드 중에 최소 30GiB 디스크 공간을 소모합니다. 소모량은 테이블 10GiB + 이진 로그 캐시 10GiB + 이진 로그 자체 10GiB입니다. 캐시 파일을 만든 세션이 종료되거나 세션이 또 다른 트랜잭션 중에 이진 로그 캐시를 다시 채울 때까지 캐시 파일은 디스크 상에 그대로 남습니다. 이진수 로그는 백업 시까지 디스크에 남아 있어야 하므로, 추가로 20GiB의 디스크 공간을 사용할 수 있게 되기까지 약간의 시간이 필요할 수 있습니다.
더구나 LOAD DATA LOCAL INFILE을 사용하여 데이터를 로드한 경우, 로드 이전에 만든 백업에서 데이터베이스를 복구해야 한다면 데이터의 또 다른 복사본이 생성됩니다. 복원 중에 MySQL이 이진 로그에서 플랫 파일로 데이터를 추출합니다. 그런 다음 MySQL이 원본 트랜잭션과 마찬가지로 LOAD DATA LOCAL INFILE을 실행합니다. 그러나 이번에는 입력 파일이 데이터베이스 서버의 로컬에 있습니다. 앞 예제를 계속 진행할 때, 40GiB 이상의 사용 가능한 디스크 공간이 없으면 복구에 실패합니다.
이진 로깅 비활성화
가능하다면 항상 큰 데이터 로드 중에는 이진 로깅을 비활성화하여 리소스 오버헤드와 추가 디스크 공간이 필요한 상황을 피하십시오. 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로 다시 전송해야 할 수도 있지만, 파일이 작으면 재전송되는 양이 최소한으로 국한됩니다.
데이터 병렬 로드 – 단일 파일 로드와 함께 따로 남겨둘 IOPS와 네트워크 대역폭이 있는 경우 병렬로 로드하면 시간을 절약할 수 있습니다.
로드 속도 조절 – 데이터 로드가 다른 프로세스에 부정적인 영향을 미칩니까? 파일 간의 간격을 늘려 로드를 조절할 수 있습니다.
주의 사항
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을 줄이십시오.
읽기 전용 복제본이 없는 DB 인스턴스로 데이터를 로드하는 경우 데이터를 로드하는 동안 sync_binlog 파라미터를 0으로 설정합니다. 데이터 로딩이 완료되면, sync_binlog 파라미터를 다시 1로 설정합니다.
DB 인스턴스가 다중 AZ 배포로 변환되기 전에 데이터를 로딩합니다. 하지만 DB 인스턴스에서 이미 다중 AZ 배포를 사용하고 있는 경우, 데이터 로딩 동안 단일 AZ 배포로 전환하는 것을 권장하지 않습니다. 이렇게 할 경우 아주 적은 개선만 제공되기 때문입니다.
참고
innodb_flush_log_at_trx_commit=0을 사용하면 InnoDB가 매번 커밋할 때가 아니라 1초마다 로그를 플러시합니다. 이는 상당한 속도상의 이점을 제공하지만, 충돌 중에 데이터 손실로 이어질 수 있습니다. 따라서 주의해서 사용하십시오.
주제
