AWS DMS를 사용하여 소스 RDS MySQL 데이터베이스를 대상 RDS MySQL 데이터베이스로 마이그레이션할 때 따라야 할 모범 사례는 무엇인가요?

간략한 설명

AWS DMS를 사용하면 소스 데이터 스토어에서 대상 데이터 스토어로 데이터를 마이그레이션할 수 있습니다. 이 두 데이터 스토어를 엔드포인트라고 합니다. 한 MySQL 데이터베이스에서 다른 MySQL 데이터베이스로 이동하는 것처럼, 동일한 데이터베이스 엔진을 사용하는 소스 엔드포인트와 대상 엔드포인트 간에 마이그레이션할 수 있습니다.

AWS DMS는 대상 스키마 객체를 생성하지만 소스에서 데이터를 효과적으로 마이그레이션하는 데 필요한 최소한의 객체만 생성합니다. 따라서 AWS DMS는 테이블, 프라이머리 키, 경우에 따라 고유 인덱스를 생성하지만 보조 인덱스, 프라이머리 키가 아닌 키의 제약 조건, 데이터 기본값과 같은 객체는 생성하지 않습니다. AWS DMS가 마이그레이션하는 대상에 대한 자세한 정보는 AWS DMS의 상위 수준 보기를 참조하세요.

마이그레이션 전에 대상 데이터베이스에서 테이블 사전 생성

기본 데이터 정의를 유지하려면 마이그레이션하기 전에 대상 데이터베이스에 테이블을 미리 생성합니다. 수행 중인 마이그레이션 유형에 따라 다음 방법 중 하나를 사용합니다.

• MySQL에서 MySQL로의 동종 마이그레이션의 경우 mysqldump와 같은 기본 데이터베이스 엔진 유틸리티를 사용하여 테이블 정의를 내보냅니다. 그런 다음 이러한 테이블 정의를 데이터 없이 대상으로 가져옵니다. 테이블 정의가 생성된 후, 대상 테이블 준비 모드가 TRUNCATE_BEFORE_LOAD로 설정된 AWS DMS 태스크를 사용하여 데이터를 로드합니다.
• 서로 다른 데이터베이스 엔진 간 마이그레이션의 경우 AWS Schema Conversion Tool(AWS SCT)을 사용합니다. 동종 데이터베이스에 대해서도 이 방법을 사용할 수 있습니다. AWS SCT는 소스 및 대상 데이터베이스에 연결한 다음 기존 데이터베이스 스키마를 한 데이터베이스 엔진에서 다른 데이터베이스 엔진으로 변환합니다. AWS SCT를 사용하여 기본 데이터 정의를 그대로 유지하면서 대상 데이터베이스에 테이블을 미리 생성할 수 있습니다. 그런 다음 대상 테이블 준비 모드를 TRUNCATE_BEFORE_LOAD로 설정한 상태에서 AWS DMS 태스크를 사용하여 데이터를 로드합니다. 자세한 정보는 AWS SCT를 사용하여 스키마 변환을 참조하세요.

해결 방법

MySQL에서 MySQL로의 AWS DMS 마이그레이션 모범 사례 준수

MySQL 소스 데이터베이스에서 MySQL 대상 데이터베이스로 데이터를 마이그레이션할 때 이러한 모범 사례를 사용합니다.

• 마이그레이션 중에 대상 데이터베이스의 백업 및 데이터베이스별 로그(예: bin, general, audit)를 해제합니다. 필요한 경우 다시 설정하여 문제를 해결할 수 있습니다.
• 마이그레이션 중에 대상 데이터베이스에서 트리거, 기타 cron 작업, 이벤트 스케줄러를 해제합니다.
• AWS DMS 마이그레이션을 수행할 때 대상 Amazon RDS 데이터베이스에서 다중 AZ를 사용하지 마세요.
• 마이그레이션을 수행할 때 대상 데이터베이스에 다른 외부 클라이언트 트래픽을 적용하지 마세요.
• AWS DMS 복제 인스턴스, 소스, 대상 데이터베이스에 필요한 CPU, 메모리, 스토리지, IOPS를 프로비저닝하여 마이그레이션 중에 리소스 경합을 방지합니다.
• 마이그레이션을 시작하기 전에 AWS DMS 변경 데이터 캡처(CDC)를 사용하기 위한 사전 조건으로 소스 데이터베이스를 구성합니다.
• 마이그레이션을 위해 제한적 LOB 및 인라인 LOB와 같은 최적화된 LOB 설정을 사용합니다.
• 소스 데이터베이스에 워크로드가 많은 여러 테이블이 포함된 경우 테이블을 여러 태스크로 분할합니다. 소스 데이터베이스에서의 테이블 크기, 애플리케이션 트래픽 패턴, LOB 열 존재 여부에 따라 테이블을 분할합니다. 소스에서 테이블에 쓰기 트래픽이 높은 여러 LOB(TEXT 또는 JSON) 열이 있는 경우 해당 테이블에 대해 별도의 태스크를 생성합니다. 트랜잭션 일관성은 태스크 내에서 유지되므로 별도의 태스크에 있는 테이블은 공통 트랜잭션에 참여하지 않는 것이 중요합니다.
• 워크로드가 많은 소스 테이블에 병렬 전체 로드 메커니즘을 사용하여 마이그레이션 시간을 줄입니다. 자세한 정보는 선택한 테이블, 뷰 및 컬렉션에 병렬 로드 사용을 참조하세요.
• 전체 로드 마이그레이션 중에 대상 테이블의 외래 키 제약 조건을 해제합니다.
• 복제의 CDC 단계를 시작하기 전에 대상 데이터베이스에 보조 인덱스를 추가합니다.
• Amazon RDS 기본 사용자에게는 기본 스키마 테이블에 대한 삭제 및 재생성 권한이 없습니다. 따라서 AWS DMS를 사용하여 소스에서 기본 데이터베이스 또는 스키마 테이블을 마이그레이션하지 마세요.
• AWS DMS가 성공적으로 마이그레이션할 수 있는 데이터 유형에 대한 자세한 정보는 AWS DMS를 사용하여 MySQL에서 MySQL로 데이터 마이그레이션 문서를 참조하세요.
• 일괄 적용 CDC 방법을 사용하기 전에 기본 트랜잭션 CDC 적용을 사용하여 워크로드를 테스트합니다. 자세한 정보는 DMS 일괄 적용 기능을 사용하여 CDC 복제 성능을 개선하려면 어떻게 해야 합니까?를 참조하세요.
• 프로덕션 마이그레이션을 시작하기 전에 다른 QA/DEV 데이터베이스 환경에서 동일한 프로덕션 데이터를 사용하여 마이그레이션을 테스트합니다. 프로덕션 마이그레이션을 수행할 때는 동일한 AWS DMS 구성을 사용해야 합니다.

자세한 내용은 AWS DMS 마이그레이션 성능 개선을 참조하세요.

소스 및 대상 데이터베이스에서 권장되는 구성 및 방법 사용

1. 대상 MySQL/PostgreSQL 데이터베이스에 테이블 DDL을 수동으로 미리 생성합니다. 그런 다음 대상 준비 모드를 DO_DOTHING”/"TRUNCATE로 설정해서 AWS DMS 태스크를 생성하여 데이터만 마이그레이션합니다.

소스 MySQL 데이터베이스의 데이터 없이 덤프를 생성하려면 다음 명령을 실행합니다.

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

이 명령은 데이터 없이 소스에서 DDL 구조를 덤프합니다.

그리고 다음 명령을 실행하여 대상에서 DDL 구조를 복원합니다.

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

또는 DROP AND CREATE 대상 준비 모드를 사용하여 AWS DMS가 대상에 테이블을 생성하도록 허용할 수 있습니다. 그런 다음 CDC 단계에 대한 태스크를 재개하기 전에 3단계로 건너뛰어 테이블을 변경하고 보조 인덱스와 같은 누락된 객체를 추가합니다.

참고: 기본적으로 AWS DMS는 프라이머리 키 또는 고유 키만 사용하여 대상에 테이블을 생성합니다. 다른 객체는 대상 MySQL 데이터베이스로 마이그레이션되지 않습니다.

2. 전체 로드 중에는 AWS DMS가 외래 키 관계형 테이블을 식별하지 않습니다. 데이터를 임의로 로드하므로 대상 데이터베이스에 외래 키 검사가 설정되어 있으면 테이블 로드가 실패할 수 있습니다. 대상 MySQL 엔드포인트에서 이 추가 연결 속성(ECA)을 사용하여 이 AWS DMS 세션에 대한 외래 키 검사를 해제합니다.

initstmt=SET FOREIGN_KEY_CHECKS=0;

자세한 정보는 MySQL 호환 데이터베이스를 AWS DMS의 대상으로 사용할 때의 추가 연결 속성을 참조하세요.

3. JSON 설정에서, Stop before applying cached changes(캐시된 변경 사항 적용 전에 태스크 중지)를 true로 설정하고, Stop after applying cached changes(캐시된 변경 사항 적용 후 태스크 중지)를 true로 설정합니다.

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

전체 로드가 완료된 후, 캐시된 변경 사항을 적용하기 전에 태스크가 중지됩니다. 태스크가 중지된 동안, 대상에 프라이머리 키 인덱스와 보조 인덱스를 생성합니다.

그런 다음 캐시된 변경 사항을 적용한 후 태스크가 다시 중지되므로 태스크를 다시 시작합니다. 그런 다음 AWS DMS 검증 출력 또는 수동 확인을 사용하여 마이그레이션된 데이터를 확인한 후 CDC 복제 단계에서 태스크를 다시 시작합니다. 이 단계를 완료하면 CDC 복제를 재개하기 전에 문제를 식별하고 해결할 수 있습니다.

4.    태스크 전체 로드 설정에서 commitRate 설정을 조정하여 소스로부터 데이터 추출 속도를 높입니다. 기본값은 10,000이므로 소스 테이블에서 많은 양의 데이터를 마이그레이션하는 경우 이 설정을 조정합니다.

CommitRate=50000

참고: commitRate를 더 높은 값으로 변경하면 성능에 영향을 줄 수 있으므로 모니터링을 통해 복제 인스턴스에 충분한 메모리가 있는지 확인해야 합니다.

5.    대상 엔드포인트에 이 ECA를 추가하여 대상 MySQL로 데이터를 전송하는 데 사용되는 .csv 파일의 최대 크기(KB)를 지정합니다. 기본값은 32,768KB(32MB)이며 유효한 값의 범위는 1~1,048,576KB(최대 1.1GB)입니다.

maxFileSize=250000;

참고: 전체 로드에 MySQL, Aurora 또는 MariaDB와 같은 대상 인스턴스를 사용하는 경우, 이 옵션을 사용하여 AWS DMS가 백그라운드에서 .csv 파일을 생성하여 대상 인스턴스로 데이터를 로드하도록 허용합니다. 32MB~1GB의 값을 사용합니다. 하지만 대상 인스턴스가 처리할 수 있는 양도 고려해야 합니다. 1GB의 .csv 파일을 로드하는 태스크가 여러 개 있는 경우, 이로 인해 대상 인스턴스에 오버헤드가 발생할 수 있습니다. 대상에 높은 컴퓨팅 성능을 갖춘 인스턴스가 있는지 확인합니다.

6.    성능 향상을 위해 제한적 LOB 또는 인라인 LOB 설정을 사용합니다.

제한적 LOB 모드: 제한적 LOB 모드를 사용하는 경우 LOB 열 데이터의 최대 크기를 지정합니다. 이를 통해 AWS DMS는 리소스를 사전 할당하고 LOB를 대량으로 적용할 수 있습니다. LOB 열의 크기가 태스크에 지정된 크기를 초과하면 AWS DMS가 데이터를 잘라냅니다. 그러면 AWS DMS가 AWS DMS 로그 파일에 경고를 보냅니다. 제한적 LOB 모드를 사용하면 성능이 개선될 수 있지만, 태스크를 실행하기 전에 소스에 있는 데이터의 최대 LOB 크기를 식별해야 합니다. 그런 다음 최대 LOB 크기 파라미터를 지정합니다. 태스크를 처리하기에 충분한 메모리가 복제 인스턴스에 할당되어 있는지 확인하는 것이 모범 사례입니다.

인라인 LOB 모드: 인라인 LOB 모드를 사용하는 경우, 작은 LOB와 큰 LOB를 모두 복제함으로써 데이터를 자르거나 태스크 성능을 저하시키지 않고 LOB를 마이그레이션할 수 있습니다. 먼저 InlineLobMaxSize 파라미터의 값을 지정합니다. 이 파라미터는 전체 LOB 모드가 true로 설정된 경우에만 사용할 수 있습니다. AWS DMS 태스크는 작은 LOB를 인라인으로 전송하므로 더 효율적입니다. 그런 다음 AWS DMS는 소스 테이블에서 조회를 수행하여 전체 LOB 모드에 지정된 크기보다 큰 LOB를 마이그레이션합니다. 그러나 인라인 LOB 모드는 전체 로드 단계 중에만 작동합니다.

참고: 태스크에 대한 태스크 설정을 지정할 때 InlineLobMaxSize를 설정해야 합니다.

이러한 쿼리를 실행하여 LOB 크기를 확인한 다음 최대 LOB 크기를 입력합니다.

LOB 열이 있는 테이블을 나열합니다.

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

LOB 열의 크기를 확인합니다.

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

모든 테이블의 LOB 열 크기를 확인한 다음 최대 LOB 크기(K)에 최대 크기를 입력합니다.

63KB보다 큰 값으로 최대 LOB 크기(K) 옵션을 사용하면 제한적 LOB 모드에서 실행되도록 구성된 전체 로드의 성능에 영향을 줍니다. 전체 로드 중에 AWS DMS는 최대 LOB 크기(k) 값에 커밋 속도를 곱하여 메모리를 할당합니다. 그리고 해당 곱의 값에 LOB 열 수를 곱합니다.

AWS DMS가 해당 메모리를 사전 할당할 수 없는 경우 AWS DMS는 스왑 메모리를 사용하기 시작합니다. 이는 전체 로드 성능에 영향을 줍니다. 따라서 제한적 LOB 모드를 사용할 때 성능 문제가 발생하는 경우, 허용 가능한 성능 수준에 도달할 때까지 커밋 속도를 줄이세요. 또는 테이블의 LOB 분포를 먼저 확인한 후 지원되는 엔드포인트에 대해 인라인 LOB 모드 사용을 고려하세요.

자세한 정보는 AWS DMS 태스크의 소스 데이터베이스에 대한 LOB 지원 설정을 참조하세요.

---

관련 정보

AWS DMS를 사용하여 MySQL에서 Amazon RDS로 마이그레이션

데이터베이스 마이그레이션 단계별 시연