AWS Database Migration Service - 단계별 마이그레이션 가이드

: Copyright 2018 Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.

Table of Contents 단계별 연습... 1 Amazon Web Services(AWS)로 데이터베이스 마이그레이션... 2 AWS Migration Tool... 2 이 가이드의 연습 단계... 2 온프레미스 Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션... 4 비용... 4 마이그레이션 고급 개요... 5 1단계: Oracle 원본 데이터베이스 준비... 5 2단계: Aurora MySQL 대상 데이터베이스 시작 및 준비... 5 3단계: 복제 인스턴스 시작... 6 4단계: 원본 엔드포인트 생성... 6 5단계: 대상 엔드포인트 생성... 6 6단계: 마이그레이션 작업 생성 및 실행... 7 마이그레이션 단계별 지침... 8 1단계: Oracle 원본 데이터베이스 구성... 8 2단계: Aurora 대상 데이터베이스 구성... 10 3단계: 복제 인스턴스 생성... 11 4단계: Oracle 원본 엔드포인트 생성... 13 5단계: Aurora MySQL 대상 엔드포인트 생성... 15 6단계: 마이그레이션 작업 생성... 16 7단계: 마이그레이션 작업 모니터링... 21 문제 해결... 21 마이그레이션을 위한 샘플 데이터베이스 사용... 22 Amazon RDS Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션... 23 비용... 24 사전 조건... 25 마이그레이션 아키텍처... 25 단계별 마이그레이션... 26 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작... 27 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치... 32 3단계: Oracle DB Instance와의 연결을 테스트하고 샘플 스키마 생성... 34 4단계: Aurora MySQL DB 인스턴스와의 연결을 테스트합니다.... 38 5단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 Aurora MySQL로 변환합니다.... 40 6단계: 스키마 변환 검증... 50 7단계: AWS DMS 복제 인스턴스를 생성합니다.... 53 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다.... 54 9단계: AWS DMS 마이그레이션 작업 생성 및 실행... 57 10단계: AWS DMS 마이그레이션이 성공적으로 완료되었는지 확인... 60 11단계: 연습 리소스 삭제... 62 다음 단계... 63 AWS CloudFormation 템플릿, SQL 스크립트 및 기타 리소스... 63 참조... 63 SQL Server 데이터베이스를 Amazon Aurora MySQL로 마이그레이션... 65 사전 조건... 65 단계별 마이그레이션... 66 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치... 66 2단계: Microsoft SQL Server 원본 데이터베이스 구성... 67 3단계: Aurora MySQL 대상 데이터베이스 구성... 69 4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다.... 69 5단계: AWS DMS 복제 인스턴스 생성... 77 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다.... 78 7단계: AWS DMS 마이그레이션 작업 생성 및 실행... 82 8단계: Aurora MySQL로 전환... 85 iii

문제 해결... 85 Oracle 데이터베이스를 PostgreSQL로 마이그레이션... 87 사전 조건... 87 단계별 마이그레이션... 88 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치... 88 2단계: Oracle 원본 데이터베이스 구성... 89 3단계: PostgreSQL 대상 데이터베이스 구성... 92 4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변 환합니다.... 92 5단계: AWS DMS 복제 인스턴스 생성... 100 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다.... 101 7단계: AWS DMS 마이그레이션 작업 생성 및 실행... 105 8단계: PostgreSQL로 전환... 108 마이그레이션 롤백... 109 문제 해결... 109 Amazon RDS for Oracle Database를 Amazon Redshift로 마이그레이션... 111 사전 조건... 111 마이그레이션 아키텍처... 112 단계별 마이그레이션... 113 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작... 114 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치... 119 3단계: Oracle DB Instance와의 연결을 테스트하고 샘플 스키마 생성... 122 4단계: Amazon Redshift 데이터베이스와의 연결을 테스트합니다.... 126 5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환... 127 6단계: 스키마 변환 검증... 135 7단계: AWS DMS 복제 인스턴스 생성... 136 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다.... 137 9단계: AWS DMS 마이그레이션 작업 생성 및 실행... 140 10단계: AWS DMS 마이그레이션이 성공적으로 완료되었는지 확인... 144 11단계: 연습 리소스 삭제... 146 다음 단계... 147 참조... 147 MySQL 호환 데이터베이스를 AWS로 마이그레이션... 148 MySQL 호환 데이터베이스를 Amazon Aurora MySQL로 마이그레이션... 149 Amazon S3를 사용하여 외부 MySQL 데이터베이스의 데이터를 Amazon Aurora MySQL로 마이그레이 션... 149 사전 조건... 149 1단계: DB 클러스터로 복원할 파일 백업... 152 2단계: Amazon S3 버킷에 파일 복사... 153 3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원... 153 mysqldump를 사용하여 MySQL에서 Amazon Aurora MySQL로 마이그레이션... 159 Amazon RDS MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션... 159 RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션... 160 문서 이력... 167 iv

단 계별 연습 (AWS DMS)를 사용하여 Oracle, PostgreSQL, Microsoft SQL Server, Amazon Redshift, Amazon Aurora, MariaDB, MySQL과 같이 가장 널리 사용되는 상용 및 오픈 소스 데이터 베이스와의 데이터 마이그레이션을 수행할 수 있습니다. 이 서비스는 Oracle에서 Oracle로의 동종 마이그레 이션뿐만 아니라 Oracle에서 MySQL로 또는 MySQL에서 MySQL과 호환되는 Amazon Aurora로 등 서로 다 른 데이터베이스 플랫폼 간 이종 마이그레이션도 지원합니다. 원본 또는 대상 데이터베이스는 AWS 서비스 에 있어야 합니다. 이 가이드를 통해 샘플 데이터를 AWS로 마이그레이션하는 단계별 연습을 진행할 수 있습니다: Amazon Web Services(AWS)로 데이터베이스 마이그레이션 (p. 2) 온프레미스 Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 4) Amazon RDS Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 23) SQL Server 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 65) Oracle 데이터베이스를 PostgreSQL로 마이그레이션 (p. 87) Amazon RDS for Oracle Database를 Amazon Redshift로 마이그레이션 (p. 111) MySQL 호환 데이터베이스를 AWS로 마이그레이션 (p. 148) MySQL 호환 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 149) 1

AWS Migration Tool Amazon Web Services(AWS)로 데이 터베이스 마이그레이션 AWS Migration Tool 여러 AWS 도구와 서비스를 사용하여 외부 데이터베이스의 데이터를 AWS로 마이그레이션할 수 있습니다. 마이그레이션할 데이터베이스 유형에 따라 데이터베이스 엔진의 기본 마이그레이션 도구가 효과적인지도 알 수 있습니다. (AWS DMS)를 통해 데이터베이스를 AWS로 효율적이고 안전하게 마이그 레이션할 수 있습니다. 마이그레이션하는 동안 소스 데이터베이스가 변함없이 운영되어 데이터베이스를 사 용하는 애플리케이션의 가동 중지 시간을 최소화할 수 있습니다. AWS DMS를 사용하면 가장 널리 사용되는 상용 및 오픈 소스 데이터베이스로 Oracle 데이터를 마이그레이션할 수 있습니다. AWS DMS는 대상 데이터베이스에 데이터, 테이블 및 기본 키를 대상 데이터베이스로 마이그레이션 합니다. 다른 모든 데이터베이스 요소는 마이그레이션되지 않습니다. 예를 들어, Oracle 데이터베이스를 MySQL과 호환되는 Amazon Aurora로 마이그레이션하는 경우, AWS DMS와 함께 AWS Schema Conversion Tool을 사용해야 합니다. AWS Schema Conversion Tool(SCT)은 보기, 저장 프로시저 및 함수를 포함하여 소스 데이터베이스 스키 마 및 사용자 지정 코드 대부분을 대상 데이터베이스와 호환되는 형식으로 자동으로 변환하여 이종 데이터 베이스를 쉽게 마이그레이션하도록 해줍니다. 자동으로 변환할 수 없는 코드는 수동으로 변환할 수 있도록 명확하게 표시됩니다. 이 도구를 사용하여 원본 Oracle 데이터베이스를 Amazon RDS 또는 EC2의 Amazon Aurora MySQL, MySQL 또는 PostgreSQL 대상 데이터베이스로 변환할 수 있습니다. AWS DMS와 AWS SCT가 다른 별개의 도구이며 각기 다른 요구 사항에 부합한다는 점, 그리고 마이그레이 션 프로세스에서 서로 상호 작용하지 못한다는 점을 이해하고 있어야 합니다. DMS 모범 사례에 따라 이 자 습서의 마이그레이션 방법이 아래에 간략하게 소개되어 있습니다. AWS DMS는 미니멀리스트 접근 방식을 취하고 기본 키가 있는 테이블 등의 데이터를 효율적으로 마이그 레이션하는 데 필요한 해당 개체만을 생성합니다. 따라서 DMS를 사용하여 외래 키나 제약 조건 없이 데이 터와 함께 테이블을 로드합니다. (SCT를 사용하여 테이블 스크립트를 생성하고 나서 DMS를 통해 로드를 생성하기 전에 대상에서 SCT를 생성합니다. SCT 활용: 문제를 식별하기 위한 스키마 변환에 대한 제한 사항 및 조치 외래 키와 제약 조건을 포함한 대상 스키마를 생성하려면 원본에서 대상으로의 절차 및 보기 등의 코드를 변환하고 대상에서 적용하려면 Oracle 데이터베이스 마이그레이션의 유형과 크기는 사용해야 하는 도구 결정에 큰 영향을 줍니다. 예를 들 어, AWS의 Oracle 데이터베이스에서 다른 데이터베이스 엔진으로 마이그레이션하는 다른 유형의 마이그레 이션 효과를 극대화하려면 AWS DMS를 수행합니다. AWS에서 Oracle 데이터베이스를 Oracle 데이터베이 스로 마이그레이션하는 같은 유형의 마이그레이션 효과를 극대화하려면 기본 Oracle 도구를 사용합니다. 이 가이드의 연습 단계 온프레미스 Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 4) 2

이 가이드의 연습 단계 Amazon RDS Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 23) SQL Server 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 65) Oracle 데이터베이스를 PostgreSQL로 마이그레이션 (p. 87) Amazon RDS for Oracle Database를 Amazon Redshift로 마이그레이션 (p. 111) MySQL 호환 데이터베이스를 AWS로 마이그레이션 (p. 148) MySQL 호환 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 (p. 149) 3

비용 온프레미스 Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레 이션 다음에서는 고급 개요와 함께 (AWS DMS)와 AWS Schema Conversion Tool(AWS SCT)을 사용하여 온프레미스 Oracle 데이터베이스(소스 엔드포인트)를 MySQL과 호환되는 Amazon Aurora(대상 엔드포인트)로 마이그레이션하는 과정을 보여 주는 완벽한 단계별 연습을 다룹니다. AWS DMS는 데이터를 Oracle 원본에서 Aurora MySQL 대상으로 마이그레이션합니다. 또한 AWS DMS는 원본 데이터베이스에서 나타나는 데이터 조작 언어(DML) 및 데이터 정의 언어(DDL) 변경 사항을 캡처하고 대상 데이터베이스에 이 변경 사항을 적용합니다. 이런 방식으로 AWS DMS를 통해 원본과 대상 데이터베이 스를 서로 지속적으로 동기화할 수 있습니다. 데이터 마이그레이션을 수월하게 진행하기 위해 필요에 따라 DMS는 대상 데이터베이스에서 테이블과 기본 키 인덱스를 생성합니다. 그렇지만, AWS DMS는 특히 데이터 마이그레이션과 관련되지 않은 보조 인덱스, 시퀀스, 기본값, 저장된 절 차, 트리거, 동의어, 보기 및 기타 스키마 객체를 마이그레이션하지 않습니다. 이 객체를 Aurora MySQL 대상 에 마이그레이션하려면 AWS Schema Conversion Tool을 사용합니다. Amazon 샘플 데이터베이스 사용하여 진행해 볼 것을 적극 권장합니다. 샘플 데이터베이스를 사용하고 샘플 데이터베이스 사본을 가져오는 방법에 대한 지침이 나온 자습서를 확인하려면 마이그레이션을 위한 샘플 데 이터베이스 사용 (p. 22) 섹션을 참조하십시오. 이전에 AWS DMS를 사용했거나 읽기보다 마우스 클릭을 선호하는 경우에는 고급 개요를 사용해야 합니다. 세부 정보가 필요하고 보다 신중한 접근 방식을 취해야 하는 경우(또는 문제가 생긴 경우), 단계별 지침을 참 조하는 것이 좋습니다. 주제: 온프레미스 Oracle에서 Amazon RDS의 Aurora MySQL 또는 MySQL로 마이그레이션 시간: 비용: 원본 데이터베이스: Oracle 대상 데이터베이스: Amazon Aurora MySQL/MySQL 제한 사항: Oracle Edition: Enterprise, Standard, Express 및 Personal Oracle 버전: 10g(10.2 이상), 11g, 12c(Amazon Relational Database Service(Amazon RDS)에서는 11g 이 상이 필요함.) MySQL 또는 관련 데이터베이스 버전: 5.5, 5.6, 5.7, MariaDB, Amazon Aurora MySQL 문자 집합: utf8mb4는 현재 지원되지 않습니다. 비용 AWS DMS에는 아직 계산기가 포함되어 있지 않기 때문에 예상 요금은 다음 표를 참조하십시오. 4

마이그레이션 고급 개요 사용자 PC 설정 외에도, 여러 AWS 구성 요소를 생성하여 마이그레이션 프로세스를 완료해야 합니다. AWS 구성 요소에는 다음이 포함됩니다. AWS 서비스 유형 설명 Amazon Aurora MySQL DB 인스턴스 db.r3.large 단일 AZ, 10GB 스 토리지, I/O 100만 개 AWS DMS 복제 인스턴스 시작 T2.large 복제 로그 보관을 위한 50GB의 스토 리지 포함 AWS DMS 데이터 전송 무료, 샘플 데이터 베이스에서 전송된 데이터 양 기준. 데이터 전송 매월 첫 1GB 무료 마이그레이션 고급 개요 AWS DMS를 사용하여 데이터를 Oracle에서 Aurora MySQL로 마이그레이션하려면 다음 단계를 진행합니 다. 이전에 AWS DMS를 사용했거나 읽기보다 마우스 클릭을 선호하는 경우에는 다음 요약이 마이그레이션 을 빠르게 시작하는 데 도움이 됩니다. 마이그레이션에 대한 세부 정보가 필요하거나 문제가 생긴 경우 단계 별 지침을 참조하십시오. 1단계: Oracle 원본 데이터베이스 준비 AWS DMS를 사용하여 Oracle 원본 데이터베이스의 데이터를 마이그레이션하려면 일부 준비 과정이 필요하 므로 모범 사례로서 몇 가지 추가 단계를 권장합니다. AWS DMS 계정 데이터를 마이그레이션하는 특정 용도에 적합한 별도의 계정을 생성하는 것이 좋습니 다. 이 계정에는 데이터를 마이그레이션하는 데 필요한 최소 권한 집합이 있어야 합니다. 이 권한에 대한 특정 세부 정보는 아래에 간략하게 나와 있습니다. 단순히 비프로덕션 데이터베이스에서 AWS DMS를 테 스트하는 데 관심이 있는 경우에는 어느 DBA 계정이라도 충분합니다. 보충 로깅 변경 사항을 캡처하려면, DMS를 사용할 수 있도록 보충 로깅을 활성화해야 합니다. 데이터베 이스 수준에서 보충 로깅을 활성화하려면, 다음 명령을 발행합니다. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 또한, AWS DMS에서는 각각의 테이블이 마이그레이션되어야 하므로, 최소 키 수준의 보충 로깅을 설정합 니다. 원본 연결을 위해 다음 추가 연결 파라미터를 포함하는 경우 AWS DMS는 이 보충 로깅을 자동으로 추가합니다. addsupplementallogging=y 원본 데이터베이스 데이터를 마이그레이션하려면, AWS DMS 복제 서버에 원본 데이터베이스에 대한 액 세스 권한이 필요합니다. 방화벽 규칙이 AWS DMS 복제 서버에 수신을 허용하는지 확인합니다. 2단계: Aurora MySQL 대상 데이터베이스 시작 및 준비 다음은 Aurora MySQL 인스턴스를 시작할 때 고려해야 하는 몇 가지 사항입니다. 5

3단계: 복제 인스턴스 시작 최상의 결과를 얻으려면, Aurora MySQL 인스턴스와 복제 인스턴스를 동일한 VPC에 배치하고 가능한 경 우에 동일한 가용 영역에 배치하는 것이 좋습니다. 데이터를 마이그레이션하기 위해 최소 권한을 가진 별도의 계정을 생성하는 것이 좋습니다. AWS DMS 계 정은 데이터가 마이그레이션되고 있는 모든 데이터베이스에 대해 다음 권한이 필요합니다. ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT 또한, AWS DMS에는 awsdms_control 데이터베이스에 대한 전체 액세스 권한이 있어야 합니다. 이 데이터 베이스에는 마이그레이션별로 AWS DMS에서 필요한 정보가 담겨 있습니다. 액세스 권한을 부여하려면, 다음 명령을 실행합니다. ALL PRIVILEGES ON awsdms_control.* TO 'dms_user' 3단계: 복제 인스턴스 시작 AWS DMS 서비스는 복제 인스턴스의 원본과 대상 데이터베이스에 연결됩니다. 다음은 복제 인스턴스를 시 작할 때 고려해야 하는 몇 가지 사항입니다. 최상의 결과를 얻으려면, 이 Aurora MySQL의 경우에 Aurora 인스턴스와 복제 인스턴스를 대상 데이터베 이스와 동일한 VPC 및 가용 영역에 배치하는 것이 좋습니다. 원본 또는 대상 데이터베이스가 복제 서버를 시작하는 VPC 외부에 있는 경우, 복제 서버를 공개적으로 액 세스할 수 있어야 합니다. AWS DMS는 상당히 많은 메모리와 CPU를 소모할 수 있습니다. 그렇지만, 필요에 따라 매우 쉽게 확장할 수 있습니다. 단일 복제 서버 또는 에서 여러 작업을 실행할 것으로 예상되는 경우 기본 스토리지는 대개 대다수 마이그레이션에 충분합니다. 4단계: 원본 엔드포인트 생성 AWS DMS가 Oracle 원본 데이터베이스에 액세스하려면, 원본 엔드포인트를 생성해야 합니다. 원본 엔드포 인트는 AWS DMS가 복제 서버에서 원본 데이터베이스에 연결하는 데 필요한 모든 정보를 정의합니다. 다음 은 원본 엔드포인트에 대한 일부 요구 사항입니다. 원본 엔드포인트는 복제 서버에서 액세스 가능해야 합니다. 이 작업을 허용하려면, 복제 서버를 화이트리 스트로 지정할 수 있도록 방화벽 규칙을 수정해야 할 수도 있습니다. AWS DMS 관리 콘솔에 복제 서버의 IP 주소가 나와 있습니다. AWS DMS가 변경 사항을 캡처할 수 있도록 Oracle에서 보충 로깅을 활성화해야 합니다. AWS DMS에서 보충 로깅을 자동으로 활성화하도록 하려면, Oracle 원본 엔드포인트의 추가 연결 속성에 다음을 추가해야 합니다. addsupplementallogging=y 5단계: 대상 엔드포인트 생성 AWS DMS가 Aurora MySQL 대상 데이터베이스에 액세스할 수 있도록 대상 엔드포인트를 생성해야 합니다. 대상 엔드포인트는 DMS가 Aurora MySQL 데이터베이스에 연결하는 데 필요한 모든 정보를 정의합니다. 대상 엔드포인트는 복제 서버에서 액세스 가능해야 합니다. 대상 엔드포인트가 액세스할 수 있도록 보안 그룹을 수정해야 할 수도 있습니다. 대상에서 데이터베이스를 미리 생성한 경우, 전체 로드 중에 외래 키 점검을 비활성화하는 것이 좋습니다. 이를 위해 추가 연결 속성에 다음을 연결해야 합니다. 6

6단계: 마이그레이션 작업 생성 및 실행 initstmt=set FOREIGN_KEY_CHECKS=0 6단계: 마이그레이션 작업 생성 및 실행 마이그레이션 작업에서는 데이터가 마이그레이션되는 위치와 방법을 AWS DMS에 지시합니다. 마이그레이 션 작업을 생성할 때에는 다음과 같이 마이그레이션 파라미터 설정을 고려해야 합니다. [Endpoints and replication server] 위에서 생성된 엔드포인트와 복제 서버를 선택합니다. 마이그레이션 유형 대다수의 경우에 [migrate existing data and replication ongoing changes]를 선택해야 합니다. 이 옵션을 통해 AWS DMS에서는 원본 데이터를 로드하는 동시에 데이터 변경 사항을 캡처합니다. 데이터 전체를 로드하고 나면, AWS DMS는 대기 중인 변경 사항을 모두 적용하고 작업이 중지될 때까지 원 본 및 대상 데이터베이스를 계속 동기화합니다. [Target table preparation mode ] AWS DMS에서 테이블을 생성하도록 하는 경우, [drop tables on target] 을 선택합니다. 대상 테이블을 생성하는 데 AWS Schema Conversion Tool과 같은 다른 방법을 사용하는 경 우, [truncate]를 선택합니다. [LOB 파라미터 ] AWS DMS만을 사용하려는 경우, [include LOB columns in replication], [Limited LOB mode]를 선택하고, [max LOB size to 16](16k임)을 설정합니다. LOB에 대한 자세한 내용은 단계별 지침의 세부 정보를 참조하십시오. [Enable logging ] 마이그레이션 문제를 쉽게 디버깅하려면 항상 로깅을 활성화합니다. [Table mappings ] Oracle에서 Aurora MySQL로 마이그레이션할 때에는 스키마, 테이블, 열 이름을 소 문자로 변환하는 것이 좋습니다. 이렇게 하려면, 사용자 지정 테이블 매핑을 생성합니다. 다음은 스키마 DMS_SAMPLE를 마이그레이션하고 스키마, 테이블 및 열 이름을 소문자로 변환하는 예제입니다. { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "transformation", "rule-id": "6", "rule-name": "6", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } }, { "rule-type": "transformation", "rule-id": "7", "rule-name": "7", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" 7

마이그레이션 단계별 지침 } }, { } ] } "rule-type": "transformation", "rule-id": "8", "rule-name": "8", "rule-action": "convert-lowercase", "rule-target": "column", "object-locator": { "schema-name": "%", "table-name": "%", "column-name": "%" } 마이그레이션 단계별 지침 다음에는 Oracle 데이터베이스를 온프레미스 환경에서 Amazon Aurora MySQL로 마이그레이션하는 단계별 지침이 나와 있습니다. 이 지침에서는 사용자가 AWS 데이터베이스 마이그레이션 서비스를 사용하기 위한 설정에 나오는 AWS DMS 사용을 위한 설정 단계를 이미 완료했다고 가정합니다. 항목 1단계: Oracle 원본 데이터베이스 구성 (p. 8) 2단계: Aurora 대상 데이터베이스 구성 (p. 10) 3단계: 복제 인스턴스 생성 (p. 11) 4단계: Oracle 원본 엔드포인트 생성 (p. 13) 5단계: Aurora MySQL 대상 엔드포인트 생성 (p. 15) 6단계: 마이그레이션 작업 생성 (p. 16) 7단계: 마이그레이션 작업 모니터링 (p. 21) 문제 해결 (p. 21) 1단계: Oracle 원본 데이터베이스 구성 (AWS DMS)에서 Oracle을 원본으로 사용하려면, 먼저 LogMiner에 정보를 제공할 수 있도록 ARCHIVELOG MODE가 켜져 있는지 확인해야 합니다. AWS DMS에서는 보관 로그의 정 보를 읽을 수 있도록 LogMiner를 사용하므로 AWS DMS에서 변경 사항을 캡처할 수 있습니다. AWS DMS가 이 정보를 읽을 수 있도록 AWS DMS에서 보관 로그를 필요로 하는 한 이 보관 로그가 데이터 베이스 서버에 보존되어 있는지 확인해야 합니다. 즉시 변경 사항 캡처를 시작하도록 작업을 구성하는 경우, 가장 긴 실행 트랜잭션의 기간보다 약간 더 오랫동안 보관 로그만을 보존해야 합니다. 대개 24시간 동안 보관 로그를 보존하면 충분합니다. 과거의 특정 시점에 시작하도록 작업을 구성하는 경우, 앞으로는 보관 로그를 사용할 수 있어야 합니다. ARCHIVELOG MODE를 활성화하고 사용자의 온프레미스 Oracle 데이터베이스에 서 로그 보존을 보장하기 위한 자세한 지침은 Oracle 설명서를 참조하십시오. 변경 사항을 캡처할 수 있도록 AWS DMS에서는 보충 로깅을 AWS DMS의 원본 데이터베이스에서 활성화해 야 합니다. 최소 보충 로깅은 데이터베이스 수준에서 활성화되어야 합니다. 또한 AWS DMS에서는 식별 키 로깅을 활성화해야 합니다. 이 옵션으로 인해 기본 키를 포함하는 행을 업데이트할 때마다(기본 키의 값이 변 경되지 않았을 경우에도) 데이터베이스는 행의 기본 키 열 전체를 다시 실행 로그 파일에 배치합니다. 데이터 베이스 또는 테이블 수준에서 이 옵션을 설정할 수 있습니다. Oracle 원본이 Amazon RDS에 있는 경우, 백업을 활성화한 경우에 한해 데이터베이스는 ARCHIVELOG MODE에 배치됩니다. 다음은 RDS 원본에 24시간 동안 보관 로그를 보존해주는 명령입니다. 8

1단계: Oracle 원본 데이터베이스 구성 exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24); Oracle 원본 데이터베이스를 구성하려면 1. 다음 명령을 실행하여 데이터베이스 수준에서 보충 로깅을 활성화합니다. 이때 AWS DMS에서는 다음 작업이 필요합니다. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; For RDS: exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add'); 2. 다음 명령을 사용하여 데이터베이스 수준에서 식별 키 보충 로깅을 활성화합니다. AWS DMS에서 필요 에 따라 보충 로깅을 자동으로 추가하거나 테이블 수준에서 키 수준 보충 로깅을 활성화하도록 허용하지 않을 경우 AWS DMS에서는 데이터베이스 수준에서 보충 키 로깅이 필요합니다. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; For RDS: exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add','primary KEY'); 3. 키 수준 보충 로깅을 활성화하면 원본 데이터베이스는 약간의 오버헤드를 발생시킵니다. 따라서 테이블 하위 집합만을 마이그레이션할 경우, 테이블 수준에서 키 수준의 보충 로깅을 활성화해야 할 수도 있습 니다. 테이블 수준에서 키 수준의 보충 로깅을 활성화하려면 다음 명령을 사용합니다. alter table table_name add supplemental log data (PRIMARY KEY) columns; 테이블에 기본 키가 없는 경우 옵션 2개가 있습니다. 테이블에서 첫 번째 고유 인덱스에 포함된 모든 열에 보충 로깅을 추가할 수 있습니다(인덱스 이름별 로 정렬). 테이블의 모든 열에서 보충 로깅을 추가할 수 있습니다. 테이블에서 열의 하위 집합(고유 인덱스에 포함된 열)에 보충 로깅을 추가하려면, 다음 명령을 실행합니 다. ALTER TABLE table_name ADD SUPPLEMENTAL LOG GROUP example_log_group (ID,NAME) ALWAYS; 모든 테이블 열에서 보충 로깅을 추가하려면, 다음 명령을 실행합니다. alter table table_name add supplemental log data (ALL) columns; 4. AWS DMS에서 사용하는 데이터베이스 계정을 생성하거나 구성합니다. AWS DMS 연결을 위해 AWS DMS에서 필요한 최소 권한을 가진 별도의 계정을 사용하는 것이 좋습니다. AWS DMS에서는 다음 권한 이 필요합니다. CREATE SELECT SELECT SELECT SESSION ANY TRANSACTION on V_$ARCHIVED_LOG on V_$LOG 9

2단계: Aurora 대상 데이터베이스 구성 SELECT on V_$LOGFILE SELECT on V_$DATABASE SELECT on V_$THREAD SELECT on V_$PARAMETER SELECT on V_$NLS_PARAMETERS SELECT on V_$TIMEZONE_NAMES SELECT on V_$TRANSACTION SELECT on ALL_INDEXES SELECT on ALL_OBJECTS SELECT on ALL_TABLES SELECT on ALL_USERS SELECT on ALL_CATALOG SELECT on ALL_CONSTRAINTS SELECT on ALL_CONS_COLUMNS SELECT on ALL_TAB_COLS SELECT on ALL_IND_COLUMNS SELECT on ALL_LOG_GROUPS SELECT on SYS.DBA_REGISTRY SELECT on SYS.OBJ$ SELECT on DBA_TABLESPACES SELECT on ALL_TAB_PARTITIONS SELECT on ALL_ENCRYPTED_COLUMNS * SELECT on all tables migrated 변경 사항(CDC)을 캡처하고 적용하려면 다음 권한도 필요합니다. EXECUTE on DBMS_LOGMNR SELECT on V_$LOGMNR_LOGS SELECT on V_$LOGMNR_CONTENTS LOGMINING /* For Oracle 12c and higher. */ * ALTER for any table being replicated (if you want DMS to add supplemental logging) Oracle 버전 11.2.0.3 이전에서는 다음 권한이 필요합니다. 보기가 표시되는 경우, 다음 권한이 필요합니 다. SELECT on DBA_OBJECTS /* versions before 11.2.0.3 */ SELECT on ALL_VIEWS (required if views are exposed) 2단계: Aurora 대상 데이터베이스 구성 원본 데이터베이스와 마찬가지로 연결되어 있는 사용자의 액세스 권한을 제한하는 것이 좋습니다. 또한 마이 그레이션 이후에 제거할 수 있는 임시 사용자를 생성할 수도 있습니다. CREATE USER 'dms_user'@'%' IDENTIFIED BY 'dms_user'; GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON <target database(s)>.* TO 'dms_user'@'%'; AWS DMS는 데이터베이스 awsdms_control의 대상에서 일부 제어 테이블을 사용합니다. 다음 명령은 dms_user가 awsdms_control 데이터베이스에 대한 필수 액세스 권한을 갖도록 해줍니다. 10

3단계: 복제 인스턴스 생성 GRANT ALL PRIVILEGES ON awsdms_control.* TO 'dms_user'@'%'; flush privileges; 3단계: 복제 인스턴스 생성 AWS DMS 복제 인스턴스는 원본과 대상 간에 실제 데이터 마이그레이션을 수행합니다. 복제 인스턴스도 마 이그레이션 중에 변경 사항을 캐시합니다. 복제 인스턴스가 갖는 CPU와 메모리 용량은 마이그레이션에 필 요한 전체 시간에 영향을 줍니다. 다음 절차에 따라 복제 인스턴스의 파라미터를 설정합니다. AWS DMS 복제 인스턴스를 생성하려면 1. AWS Management Console에 로그인하고 https://console.aws.amazon.com/dms/에서 AWS DMS 콘솔 을 열고 [Replication instances]를 선택합니다. AWS Identity and Access Management(IAM) 사용자로서 로그인한 경우에는 AWS DMS 액세스를 위한 적절한 권한이 있어야 합니다. 필요한 권한에 대한 자세한 내용은 AWS DMS 사용에 필요한 IAM 권한을 참조하십시오. 2. [Create replication instance]를 선택합니다. 3. [Create replication instance] 페이지에서 다음과 같이 복제 인스턴스 정보를 지정합니다. 이 파라미터의 경우... 수행할 작업 이름 여러 복제 인스턴스를 시작하거나 계정을 공유하려고 계획 한 경우, 여러 복제 인스턴스를 빠르게 구분하도록 해주는 이름을 선택합니다. 설명 양호한 설명은 다른 사람들에게 사용 중인 복제 인스턴스의 용도에 대한 아이디어를 제공하고 사고를 예방할 수 있습니 다. 인스턴스 클래스 AWS DMS는 상당히 많은 메모리와 CPU를 사용할 수 있습 니다. 대규모 데이터베이스(다수의 테이블)가 있거나 많은 LOB 데이터 유형을 사용하는 경우, 큰 인스턴스를 설정하는 것이 더 바람직할 수 있습니다. 다음 설명과 같이 여러 작업 을 실행하여 처리량을 개선할 수 있습니다. 여러 작업은 더 많은 리소스를 소모하고 큰 인스턴스를 필요로 합니다. 테스 트를 실행할 때 CPU와 메모리 소모량을 계속 확인해야 합 니다. 전체 용량의 CPU나 스왑 공간을 사용하고 있는 경우, 쉽게 확장할 수 있습니다. VPC 여기에서 복제 인스턴스를 시작하는 VPC를 선택할 수 있 습니다. 가능한 경우 원본이나 대상 데이터베이스(또는 이 모두)가 있는 동일한 VPC를 선택하는 것이 좋습니다. AWS DMS는 이 VPC 내에서 원본과 대상 데이터베이스에 액세스 해야 합니다. 데이터베이스 엔드포인트 중 하나 또는 모두가 이 VPC 밖에 있으면, AWS DMS 액세스를 허용하도록 방화 벽 규칙을 수정합니다. 다중 AZ 다중 AZ를 선택하는 경우, AWS DMS에서는 별도의 가용 영 역에서 기본 및 보조 복제 인스턴스를 시작합니다. 치명적인 디스크 장애가 발생한 경우, 기본 복제 인스턴스는 자동으로 보조 인스턴스로 장애 조치를 취합니다. 대다수의 경우에 마 이그레이션을 수행하는 경우 다중 AZ가 필요하지 않습니다. 초기 데이터 로드에 오랜 시간이 소요되고 원본과 대상 데이 터베이스 동기화를 상당한 시간 동안 유지해야 하는 경우, 11

3단계: 복제 인스턴스 생성 이 파라미터의 경우... 수행할 작업 다중 AZ 구성으로 마이그레이션 서버를 실행하는 것이 좋습 니다. [Publicly accessible] 4. 원본 또는 대상 데이터베이스가 복제 서버가 있는 VPC 외부 에 있는 경우, 복제 인스턴스를 공개적으로 액세스할 수 있 도록 해야 합니다. [Advanced] 섹션에서 다음 파라미터를 설정한 후 [Next]를 선택합니다. 옵션 수행할 작업 [Allocated storage (GB)] 스토리지는 주로 로그 파일과 캐시된 트랜잭션에서 소모합 니다. 캐시 트랜잭션에서 스토리지는 캐시된 트랜잭션을 디 스크에 기록해야 할 때에만 사용됩니다. 따라서 AWS DMS 는 스토리지를 많이 사용하지 않습니다. 일부 예외 사항은 다음과 같습니다. 상당한 트랜잭션 로드를 발생하는 매우 큰 테이블. 큰 테 이블을 로드하면 다소 시간이 걸릴 수 있으므로, 캐시된 트랜잭션은 큰 테이블 로드 중에 디스크에 기록될 가능성 이 더 높습니다. 캐시된 트랜잭션을 로드하기 전에 일시 중지되도록 구성 되는 작업입니다. 이 경우에 모든 테이블에서 전체 로드가 완료될 때까지 모든 트랜잭션이 캐시됩니다. 이 구성에서 상당량의 스토리지가 캐시된 트랜잭션에서 소모될 수 있 습니다. Amazon Redshift로 로드되고 있는 테이블을 사용하여 구 성된 작업입니다. 그렇지만, 이 구성은 Aurora MySQL가 대상일 때는 문제가 아닙니다. 대다수의 경우에 스토리지의 기본 할당량은 충분합니다. 그 렇지만, 항상 스토리지 관련 지표에 유의하고 기본 할당량보 다 더 많이 소모하게 되면 스토리지를 확장하는 것이 좋습니 다. [Replication Subnet Group] 다중 AZ 구성으로 실행하는 경우, 최소 2개의 서브넷 그룹 이 필요합니다. [Availability Zone] 가능한 경우, 대상 데이터베이스와 동일한 가용 영역에 기본 복제 서버를 배치합니다. [VPC Security group(s)] 보안 그룹을 사용하여 VPC에 대한 수신 및 송신을 제어할 수 있습니다. AWS DMS를 통해 하나 이상의 보안 그룹을 복 제 서버가 시작하는 VPC와 연결할 수 있습니다. [KMS master key] AWS DMS를 통해 모든 데이터는 KMS 암호화 키를 사용하 여 유휴 상태로 암호화됩니다. 기본적으로 AWS DMS는 사 용자의 복제 서버에서 새 암호화 키를 생성합니다. 그렇지만 필요에 따라 기존 키를 사용할 수 있습니다. 12

4단계: Oracle 원본 엔드포인트 생성 4단계: Oracle 원본 엔드포인트 생성 복제 인스턴스가 생성되는 동안 AWS Management Console을 사용하여 Oracle 원본 엔드포인트를 지정할 수 있습니다. 그렇지만, 복제 인스턴스는 연결을 테스트하는 데 사용되기 때문에 복제 인스턴스가 생성된 후 에는 연결을 테스트만할 수 있습니다. AWS 콘솔을 사용하여 원본 또는 대상 데이터베이스 엔드포인트를 지정하려면 1. AWS DMS 콘솔의 탐색 창에서 [Endpoints]를 선택합니다. 2. [Create endpoint]를 선택합니다. 아래와 같이 [Create database endpoint] 페이지가 나타납니다. 3. 원본 Oracle 데이터베이스에 대한 연결 정보를 지정합니다. 다음 표는 원본 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Endpoint type] [Source]를 선택합니다. [Endpoint Identifier] Oracle 엔드포인트의 식별자를 입력합니다. 엔드포인트의 식별자는 AWS 리전 내에서 고유해야 합니다. 소스 엔진 [oracle]을 선택합니다. [Server name] 데이터베이스가 온프레미스인 경우, AWS DMS가 복제 서 버의 데이터베이스와 연결하는 데 사용할 수 있는 IP 주소를 입력합니다. Amazon Elastic Compute Cloud(Amazon EC2) 또는 Amazon RDS에서 데이터베이스가 실행되고 있는 경 13

4단계: Oracle 원본 엔드포인트 생성 이 파라미터의 경우... 수행할 작업 우, 퍼블릭 DNS(Domain Name Service) 주소를 입력합니 다. 4. Port 데이터베이스가 연결을 위해 수신하고 있는 포트를 입력합 니다(Oracle 기본값은 1521). [SSL mode] 이 엔드포인트에서 연결 암호화를 활성화해야 하는 경우 Secure Sockets Layer(SSL) 모드를 선택합니다. 선택하는 모드에 따라 인증서와 서버 인증서 정보를 제공해야 할 수도 있습니다. 사용자명 AWS 계정 사용자 이름을 입력합니다. 마이그레이션별 AWS 계정을 생성하는 것이 좋습니다. [Password] 앞에 나온 사용자 이름의 암호를 입력합니다. [Advanced ] 탭을 선택하여 추가 연결 문자열과 암호화 키 값을 설정합니다. 옵션 수행할 작업 [Extra connection attributes] 여기에서 엔드포인트의 동작을 제어하는 추가 속성 값을 추 가할 수 있습니다. 여기에 나열된 속성은 가장 관련도가 높 은 일부 속성입니다. 전체 목록은 설명서를 참조하십시오. 세미콜론(;)을 사용하여 여러 항목을 서로 구분합니다. addsupplementallogging: AWS DMS는 이 옵션을 활성 화하는 경우(addSupplementalLogging=Y) 보충 로깅을 자동으로 추가합니다. uselogminerreader: 기본적으로 AWS DMS는 Oracle LogMiner를 사용하여 로그에서 변경 데이터를 캡처합니 다. AWS DMS는 또한 독자적인 기술을 활용하여 로그 구 문을 분석할 수 있습니다. Oracle 12c를 사용하고 LOBS 를 포함하는 테이블의 변경 사항을 캡처해야 하는 경우, 이것을 [No](useLogminerReader=N)로 설정합니다. numberdatatypescale: Oracle은 정밀도 또는 크기가 없는 NUMBER 데이터 형식을 지원합니다. 기본적으로 NUMBER는 정밀도가 38이고 크기가 10인 숫자(38,10)로 변환됩니다. FLOAT에서 유효한 값은 0 38 또는 1입니 다. archivedlogdestid: 이 옵션은 보관된 다시 실행 로 그의 대상을 지정합니다. 이 값은 $archived_log 테이 블의 DEST_ID 숫자와 같아야 합니다. 여러 로그 대상 (DEST_ID)을 사용할 때에는 보관된 다시 실행 로그의 위 치 식별자를 지정하는 것이 좋습니다. 그러면 시작 단계부 터 올바른 로그에 액세스하도록 보장하여 성능이 개선됩 니다. 이 옵션의 기본값은 0입니다. [KMS master key] 복제 스토리지와 연결 정보를 암호화하기 위해 사용할 암호 화 키를 선택합니다. [(Default) aws/dms]를 선택하면, 계정 및 리전과 연결된 AWS KMS 키가 사용됩니다. 엔드포인트를 저장하기 전에 테스트할 수 있습니다. 이 작업을 하려면, 테스트를 실시할 VPC 및 복제 인스 턴스를 선택합니다. 테스트의 일환으로서 AWS DMS는 엔드포인트와 연결된 스키마 목록을 새로 고칩니다. (이 원본 엔드포인트를 사용하여 작업을 생성할 때 이 스키마는 원본 옵션으로서 제공됩니다.) 14

5단계: Aurora MySQL 대상 엔드포인트 생성 5단계: Aurora MySQL 대상 엔드포인트 생성 그 다음, 대상 엔드포인트 설정을 지정하여 대상 Amazon Aurora MySQL 데이터베이스에 대한 정보를 제공 할 수 있습니다. 다음 표는 대상 설정에 대한 설명입니다. AWS Management Console을 사용하여 대상 데이터베이스 엔드포인트를 지정하려면 1. AWS DMS 콘솔의 탐색 창에서 [Endpoints]를 선택합니다. 2. [Create endpoint]를 선택합니다. 아래와 같이 [Create database endpoint] 페이지가 나타납니다. 3. 대상 Aurora MySQL 데이터베이스에 대한 연결 정보를 지정합니다. 다음 표는 대상 설정에 대한 설명입 니다. 이 파라미터의 경우... 수행할 작업 [Endpoint type] [Target]을 선택합니다. [Endpoint Identifier] Aurora MySQL 엔드포인트의 식별자를 입력합니다. 엔드포 인트의 식별자는 AWS 리전 내에서 고유해야 합니다. [Target Engine] [aurora]를 선택합니다. [Servername ] Aurora MySQL 인스턴스의 라이터 엔드포인트를 입력합니 다. 라이터 엔드포인트는 기본 인스턴스입니다. Port 인스턴스에 할당된 포트를 입력합니다. 15

6단계: 마이그레이션 작업 생성 4. 이 파라미터의 경우... 수행할 작업 [SSL mode] 이 엔드포인트에서 연결 암호화를 활성화해야 하는 경우 SSL 모드를 선택합니다. 선택하는 모드에 따라 인증서와 서 버 인증서 정보를 제공해야 할 수도 있습니다. 사용자명 마이그레이션을 위해 사용 중인 계정의 사용자 이름을 입력 합니다. 마이그레이션별 계정을 생성하는 것이 좋습니다. [Password] 앞에 나온 사용자 이름의 암호를 입력합니다. [Advanced ] 탭을 선택하여 필요에 따라 추가 연결 문자열과 암호화 키 값을 설정합니다. 옵션 수행할 작업 [Extra connection attributes] 여기에서 엔드포인트의 동작을 제어하는 추가 속 성 값을 입력할 수 있습니다. 여기에 나열된 속성 은 가장 관련도가 높은 일부 속성입니다. 전제 목 록은 설명서를 참조하십시오. 세미콜론(;)을 사용 하여 여러 항목을 서로 구분합니다. targetdbtype: 기본적으로 AWS DMS에서는 마이그레이션 중인 각 스키마별로 다른 MySQL 데이터베이스를 생성합니다. 때로는 여러 스 키마에서 단일 데이터베이스로 여러 객체를 결합해야 할 수도 있습니다. 이 작업을 하려면 이 옵션을 특정 데이터베이스로 설정합니다 (targetdbtype=specific_database). initstmt: 이 옵션을 사용하여 MySQL initstmt 연 결 파라미터를 호출하고 mysql initstmt가 수락 하는 모든 항목을 수락합니다. Aurora MySQL 대상을 사용할 때에는 흔히 외래 키 점검을 비 활성화하는 것이 유용합니다. 이 작업을 하려 면, 다음과 같이 initstmt 파라미터를 사용합니 다. initstmt=set FOREIGN_KEY_CHECKS=0 [KMS master key] 복제 스토리지와 연결 정보를 암호화하기 위해 사용할 암호화 키를 선택합니다. [(Default) aws/ dms]를 선택하면, 계정 및 리전과 연결된 AWS KMS 키가 사용됩니다. 엔드포인트를 저장하기 전에 테스트해 볼 수 있습니다. 이 작업을 하려면, 테스트를 실시할 VPC 및 복제 인 스턴스를 선택해야 합니다. 6단계: 마이그레이션 작업 생성 마이그레이션 작업을 생성할 때에는 데이터가 마이그레이션되는 방법을 정확하게 AWS DMS에 지시합니다. 작업 내에서 마이크레이션될 테이블, 이 테이블을 마이그레이션할 위치, 이 테이블을 마이그레이션할 방법을 정의합니다. 변경 캡처를 사용하여 AWS DMS 기능을 적용할 계획인 경우, 단일 작업 내에서 트랜잭션이 유 지되고 있음을 알고 있어야 합니다. 즉, 동일한 작업에서 단일 트랜잭션에 함께 참여하는 모든 테이블을 마이 그레이션해야 합니다. 16

6단계: 마이그레이션 작업 생성 AWS DMS 작업을 사용하여 마이그레이션할 스키마와 마이그레이션 유형을 지정할 수 있습니다. 기존 데이 터를 마이그레이션하거나, 지속적 변경 사항을 복제하거나, 또는 데이터 변경 사항만 복제할 수 있습니다. 이 연습에서는 기존 데이터만을 마이그레이션합니다. 마이그레이션 작업을 생성하려면 1. 탐색 창에서 [Tasks]를 선택합니다. 2. [Create Task]를 선택합니다. 3. [Create Task] 페이지에서 작업 옵션을 지정합니다. 다음 표는 설정에 대한 설명입니다. 옵션 수행할 작업 [Task name] 작업에는 항상 조직에 도움이 되는 설명 이름을 부여하는 것 이 좋습니다. [Task description] 작업 설명을 입력합니다. [Source endpoint] 원본 엔드포인트를 선택합니다. [Target endpoint] 대상 엔드포인트를 선택합니다. 복제 인스턴스 작업을 실행할 복제 인스턴스를 선택합니다. 원본과 대상 엔 드포인트는 인스턴스에서 액세스할 수 있어야 합니다. [Migration type] AWS DMS에서는 세 가지 마이그레이션 유형을 사용할 수 있습니다. [Migrate existing data:] 이 옵션을 선택하면 AWS DMS에서는 기존 데이터만을 마이그레이션합니다. 원본 데이터에 대한 변경 사항이 대 상에 캡처 및 적용되지 않습니다. 전체 로드 기간 동안 중 단을 감수할 수 있는 경우, 이 옵션을 통한 마이그레이션 은 쉽고 간편합니다. 이 메서드는 데이터베이스의 테스트 사본을 생성할 때 사용하기에 좋습니다. [Migrate existing data and replicate ongoing changes: ] 이 옵션을 통해 AWS DMS에서는 기존 데이터를 마이그 레이션하는 동안 변경 사항을 캡처합니다. AWS DMS에 서는 대량 데이터를 로드한 후에도 계속해서 변경 사항을 캡처하고 적용합니다. 결국 원본과 대상 데이터베이스는 동기화되어 가동 중지가 최소화된 마이그레이션이 가능 합니다. 이 작업을 수행하려면 다음 단계를 수행하십시오. 애플리케이션 종료 최종 변경 사항이 대상으로 흐르도록 허용 외래 키와 트리거 활성화와 같은 관리 작업 수행 새 대상 데이터베이스를 가리키는 애플리케이션 시작 Note AWS DMS는 대량 데이터를 테이블별로, 한 번 에 여러 <n> 테이블을 로드합니다. 전체 로드가 진행되면 AWS DMS는 가능한 한 신속하게 대상 테이블에 캐시된 변경 사항을 적용하기 시작합 니다. 대량 로드 중에 참조 무결성이 위반되므로, 전체 로드에서는 기존 외래 키를 비활성화해야 합니다. 전체 로드가 완료되고 나면, 대상 데이터 17

6단계: 마이그레이션 작업 생성 옵션 수행할 작업 베이스에는 무결성이 있고 변경 사항이 트랜잭 션으로 적용됩니다. [Replicate data changes only:] 경우에 따라서는 다른 메서드를 사용하여 대량 데이터를 로드하도록 선택할 수도 있습니다. 이 접근 방식은 대개 같은 유형의 마이그레이션을에만 적용됩니다. [Start task on create] 4. 상황에 따라서는 작업을 즉시 시작하는 것이 좋습니다. 때로 는 인스턴스가 로깅 수준을 변경할 수 있도록 작업 시작을 지연해야 할 수도 있습니다. 그 다음, 다음과 같이 [Advanced] 설정을 적용합니다. 옵션 수행할 작업 [Target table preparation mode] AWS DMS를 통해 로드 전에 대상 테이블이 준비되는 방식 을 지정할 수 있습니다. [Do nothing] - 이 옵션을 선택하면 AWS DMS에서는 테이블 을 준비하기 위한 어떤 작업도 하지 않습니다. 테이블 구조 는 그대로 유지되고 기존 데이터는 테이블에 남습니다. 이 메서드를 사용하여 여러 시스템의 데이터를 통합할 수 있습 니다. [Drop tables on target] - AWS DMS에서 자동으로 대상을 생성하도록 하는 경우 대개 이 옵션을 사용합니다. 이 옵션 을 선택하면 AWS DMS에서는 마이그레이션 전에 마이그레 이션할 테이블을 삭제 및 다시 생성합니다. [Truncate] - 대상 시스템에서 일부 또는 전체 테이블을 미리 생성할 경우 이 옵션을 선택하고, AWS Schema Conversion Tool을 사용할 수 있습니다. 이 옵션을 선택하면 AWS DMS 는 로드하기 전에 대상 테이블을 자릅니다. 대상 테이블이 없는 경우, AWS DMS에서는 자동으로 테이블을 생성합니 다. [Include LOB columns in replication] 대형 객체(LOB)는 때때로 시스템 사이에서 마이그레이션하 기 어려울 수 있습니다. AWS DMS에는 LOB 열을 튜닝할 때 도움이 되는 다양한 옵션이 있습니다. AWS DMS에서 어느 데이터 형식을 언제 LOBS로 고려하는지 확인하려면, AWS DMS 설명서를 참조하십시오. [Don't include LOB columns] - 다른 데이터베이스로 데이터 를 마이그레이션할 때에는 LOB 저장 방법을 재고해 볼 수 있으며, 특히 이종 마이그레이션에서 그러합니다. 이 작업을 수행할 경우, LOB 데이터를 마이그레이션할 필요가 없습니 다. [Full LOB mode] - [full LOB mode]에서 AWS DMS는 크기 에 상관 없이 모든 LOB를 원본에서 대상으로 마이그레이션 합니다. 이 구성에서 AWS DMS에는 예상할 수 있는 최대 크 기의 LOB 정보가 없습니다. 또한, LOB는 한 번에 하나씩, 조각별로 마이그레이션됩니다. 전체 LOB 모드는 매우 느릴 수 있습니다. 18

6단계: 마이그레이션 작업 생성 옵션 수행할 작업 [Limited LOB mode] - [limited LOB mode]에서 AWS DMS가 수용하는 최대 크기의 LOB를 설정합니다. 이 설정을 통해 AWS DMS는 메모리를 미리 할당하고 LOB 데이터를 대량 으로 로드할 수 있습니다. 최대 LOB 크기를 초과하는 LOB 는 잘리고 경고가 로그 파일에 발행됩니다. [ limited LOB mode]는 [full LOB mode]에 비해 상당한 성능 이점이 있습 니다. 가능하다면 [limited LOB mode] 사용을 권장합니다. Note Oracle을 통해 LOB는 가능할 때마다 VARCHAR 데이터 형식으로 처리됩니다. 이 접근 방식은 AWS DMS가 데이터베이스에서 데이터를 대량으로 가 져오므로, 다른 메서드보다 훨씬 빠릅니다. Oracle 에서 VARCHAR의 최대 크기는 64K이므로, Oracle 이 원본 데이터베이스일 때 64K 미만의 제한적인 LOB 크기가 최적입니다. 5. 6. [Max LOB size (K)] [limited LOB mode]에서 작업이 실행되도록 구성하면, 이 옵 션은 AWS DMS에서 수용하는 최대 크기의 LOB를 결정합 니다. 이 값보다 큰 LOB는 이 값으로 잘립니다. [LOB chunk size (K)] 작업을 [full LOB mode]를 사용하도록 구성하면, AWS DMS 는 LOB를 여러 조각으로 가져옵니다. 이 옵션은 각 조각의 크기를 결정합니다. 이 옵션을 설정하면, 네트워크 구성에서 허용된 최대 패킷 크기에 특히 유의해야 합니다. LOB 청크 크기가 최대 허용 패킷 크기를 초과하면, 연결 해제 오류가 나타날 수 있습니다. [Custom CDC start time] 이 파라미터는 데이터 변경 사항만을 복제하도록 구성된 작 업에 대한 것입니다. 이 파라미터는 변경 스트림에서 변경 사항을 찾기 시작하는 위치를 AWS DMS에 알려줍니다. [Enable logging] 항상 로깅을 활성화합니다. 추가 파라미터를 설정합니다. 옵션 수행할 작업 [Create control table(s) in target schema] AWS DMS는 대상 데이터베이스에서 일부 제어 테이블을 필요로 합니다. 기본적으로 이 테이블은 사용자 데이터와 동 일한 데이터베이스에서 생성됩니다. 이 파라미터를 통해 어 딘가에 이 아티팩트를 배치하도록 AWS DMS에 지시할 수 있습니다. [Maximum number of tables to load in parallel] AWS DMS는 테이블별로 데이터를 로드합니다. 이 파라미 터를 통해 AWS DMS가 동시에 로그할 테이블 개수를 제어 할 수 있습니다. 기본값은 대다수 상황에서 최적인 8입니다. 테이블 매핑 설정을 지정합니다. 테이블 매핑은 AWS DMS에 작업이 원본에서 대상으로 마이그레이션해야 하는 테이블을 지정해 줍니 다. 일부 설정이 AWS Management Console을 사용하여 적용될 수 있더라도 테이블 매핑은 JSON으로 표현됩니다. 또한, 테이블 매핑에는 대문자에서 소문자로 테이블 이름 변경과 같은 변환도 포함될 수 있 습니다. 19

6단계: 마이그레이션 작업 생성 AWS DMS는 원본 데이터베이스에서 각 (비시스템) 스키마별로 기본 테이블 매핑을 생성합니다. 대다수 경우에 테이블 매핑을 사용자 지정해야 합니다. 테이블 매핑을 사용자 지정하려면 사용자 지정 라디오 버튼을 선택합니다. 테이블 매핑 생성에 대한 세부 정보는 AWS DMS 설명서를 참조하십시오. 다음 테 이블 매핑의 기능은 다음과 같습니다. 마이그레이션에 DMS_SAMPLE 스키마를 포함합니다. 테이블 NFL_DATA, MLB_DATA, NAME_DATE, STADIUM_DATA를 제외합니다. 스키마, 테이블, 열 이름을 소문자로 변환합니다. { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "%" }, "rule-action": "include" }, { { "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "MLB_DATA" }, "rule-action": "exclude" }, "rule-type": "selection", "rule-id": "3", "rule-name": "3", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "NAME_DATA" }, "rule-action": "exclude" }, { "rule-type": "selection", "rule-id": "4", "rule-name": "4", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "NFL_DATA" }, "rule-action": "exclude" }, { "rule-type": "selection", "rule-id": "5", "rule-name": "5", "object-locator": { "schema-name": "DMS_SAMPLE", 20

7단계: 마이그레이션 작업 모니터링 } ] "table-name": "NFL_STADIUM_DATA" }, "rule-action": "exclude" },{ "rule-type": "transformation", "rule-id": "6", "rule-name": "6", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } }, { "rule-type": "transformation", "rule-id": "7", "rule-name": "7", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" } }, { "rule-type": "transformation", "rule-id": "8", "rule-name": "8", "rule-action": "convert-lowercase", "rule-target": "column", "object-locator": { "schema-name": "%", "table-name": "%", "column-name": "%" } } 7단계: 마이그레이션 작업 모니터링 콘솔의 3개 섹션에서 마이그레이션 작업 현황을 확인할 수 있습니다. 작업 모니터링 [Task Monitoring] 탭에는 전체 로드 처리량과 변경 캡처 및 적용 지연 시간에 대한 정보가 나와 있습니다. 테이블 통계 [Table Statistics] 탭에는 처리된 행 수와 처리된 트랜잭션 수에 대한 세부 정보와 DDL 작업 에 대한 정보가 나옵니다. 로그 [Logs] 탭에서 작업의 로그 파일을 볼 수 있습니다(로깅을 켰다고 가정함). 어떤 이유로든 작업에 실 패하면 해당 파일에서 오류를 찾습니다. 또한, 파일에서 경고를 찾을 수 있습니다. 작업에서 데이터 잘림은 로그 파일의 경고로 나타납니다. 필요에 따라 AWS 명령줄 인터페이스(CLI)를 사용하여 로깅 수준을 증가 시킬 수 있습니다. 문제 해결 원본으로서 Oracle을 사용하고 대상으로서 Aurora MySQL를 사용할 때 문제가 나타나는 가장 일반적이 두 영역은 보충 로깅과 대소문자 구분입니다. 21

마이그레이션을 위한 샘플 데이터베이스 사용 보충 로깅 Oracle을 통해 변경 데이터를 복제하려면 보충 로깅을 활성화해야 합니다. 그렇지만, 데이터베 이스 수준에서 보충 로깅을 활성화할 경우, 때로는 새 테이블을 생성할 때 보충 로깅을 계속 활성화해야 합 니다. 이 문제에 대한 최적의 해결책은 추가 연결 속성을 사용하여 DMS가 보충 로깅을 자동으로 활성화하 도록 허용하는 것입니다. addsupplementallogging=y 대소문자 구분: Oracle은 대소문자를 구분하지 않습니다(객체 이름을 따옴표로 묶지 않은 경우). 그렇지만, 텍스트는 대문자로 표시됩니다. 또한, AWS DMS는 기본적으로 대문자로 대상 객체를 명명합니다. 대다수 의 경우에 변환을 사용하여 스키마, 테이블 또는 열 이름을 소문자로 변경해야 합니다. 추가 팁을 보려면, AWS DMS 사용 설명서의 AWS DMS 문제 해결 섹션을 참조하십시오. Oracle별로 문제를 해결하려면, Oracle 문제 해결 섹션을 참조하십시오. http://docs.aws.amazon.com/dms/latest/userguide/ CHAP_Troubleshooting.html#CHAP_Troubleshooting.Oracle Aurora MySQL 및 MySQL 문제를 해결하려면, MySQL 문제 해결 섹션을 참조하십시오. http://docs.aws.amazon.com/dms/latest/userguide/ CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL 마이그레이션을 위한 샘플 데이터베이스 사용 Amazon에서 제공한 샘플 Oracle 데이터베이스를 사용하여 앞의 개요와 가이드를 잘 살펴보는 것이 좋습니 다. 이 데이터베이스는 간단한 스포츠 이벤트 및 티켓팅 시스템을 모방한 것입니다. 샘플 데이터베이스를 생 성하는 스크립트는 https://github.com/awslabs/aws-database-migration-samples에 있는.tar 파일의 일부입 니다. 샘플 데이터베이스를 빌드하려면,.tar 파일을 추출하고 README의 지침에 따라 파일을 설치합니다. 샘플에는 약 8-10GB의 데이터가 포함되어 있습니다. 이 샘플 데이터베이스에는 일부 트랜잭션을 생성하는 데 사용할 수 있는 ticketmanagment 패키지가 포함되어 있습니다. 트랜잭션을 생성하려면, SQL*Plus 또는 SQL Developer에 로그인하고 dms_sample로서 다음을 실행합니다. SQL>exec ticketmanagement.generateticketactivity(0.01,1000); 첫 번째 파라미터는 트랜잭션 지연 시간(초이고, 두 번째 파라미터는 생성할 트랜잭션 수입니다. 앞의 절차는 간단히 사람들에게 "티켓을 판매"합니다. 테이블 sporting_event_ticket 및 ticket_purchase_history에 업데이 트가 표시됩니다. 일부 티켓이 "판매된 후"에는 다음 명령을 사용하여 전송할 수 있습니다. SQL>exec ticketmanagement.generatetransferactivity(1,100); 첫 번째 파라미터는 트랜잭션 지연 시간(초이고, 두 번째 파라미터는 생성할 트랜잭션 수입니다. 이 절차도 sporting_event_ticket 및 ticket_purchase_history를 업데이트합니다. 22

Amazon RDS Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레 이션 본 연습에서는 와 AWS Schema Conversion Tool을 사용하여 다른 유형의 데이터베이스를 Amazon RDS Oracle에서 MySQL과 호환되는 Amazon Aurora로 마이그레이션하는 과정을 안내합니다. 다음은 입문용 실습이므로 모든 시나리오를 다루지 않지만 그러한 마이그레이션을 실행할 때 따 라야 하는 단계를 이해하는 데 도움이 됩니다. AWS DMS와 AWS SCT가 다른 별개의 도구이며 각기 다른 요구 사항에 부합한다는 점도 잘 알고 있어야 합 니다. 이들 도구는 마이그레이션 프로세스에서 서로 상호작용하지 않습니다. 고급 수준에서 이 마이그레이션 에 수반되는 단계는 다음과 같습니다. 1. AWS SCT를 사용하여 다음 작업 진행: Oracle에서 Aurora MySQL로의 변환 보고서를 실행하여 스키마 변환에 필요한 문제, 제한 사항 및 작업 을 확인합니다. 스키마 스크립트를 생성하고 대상에서 이것을 적용한 후 AWS DMS를 통해 데이터 로드를 실행합니다. AWS SCT는 절차 및 보기와 같은 객체에 대한 필수 코드 변환을 수행합니다. 2. AWS SCT에서 보고한 문제에 대한 해결책을 확인하고 구현합니다. 예를 들어, Amazon Aurora MySQL에 서 지원되지 않는 Oracle Sequence와 같은 객체 유형은 auto_increment 옵션을 사용하여 처리되어 대리 키를 채우거나 애플리케이션 계층에서 시퀀스 로직을 개발할 수 있습니다. 3. AWS DMS 데이터 로드에 영향을 줄 수 있는 외래 키 또는 다른 모든 제약을 비활성화합니다. 4. AWS DMS는 전체 로드 접근 방식을 사용하여 원본에서 대상으로 데이터를 로드합니다. AWS DMS가 로 드의 일부로서 대상에서 객체를 생성할 수 있더라도 최소한의 접근 방식에 따라 데이터를 효율적으로 마 이그레이션하므로 전체 스키마 구조가 원본에서 대상으로 복제되지 않습니다. 5. 추가 인덱스 생성과 같은 마이그레이션 후 활동을 수행하여 외래 키를 활성화하고 애플리케이션에서 필요 한 변경 사항을 적용하여 새 데이터베이스를 가리킵니다. 다음 연습에서는 사용자 지정 AWS CloudFormation 템플릿을 사용하여 Oracle 및 Amazon Aurora MySQL 용 Amazon RDS DB 인스턴스를 생성합니다. 그런 다음 SQL 명령 스크립트를 사용하여 샘플 스키마와 데이 터를 Amazon RDS Oracle DB 인스턴스에 설치한 후 Amazon Aurora MySQL로 마이그레이션합니다. 이 연습을 완료하기까지 약 2시간이 소요됩니다. AWS 리소스를 사용하여 이 작업을 완료하기까지 추정 비 용은 약 $5.00입니다. 추가 요금이 발생하지 않도록 이 연습이 끝날 때까지 반드시 지침에 따라 리소스를 삭 제해야 합니다. 항목 비용 (p. 24) 사전 조건 (p. 25) 마이그레이션 아키텍처 (p. 25) 단계별 마이그레이션 (p. 26) 다음 단계 (p. 63) AWS CloudFormation 템플릿, SQL 스크립트 및 기타 리소스 (p. 63) 23

비용 참조 (p. 63) 비용 본 연습에서는 AWS CloudFormation과 (AWS DMS) 리소스를 사용하여 Amazon Relational Database Service(Amazon RDS) 리소스를 프로비저닝합니다. 이 리소스를 프로비저닝 하면 AWS 계정에 시간당 요금이 부과됩니다. AWS Schema Conversion Tool에서는 비용이 부과되지 않습 니다. 즉, AWS DMS의 일부로 제공됩니다. 이 연습에 최소의 리소스만이 필요하더라도 이 리소스의 일부는 AWS 프리 티어에 적합하지 않습니다. 이 연 습이 끝나면 추가 요금이 발생하지 않도록 리소스를 삭제하는 섹션이 나옵니다. 연습을 마친 후 바로 리소스 를 삭제합니다. AWS에서 이 연습을 실행할 때 발생하는 요금을 추정하기 위해 AWS 월 사용량 계산기를 이용할 수 있습 니다. 그렇지만, AWS DMS 서비스는 이 계산기에 아직 포함되어 있지 않습니다. 다음 표에는 AWS DMS와 Amazon RDS Oracle Standard Edition Two의 요금이 나와 있습니다. AWS 서비스 인스턴스 유형 스토리지 및 I/O Amazon RDS Oracle DB 인스턴스, 라이선스 포함(Standard Edition Two), 단일 AZ db.m3.medium 단일 AZ, 10GB 스 토리지, GP2 Amazon Aurora MySQL DB 인스턴스 db.r3.large 단일 AZ, 10GB 스 토리지, I/O 100만 개 AWS DMS 복제 인스턴스 시작 t2.small 복제 로그 보관을 위한 50GB의 스토 리지 포함 AWS DMS 데이터 전송 무료 동일한 가용 영역에 있는 RDS 인스턴스의 AWS DMS와 데이터베이 스 간 데이터 전송 은 무료입니다. 데이터 전송 매월 첫 1GB 무료 이 연습을 2시간 동안 실행한다는 가정 하에 AWS 리소스에 대한 추정 요금은 다음과 같습니다. AWS 월 사용량 계산기를 사용하여 추정한 Amazon Aurora MySQL +10GB 스토리지 요금은 $1.78입니다. Amazon RDS Oracle SE2(라이선스 포함) + 10GB GP2 스토리지 비용(요금 사이트에 따라 추정)($0.226) * 2시간 + ($0.115) * 10GB는 $1.602입니다. 50GB GP2 스토리지를 지원하는 t2.small 인스턴스의 AWS DMS 서비스 비용(요금 사이트에 따라 추정) ($0.036) * 2시간은 $0.072입니다. 이 프로젝트를 실행하는 데 소요되는 총 추정 비용 = $1.78 + $1.602 + $0.072 = $3.454 약 $5.00. 이 요금은 다음 가정을 기반으로 합니다. 인터넷으로 전송되는 총 데이터 양은 기가바이트 미만이라고 가정합니다. 앞에 나온 요금 추정치는 RDS 및 DMS 서비스와 관련된 데이터 전송과 백업 요금이 프리 티어 한도 내에 있다고 가정한 것입니다. 24

사전 조건 Aurora MySQL 데이터베이스가 사용한 스토리지는 GB-월 단위 증분으로 청구되고, 사용된 I/O는 1백만 개 요청 단위 증분으로 청구됩니다. 동일한 가용 영역에 있는 RDS 인스턴스의 DMS와 데이터베이스 간 데이터 전송은 무료입니다. 사전 조건 이 연습을 완료하려면 다음 사전 요구 사항도 필요합니다. Amazon RDS, 해당 데이터베이스 기술 및 SQL에 대한 지식. 마이그레이션할 테이블 생성과 마이그레이션 확인을 위한 SQL 쿼리를 포함하는 사용자 지정 스크립트입 니다. 스크립트와 쿼리는 다름 링크에서 사용할 수 있습니다. 이 연습의 각 단계마다 파일을 다운로드할 수 있는 링크가 포함되어 있거나 해당 단계에 정확한 쿼리가 포함되어 있습니다. HR 스키마를 빌드하는 SQL 문 - https://dms-sbs.s3.amazonaws.com/oracle-hr-schema-build.sql. 스키마 콘텐츠의 유효성을 확인하는 SQL 쿼리 - (텍스트) https://dms-sbs.s3.amazonaws.com/ AWSDMSDemoStats.txt 및 (스프레드시트) https://dms-sbs.s3.amazonaws.com/ AWSDMSDemoStats.xlsx. AWS CloudFormation 템플릿 - https://dms-sbs.s3.amazonaws.com/ Oracle_Aurora_RDS_For_DMSDemo.template. AWS 리전에서 Amazon Relational Database Service(Amazon RDS)와 AWS Database Migration Service(AWS DMS) 인스턴스를 시작할 수 있도록 해주는 AWS Identity and Access Management(IAM) 자 격 증명을 가진 AWS 계정입니다. IAM 자격 증명에 대한 정보는 IAM 사용자 생성 섹션을 참조하십시오. Amazon Virtual Private Cloud(Amazon VPC) 서비스 및 보안 그룹에 대한 기본 지식. Amazon RDS에서 Amazon VPC를 사용하는 방법에 대한 정보는 가상 사설 클라우드(VPCs) 및 Amazon RDS 섹션을 참조하 십시오. Amazon RDS 보안 그룹에 대한 자세한 내용은 Amazon RDS 보안 그룹을 참조하십시오. AWS DMS의 지원 기능 및 제한 사항에 대한 이해 AWS DMS에 대한 자세한 내용은 AWS Database Migration Service란 무엇입니까? 를 참조하십시오. Oracle 및 Amazon Aurora MySQL에서 지원되는 데이터 형식 변환 옵션에 대한 정보입니다. 원본으로서 Oracle용 데이터 형식에 대한 정보는 에서 Oracle 데이터베이스를 원 본으로 사용 을 참조하십시오. 원본으로서 Amazon Aurora MySQL용 데이터 형식에 대한 정보는 AWS Database Migration Service에서 MySQL 호환 데이터베이스를 원본으로 사용 을 참조하십시오. AWS DMS에 대한 자세한 내용은 AWS DMS 설명서를 참조하십시오. 마이그레이션 아키텍처 이 예제에서는 AWS CloudFormation을 사용하여 데이터베이스 마이그레이션을 위한 단순 네트워크 토폴로 지를 생성하며, 여기에는 원본 데이터베이스, 복제 인스턴스, 동일한 VPC의 대상 데이터베이스가 포함됩니 다. AWS CloudFormation에 대한 자세한 내용은 CloudFormation 설명서를 참조하십시오. AWS CloudFormation을 통해 본 (AWS DMS) 연습에 필요한 AWS 리소 스를 프로비저닝합니다. 이 리소스에는 Oracle 및 Amazon Aurora MySQL용 VPC와 Amazon Relational Database Service(Amazon RDS) 인스턴스가 포함되어 있습니다. AWS CloudFormation을 통해 프로 비저닝하므로 프로세스가 간편해져 데이터 마이그레이션과 관련된 작업에 집중할 수 있습니다. AWS CloudFormation 템플릿에서 스택을 생성하면 다음 리소스를 프로비저닝합니다. 리전에서 퍼블릭 서브넷 2개를 지원하는 CIDR(10.0.0.0/24)을 사용한 VPC, 가용 영역(AZ) 1에서 주소가 10.0.0.0/26인 DBSubnet1, AZ 12에서 주소가 10.0.0.64/26인 DBSubnet2입니다. DBSubnet1과 DBSubnet2를 포함하는 DB 서브넷 그룹입니다. Oracle RDS Standard Edition Two의 배포 옵션 2개는 다음과 같습니다. 25

단계별 마이그레이션 라이선스 포함 Single-AZ 설정 db.m3 미디엄 또는 이에 준하는 인스턴스 클래스 포트 1521 기본 옵션 및 파리미터 그룹 Amazon Aurora MySQL DB 인스턴스의 배포 옵션은 다음과 같습니다. 복제본 없음 db.r3.large 또는 이에 준하는 인스턴스 클래스 포트 3306 기본 옵션 및 파리미터 그룹 입력 파라미터를 기반으로 컴퓨터 또는 0.0.0.0/0(어디에서든 액세스)에서 수신 액세스가 지원되는 보안 그 룹 사용자의 입력이 거의 필요 없도록 CloudFormation 템플릿을 설계했습니다. 최소 권장 구성으로 필요한 AWS 리소스를 프로비저닝합니다. 그렇지만, VPC CIDR 블록과 Amazon RDS 인스턴스 형식과 같은 일부 구성과 파라미터를 변경해야 하는 경우에는 언제든지 템플릿을 업데이트하십시오. AWS Management Console을 사용하여 복제 인스턴스, 엔드포인트 및 작업과 같은 AWS DMS 리소스를 프 로비저닝합니다. 로컬 컴퓨터에 SQL Workbench/J 및 AWS Schema Conversion Tool(AWS SCT)과 같은 클 라이언트 도구를 설치하여 Amazon RDS 인스턴스에 연결합니다. 다음은 이 연습에 해당하는 마이그레이션 아키텍처에 대한 그림입니다. 단계별 마이그레이션 다음 섹션에서는 Amazon Relational Database Service(Amazon RDS) Oracle 데이터베이스를 Amazon Aurora MySQL로 마이그레이션하기 위한 단계별 지침에 대해 다룹니다. 이 단계는 사용자가 이미 앞의 섹션 에서 설명한 원본 데이터베이스를 준비했다고 가정합니다. 26

항목 1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작 (p. 27) 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 (p. 32) 3단계: Oracle DB Instance와의 연결을 테스트하고 샘플 스키마 생성 (p. 34) 4단계: Aurora MySQL DB 인스턴스와의 연결을 테스트합니다. (p. 38) 5단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 Aurora MySQL로 변환 합니다. (p. 40) 6단계: 스키마 변환 검증 (p. 50) 7단계: AWS DMS 복제 인스턴스를 생성합니다. (p. 53) 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. (p. 54) 9단계: AWS DMS 마이그레이션 작업 생성 및 실행 (p. 57) 10단계: AWS DMS 마이그레이션이 성공적으로 완료되었는지 확인 (p. 60) 11단계: 연습 리소스 삭제 (p. 62) 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작 먼저 이 연습에서 필요한 AWS 리소스를 프로비저닝해야 합니다. 다음 연습에서는 AWS CloudFormation 템플릿을 사용하여 이 연습에 적합한 Amazon RDS 리소스 를 생성합니다. 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/cloudformation에서 AWS CloudFormation 콘솔을 엽니다. 2. [Create stack]을 선택합니다. 3. [Select Template ] 페이지에서 [Specify an Amazon S3 template URL ]을 선택하고 다음 URL을 인접한 텍스트 상자에 붙여 넣습니다. https://dms-sbs.s3.amazonaws.com/oracle_aurora_rds_for_dmsdemo.template 27

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 4. [Next]를 선택합니다. [Specify DB Details] 페이지에서 다음과 같이 파라미터 값을 입력합니다. 이 파라미터의 경우... 수행할 작업 [Stack Name ] [DMSdemo]를 입력합니다. [OracleDBName] 데이터베이스 고유 이름을 입력합니다. 이름은 문자로 시작 해야 합니다. 기본값은 ORCL입니다. [OracleDBUsername] Oracle 인스턴스를 관리할 관리(DBA) 사용자를 지정합니 다. 기본값은 oraadmin입니다. [OracleDBPassword] 관리 사용자 암호를 입력합니다. [AuroraDBUsername] Aurora MySQL 인스턴스를 관리할 관리(DBA) 사용자를 지 정합니다. 기본값은 auradmin입니다. [AuroraDBPassword] 관리 사용자 암호를 입력합니다. [ClientIP] 로컬 컴퓨터의 IP 주소를 CIDR(x.x.x.x/32) 형식으로 지정 합니다. whatsmyip.org에서 IP 주소를 가져올 수 있습니다. RDS 인스턴스의 보안 그룹은 이 IP 주소로의 수신을 허용합 니다. 기본값은 어디에서든 액세스 가능한 (0.0.0.0/0)이고, 권장되지 않습니다. 이 연습에서 IP 주소를 사용해야 합니 다. 28

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 5. [Next]를 선택합니다. 다음 [Options] 페이지에서 [Next]를 선택합니다. 29

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 6. [Review] 페이지에서 세부 정보를 검토하고 올바를 경우 [Create Stack]을 선택합니다. 이 CloudFormation 템플릿 실행에 따른 추정 비용을 확인하려면 [Cost]를 선택합니다. 7. AWS에서 Amazon RDS Oracle 및 Amazon Aurora MySQL 인스턴스를 사용하여 스택을 생성하기까지 약 20분 이상이 소요될 수 있습니다. 30

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 8. 스택 생성 후 [Stack], DMSdemo 스택, [Outputs] 진행률을 차례대로 선택합니다. JDBC 연결 문자열 [OracleJDBCConnectionString] 및 [AuroraJDBCConnectionString]을 기록해 두면 이 연습에서 나중에 Oracle 및 Aurora MySQL DB 인스턴스에 연결하는 데 사용할 수 있습니다. 31

2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 Note Oracle 12c SE Two 라이선스 버전 12.1.0.2.v4는 모든 리전에서 사용할 수 있습니다. 그렇지만, 일 부 리전에서는 Amazon Aurora MySQL를 사용할 수 없습니다. Amazon Aurora MySQL가 현재 출시 된 리전은 미국 동부(버지니아), 미국 서부(오레곤), EU(아일랜드), 아시아 태평양(도쿄), 아시아 태 평양(뭄바이), 아시아 태평양(시드니), 아시아 태평양(서울)입니다. Aurora MySQL 미출시 리전에서 스택을 생성하려고 하면, Invalid DB Engine for AuroraCluster 오류가 표시되면서 생성 에 실패합니다. 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 그 다음, 로컬 컴퓨터에 SQL 클라이언트 및 AWS Schema Conversion Tool(AWS SCT)를 설치합니다. 이 연습에서는 마이그레이션 확인을 위해 SQL Workbench/J 클라이언트를 사용하여 RDS 인스턴스에 연결 한다고 가정합니다. 권장되는 다른 소프트웨어 도구는 다음과 같습니다. JACK DB, JDBC를 통해 RDS 데이터베이스(Oracle 및 Aurora MySQL)를 사용하는 온라인 웹 인터페이스 DBVisualizer Oracle SQL Developer 32

2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 SQL 클라이언트 소프트웨어를 설치하려면 1. SQL Workbench/J 웹사이트에서 SQL Workbench/J를 다운로드한 후 로컬 컴퓨터에 설치합니다. 이 SQL 클라이언트는 무료로 제공되는 오픈 소스로서 DBMS에 종속되어 있지 않습니다. 2. Oracle Database 12.1.0.2 JDBC 드라이버(ojdbc7.jar)를 다운로드합니다. 3. MySQL 드라이버( mysql-connector-java-5.1.39-bin.jar)를 다운로드합니다. 4. SQL Workbench/J를 사용하여 다음 설명과 같이 Oracle 및 Aurora MySQL용 JDBC 드라이버를 구성하 여 연결을 설정합니다. 1. SQL Workbench/J에서 [File]을 선택한 후 [Manage Drivers]를 선택합니다. 2. 드라이버 목록에서 [Oracle]을 선택합니다. 3. [Open] 아이콘을 선택하고 나서 이전 단계에서 다운로드한 ojdbc.jar 파일을 선택합니다. [OK]를 선택합니다. 4. 드라이버 목록에서 MySQL을 선택합니다. 5. [Open] 아이콘을 선택하고 나서 이전 단계에서 다운로드한 MySQL JDBC 드라이버를 선택합니다. [OK]를 선택합니다. 33

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 그 다음, AWS 스키마 마이그레이션 도구와 필요한 JDBC 드라이버를 설치합니다. AWS 스키마 마이그레이션 도구와 JDBC 드라이버를 설치하려면 1. AWS Schema Conversion Tool 사용 설명서의 AWS Schema Conversion Tool 설치 및 업데이트에 서 AWS Schema Conversion Tool을 다운로드합니다.기본적으로 "C:\Program Files\AWS Schema Conversion Tool\AWS 디렉터리에 이 도구가 설치됩니다. 2. AWS Schema Conversion Tool을 시작합니다. 3. AWS Schema Conversion Tool의 [Settings]에서 [Global Settings]를 선택합니다. 4. [Global Settings]에서 [Driver]를 선택한 후 [Browse]를 선택하여 [Oracle Driver Path]를 찾습니다. JDBC Oracle 드라이버를 찾고 [OK]를 선택합니다. 그런 다음, [Browse]를 선택하여 [MySql Driver Path]를 찾 습니다. JDBC MySQL 드라이버를 찾고 [OK]를 선택합니다. [OK]를 선택하여 대화 상자를 닫습니다. 3단계: Oracle DB Instance와의 연결을 테스트하고 샘 플 스키마 생성 CloudFormation 스택을 생성한 후 SQL Workbench/J를 사용하여 Oracle DB 인스턴스 연결을 테스트하고 HR 샘플 스키마를 생성합니다. SQL Workbench/J를 사용하여 Oracle DB 인스턴스와의 연결을 테스트하고 샘플 스키마를 생성하 려면 1. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. 아래와 같이 다음 정보를 사 용하여 새 연결 프로필을 생성합니다. 이 파라미터의 경우... 수행할 작업 [New profile] 이름 RDSOracleConnection을 입력합니다. 34

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 2. 이 파라미터의 경우... 수행할 작업 드라이버 Oracle (oracle.jdbc.oracledriver)을 선택합니 다. URL 이전 단계에서 DMSdemo 스택의 출력 세부 정보를 검사했 을 때 기록한 [OracleJDBCConnectionString] 값을 사용합니 다. 사용자명 oraadmin을 입력합니다. [Password] AWS CloudFormation 템플릿을 사용하여 Oracle DB 인스 턴스를 생성할 때 할당한 관리 사용자의 암호를 입력합니다. 연결을 테스트하려면 [Test]를 선택합니다. [OK]를 선택하여 대화 상자를 닫은 후 [OK]를 선택하여 연결 프로필을 생성합니다. Note 용 Oracle DB 인스턴스에 연결 연결에 실패한 경우, CloudFormation 템플릿을 생성할 때 할당한 IP 주소가 연결을 시도한 IP 주소인지 확인합니다. 인스턴스에 연결할 때 가장 일반적으로 발생하는 문제입니다. 3. 사용자 지정 스크립트를 사용하여 마이그레이션에 사용할 HR 스키마를 생성합니다. AWS에서 제공하 는 SQL 스크립트는 이 사이트의 에 있습니다. 1. 텍스트 편집기에서 제공된 SQL 스크립트를 엽니다. 전체 스크립트를 복사합니다. 2. SQL Workbench/J에서 다음 코드를 복사하고 [Statement 1]를 보여 주는 Default.wksp 창에 SQL 스 크립트를 붙여 넣습니다. 3. [SQL]을 선택한 후 [Execute All]을 선택합니다. 35

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 스크립트를 실행하면, 사용자 HR이 없음을 나타내는 오류 메시지가 반환됩니다. 이 오류를 무시하 고 스크립트를 실행할 수 있습니다. 이 스크립트는 사용자를 생성하기 전에 이 사용자를 삭제하므 로, 오류가 발생합니다. 4. 다음 SQL 쿼리를 실행하여 HR 스키마에서 객체 유형과 개수가 생성되었는지 확인합니다. 또한 AWS 사 이트에서 제공하는 스프레드시트에 나열된 결과와 다음 쿼리 결과를 비교해 볼 수도 있습니다. Select OBJECT_TYPE, COUNT(*) from dba_objects where owner='hr' GROUP BY OBJECT_TYPE; 이 쿼리 결과는 다음과 비슷해야 합니다. OBJECT_TYPE COUNT(*) INDEX 7 PROCEDURE 2 36

SEQUENCE 3 TABLE 7 VIEW 1 5. 3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 다음 SQL 쿼리를 실행하여 HR 스키마에서 제약 개수를 확인합니다. Select CONSTRAINT_TYPE,COUNT(*) from dba_constraints where owner='hr' AND (CONSTRAINT_TYPE IN ('P','R')OR SEARCH_CONDITION_VC NOT LIKE '%NOT NULL%') GROUP BY CONSTRAINT_TYPE; 이 쿼리 결과는 다음과 비슷해야 합니다. 37

4단계: Aurora MySQL DB 인스 턴스와의 연결을 테스트합니다. CONSTRAINT_TYPE COUNT(*) R 10 P 7 C 2 6. 다음 SQL 쿼리를 실행하여 총 테이블 수와 각 테이블별 행 수를 확인합니다. Select table_name, num_rows from dba_tables where owner='hr' order by 1; 이 쿼리 결과는 다음과 비슷해야 합니다. TABLE_NAME NUM_ROWS COUNTRIES 25 DEPARTMENTS 27 EMPLOYEES 107 JOBS 19 JOB_HISTORY 10 LOCATIONS 23 REGIONS 4 7. 테이블에서 관계를 확인합니다. 다음 SQL 쿼리를 실행하여 10명이 넘는 직원이 있는 부서를 확인합니 다. Select b.department_name,count(*) from HR.Employees a,hr.departments b where a.department_id=b.department_id group by b.department_name having count(*) > 10 order by 1; 이 쿼리 결과는 다음과 비슷해야 합니다. DEPARTMENT_NAME COUNT(*) Sales 34 Shipping 45 4단계: Aurora MySQL DB 인스턴스와의 연결을 테스트 합니다. 그 다음, Aurora MySQL DB 인스턴스와의 연결을 테스트합니다. SQL Workbench/J를 사용하여 Aurora MySQL DB 인스턴스와의 연결을 테스트하려면 1. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. [Create a new connection profile] 아이콘을 선택합니다. 다음 정보 사용: 다음과 같은 정보를 사용하여 SQL Workbench/J에서 Aurora MySQL DB 인스턴스에 연결합니다. 38

4단계: Aurora MySQL DB 인스 턴스와의 연결을 테스트합니다. 2. 이 파라미터의 경우... 수행할 작업 [New profile] 이름 RDSAuroraConnection을 입력합니다. [Driver] MySQL (com.mysql.jdbc.driver)을 선택합니다. [URL] 이전 단계에서 DMSdemo 스택의 출력 세부 정보를 검사했 을 때 기록한 [AuroraJDBCConnectionString] 값을 사용합니 다. [Username] auradmin을 입력합니다. [Password] AWS CloudFormation 템플릿을 사용하여 Aurora MySQL DB 인스턴스를 생성할 때 할당한 관리 사용자의 암호를 입 력합니다. 연결을 테스트하려면 [Test]를 선택합니다. [OK]를 선택하여 대화 상자를 닫은 후 [OK]를 선택하여 연결 프로필을 생성합니다. Note 용 Aurora MySQL DB 인스턴스에 연결 연결에 실패한 경우, CloudFormation 템플릿을 생성할 때 할당한 IP 주소가 연결을 시도한 IP 주소인지 확인합니다. 인스턴스에 연결할 때 가장 일반적으로 발생하는 문제입니다. 3. 마스터 관리 자격 증명을 사용하여 Aurora MySQL 인스턴스에 로그온합니다. 4. SHOW DATABASES;와 같은 샘플 SQL 명령을 실행하여 Aurora MySQL DB 인스턴스와의 연결을 확인 합니다. 39

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 5단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 Aurora MySQL로 변환합니 다. 데이터를 Aurora MySQL로 변환하기 전에 아래 설명과 같이 Oracle 스키마를 Aurora MySQL 스키마로 변환 합니다. AWS Schema Conversion Tool(AWS SCT)를 사용하여 Oracle 스키마를 Aurora MySQL 스키마로 변환하려면 1. AWS Schema Conversion Tool(AWS SCT)를 시작합니다. AWS SCT에서 [File]을 선택하고 나서 [New Project]를 선택합니다. DMSDemoProject라고 하는 새 프로젝트를 만듭니다. [New Project] 창에 다음 정보를 입력하고 [OK]를 선택합니다. 이 파라미터의 경우... 수행할 작업 [프로젝트 이름] DMSDemoProject를 입력합니다. [Location] 기본 [Projects] 폴더와 기본 [Transactional Database (OLTP)] 옵션을 사용합니다. [Source Database Engine] Oracle을 선택합니다. [Target Database Engine] [Amazon Aurora(MySQL Compatible)]를 선택합니다. 40

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 2. [Connect to Oracle]을 선택합니다. [Connect to Oracle] 대화 상자에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 이 파라미터의 경우... 수행할 작업 Type [SID]를 선택합니다. [Server name] Oracle DB 인스턴스에 연결하는 데 사용한 [OracleJDBCConnectionString] 값을 사용하지만, JDBC 접두사 정보를 제거합니다. 예를 들어, SQL Workbench/J에서 사용하는 샘플 연결 문자열은 "jdbc:oracle:thin:@do1xa4grferti8y.cqiw4tcs0mg7.uswest-2.rds.amazonaws.com:1521:orcl"이 될 수도 있습니 다. AWS SCT [Server name]의 경우, "jdbc:oracle:thin:@"을 제거하고 서버 이름: "do1xa4grferti8y.cqiw4tcs0mg7.uswest-2.rds.amazonaws.com"만을 사용합니다. [Server port] [1521]을 입력합니다. [Oracle SID] ORCL을 입력합니다. 사용자 이름 oraadmin을 입력합니다. [Password] AWS CloudFormation 템플릿을 사용하여 Oracle DB 인스 턴스를 생성할 때 할당한 관리 사용자의 암호를 입력합니다. 41

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 3. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 Oracle DB 인스턴스와의 연 결을 시작합니다. Oracle DB 인스턴스의 데이터베이스 구조가 표시됩니다. HR 스키마만을 선택합니다. 42

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 4. [Connect to Amazon Aurora]를 선택합니다. [Connect to Amazon Aurora] 대화 상자에서 다음 정보를 입 력한 후 [Test Connection]을 선택합니다. 이 파라미터의 경우... 수행할 작업 Type [SID]를 선택합니다. [Server name] Aurora MySQL DB 인스턴스에 연결하는 데 사용한 [AuroraJDBCConnectionString] 값을 사용하지만, JDBC 접두사 정보와 포트 접두사를 제거합니다. 예를 들어, SQL Workbench/J에서 사용하는 샘플 연결 문자열은 "jdbc:mysql://dmsdemo-auroracluster-1u1ogdfg35v.clustercqiw4tcs0mg7.us-west-2.rds.amazonaws.com:3306"이 될 수도 있습니다. AWS SCT [Server name]의 경우, "jdbc:oracle:thin:@"과 ":3306"을 제거하고 서버 이 름: "dmsdemo-auroracluster-1u1ogdfg35v.clustercqiw4tcs0mg7.us-west-2.rds.amazonaws.com"만을 사용합 니다. 43

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 이 파라미터의 경우... 수행할 작업 [Server port] [3306]을 입력합니다. [User name] auradmin을 입력합니다. [Password] AWS CloudFormation 템플릿을 사용하여 Oracle DB 인스 턴스를 생성할 때 할당한 관리 사용자의 암호를 입력합니다. AWS SCT는 HR 스키마를 분석하고 데이터베이스 마이그레이션 평가 보고서를 생성하여 Amazon Aurora MySQL로 변환합니다. 5. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 Amazon Aurora MySQL DB 인스턴스와의 연결을 시작합니다. 6. HR 스키마를 마우스 오른쪽 버튼으로 클릭하고 [Create Report]를 선택합니다. 44

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 7. 보고서 및 보고서가 제안하는 작업 항목을 확인합니다. 이 보고서에서는 잠재적인 마이그레이션 문제 및 이 문제를 해결하는 조치와 더불어 AWS SCT를 사용하여 변환할 수 있는 객체 유형에 대해 다룹니다. 이 연습에서는 다음과 같은 항목이 표시됩니다. 45

8. 5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 자세한 분석을 위해 보고서를.csv 또는.pdf 형식으로 저장하고 나서 [Action Items] 탭을 선택합니다. 이 작업 항목에서는 다음 문제 2개가 나타납니다. 1. MySQL은 점검 제약을 지원하지 않고, 2. MySQL은 시 퀀스를 지원하지 않습니다. 작업 항목 #1의 경우, SCT는 트리거를 자동으로 프로비저닝하여 Aurora MySQL 데이터베이스에서 점 검 제약을 시뮬레이션합니다(에뮬레이트 트리거). 예를 들어, EMPLOYEES 테이블(Oracle에서)에서 SAL > 0의 점검 제약은 Aurora MySQL의 이전 및 업데이트 트리거 문을 사용하여 적용됩니다. 이 로직 이 애플리케이션 계층에서 처리되도록 하려는 경우, 필요에 따라 트리거를 삭제하거나 업데이트할 수 있 습니다. 작업 항목 #2의 경우, EMPLOYEES(EMPLOYEE_ID), DEPARTMENTS(DEPARTMENT_ID), LOCATIONS(LOCATION_ID) 테이블용 기본 키를 생성할 때 사용되는 원본 데이터베이스에 시퀀스 객 체 3개가 있습니다. 이 예제에서 앞서 언급한 바와 같이 Aurora MySQL에서 대리 키용 시퀀스 사용을 대체하는 한 가지 방법은 auto_increment 기능을 사용하는 것입니다. auto_increment 기능을 활성화 하려면, SCT 설정을 변경해야 합니다. 간결함을 위해 다음 하위 단계에서는 EMPLOYEES 테이블의 EMPLOYEE_ID 열에서만 auto_increment 활성화를 보여줍니다. 다른 시퀀스 객체에서 동일한 절차를 반복할 수 있습니다. 시작하기 전에 auto_increment 옵션을 활성화하려면 다음 이유로 SCT를 통해 일부 추가 단계를 진행해 야 한다는 점에 유의하십시오. 기본적으로 SCT는 모든 NUMBER(Oracle) 데이터 형식을 Aurora MySQL에서 DECIMAL로 변환합 니다(http://docs.aws.amazon.com/dms/latest/userguide/SchemaConversionTool/latest/userguide/ CHAP_SchemaConversionTool.Reference.ConversionSupport.Oracle.html#d0e50104). Aurora MySQL는 DECIMAL 데이터 형식에 대해 auto_increment를 지원하지 않습니다. 따라서 기본 키 열과 해당 외래 키 열의 데이터 형식을 스키마 변환의 일부로서 INT, SMALLINT, MEDIUMINT 또는 BIGINT와 같은 INTEGER 데이터 형식 중 하나로 변경해야 합니다. 한 가지 반가운 소식은 최신 SCT 릴리스에 [Mapping Rules] 기능이 포함되어 있어 다음 단계를 진행하 여 위의 변환을 수행할 수 있습니다. 1. EMPLOYEES 테이블에서는 기본 키와 외래 키 관계를 확인하기 위해 원본 Oracle 데이터베이스에 서 다음 쿼리를 실행해야 합니다. SCT 매핑 규칙에서 지정되어야 하는 열을 적으십시오. SELECT * FROM (SELECT PK.TABLE_NAME, C.COLUMN_NAME, PK.CONSTRAINT_TYPE FROM DBA_CONSTRAINTS PK, DBA_CONS_COLUMNS C WHERE PK.CONSTRAINT_NAME = C.CONSTRAINT_NAME AND PK.OWNER = 'HR' AND PK.TABLE_NAME = 'EMPLOYEES' AND PK.CONSTRAINT_TYPE = 'P' UNION SELECT FK.TABLE_NAME, COL.COLUMN_NAME, FK.CONSTRAINT_TYPE FROM DBA_CONSTRAINTS PK, DBA_CONSTRAINTS FK, DBA_CONS_COLUMNS COL WHERE PK.CONSTRAINT_NAME = FK.R_CONSTRAINT_NAME AND FK.CONSTRAINT_TYPE = 'R' AND FK.CONSTRAINT_NAME = COL.CONSTRAINT_NAME AND PK.OWNER = 'HR' AND PK.TABLE_NAME = 'EMPLOYEES' AND PK.CONSTRAINT_TYPE = 'P' ) ORDER BY 3 ASC; 46

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 쿼리 결과는 다음과 비슷해야 합니다. TABLE_NAME COLUMN_NAME CONSTRAINT_TYPE EMPLOYEES EMPLOYEE_ID P JOB_HISTORY EMPLOYEE_ID R EMPLOYEES MANAGER_ID R DEPARTMENTS MANAGER_ID R 2. [Settings]를 선택하고 나서 [Mapping Rules]를 선택합니다. 3. 1단계에서 확인된 열 목록에서 데이터 형식 변환에 대한 매핑 규칙을 지정합니다. 아래 설명과 같기 각 열별로 하나씩 규칙 4개를 지정해야 합니다. 이 파라미터의 경우 규칙 1 규칙 2 규칙 3 규칙 4 이름 EMP_SEQ1 EMP_SEQ2 JOB_SEQ1 DEPT_SEQ1 대상 열 선택 열 선택 열 선택 열 선택 장소 HR HR HR HR (스키마 이름) 및 (테이블 이름) 및 (열 이름) EMPLOYEES EMPLOYEES JOB_HISTORY DEPARTMENTS Actions [Change data type] 선택 [Change data type] 선택 [Change data type] 선택 [Change data type] 선택 끝 SMALLINT SMALLINT SMALLINT SMALLINT EMPLOYEE_ID MANAGER_ID EMPLOYEE_ID MANAGER_ID 실제 시나리오에서는 요구 사항을 기준으로 데이터를 선택하게 됩니다. 47

4. 9. 5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. [Would you like to save Mapping Rule settings?]에서 [Yes]를 선택합니다. HR 스키마를 오른쪽 버튼으로 클릭한 다음 [Convert schema]를 선택합니다. 10. 확인 메시지에서 [Yes]를 선택합니다. 그런 다음 AWS SCT는 스키마를 대상 데이터베이스 형식으로 변 환합니다. 48

5단계: AWS Schema Conversion Tool(AWS SCT)을 사 용하여 Oracle 스키마를 Aurora MySQL로 변환합니다. 11. HR 스키마를 선택하고 나서 [Apply to database]를 선택하여 다음과 같이 스키마 스크립트를 대상 Aurora MySQL 인스턴스에 적용합니다. 12. HR 스키마를 선택하고 나서 [Refresh from Database]를 선택하여 다음과 같이 대상 데이터베이스를 새 로 고칩니다. 49

6단계: 스키마 변환 검증 이제 데이터베이스 스키마가 변환되어 원본에서 대상으로 가져올 수 있습니다. 6단계: 스키마 변환 검증 스키마 변환을 확인하려면, SQL Workbench/J를 사용하여 Oracle과 Aurora MySQL 데이터베이스에 있는 객 체를 비교합니다. SQL Workbench/J를 사용하여 스키마 변환을 검증하려면 1. 2. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. 이전 단계에서 생성한 RDSAuroraConnection을 선택합니다. [OK]를 클릭합니다. 다음 스크립트를 실행하여 대상 Aurora MySQL 데이터베이스에서 객체 형식 개수와 HR 스키마 개수를 확인합니다. 이 값은 원본 Oracle 데이터베이스의 객체 수와 일치해야 합니다. SELECT a.object_type, COUNT(*) FROM ( SELECT OBJECT_TYPE,OBJECT_SCHEMA,OBJECT_NAME FROM ( SELECT 'TABLE' AS OBJECT_TYPE,TABLE_NAME AS OBJECT_NAME,TABLE_SCHEMA AS OBJECT_SCHEMA FROM information_schema.tables 50

6단계: 스키마 변환 검증 where TABLE_TYPE='BASE TABLE' UNION SELECT 'VIEW' AS OBJECT_TYPE,TABLE_NAME AS OBJECT_NAME,TABLE_SCHEMA AS OBJECT_SCHEMA FROM information_schema.views UNION SELECT 'INDEX' AS OBJECT_TYPE,CONCAT ( CONSTRAINT_TYPE,' : ',CONSTRAINT_NAME,' : ',TABLE_NAME ) AS OBJECT_NAME,TABLE_SCHEMA AS OBJECT_SCHEMA FROM information_schema.table_constraints where constraint_type='primary KEY' UNION SELECT ROUTINE_TYPE AS OBJECT_TYPE,ROUTINE_NAME AS OBJECT_NAME,ROUTINE_SCHEMA AS OBJECT_SCHEMA FROM information_schema.routines UNION SELECT 'TRIGGER' AS OBJECT_TYPE,CONCAT ( TRIGGER_NAME,' : ',EVENT_OBJECT_SCHEMA,' : ',EVENT_OBJECT_TABLE ) AS OBJECT_NAME,TRIGGER_SCHEMA AS OBJECT_SCHEMA FROM information_schema.triggers ) R WHERE R.OBJECT_SCHEMA ='HR' order by 1) a GROUP BY a.object_type; 이 쿼리는 다음과 비슷한 내용을 출력해야 합니다. OBJECT_TYPE COUNT(*) INDEX 7 PROCEDURE 2 TABLE 7 TRIGGER 4 VIEW 1 그 다음, 다음 쿼리를 실행하여 테이블 제약 정보를 가져옵니다. SELECT CONSTRAINT_TYPE,COUNT(*) FROM information_schema.table_constraints where constraint_schema='hr' GROUP BY CONSTRAINT_TYPE; 이 쿼리는 다음과 비슷한 내용을 출력해야 합니다. 51

6단계: 스키마 변환 검증 CONSTRAINT_TYPE COUNT(*) FOREIGN KEY 10 PRIMARY KEY 7 3. 다음 단계를 진행하여 EMPLOYEES 테이블에서 auto_increment 옵션을 활성화한 후 원본 Oracle 데이 터베이스의 시퀀스 기능을 에뮬레이션합니다. 1. 데이터 형식 변환에 대한 매핑 규칙이 대상 Aurora MySQL 데이터베이스에서 다음 쿼리를 실행하 여 EMPLOYEES 및 해당 종속적 테이블에서 올바르게 실행되었는지 확인합니다. SELECT kcu.constraint_name, kcu.column_name, col.data_type, kcu.table_schema, kcu.table_name, kcu.referenced_column_name FROM information_schema.key_column_usage kcu, information_schema.table_constraints tc, information_schema.columns col WHERE kcu.referenced_table_schema = 'HR' AND kcu.referenced_table_name = 'EMPLOYEES' AND kcu.referenced_table_name=tc.table_name AND kcu.referenced_table_schema=tc.table_schema AND tc.constraint_type='primary KEY' AND col.column_name=kcu.column_name and col.table_name=kcu.table_name ORDER BY kcu.table_name,kcu.column_name; 쿼리 결과는 다음과 같아야 합니다. constraint_name column_name data_type referenced_column_name DEPT_MGR_FK MANAGER_ID Smallint HR EMP_MANAGER_FK MANAGER_ID Smallint JHIST_EMP_FK EMPLOYEE_ID Smallint 2. table_schema table_name DEPARTMENTS EMPLOYEE_ID HR EMPLOYEES EMPLOYEE_ID HR JOB_HISTORY EMPLOYEE_ID 다음 명령을 실행하여 EMPLOYEES 테이블에 대한 외래 키 점검을 비활성화합니다. 이 단계는 기 본 키 열을 변경하기 전에 진행해야 합니다. 경고 메시지를 무시해도 됩니다. SET FOREIGN_KEY_CHECKS=0; 3. 기본 키 열을 수정하여 auto_increment 옵션을 활성화하려면 다음 명령을 실행합니다. Alter table HR.EMPLOYEES modify column employee_id smallint auto_increment; 4. 다음 쿼리를 실행하여 열 세부 정보를 확인합니다. SELECT column_name, column_type,column_key,extra from information_schema.columns where table_name = 'EMPLOYEES' AND COLUMN_NAME='EMPLOYEE_ID'; 쿼리 결과는 다음과 같아야 합니다. 52

7단계: AWS DMS 복제 인스턴스를 생성합니다. column_name column_type column_key extra employee_id smallint(6) PRI auto_increment 4. 5. 다음 테이블에는 예상되는 객체 수와 이 객체가 AWS SCT를 통해 마이그레이션되었는지 여부가 나옵니 다. 파라미터 Oracle에서 의 개수 # Amazon Aurora MySQL에서 AWS SCT를 SCT 권장 통해 마이그 레이션됨 INDEX 7 7 예 PROCEDURE 2 2 예 SEQUENCE 3 3 예, 매핑 규 칙 사용 TABLE 7 7 예 VIEW 1 1 예 기본 키 10 10 예 외래 키 7 7 예 제약 점검 2 4개(트리거) 코드 변환 시퀀스 기능은 Aurora MySQL의 auto_increment 기능을 사용하여 구현됩니 다. Aurora MySQL에서 제약이 지원되지 않는지 확인합니 다. AWS SCT는 삽입 또는 업데이트 문 앞에서 트리거 를 생성한 후 이 제약이 있 었던 테이블의 점검 제약을 모방합니다. AWS 이 사이트에서 AWS가 제공한 스프레드시크에 나오는 결과 또는 이 사이트에서 AWS가 제공한 텍 스트 문서를 확인합니다. 7단계: AWS DMS 복제 인스턴스를 생성합니다. 앞의 설명과 같이 원본과 대상 데이터베이스에서 스키마 구조를 검증한 후 이 연습의 핵심 부분인 데이터 마 이그레이션으로 진행합니다. 다음 그림은 마이그레이션 프로세스의 상위 수준 보기를 보여줍니다. DMS 복제 인스턴스는 원본과 대상 간에 실제 데이터 마이그레이션을 수행합니다. 복제 인스턴스도 마이그 레이션 중에 트랜잭션 로그를 캐시합니다. 복제 인스턴스가 갖는 CPU와 메모리 용량은 마이그레이션에 필 요한 전체 시간에 영향을 줍니다. 53

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. AWS DMS 복제 인스턴스를 생성하려면 1. 2. AWS Management Console에 로그인하고 https://console.aws.amazon.com/dms/에서 AWS DMS를 선 택하고 [Create Migration]을 선택합니다. AWS Identity and Access Management(IAM) 사용자로서 로그 인한 경우에는 AWS DMS 액세스를 위한 적절한 권한이 있어야 합니다. 필요한 권한에 대한 자세한 내 용은 AWS DMS 사용에 필요한 IAM 권한을 참조하십시오. [Next]를 선택하여 콘솔의 [Welcome] 페이지에서 데이터베이스 마이그레이션을 시작합니다. 3. [Create replication instance] 페이지에서 다음과 같이 복제 인스턴스 정보를 지정합니다. 4. 이 파라미터의 경우... 수행할 작업 이름 [DMSdemo-repserver]를 입력합니다. 설명 DMS 데데 데데 데데와 같은 간략한 설명을 입력합니다. 인스턴스 클래스 [dms.t2.medium]을 선택합니다. 이 인스턴스 클래스는 작은 테이블 집합을 마이그레이션하기에 충분히 큽니다. [VPC] CloudFormation 스택에서 생성된 VPC인 DMSDemoVPC를 선택합니다. [Multi-AZ] [No]를 선택합니다. [Publicly accessible] 이 항목을 선택한 상태로 둡니다. [Advanced] 섹션에서 기본 설정은 그대로 두고, [Next: Tag Instance]를 선택합니다. 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니 다. 복제 인스턴스가 생성되는 동안 AWS Management Console을 사용하여 원본과 대상 데이터베이스 엔드포 인트를 지정할 수 있습니다. 그렇지만, 복제 인스턴스는 연결에 사용되기 때문에 복제 인스턴스가 생성된 후 에는 연결을 테스트만할 수 있습니다. AWS 콘솔을 사용하여 원본 또는 대상 데이터베이스 엔드포인트를 지정하려면 1. 원본 Oracle 데이터베이스와 대상 Amazon Aurora MySQL 데이터베이스에 대한 연결 정보를 지정합니 다. 다음 표는 원본 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Endpoint Identifier] Orasource(Amazon RDS Oracle 엔드포인트)를 입력합니 다. 소스 엔진 [oracle]을 선택합니다. [Server name] Oracle DB 인스턴스 이름을 입력합니다. 이 것은 "do1xa4grferti8y.cqiw4tcs0mg7.uswest-2.rds.amazonaws.com"와 같이 AWS SCT에서 사용한 [Server name]입니다. [Port] [1521]을 입력합니다. [SSL mode] [None]을 선택합니다. 사용자명 oraadmin을 입력합니다. 54

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 이 파라미터의 경우... 수행할 작업 [Password] Oracle DB 인스턴스에 암호를 입력합니다. [SID] Oracle 데이터베이스 이름을 입력합니다. 다음 표는 대상 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Endpoint Identifier] Aurtarget(Amazon Aurora MySQL 엔드포인트)을 입력합 니다. [Target Engine] [aurora]를 선택합니다. [Servername ] Aurora MySQL DB 인스턴스 이름을 지정합니다. 이것 은 "dmsdemo-auroracluster-1u1oyqny35jwv.clustercqiw4tcs0mg7.us-west-2.rds.amazonaws.com"과 같이 AWS SCT에서 사용한 [Server name]입니다.. [Port] [3306]을 입력합니다. [SSL mode] [None]을 선택합니다. [Username] auraadmin을 입력합니다. [Password] Aurora MySQL DB 인스턴스의 암호를 지정합니다. 완료한 페이지는 다음과 같아야 합니다. 55

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 2. 초기 데이터 로드 중에 외래 키 점검을 비활성화하려면, 다음 명령을 대상 Aurora MySQL DB 인스턴스 에 추가해야 합니다. 다음과 같이 [Advanced] 섹션에서 [Extra connection attributes]에 다음 명령을 입력 합니다. initstmt=set FOREIGN_KEY_CHECKS=0, autocommit=1 첫 번째 명령은 로드 중에 외래 키 점검을 비활성화하고, 두 번째 명령은 DMS가 실행하는 트랜잭션을 커밋합니다. 56

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 3. [Next]를 선택합니다. 9단계: AWS DMS 마이그레이션 작업 생성 및 실행 AWS DMS 작업을 사용하여 마이그레이션할 스키마와 마이그레이션 유형을 지정할 수 있습니다. 기존 데이 터를 마이그레이션하거나, 지속적 변경 사항을 복제하거나, 또는 데이터 변경 사항만 복제할 수 있습니다. 이 연습에서는 기존 데이터만을 마이그레이션합니다. 마이그레이션 작업을 생성하려면 1. [Create Task] 페이지에서 작업 옵션을 지정합니다. 다음 표는 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Task name] migratehrschema를 입력합니다. [Task description] 작업 설명을 입력합니다. [Source endpoint] orasource(amazon RDS Oracle 엔드포인트)를 보여줍니 다. [Target endpoint] aurtarget(amazon Aurora MySQL 엔드포인트)을 표시합 니다. 57

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 이 파라미터의 경우... 수행할 작업 복제 인스턴스 DMSdemo-repserver(이전 단계에서 생성한 AWS DMS 복제 인스턴스)를 보여줍니다. [Migration type] [Migrate existing data] 옵션을 선택합니다. [Start task on create] 이 옵션을 선택합니다. 이 페이지는 다음과 같이 보여야 합니다. 2. [Task Settings]에서 [Target table preparation mode]에 대해 [Do nothing]을 선택합니다. 그 이유는 스키 마 마이그레이션 도구를 통해 이미 테이블을 생성했기 때문입니다. 이 마이그레이션에 LOB가 포함되어 있지 않기 때문에 기본값을 LOB 설정으로 두어야 합니다. 선택적으로 [Enable logging]을 선택할 수 있습니다. 로깅을 활성화할 경우, CloudWatch 로그 생성에 대 해 Amazon CloudWatch 요금이 추가로 부과됩니다. 이 연습에서는 로그가 필요하지 않습니다. 58

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 3. [Advanced] 설정을 기본값으로 둡니다. 4. [Table mappings]를 선택하고 [Mapping method]에서 [Default]를 선택하고 나서 [Schema to migrate]에 서 [HR]을 선택합니다. 완료한 섹션은 다음과 같이 보여야 합니다. 5. [Create task]를 선택합니다. 작업이 즉시 시작됩니다. 59

10단계: AWS DMS 마이그레이션 이 성공적으로 완료되었는지 확인 [Tasks] 섹션에는 마이그레이션 작업 상태가 나타납니다. 작업을 설정할 때 [Enable logging]을 선택하면 작업을 모니터링할 수 있습니다. 그리고 나서 다음 작업을 수 행하여 CloudWatch 측정치를 확인할 수 있습니다. 진행 중인 데이터 마이그레이션 작업을 모니터링하려면 1. 탐색 창에서 [Tasks]를 선택합니다. 2. 마이그레이션 작업(migratehrschema)을 선택합니다. 3. [Task monitoring] 탭을 선택하고 이 탭에서 진행 중인 작업을 모니터링합니다. 10단계: AWS DMS 마이그레이션이 성공적으로 완료되 었는지 확인 마이그레이션 작업이 완료되면, 작업 결과를 예상 결과와 비교할 수 있습니다. 마이그레이션 작업 결과를 예상 결과와 비교하려면 1. 탐색 창에서 [Tasks]를 선택합니다. 2. 마이그레이션 작업(migratehrschema)을 선택합니다. 3. 다음 그림과 같이 [Table statistics] 탭을 선택합니다. 60

10단계: AWS DMS 마이그레이션 이 성공적으로 완료되었는지 확인 4. SQL Workbench/J를 사용하여 Amazon Aurora MySQL 인스턴스에 연결하고 나서 데이터베이스 테이블 을 Oracle에서 Aurora MySQL로 마이그레이션했는지 여부를 확인하기 위해 다음 그림과 같이 SQL 스크 립트를 실행합니다. Show databases; Use HR; SELECT TABLE_NAME,TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'HR' and TABLE_TYPE='BASE TABLE' order by 1; 61

11단계: 연습 리소스 삭제 5. 이전 쿼리의 테이블 출력과 행 수가 RDS Oracle에서 예상한 수치와 일치하는지 확인하기 위해, 이 사이 트의 AWS에서 제공한 스프레드시트의 결과와 현재 결과를 비교합니다. 6. 다음 쿼리를 실행하여 테이블에서 관계를 확인합니다. 이 쿼리는 10명이 넘는 직원이 있는 부서를 확인 합니다. SELECT B.DEPARTMENT_NAME,COUNT(*) FROM HR.EMPLOYEES A,HR.DEPARTMENTS B WHERE A.DEPARTMENT_ID=B.DEPARTMENT_ID GROUP BY B.DEPARTMENT_NAME HAVING COUNT(*) > 10 ORDER BY 1; 이 쿼리는 다음과 비슷한 내용을 출력해야 합니다. department_name count(*) Sales 34 Shipping 45 이제 Amazon RDS Oracle DB 인스턴스에서 Amazon Aurora MySQL로 데이터베이스 마이그레이션을 완료 했습니다. 11단계: 연습 리소스 삭제 이 연습을 완료한 뒤에는 다음 단계를 수행하여 이 연습에서 사용된 추가 AWS 리소스에 요금이 부과되지 않 도록 다음 단계를 수행합니다. 일부 리소스가 다른 리소스에 대한 종속성이 있는 경우 이 리소스는 삭제할 수 없기 때문에 단계를 순서대로 수행해야 합니다. AWS DMS 리소스를 삭제하려면 1. 탐색 창에서 [Tasks]를 선택하고, 마이그레이션 작업(migratehrschema)을 선택한 후 [Delete]를 선택 합니다. 62

다음 단계 2. 탐색 창에서 [Endpoints]를 선택하고, Oracle 소스 엔드포인트(orasource)를 선택하고 나서 [Delete]를 선택합니다. 3. 4. Amazon Aurora MySQL 대상 엔드포인트 (aurtarget)를 선택하고 나서 [Delete]를 선택합니다. 탐색 창에서 [Replication instances]를 선택하고, 복제 인스턴스(DMSdemo-repserver)를 선택하고 나 서 [Delete]를 선택합니다. 그런 다음 AWS CloudFormation 스택 DMSdemo를 삭제해야 합니다. AWS CloudFormation 스택을 삭제하려면 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/cloudformation에서 AWS CloudFormation 콘솔을 엽니다. AWS Identity and Access Management(IAM) 사용자로서 로그인한 경우에는 AWS CloudFormation 액 세스를 위한 적절한 권한이 있어야 합니다. 2. CloudFormation 스택 DMSdemo를 선택합니다. 3. [ Actions]에서 [Delete stack]을 선택합니다. 스택 상태가 DELETE_IN_PROGRESS로 바뀌고, AWS CloudFormation이 DMSdemo 스택과 관련된 리소스 를 정리합니다. AWS CloudFormation이 리소스 정리를 마치면 목록에서 스택을 제거합니다. 다음 단계 다음 기능을 포함하여 이 연습에 포함되지 않은 AWS DMS의 다른 여러 기능을 살펴볼 수 있습니다. 데이터의 지속적 복제를 위한 AWS DMS 변경 데이터 캡처(CDC) 기능입니다. 마이그레이션 프로세스의 일부로서 변환을 지정하고 선택한 스키마에 적용할 수 있는 변환 작업입니다. 자세한 내용은 the AWS DMS 설명서를 참조하십시오. AWS CloudFormation 템플릿, SQL 스크립트 및 기 타 리소스 다음에 나열된 AWS 사이트에는 이 연습에서 사용된 AWS CloudFormation 템플릿, SQL 스크립트 및 기타 리소스가 나와 있습니다. Oracle 스키마 SQL 스크립트 AWS CloudFormation 템플릿 SQL 확인 스크립트, 스프레드시트 형식 SQL 확인 스크립트, 텍스트 형식 아키텍처 다이어그램,.jpg 형식 또는 아키텍처 다이어그램,.vsd 형식 MySQL JDBC 드라이버,.jar 파일 형식 Oracle Database 12.1.0.2 JDBC 드라이버,.jar 파일 형식 참조 다음 설명서와 샘플 스키마는 이 연습에서 참조로서 유용할 수 있습니다. 63

참조 AWS DMS 설명서 AWS SCT 설명서 Oracle 샘플 스키마 64

사전 조건 SQL Server 데이터베이스를 Amazon Aurora MySQL로 마이그레이션 이 연습을 통해 (AWS DMS) 및 AWS Schema Conversion Tool(AWS SCT)을 사용하여 Microsoft SQL Server 데이터베이스를 MySQL과 호환되는 Amazon Aurora 데이터베이스 로 마이그레이션하는 방법을 배울 수 있습니다. AWS DMS는 데이터를 SQL Server 원본의 데이터를 Aurora MySQL 대상으로 마이그레이션합니다. AWS DMS는 특히 데이터 마이그레이션과 관련되지 않은 보조 인덱스, 시퀀스, 기본값, 저장된 절차, 트리거, 동의어, 보기 및 기타 스키마 객체를 마이그레이션하지 않습니다. 이러한 객체를 Aurora MySQL 대상으로 마 이그레이션하려면 AWS SCT를 사용합니다. 항목 사전 조건 (p. 65) 단계별 마이그레이션 (p. 66) 문제 해결 (p. 85) 사전 조건 이 연습을 완료하려면 다음 사전 요구 사항이 충족되어야 합니다. Amazon Relational Database Service(Amazon RDS), 해당되는 데이터베이스 기술 및 SQL을 이해합니다. AWS 리전에서 Amazon RDS 및 (AWS DMS) 인스턴스를 시작하는 데 사용되는 AWS Identity and Access Management(IAM) 자격 증명으로 AWS 계정을 생성합니다. IAM 자격 증명에 대한 자세한 내용은 IAM 사용자 생성을 참조하십시오. Amazon Virtual Private Cloud(Amazon VPC) 서비스 및 보안 그룹을 이해합니다. Amazon RDS에서 Amazon VPC를 사용하는 방법에 대한 정보는 Amazon Virtual Private Cloud(VPC) 및 Amazon RDS 섹션 을 참조하십시오. Amazon RDS 보안 그룹에 대한 자세한 내용은 Amazon RDS 보안 그룹을 참조하십시 오. AWS DMS의 지원 기능 및 제한 사항에 대해 이해합니다. AWS DMS에 대한 자세한 내용은 AWS Database Migration Service란 무엇입니까? 를 참조하십시오. Microsoft SQL Server를 원본으로, Amazon Aurora MySQL을 대상으로 사용하여 작업하는 방법을 이해 합니다. 원본으로서 SQL Server를 사용한 작업에 대한 자세한 내용은 Using a SQL Server Database as a Source for 를 참조하십시오. Aurora MySQL은 MySQL 호환 데이터 베이스입니다. 원본으로 Aurora MySQL을 사용한 작업에 대한 자세한 내용은 AWS Database Migration Service에서 MySQL 호환 데이터베이스를 원본으로 사용 을 참조하십시오. SQL Server 및 Aurora MySQL에 대해 지원되는 데이터 형식 변환 옵션을 이해합니다. 원본으로 사용되는 SQL Server의 데이터 형식에 대한 자세한 내용은 Microsoft SQL Server용 원본 데이터 형식을 참조하십시 오. 대상으로 사용되는 Aurora MySQL의 데이터 형식에 대한 자세한 내용은 MySQL용 대상 데이터 형식을 참조하십시오. 대상 Aurora MySQL 데이터베이스 호스트의 규모를 조정합니다. DBA는 현재 원본 SQL Server 데이터 베이스 호스트의 로드 프로필을 알고 있어야 합니다. CPU, 메모리 및 IOPS를 고려합니다. Amazon RDS 를 사용하여 마이그레이션 후에 대상 데이터베이스 호스트의 규모를 늘리거나 줄일 수 있습니다. Aurora MySQL로 처음 마이그레이션하는 경우에는 성능 문제와 튜닝 기회를 고려하여 추가 용량을 확보하는 것 이 좋습니다. 65

단계별 마이그레이션 원본 SQL Server 데이터베이스를 감사합니다. 각 스키마와 스키마 아래에 있는 모든 객체에 대해 객체가 더 이상 사용되지 않는지 여부를 알아봅니다. 더 이상 사용되지 않는 경우 마이그레이션할 필요가 없으므 로 원본 SQL Server 데이터베이스에서 이러한 객체를 사용 중지합니다. 두 마이그레이션 옵션, 즉 기존 데이터만 마이그레이션하는 옵션과 기존 데이터를 마이그레이션하고 지속 적인 변경 내용을 복제하는 옵션 중에서 결정합니다. 기존 데이터만 마이그레이션하는 경우 마이그레이션은 SQL Server 원본 데이터베이스에서 Aurora MySQL 대상 데이터베이스로 전송되는 일회성 데이터 전송입니다. 원본 데이터베이스가 마이그레이션 중에 변경 가능한 상태로 유지되는 경우 마이그레이션이 완료된 후에 이러한 변경 내용이 대상 데이터베 이스에 적용되어야 합니다. Note SQL Server 데이터베이스가 Amazon RDS 데이터베이스인 경우 복제가 지원되지 않으므로 기 존 데이터만 마이그레이션하는 옵션을 사용해야 합니다. 기존 데이터를 마이그레이션하고 지속적인 변경 내용을 복제하는 경우 사용할 수 있는 한 가지 옵션은 원본 데이터베이스 변경 내용을 복제하는 것입니다. 복제 시 마이그레이션 프로세스 중에 원본 데이터 베이스와 대상 데이터베이스가 서로 동기화 상태로 유지되어 데이터베이스 중단 시간이 감소될 수 있습 니다. 이 옵션을 사용하는 경우 초기 동기화 작업을 완료하고 나서 MS-REPLICATION을 구성합니다. 이 옵션을 사용하려면 Standard, Enterprise 또는 Developer SQL Server 에디션이 필요합니다. 데이터베이 스 원본으로 사용할 각 SQL Server 인스턴스에 대해 MS-REPLICATION을 활성화합니다. 기존 데이터를 마이그레이션하고 지속적인 변경 내용을 복제하려는 경우 사용할 수 있는 또 한 가지 옵 션은 복제 대신에 변경 데이터를 캡처(CDC)하는 것입니다. 이 옵션을 사용하면 AWS DMS가 데이터의 지속적인 마이그레이션을 수행할 수 있습니다. CDC의 경우, AWS DMS는 CDC 테이블을 사용하여 지 속적인 데이터베이스 마이그레이션을 활성화합니다. 이 옵션을 사용하려면 Enterprise 또는 Developer SQL Server 에디션이 필요합니다. AWS DMS에 대한 자세한 내용은 AWS DMS 사용 설명서를 참조하십시오. 단계별 마이그레이션 다음 단계에서는 Microsoft SQL Server 데이터베이스를 Amazon Aurora MySQL 데이터베이스로 마이그레 이션하기 위한 지침을 제공합니다. 이러한 단계에서는 사전 조건 (p. 65)에 설명된 대로 원본 데이터베이 스를 이미 준비했다고 가정합니다. 항목 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치 (p. 66) 2단계: Microsoft SQL Server 원본 데이터베이스 구성 (p. 67) 3단계: Aurora MySQL 대상 데이터베이스 구성 (p. 69) 4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. (p. 69) 5단계: AWS DMS 복제 인스턴스 생성 (p. 77) 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. (p. 78) 7단계: AWS DMS 마이그레이션 작업 생성 및 실행 (p. 82) 8단계: Aurora MySQL로 전환 (p. 85) 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치 먼저 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool(AWS SCT)을 설치합니다. 66

2단계: Microsoft SQL Server 원본 데이터베이스 구성 SQL 클라이언트 소프트웨어를 설치하려면 1. Microsoft SQL Server용 JDBC 드라이버를 다운로드합니다. 2. Aurora MySQL용 JDBC 드라이버를 다운로드합니다. Amazon Aurora MySQL에는 MySQL 드라이버가 사용됩니다. 3. AWS SCT 및 필수 JDBC 드라이버를 설치합니다. a. AWS Schema Conversion Tool 사용 설명서에서 AWS Schema Conversion Tool 설치 및 업데이 트를 참조하고 해당 링크를 선택하여 AWS SCT를 다운로드합니다. b. AWS SCT를 시작하고 [Settings], [Global Settings]를 선택합니다. c. [Global Settings]에서 [Drivers]를 선택한 후 [Browse]를 선택하여 [Microsoft Sql Server Driver Path] 를 찾습니다. SQL Server용 JDBC 드라이버를 찾아서 [OK]를 선택합니다. d. [Browse]를 선택하여 [MySql Driver Path]를 찾습니다. Aurora MySQL에 다운로드한 JDBC 드라이 버를 찾아서 [OK]를 선택합니다. e. [OK]를 선택하여 [Global Settings] 대화 상자를 닫습니다. 2단계: Microsoft SQL Server 원본 데이터베이스 구성 SQL 드라이버 및 AWS Schema Conversion Tool를 설치한 후 원하는 데이터 마이그레이션 방식에 따라 여 러 옵션 중 하나를 사용하여 Microsoft SQL Server 원본 데이터를 구성할 수 있습니다. SQL Server 원본 데이터베이스를 구성하려면 원본 데이터베이스를 구성할 때는 기존 데이터만을 마이그레이션하거나, 기존 데이터를 마이그레이션 하고 지속적인 변경 내용을 복제하거나, 기존 데이터를 마이그레이션하고 변경 데이터 캡처(CDC)를 사 용하도록 선택하여 지속적인 변경 내용을 복제할 수 있습니다. 이러한 옵션에 대한 자세한 내용은 사전 요구 사항을 참조하십시오. 기존 데이터만 마이그레이션 67

2단계: Microsoft SQL Server 원본 데이터베이스 구성 SQL Server 데이터베이스에는 구성 단계가 필요하지 않습니다. 3단계: Aurora MySQL 대상 데이터베 이스 구성 (p. 69) 섹션으로 이동할 수 있습니다. Note SQL Server 데이터베이스가 Amazon RDS 데이터베이스인 경우 복제가 지원되지 않으므로 기존 데이터만 마이그레이션하는 옵션을 사용해야 합니다. 기존 데이터 마이그레이션과 지속적인 변경 복제 Note 복제하려면 복제할 모든 테이블에 대해 기본 키가 필요합니다. 테이블에 기본 키가 정의되지 않은 경우 CDC 사용을 고려해 보십시오. MS-REPLICATION을 구성하려면 다음 단계를 완료합니다. 1. Microsoft SQL Server Management Studio에서 [Replication] 폴더의 컨텍스트(마우스 오른쪽 버 튼을 클릭) 메뉴를 열고 나서 [Configure Distribution]을 선택합니다. 2. [Distributor] 단계에서 [db_name will act as its own distributor]를 선택합니다. SQL Server는 배포 데이터베이스와 로그를 생성합니다. 자세한 내용은 Microsoft 설명서를 참조하십시오. 구성이 완료되면 복제에 대해 서버가 활성화됩니다. 배포 데이터베이스가 제 위치에 있거나, 원격 배포 데이터베이스를 사용하도록 서버를 구성했습니다. 기존 데이터를 마이그레이션하고 변경 데이터 캡처(CDC)를 사용하여 지속적인 변경 내용 복제 MS-CDC를 구성하려면 다음 단계를 완료합니다. 1. SYSADMIN 역할 멤버십이 지정된 로그인을 사용하여 SLQ Server에 연결합니다. 2. 마이그레이션되는 데이터를 포함하는 각 데이터베이스마다 데이터베이스 컨텍스트 내에서 다음 명령을 실행합니다. use [DBname] EXEC sys.sp_cdc_enable_db 3. 진행 중인 마이그레이션용으로 구성할 각 테이블마다 다음 명령을 실행합니다. EXEC sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL; 자세한 내용은 Microsoft 설명서를 참조하십시오. Note AlwaysOn 가용성 그룹에 포함되는 데이터베이스를 마이그레이션하려는 경우 마이그레이션용으 로 복제를 사용하는 것이 좋습니다. 이 옵션을 사용하려면 게시를 활성화하고 AlwaysOn 가용성 그룹의 각 노드마다 배포 데이터베이스를 구성해야 합니다. 추가로, 가용성 그룹 데이터베이스를 현재 호스팅 중인 서버 이름이 아닌 데이터베이스의 가용성 그룹 리스너 이름을 대상 서버 이름으 로 사용하고 있는지 확인합니다. 이러한 요구 사항은 클러스터의 각 SQL Server 인스턴스에 적용 되며 가용성 그룹 리스너를 사용하여 구성하면 안 됩니다. 데이터베이스가 MS-REPLICATION 또는 MS-CDC에 지원되지 않는 경우(예를 들면 SQL Server 의 Workgroup 버전을 실행 중인 경우), INSERT 및 DELETE 문 같은 일부 변경 내용을 여전히 캡 68

3단계: Aurora MySQL 대상 데이터베이스 구성 처할 수 있지만, UPDATE 및 TRUNCATE TABLE 같은 다른 DML 문은 캡처되지 않습니다. 그러므 로 연속 데이터 복제를 이용한 마이그레이션은 이 구성에서는 권장되지 않으며, 대신에 고정 일회 성 마이그레이션(또는 반복 일회성 전체 마이그레이션)을 고려해야 합니다. MS-REPLICATION 및 MS-CDC 사용에 대한 자세한 내용은 Configuring a Microsoft SQL Server Database as a Replication Source for 섹션을 참조하십시오. 3단계: Aurora MySQL 대상 데이터베이스 구성 AWS DMS는 SQL Server 원본에서 Amazon Aurora MySQL 대상으로 데이터를 마이그레이션합니다. 이 단 계에서는 Aurora MySQL 대상 데이터베이스를 구성합니다. 1. 대상 데이터베이스에 연결할 AWS DMS 사용자를 생성하고, 수퍼유저 또는 필요한 개인 권한을 부여하 거나 RDS의 마스터 사용자 이름(Amazon RDS의 경우)을 사용합니다. 또는 권한을 기존 사용자에게 부여할 수 있습니다. CREATE USER 'aurora_dms_user' IDENTIFIED BY 'password'; GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON target_database.* TO 'aurora_dms_user'; 2. AWS DMS에서는 awsdms_control 데이터베이스의 대상에 제어 테이블을 사용합니다. 다음 명령을 사용하여 사용자에게 awsdms_control 데이터베이스에 필요한 액세스 권한이 있는지 확인합니다. GRANT ALL PRIVILEGES ON awsdms_control.* TO 'aurora_dms_user'; FLUSH PRIVILEGES; 4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 데이터를 Amazon Aurora MySQL로 변환하려면 먼저 AWS Schema Conversion Tool(AWS SCT)을 사용하 여 Microsoft SQL Server 스키마를 Aurora MySQL 스키마로 변환합니다. SQL Server 스키마를 Aurora MySQL 스키마로 변환하려면 1. AWS SCT에서 [File], [New Project]를 선택합니다. AWS Schema Conversion Tool SQL Server to Aurora MySQL 이름의 새 프로젝트를 생성합니다. 2. [New Project] 대화 상자에서 다음 정보를 입력한 다음 [OK]를 선택합니다. 파라미터 설명 [프로젝트 이름] AWS Schema Conversion Tool SQL Server to Aurora MySQL을 입력합니다. [Location] 기본 [Projects] 폴더와 기본 [Transactional Database (OLTP)] 옵션을 사용합니다. 69

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 3. 파라미터 설명 [Source Database Engine] [Microsoft SQL Server]를 선택합니다. [Target Database Engine] [Amazon Aurora(MySQL compatible)]를 선택합니다. [Connect to Microsoft SQL Server]를 선택합니다. [Connect to Microsoft SQL Server] 대화 상자에서 다 음 정보를 입력한 후 [Test Connection]을 선택합니다. 파라미터 설명 [Server name] 서버 이름을 입력합니다. [Server port] SQL Server 포트 번호를 입력합니다. 기본값은 1433입니 다. Instance name SQL Server 데이터베이스 인스턴스 이름을 입력합니다. 사용자 이름 SQL Server 관리자의 사용자 이름을 입력합니다. [Password] 관리 사용자 암호를 입력합니다. 70

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 4. [OK]를 선택하여 경고 상자를 닫습니다. 그런 다음 [OK]를 선택하여 대화 상자를 닫고 SQL Server DB 인스턴스와의 연결을 시작합니다. SQL Server DB 인스턴스의 데이터베이스 구조가 표시됩니다. 5. [Connect to Amazon Aurora(MySQL 호환)]를 선택합니다. [Connect to Amazon Aurora(MySQL 호환)] 대화 상자에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 파라미터 설명 [Server name] 서버 이름을 입력합니다. [Server port] SQL Server 포트 번호를 입력합니다. 기본값은 3306입니 다. 사용자 이름 Aurora MySQL 관리자의 사용자 이름을 입력합니다. [Password] 관리 사용자 암호를 입력합니다. 71

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 6. [OK]를 선택하여 경고 상자를 닫습니다. 그런 다음 [OK]를 선택하여 대화 상자를 닫고 Aurora MySQL DB 인스턴스와의 연결을 시작합니다. 7. 마이그레이션할 스키마에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 나서 [Convert schema] 를 선택합니다. 72

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 8. 확인 메시지에서 [Yes]를 선택합니다. 그런 다음 AWS SCT는 스키마를 대상 데이터베이스 형식으로 변 환합니다. 73

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. AWS SCT는 스키마를 분석하고 Aurora MySQL로의 변환을 위한 데이터베이스 마이그레이션 평가 보 고서를 생성합니다. 9. [View]에서 [Assessment Report View]를 선택하여 보고서를 확인합니다. 보고서는 변환이 성공적으로 수행되는 데 필요한 수동 변경의 양과 각 객체 유형별로 구분됩니다. 74

4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. 일반적으로 패키지, 절차 및 기능은 매우 세부적으로 사용자 지정된 PL/SQL 코드를 포함하므로 해결할 문제가 있을 가능성이 높습니다. 또한 AWS SCT는 이러한 객체를 수정하는 방법에 대한 힌트를 제공합 니다. 10. [Action Items] 탭을 선택합니다. [Action Items] 탭에는 주의를 요하는 각 객체에 대한 각 문제가 표시됩니다. 각 변환 문제마다 다음 작업 중 하나를 완료할 수 있습니다. AWS SCT에서는 객체를 대상 Aurora MySQL 데이터베이스로 변환할 수 있도록 원본 SQL Server 데이터베이스에서 객체를 수정합니다. 1. 원본 SQL Server 데이터베이스에서 객체를 수정합니다. 2. 이전 단계를 반복하여 스키마를 변환하고 평가 보고서를 확인합니다. 3. 필요할 경우 변환 문제가 없을 때까지 이 프로세스를 반복합니다. 75

4. 4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. [Main View]를 [View]에서 선택합니다. 대상 Aurora MySQL 스키마에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 [Apply to database]를 선택하여 스키마 변경 내용을 Aurora MySQL 데이터베이스에 적용한 후, 스키마 변경 내용을 적용하고자 함을 확인합니다. 대상 Aurora MySQL 데이터베이스에서 스크립트를 적용하기 전에 원본 스키마를 수정하는 대신에 AWS SCT에 의해 생성된 스크립트를 수정합니다. 1. [Main View]를 [View]에서 선택합니다. 대상 Aurora MySQL 스키마 이름에 대한 컨텍스트(마우 스 오른쪽 버튼 클릭)를 열고 [Save as SQL]을 선택합니다. 다음에는 스크립트의 이름과 대상 을 선택합니다. 2. 스크립트에서 객체를 수정하여 변환 문제를 해결합니다. 또한 마이그레이션 시 문제를 유발할 수 있으므로 스크립트에서 외래 키 제약 조건, 트리거 및 보조 인덱스를 제외할 수도 있습니다. 마이그레이션이 완료된 후에는 Aurora MySQL 데이터베 이스에서 이러한 객체를 생성할 수 있습니다. 3. 대상 Aurora MySQL 데이터베이스에서 스크립트를 실행합니다. 자세한 내용은 AWS Schema Conversion Tool 사용 설명서의 Converting Database Schema to Amazon RDS by Using the AWS Schema Conversion Tool 단원을 참조하십시오. 11. (선택 사항) AWS SCT를 사용하여 매핑 규칙을 생성합니다. a. [Settings]에서 [Mapping Rules]를 선택합니다. 76

5단계: AWS DMS 복제 인스턴스 생성 b. 작업 항목에 따라 요구되는 추가 매핑 규칙을 생성합니다. c. 매핑 규칙을 저장합니다. d. [Export script for DMS]를 선택하여 AWS DMS 작업에서 사용할 모든 변환의 JSON 형식을 내보냅 니다. Save를 선택합니다. 5단계: AWS DMS 복제 인스턴스 생성 원본과 대상 데이터베이스 간의 스키마 구조를 검증한 후 이 연습의 핵심 부분인 데이터 마이그레이션을 계 속 진행합니다. 다음 그림은 마이그레이션 프로세스의 상위 수준 보기를 보여줍니다. AWS DMS 복제 인스턴스는 원본과 대상 간에 실제 데이터 마이그레이션을 수행합니다. 복제 인스턴스도 마 이그레이션 중에 트랜잭션 로그를 캐시합니다. 복제 인스턴스에 보유한 CPU 및 메모리 용량은 마이그레이 션에 소요되는 전체 시간에 영향을 미칩니다. AWS DMS 사용 관련 모범 사례에 대한 자세한 내용은 모범 사례를 참조 하십시오. AWS DMS 복제 인스턴스를 생성하려면 1. AWS Management 콘솔에 로그인하고 https://console.aws.amazon.com/dms/에서 AWS DMS 콘솔을 엽니다. 2. 이 콘솔에서 [Create migration]을 선택합니다. AWS Identity and Access Management(IAM) 사용자로 로그인한 경우 AWS DMS에 액세스할 수 있는 적절한 권한이 있어야 합니다. 필요한 권한에 대한 자세 한 내용은 AWS DMS를 사용하는 데 필요한 IAM 권한을 참조하십시오. 3. Welcome 페이지에서 [Next]를 선택하여 데이터베이스 마이그레이션을 시작합니다. 4. [Create replication instance] 페이지에서 복제 인스턴스 정보를 지정합니다. 파라미터 설명 이름 복제 인스턴스의 이름을 선택합니다. 여러 복제 서버를 사용 중이거나 계정을 공유하고 있는 경우 다양한 서버 간에 빨리 구분할 수 있는 이름을 선택합니다. 설명 간단한 설명을 입력합니다. 인스턴스 클래스 생성할 복제 서버의 유형을 선택합니다. 인스턴스 클래스의 각 크기 및 유형이 CPU, 메모리 및 I/O 용량을 증가시킵니 다. 일반적으로 t2 인스턴스는 저로드 작업용이며, c4 인스 턴스는 고로드 및 기타 작업용입니다. [VPC] 복제 인스턴스를 시작할 가상 프라이빗 클라우드(VPC)를 선택합니다. 가능한 경우 원본이나 대상 데이터베이스(또는 이 모두)가 상주하는 동일한 VPC를 선택합니다. 77

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 5. 파라미터 설명 다중 AZ [Yes]를 선택하는 경우 AWS DMS에서는 기본 복제 서버 관 련 문제가 있는 경우 장애 조치용으로 사용할 두 번째 복제 서버를 다른 가용 영역에 생성합니다. [Publicly accessible] 복제 서버가 상주하는 VPC 외부에 원본이나 대상 데이터베 이스가 상주하는 경우 복제 서버 정책을 공개적으로 액세스 할 수 있도록 설정해야 합니다. [Advanced] 섹션에서는 다음 정보를 지정합니다. 파라미터 설명 [Allocated storage (GB)] 과거 작업 로그를 포함하여 AWS DMS 작업 로그에 대한 복 제 서버의 스토리지 양. 또한 AWS DMS는 디스크 스토리지 를 사용하여 특정 데이터를 캐시하는 동시에, 원본 데이터베 이스에서 대상 데이터베이스로 복제합니다. 또한, 스토리지 가 많을수록 일반적으로 서버에서 IOPS가 향상됩니다. [Replication Subnet Group] 다중-AZ 구성에서 실행 중인 경우 두 개 이상의 서브넷 그룹 이 필요합니다. [Availability zone] 일반적으로 대상 데이터베이스와 동일한 가용 영역에 기본 할당 서버가 있으면 성능이 향상됩니다. VPC Security Group(s) 보안 그룹을 사용하면 VPC에 대한 수신 및 송신을 제어할 수 있습니다. AWS DMS에서는 복제 서버가 시작되는 VPC 와 하나 이상의 보안 그룹을 연결할 수 있습니다. [KMS master key] AWS DMS를 통해 모든 데이터는 KMS 암호화 키를 사용하 여 유휴 상태로 암호화됩니다. 기본적으로 AWS DMS는 사 용자의 복제 서버에서 새 암호화 키를 생성합니다. 하지만 기존 키를 사용하도록 선택할 수도 있습니다. KMS 마스터 키에 대한 자세한 내용은 암호화 키 설정 및 KMS 권한 지정을 참조하십시오. 6. [Next]를 클릭합니다. 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니 다. 복제 인스턴스를 생성 중인 동안 AWS Management 콘솔을 사용하여 원본 및 대상 데이터베이스 엔드포인 트를 지정할 수 있습니다. 하지만 복제 인스턴스가 연결에 사용되므로 복제 인스턴스가 생성된 후에만 연결 을 테스트할 수 있습니다. 콘솔을 사용하여 원본 또는 대상 데이터베이스 엔드포인트를 지정하려면 1. AWS DMS 콘솔에서 원본 SQL Server 데이터베이스와 대상 Aurora MySQL 데이터베이스의 연결 정보 를 지정합니다. 다음 표는 원본 설정에 대한 설명입니다. 파라미터 설명 [Endpoint Identifier] SQLServerSource 같은 이름을 입력합니다. 78

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 파라미터 설명 소스 엔진 [sqlserver]를 선택합니다. [Server name] SQL Server DB 인스턴스 서버 이름을 지정합니다. Port 데이터베이스의 포트 번호를 입력합니다. SQL Server의 기 본값은 1433입니다. [SSL mode] 연결 트래픽에 대해 암호화를 활성화해야 하는 경우 SSL 모 드를 선택합니다. 사용자 이름 원본 데이터베이스에 연결하는 데 사용할 사용자의 이름을 입력합니다. [Password] 사용자 암호를 입력합니다. 데이터베이스 이름 SQL Server 데이터베이스 이름을 지정합니다. 다음 표에서는 고급 원본 설정을 설명합니다. 파라미터 설명 [Extra connection attributes] AWS DMS의 동작을 변경하거나 기능을 추가하기 위해 엔 드포인트에서 설정할 수 있는 추가 파라미터. 여기에 나열된 속성은 가장 관련도가 높은 일부 속성입니다. 세미콜론(;)을 사용하여 여러 항목을 구분합니다. safeguardpolicy - AWS DMS에서 로그를 읽는 동안 트랜잭션 로그가 잘리지 않도록 트랜잭션을 열 어서 SQL Server의 작동을 변경합니다. 유효한 값 은 EXCLUSIVE_AUTOMATIC_TRUNCATION 또는 RELY_ON_SQL_SERVER_REPLICATION_AGENT(기본값) 입니다. usebcpfullload - AWS DMS에 데이터 로드 시 BCP(대량 복사)를 사용하도록 지정합니다. 유효한 값은 Y 또는 N입니다. 원본 테이블에 없는 자격 증명 열이 대상 테이블에 들어 있는 경우 파라미터를 N으로 설정하여 테 이블 로드 시 BCP 사용을 비활성화해야 합니다. BCPPacketSize - BCP가 데이터 로드용으로 활성화된 경우 BCP에 사용되는 최대 패킷 크기를 입력합니다. 유효 한 값은 1 100000(기본값 16384)입니다. controltablesfilegroup - 데이터베이스에서 AWS DMS 프로세스가 생성하는 제어 테이블에 사용할 파일 그 룹을 지정합니다. [KMS master key] 복제 인스턴스의 스토리지를 암호화하기로 한 경우 KMS 마 스터 키를 입력합니다. 다음 표는 대상 설정에 대한 설명입니다. 파라미터 설명 [Endpoint Identifier] Auroratarget 같은 이름을 입력합니다. 79

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 파라미터 설명 [Target Engine] [aurora]를 선택합니다. [Server name] 기본 인스턴스에 대해 Aurora MySQL DB 서버 이름을 지정 합니다. Port 데이터베이스의 포트 번호를 입력합니다. Aurora MySQL의 기본값은 3306입니다. [SSL mode] [None]을 선택합니다. 사용자 이름 대상 데이터베이스에 연결하는 데 사용할 사용자의 이름을 입력합니다. [Password] 사용자 암호를 입력합니다. 다음 표에서 고급 대상 설정을 설명합니다. 파라미터 설명 [Extra connection attributes] AWS DMS의 동작을 변경하거나 기능을 추가하기 위해 엔 드포인트에서 설정할 수 있는 추가 파라미터. 여기에 나열된 속성은 가장 관련도가 높은 일부 속성입니다. 세미콜론을 사 용하여 여러 항목을 구분합니다. targetdbtype - 기본적으로 AWS DMS는 마이그레이 션되는 각 스키마마다 다른 데이터베이스를 생성합니다. 여러 스키마를 단일 데이터베이스로 결합하려면 이 옵션 을 targetdbtype=specific_database로 설정합니 다. initstmt - 이 옵션을 사용하여 MySQL initstmt 연결 파라미터를 호출하고 MySQL initstmt에서 허용하는 것을 허용할 수 있습니다. Aurora MySQL 대상의 경우, 이 옵션을 initstmt=set FOREIGN_KEY_CHECKS=0으로 설정하여 외래 키 검사를 비활성화하는 것이 매우 유용합 니다. [KMS master key] 복제 인스턴스의 스토리지를 암호화하기로 한 경우 KMS 마 스터 키를 입력합니다. 다음은 완료한 페이지의 예입니다. 80

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 추가 연결 속성에 대한 자세한 내용은 Using Extra Connection Attributes with AWS Database Migration Service를 참조하십시오. 2. 엔드포인트와 복제 인스턴스가 생성된 후, 원본 및 대상 엔드포인트에 대해 [Run test]를 선택하여 엔드 포인트 연결을 테스트합니다. 3. 대상 데이터베이스에서 외래 키 제약 조건 및 트리거를 삭제합니다. 전체 로드 프로세스를 수행하는 동안 AWS DMS는 특정 순서로 테이블을 로드하지 않으므로 상위 테이 블 데이터 전에 하위 테이블 데이터를 로드할 수도 있습니다. 따라서 외래 키 제약 조건이 활성화되는 경 우 이러한 제약 조건을 위반하게 될 수도 있습니다. 또한 트리거가 대상 데이터베이스에 있는 경우 이러 한 트리거가 AWS DMS에 의해 로드되는 데이터를 예기치 않은 방식으로 변경할 수도 있습니다. ALTER TABLE 'table_name' DROP FOREIGN KEY 'fk_name'; DROP TRIGGER 'trigger_name'; 4. 대상 데이터베이스에서 외래 키 제약 조건과 트리거를 삭제한 경우 외래 키 제약 조건과 트리거를 활성 화하는 스크립트를 생성합니다. 나중에 마이그레이션된 데이터베이스에 추가하려는 경우에는 이 스크립트만 실행하면 됩니다. 5. (선택 사항) 대상 데이터베이스에 보조 인덱스를 삭제합니다. 81

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 보조 인덱스(모든 인덱스와 마찬가지로)로 인해 데이터를 테이블로 전체 로드하는 속도가 느려질 수 있 습니다. 로딩 프로세스를 수행하는 동안 보조 인덱스를 유지 및 업데이트해야 하기 때문입니다. 이러한 인덱스를 삭제하면 전체 로드 프로세스의 성능이 향상될 수 있습니다. 인덱스를 삭제하는 경우 전체 로 드가 완료된 후 나중에 인덱스를 다시 추가해야 합니다. ALTER TABLE 'table_name' DROP INDEX 6. 'index_name'; [Next]를 선택합니다. 7단계: AWS DMS 마이그레이션 작업 생성 및 실행 AWS DMS 작업을 사용하여 마이그레이션할 스키마와 마이그레이션 유형을 지정할 수 있습니다. 기존 데이 터를 마이그레이션하거나, 지속적 변경 사항을 복제하거나, 또는 데이터 변경 사항만 복제할 수 있습니다. 마이그레이션 작업을 생성하려면 1. AWS DMS 콘솔의 [Create task] 페이지에서 작업 옵션을 지정합니다. 다음 표는 설정에 대한 설명입니 다. 파라미터 설명 [Task name] 마이그레이션 작업의 이름을 입력합니다. [Task description] 작업 설명을 입력합니다. [Source endpoint] SQL Server 소스 엔드포인트를 표시합니다. 계정에 두 개 이상의 엔드포인트가 있는 경우 목록에서 올바 른 엔드포인트를 선택합니다. [Target endpoint] Aurora MySQL 대상 엔드포인트를 표시합니다. 복제 인스턴스 AWS DMS 복제 인스턴스를 표시합니다. [Migration type] 옵션을 선택합니다. Migrate existing data - AWS DMS 기존 데이터만 마이그 레이션합니다. 원본 데이터에 대한 변경 사항이 대상에 캡 처 및 적용되지 않습니다. 전체 로드 기간 동안 중단을 감 수할 수 있는 경우 이 옵션이 가장 간단한 마이그레이션 옵션입니다. 또한 이 옵션을 사용하여 데이터베이스의 테 스트 사본을 생성할 수도 있습니다. 원본 SQL Server 데 이터베이스가 Amazon RDS 데이터베이스인 경우 이 옵 션을 선택해야 합니다. Migrate existing data and replicate ongoing changes AWS DMS는 기존 데이터를 마이그레이션하는 동안 변경 내용을 캡처합니다. AWS DMS에서는 대량 데이터를 로 드한 후에도 계속해서 변경 사항을 캡처하고 적용합니다. 결국 원본과 대상 데이터베이스는 동기화되어 중단 시간 을 최소화할 수 있습니다. Replicate data changes only - 다른 방법을 사용하여 데이 터를 대량 로드합니다. 이 접근 방식은 동종 마이그레이션 에만 적용됩니다. 82

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 파라미터 설명 [Start task on create] 대부분의 상황에서 이 옵션을 선택해야 합니다. 때로는 작업 시작을 지연시켜야 할 수도 있습니다. 예를 들면 로깅 수준 을 변경하려는 경우가 이에 해당합니다. 페이지는 다음과 비슷하게 보일 것입니다. 2. [Task settings]에서 설정을 지정합니다. 다음 표는 설정에 대한 설명입니다. 파라미터 설명 [Target table preparation mode] 옵션을 선택합니다. Do nothing - AWS DMS는 테이블을 준비하기 위해 아무 런 작업도 수행하지 않습니다. 테이블 구조는 동일하게 유 지되고 기존 데이터는 테이블에 남습니다. 이 메서드를 사 용하여 여러 시스템의 데이터를 통합할 수 있습니다. Drop tables on target - AWS DMS에서 대상 테이블이 자동으로 생성됩니다. AWS DMS는 테이블을 삭제했다 가 마이그레이션 전에 테이블을 다시 생성합니다. AWS DMS는 동종 마이그레이션에 대해서만 테이블과 기본 키 를 만듭니다. Truncate - AWS DMS는 대상 테이블을 로드하기 전에 자 릅니다. 대상 테이블이 존재하지 않으면 AWS DMS에서 대상 테이블을 생성합니다. Important If the AWS Schema Conversion Tool이 대상에 테이블을 이미 생성한 경우 [Do nothing] 또는 [Truncate]를 선택합니다. [Include LOB columns in replication] 옵션을 선택합니다. 83

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 파라미터 설명 Don't include LOB columns - LOB 데이터를 마이그레이 션하지 않습니다. [Full LOB mode] - AWS DMS는 크기와 관계 없이 원본에 서 대상으로 모든 LOB(대형 객체)를 마이그레이션합니 다. 이 구성에서 AWS DMS에는 예상할 수 있는 최대 크 기의 LOB 정보가 없습니다. 또한, LOB는 한 번에 하나씩, 조각별로 마이그레이션됩니다. 전체 LOB 모드는 상당히 느릴 수 있습니다. Limited LOB mode - AWS DMS에서 허용하는 최대 크기 LOB를 설정할 수 있습니다. 이 옵션을 통해 AWS DMS는 메모리를 미리 할당하고 LOB 데이터를 대량으로 로드할 수 있습니다. 최대 LOB 크기를 초과하는 LOB는 잘리고 경고가 로그 파일에 발행됩니다. [ limited LOB mode]는 [full LOB mode]에 비해 상당한 성능 이점이 있습니다. 가 능하다면 [limited LOB mode] 사용을 권장합니다. [Max LOB size (kb)] [Limited LOB mode]를 선택하는 경우 이 옵션은 AWS DMS 에서 수용하는 최대 크기의 LOB를 결정합니다. 이 값보다 큰 LOB는 이 값으로 잘립니다. [Enable logging] [Enable logging]을 선택하는 것이 좋습니다. 로깅을 활성화 할 경우 작업에서 발생하는 오류나 경고를 확인하고 이러한 문제를 해결할 수 있습니다. 3. [Advanced] 설정을 기본값으로 둡니다. 4. 4단계: AWS SCT를 사용하여 SQL Server 스키마를 Aurora MySQL로 변환합니다. (p. 69) 섹션의 마 지막 단계에서 AWS SCT를 사용하여 매핑 규칙을 생성 및 내보낸 경우 [Table mappings]를 선택한 다음 [JSON] 탭을 선택합니다. 그런 다음 [Enable JSON editing]을 선택하고 저장한 테이블 매핑을 입력합니 다. 매핑 규칙을 생성하지 않은 경우 다음 단계로 이동합니다. 5. [Create task]를 선택합니다. 작업이 즉시 시작됩니다. [Tasks] 섹션에는 마이그레이션 작업 상태가 나타납니다. 설정하는 동안 [Enable logging]을 선택했으면 작업을 모니터링할 수 있습니다. 그러고 나면 Amazon CloudWatch 측정치를 볼 수 있습니다. 진행 중인 데이터 마이그레이션 작업을 모니터링하려면 1. 2. 3. 탐색 창에서 [Tasks]를 선택합니다. 마이그레이션 작업을 선택합니다. [Task monitoring] 탭을 선택하고 이 탭에서 진행 중인 작업을 모니터링합니다. 전체 로드가 완료되고 캐시된 변경 사항이 적용되면 작업 자체가 중지됩니다. 4. 대상 Aurora MySQL 데이터베이스에서 외래 키 제약 조건과 트리거를 비활성화한 경우 이전에 저장한 스크립트를 사용하여 활성화합니다. 84

8단계: Aurora MySQL로 전환 5. 대상 Aurora MySQL 데이터베이스에서 이전에 제거한 경우 보조 인덱스를 다시 생성합니다. 6. AWS DMS를 사용하여 변경 내용을 복제하도록 선택한 경우 AWS DMS 콘솔에서 작업에 대해 [Start/ Resume]을 선택하여 AWS DMS 작업을 시작합니다. 모니터링할 중요 복제 인스턴스 측정치는 다음과 같습니다. CPU FreeableMemory DiskQueueDepth CDCLatencySource CDCLatencyTarget AWS DMS 작업은 원본 데이터 변경 내용으로 대상 Aurora MySQL 데이터베이스를 항상 최신 상태로 유지합니다. AWS DMS는 애플리케이션 마이그레이션을 구현할 시기가 도래할 때까지 작업의 모든 테 이블을 최신 상태로 유지합니다. 대상이 원본과 거의 비슷해지면 지연 시간이 0이거나 0에 가깝습니다. 자세한 내용은 작업 모니터링을 참조하십시오. 8단계: Aurora MySQL로 전환 다음 단계를 수행하여 Microsoft SQL Server 데이터베이스에서 Amazon Aurora MySQL 데이터베이스로 연 결을 전환합니다. Aurora MySQL로 전환하려면 1. 스크립트 실행 및 클라이언트 연결 같은 모든 SQL Server 데이터베이스 종속성 및 작업을 종료합니다. SQL Server 에이전트 서비스가 중지되었는지 확인합니다. 다음 쿼리 시 연결 이와의 결과가 반환되지 않아야 합니다. SELECT session_id, login_name from sys.dm_exec_sessions where session_id > 50; 2. 나머지 세션(소유 세션 이외)을 종료합니다. KILL session_id; 3. SQL Server 서비스를 종료합니다. 4. AWS DMS에서 Amazon Aurora MySQL 데이터베이스에 SQL Server 데이터베이스의 최종 변경 내용이 적용되게 합니다. 5. AWS DMS 콘솔에서 작업에 대해 [Stop]을 선택하고 다음 작업을 중지하려 함을 확인함으로써 AWS DMS 작업을 중지합니다. 문제 해결 Microsoft SQL Server를 원본 데이터베이스로, Amazon Aurora MySQL을 대상 데이터베이스로 사용하여 작 업하는 경우 가장 일반적으로 문제가 발생하는 영역은 SQL Server 변경 데이터 캡처(CDC) 및 외래 키입니 다. 85

문제 해결 MS-CDC: 마이그레이션 시 SQL Server와 함께 MS-CDC를 사용하려는 경우 변경 데이터 캡처 중 오류 또 는 권한 관련 오류가 일반적으로 발생합니다. 사전 요구 사항 중 하나가 충족되지 않은 경우 일반적으로 이 러한 오류 유형이 발생합니다. 예를 들어, 자주 간과되는 사전 요구 사항은 전체 데이터베이스 백업입니다. 외래 키: 전체 로드 프로세스를 수행하는 동안 AWS DMS에서 테이블을 특정 순서대로 로드하지 않으므로 상위 테이블 데이터 이전에 하위 테이블 데이터가 로드될 수도 있습니다. 따라서 외래 키 제약 조건이 활성 화되는 경우 이러한 제약 조건을 위반하게 될 수도 있습니다. Aurora MySQL 대상 데이터베이스에서 외래 키를 비활성화해야 합니다. 마이그레이션이 완료된 후 대상에서 외래 키를 활성화할 수 있습니다. 추가 팁을 보려면 AWS DMS 사용 설명서의 AWS DMS 문제 해결 섹션을 참조하십시오. SQL Server 관련 문제를 보려면 SQL Server 문제 해결 섹션을 참조하십시오. Microsoft SQL Server별 문제 해결 Aurora MySQL 문제를 해결하려면 Aurora MySQL 문제 해결 섹션과 MySQL 문제 해결 섹션을 참조하십시 오. Amazon Aurora MySQL 관련 문제 해결 MySQL별 문제 해결 86

사전 조건 Oracle 데이터베이스를 PostgreSQL 로 마이그레이션 이 연습을 통해 (AWS DMS) 및 AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 데이터베이스를 PostgreSQL 데이터베이스로 마이그레이션하는 방법을 배울 수 있 습니다. AWS DMS는 데이터를 Oracle 원본에서 &PostgreSQL 대상으로 마이그레이션합니다. 또한 AWS DMS는 원 본 데이터베이스에 나타나는 지원 데이터 정의 언어(DDL) 변경 내용을 캡처하고 대상 데이터베이스에 이러 한 변경 내용을 적용합니다. AWS DMS는 이러한 방식을 통해 원본과 대상 데이터베이스를 서로 동기적으로 유지합니다. 데이터 마이그레이션을 지원하기 위해 AWS SCT는 필요할 경우 대상의 테이블과 기본 키 인덱 스를 비롯하여 대상 데이터베이스에서 마이그레이션된 스키마를 생성합니다. 그렇지만, AWS DMS는 특히 데이터 마이그레이션과 관련되지 않은 보조 인덱스, 시퀀스, 기본값, 저장된 절 차, 트리거, 동의어, 보기 및 기타 스키마 객체를 마이그레이션하지 않습니다. 이러한 객체를 PostgreSQL 대 상으로 마이그레이션하려면 AWS SCT를 사용합니다. 항목 사전 조건 (p. 87) 단계별 마이그레이션 (p. 88) 마이그레이션 롤백 (p. 109) 문제 해결 (p. 109) 사전 조건 이 연습을 완료하려면 다음 사전 요구 사항이 충족되어야 합니다. Amazon Relational Database Service(Amazon RDS), 해당되는 데이터베이스 기술 및 SQL을 이해합니다. AWS 리전에서 Amazon Relational Database Service(Amazon RDS)와 AWS Database Migration Service(AWS DMS) 인스턴스를 시작할 수 있도록 해주는 AWS Identity and Access Management(IAM) 자 격 증명을 가진 AWS 계정을 생성합니다. IAM 자격 증명에 대한 자세한 내용은 IAM 사용자 생성을 참조하 십시오. Amazon Virtual Private Cloud(Amazon VPC) 서비스 및 보안 그룹에 대해 이해합니다. Amazon RDS에서 Amazon VPC를 사용하는 방법에 대한 정보는 Amazon Virtual Private Cloud(VPC) 및 Amazon RDS 섹션 을 참조하십시오. Amazon RDS 보안 그룹에 대한 자세한 내용은 Amazon RDS 보안 그룹을 참조하십시 오. AWS DMS의 지원 기능 및 제한 사항에 대해 이해합니다. AWS DMS에 대한 자세한 내용은 AWS Database Migration Service란 무엇입니까? 를 참조하십시오. Oracle 및 PostgreSQL에서 지원되는 데이터 형식 변환 옵션에 대해 이해합니다. 원본으로서 Oracle용 데 이터 형식에 대한 정보는 에서 Oracle 데이터베이스를 원본으로 사용 을 참조하십시오. 대상으로서 PostgreSQL용 데이터 형식에 대한 정보는 PostgreSQL 데이터베이스를 AWS Database Migration Service에서 원본으로 사용 을 참조하십시오. 대상 PostgreSQL 데이터베이스 호스트의 규모를 조정합니다. DBA는 현재 원본 Oracle 데이터베이스 호 스트의 로드 프로필을 알고 있어야 합니다. CPU, 메모리 및 IOPS를 고려합니다. RDS를 사용하여 마이그 레이션 후에 대상 데이터베이스 호스트의 규모를 늘리거나 줄일 수 있습니다. PostgreSQL로 처음 마이그 레이션하는 경우에는 성능 문제와 튜닝 기회를 고려하여 추가 용량을 확보하는 것이 좋습니다. 87

단계별 마이그레이션 원본 Oracle 데이터베이스를 감사합니다. 각 스키마와 스키마 아래에 있는 모든 객체에 대해 객체가 더 이 상 사용되지 않는지 여부를 알아봅니다. 더 이상 사용되지 않는 경우 마이그레이션할 필요가 없으므로 원 본 Oracle 데이터베이스에서 이러한 객체를 사용 중지합니다. 로드 용량이 허용되면 원본 데이터베이스에서 각 LOB 유형마다 최대 크기(kb)를 가져오고 나중을 위해 이 정보를 보관합니다. 가능하면 BLOB, CLOB, NCLOB, LONG, LONG RAW 및 XMLTYPE이 있는 열을 S3, Dynamo DB 또는 다 른 데이터 스토어로 이동합니다. 이렇게 하면 원본 Oracle 데이터베이스가 간소화되어 보다 쉽게 마이그레 이션할 수 있습니다. 또한 대상 PostgreSQL 데이터베이스에 대한 용량 요구 사항도 축소됩니다. AWS DMS에 대한 자세한 내용은 AWS DMS 설명서를 참조하십시오. 단계별 마이그레이션 다음 단계에서는 Oracle 데이터베이스를 PostgreSQL 데이터베이스로 마이그레이션하기 위한 지침을 제공 합니다. 이러한 단계에서는 사전 조건 (p. 87)에 설명된 대로 원본 데이터베이스를 이미 준비했다고 가정 합니다. 항목 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치 (p. 88) 2단계: Oracle 원본 데이터베이스 구성 (p. 89) 3단계: PostgreSQL 대상 데이터베이스 구성 (p. 92) 4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합 니다. (p. 92) 5단계: AWS DMS 복제 인스턴스 생성 (p. 100) 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. (p. 101) 7단계: AWS DMS 마이그레이션 작업 생성 및 실행 (p. 105) 8단계: PostgreSQL로 전환 (p. 108) 1단계: 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool 설치 로컬 컴퓨터에 SQL 드라이버와 AWS Schema Conversion Tool(AWS SCT)을 설치합니다. SQL 클라이언트 소프트웨어를 설치하려면 1. Oracle 데이터베이스의 JDBC 드라이버를 다운로드합니다. 예를 들면 Oracle Database 12.1.0.2 JDBC 드라이버(ojdbc7.jar)를 다운로드합니다. 2. PostgreSQL 드라이버(postgresql-42.1.4.jar)를 다운로드합니다. 3. AWS SCT 및 필수 JDBC 드라이버를 설치합니다. a. AWS Schema Conversion Tool 사용 설명서의 AWS Schema Conversion Tool 설치 및 업데이트에 서 AWS SCT를 다운로드합니다. b. AWS SCT를 시작합니다. c. AWS SCT의 [Settings]에서 [Global Settings]를 선택합니다. d. [Global Settings]에서 [Driver]를 선택한 후 [Browse]를 선택하여 [Oracle Driver Path]를 찾습니다. JDBC Oracle 드라이버를 찾고 [OK]를 선택합니다. e. [PostgreSQL Driver Path]에서 [Browse]를 선택합니다. Oracle JDBC PostgreSQL 드라이버를 찾고 [OK]를 선택합니다. 88

2단계: Oracle 원본 데이터베이스 구성 f. [OK]를 선택하여 대화 상자를 닫습니다. 2단계: Oracle 원본 데이터베이스 구성 (AWS DMS)에서 Oracle을 원본으로 사용하려면, 먼저 LogMiner에 정보를 제공할 수 있도록 ARCHIVELOG MODE가 켜져 있는지 확인해야 합니다. AWS DMS에서는 보관 로그의 정 보를 읽을 수 있도록 LogMiner를 사용하므로 AWS DMS에서 변경 사항을 캡처할 수 있습니다. AWS DMS가 이 정보를 읽을 수 있도록 AWS DMS에서 보관 로그를 필요로 하는 한 이 보관 로그가 데이터 베이스 서버에 보존되어 있는지 확인해야 합니다. 즉시 변경 사항 캡처를 시작하도록 작업을 구성하는 경우, 가장 긴 실행 트랜잭션의 기간보다 약간 더 오랫동안 보관 로그만을 보존해야 합니다. 대개 24시간 동안 보관 로그를 보존하면 충분합니다. 과거의 특정 시점에 시작하도록 작업을 구성하는 경우, 앞으로는 보관 로그를 사용할 수 있어야 합니다. ARCHIVELOG MODE를 활성화하고 사용자의 Oracle 데이터베이스에서 로그 보 존을 보장하는 방법에 대한 자세한 지침은 Oracle 설명서를 참조하십시오. 변경 사항을 캡처할 수 있도록 AWS DMS에서는 보충 로깅을 원본 데이터베이스에서 활성화해야 합니다. 최 소 보충 로깅은 데이터베이스 수준에서 활성화되어야 합니다. 또한 AWS DMS에서는 식별 키 로깅을 활성화 해야 합니다. 이 옵션을 선택하면 기본 키를 포함하는 행이 업데이트될 때마다 행 기본 키의 모든 열이 재실 행 로그 파일에 추가됩니다. 기본 키에 변경된 값이 없더라도 이 결과가 발생합니다. 데이터베이스 또는 테이 블 수준에서 이 옵션을 설정할 수 있습니다. Oracle 원본 데이터베이스를 구성하려면 1. AWS DMS에서 사용하는 데이터베이스 계정을 생성하거나 구성합니다. AWS DMS 연결을 위해 AWS DMS에서 필요한 최소 권한을 가진 별도의 계정을 사용하는 것이 좋습니다. AWS DMS에서는 다음 권한 이 필요합니다. CREATE SESSION SELECT ANY TRANSACTION 89

2단계: Oracle 원본 데이터베이스 구성 SELECT on V_$ARCHIVED_LOG SELECT on V_$LOG SELECT on V_$LOGFILE SELECT on V_$DATABASE SELECT on V_$THREAD SELECT on V_$PARAMETER SELECT on V_$NLS_PARAMETERS SELECT on V_$TIMEZONE_NAMES SELECT on V_$TRANSACTION SELECT on ALL_INDEXES SELECT on ALL_OBJECTS SELECT on ALL_TABLES SELECT on ALL_USERS SELECT on ALL_CATALOG SELECT on ALL_CONSTRAINTS SELECT on ALL_CONS_COLUMNS SELECT on ALL_TAB_COLS SELECT on ALL_IND_COLUMNS SELECT on ALL_LOG_GROUPS SELECT on SYS.DBA_REGISTRY SELECT on SYS.OBJ$ SELECT on DBA_TABLESPACES SELECT on ALL_TAB_PARTITIONS SELECT on ALL_ENCRYPTED_COLUMNS * SELECT on all tables migrated 변경 사항(CDC)을 캡처하고 적용하려면 다음 권한도 필요합니다. EXECUTE on DBMS_LOGMNR SELECT on V_$LOGMNR_LOGS SELECT on V_$LOGMNR_CONTENTS LOGMINING /* For Oracle 12c and higher. */ * ALTER for any table being replicated (if you want AWS DMS to add supplemental logging) Oracle 버전 11.2.0.3 이전에서는 다음 권한이 필요합니다. SELECT on DBA_OBJECTS /* versions before 11.2.0.3 */ SELECT on ALL_VIEWS (required if views are exposed) 2. Oracle 데이터베이스가 AWS RDS 데이터베이스인 경우 관리 사용자로 연결하고 다음 명령을 실행하여 24시간 동안 RDS 원본에 대해 보관 로드가 유지되도록 합니다. exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24); Oracle 원본이 AWS RDS 데이터베이스에 있는 경우, 백업을 활성화한 경우에 한해 데이터베이스가 ARCHIVELOG MODE에 배치됩니다. 3. 다음 명령을 실행하여 데이터베이스 수준에서 보충 로깅을 활성화합니다. 이때 AWS DMS에서는 다음 작업이 필요합니다. Oracle SQL에서: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; RDS에서: 90

2단계: Oracle 원본 데이터베이스 구성 exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add'); 4. 다음 명령을 사용하여 데이터베이스 수준에서 식별 키 보충 로깅을 활성화합니다. AWS DMS에서는 데 이터베이스 수준의 보충 키 로깅이 필요합니다. 단, AWS DMS에서 필요에 따라 보충 로깅을 자동으로 추가하거나 테이블 수준에서 키 수준 보충 로깅을 활성화하도록 허용하는 경우는 제외합니다. Oracle SQL에서: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; RDS에서: exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add','primary KEY'); 키 수준 보충 로깅을 활성화하면 원본 데이터베이스는 약간의 오버헤드를 발생시킵니다. 따라서 테 이블 하위 집합만을 마이그레이션할 경우, 테이블 수준에서 키 수준의 보충 로깅을 활성화해야 할 수도 있습니다. 5. 테이블 수준에서 키 수준의 보충 로깅을 활성화하려면 다음 명령을 사용합니다. ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; 테이블에 기본 키가 없는 경우 옵션 2개가 있습니다. 테이블에서 첫 번째 고유 인덱스에 포함된 모든 열에 보충 로깅을 추가할 수 있습니다(인덱스 이름별 로 정렬). 테이블의 모든 열에서 보충 로깅을 추가할 수 있습니다. 테이블에서 열의 하위 집합(예: 고유 인덱스에 포함된 열)에 보충 로깅을 추가하려면, 다음 명령을 실행 합니다. ALTER TABLE table_name ADD SUPPLEMENTAL LOG GROUP example_log_group (column_list) ALWAYS; 모든 테이블 열에서 보충 로깅을 추가하려면, 다음 명령을 실행합니다. ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; 6. AWS SCT용 사용자를 생성합니다. CREATE USER oracle_sct_user IDENTIFIED BY password; GRANT CONNECT TO oracle_sct_user; GRANT SELECT_CATALOG_ROLE TO oracle_sct_user; GRANT SELECT ANY DICTIONARY TO oracle_sct_user; 91

3단계: PostgreSQL 대상 데이터베이스 구성 3단계: PostgreSQL 대상 데이터베이스 구성 1. 마이그레이션하려는 스키마가 PostgreSQL 데이터베이스에 없으면 해당 스키마를 생성합니다. 2. 대상 데이터베이스에 연결할 AWS DMS 사용자를 생성하고, 수퍼유저 또는 필요한 개인 권한을 부여하 거나 RDS의 마스터 사용자 이름을 사용합니다. CREATE USER postgresql_dms_user WITH PASSWORD 'password'; ALTER USER postgresql_dms_user WITH SUPERUSER; 3. AWS SCT용 사용자를 생성합니다. CREATE USER postgresql_sct_user WITH PASSWORD 'password'; GRANT GRANT GRANT GRANT CONNECT ON DATABASE database_name TO postgresql_sct_user; USAGE ON SCHEMA schema_name TO postgresql_sct_user; SELECT ON ALL TABLES IN SCHEMA schema_name TO postgresql_sct_user; ALL ON SEQUENCES IN SCHEMA schema_name TO postgresql_sct_user; 4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 데이터를 PostgreSQL로 마이그레이션하기 전에 먼저 Oracle 스키마를 PostgreSQL 스키마로 변환합니다. AWS SCT를 사용하여 Oracle 스키마를 PostgreSQL 스키마로 변환하려면 1. AWS SCT를 시작합니다. AWS SCT에서 [File]을 선택하고 나서 [New Project]를 선택합니다. AWS Schema Conversion Tool Oracle to PostgreSQL라는 프로젝트를 생성합니다. [New Project] 창에 다음 정보를 입력하고 [OK]를 선택합니다. 파라미터 설명 [프로젝트 이름] AWS Schema Conversion Tool Oracle to PostgreSQL을 입력합니다. [Location] 기본 [Projects] 폴더와 기본 [Transactional Database (OLTP)] 옵션을 사용합니다. [Source Database Engine] Oracle을 선택합니다. [Target Database Engine] [Amazon RDS for PostgreSQL]을 선택합니다. 92

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 2. [Connect to Oracle]을 선택합니다. [Connect to Oracle] 대화 상자에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 파라미터 설명 Type [SID]를 선택합니다. [Server name] 서버 이름을 입력합니다. [Server port] Oracle 포트 번호를 입력합니다. 기본값은 1521입니다. [Oracle SID] 데이터베이스 SID를 입력합니다. 사용자 이름 Oracle 관리자 사용자 이름을 입력합니다. [Password] 관리 사용자 암호를 입력합니다. 93

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 3. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 Oracle DB 인스턴스와의 연 결을 시작합니다. Oracle DB 인스턴스의 데이터베이스 구조가 표시됩니다. 4. [Connect to Amazon RDS for PostgreSQL]을 선택합니다. [Connect to Amazon PostgreSQL] 대화 상자 에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 파라미터 설명 [Server name] 서버 이름을 입력합니다. [Server port] PostgreSQL 포트 번호를 입력합니다. 기본값은 5432입니 다. 데이터베이스 데이터베이스 이름을 입력합니다. 사용자 이름 PostgreSQL 관리자 사용자 이름을 입력합니다. [Password] 관리 사용자 암호를 입력합니다. 94

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 5. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 PostgreSQL DB 인스턴스 와의 연결을 시작합니다. 6. 마이그레이션할 스키마에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 나서 [Convert schema] 를 선택합니다. 95

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 7. 확인 메시지에서 [Yes]를 선택합니다. 그런 다음 AWS SCT는 스키마를 대상 데이터베이스 형식으로 변 환합니다. 96

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. AWS SCT는 스키마를 분석하고 PostgreSQL로 변환하기 위한 데이터베이스 마이그레이션 평가 보고서 를 생성합니다. 8. [View]에서 [Assessment Report View]를 선택하여 보고서를 확인합니다. 보고서는 변환이 성공적으로 수행되는 데 필요한 수동 변경의 양과 각 객체 유형별로 구분됩니다. 일반적으로 패키지, 절차 및 기능은 매우 세부적으로 사용자 지정된 PL/SQL 코드를 포함하므로 해결할 문제가 있을 가능성이 높습니다. 또한 AWS SCT는 이러한 객체를 수정하는 방법에 대한 힌트를 제공합 니다. 97

4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 9. [Action Items] 탭을 선택합니다. [Action Items] 탭에는 주의를 요하는 각 객체에 대한 각 문제가 표시됩니다. 각 변환 문제마다 다음 작업 중 하나를 완료할 수 있습니다. AWS SCT는 객체를 대상 PostgreSQL 데이터베이스로 변환할 수 있도록 원본 Oracle 데이터베이 스에서 객체를 수정합니다. 1. 원본 Oracle 데이터베이스에서 객체를 수정합니다. 2. 이전 단계를 반복하여 스키마를 변환하고 평가 보고서를 확인합니다. 98

3. 4. 4단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니다. 필요할 경우 변환 문제가 없을 때까지 이 프로세스를 반복합니다. [View]에서 [Main View]를 선택하고 대상 PostgreSQL 스키마에 대해 컨텍스트(마우스 오른쪽 버튼 클릭)를 연 다음, [Apply to database]를 선택하여 스키마 변경 내용을 PostgreSQL 데이터 베이스에 적용합니다. 대상 PostgreSQL 데이터베이스에서 스크립트를 적용하기 전에 원본 스키마를 수정하는 대신에 AWS SCT에 의해 생성된 스크립트를 수정합니다. 1. 대상 PostgreSQL 스키마 이름에 대한 컨텍스트(마우스 오른쪽 버튼 클릭)를 열고 [Save as SQL]을 선택합니다. 다음에는 스크립트의 이름과 대상을 선택합니다. 2. 스크립트에서 객체를 수정하여 변환 문제를 해결합니다. 3. 대상 PostgreSQL 데이터베이스에서 이 스크립트를 실행합니다. 자세한 내용은 AWS Schema Conversion Tool 사용 설명서의 Converting Database Schema to Amazon RDS by Using the AWS Schema Conversion Tool 단원을 참조하십시오. 10. AWS SCT를 사용하여 매핑 규칙을 생성합니다. a. [Settings]에서 [Mapping Rules]를 선택합니다. b. 스키마 이름 및 테이블 이름을 소문자로 변환하는 두 가지 기본 매핑 규칙 외에도, 작업 항목에 따라 요구되는 추가 매핑 규칙을 생성합니다. c. 매핑 규칙을 저장합니다. 99

5단계: AWS DMS 복제 인스턴스 생성 d. [Export script for DMS]를 클릭하여 AWS DMS 작업에서 원본의 어느 객체가 대상의 어느 객체에 해 당하는지를 결정하는 데 사용할 모든 변환의 JSON 형식을 내보냅니다. Save를 클릭합니다. 5단계: AWS DMS 복제 인스턴스 생성 원본과 대상 데이터베이스 간의 스키마 구조를 검증한 후 이 연습의 핵심 부분인 데이터 마이그레이션을 계 속 진행합니다. 다음 그림은 마이그레이션 프로세스의 상위 수준 보기를 보여줍니다. AWS DMS 복제 인스턴스는 원본과 대상 간에 실제 데이터 마이그레이션을 수행합니다. 복제 인스턴스도 마 이그레이션 중에 트랜잭션 로그를 캐시합니다. 복제 인스턴스가 갖는 CPU와 메모리 용량은 마이그레이션에 필요한 전체 시간에 영향을 줍니다. AWS DMS 복제 인스턴스를 생성하려면 1. AWS Management Console에 로그인하고 https://console.aws.amazon.com/dms/에서 AWS DMS를 선 택합니다. 다음에는 [Create Migration]을 선택합니다. AWS Identity and Access Management(IAM) 사 용자로서 로그인한 경우에는 AWS DMS 액세스를 위한 적절한 권한이 있어야 합니다. 필요한 권한에 대 한 자세한 내용은 AWS DMS 사용에 필요한 IAM 권한을 참조하십시오. 2. [Next]를 선택하여 콘솔의 [Welcome] 페이지에서 데이터베이스 마이그레이션을 시작합니다. 3. [Create replication instance] 페이지에서 복제 인스턴스 정보를 지정합니다. 파라미터 설명 이름 복제 인스턴스의 이름을 선택합니다. 여러 복제 서버를 사용 하거나 계정을 공유하려는 경우 서로 다른 서버 간에 쉽게 구별할 수 있는 이름을 선택합니다. 설명 간단한 설명을 입력합니다. 100

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 4. 파라미터 설명 인스턴스 클래스 생성할 복제 서버의 유형을 선택합니다. 각각의 인스턴스 클 래스의 크기 및 유형은 CPU, 메모리 및 I/O 용량을 늘립니 다. 일반적으로 t2 인스턴스는 저로드 작업용이며, c4 인스 턴스는 고로드 및 기타 작업용입니다. [VPC] 복제 인스턴스가 시작될 VPC를 선택합니다. 가능한 경우 원 본이나 대상 데이터베이스(또는 이 모두)가 상주하는 동일 한 VPC를 선택합니다. 다중 AZ [Yes]를 선택하면 AWS DMS는 기본 복제 서버 관련 문제가 있는 경우 다른 가용 영역에 장애 조치용으로 두 번째 복제 서버를 생성합니다. [Publicly accessible] 복제 서버가 상주하는 VPC 외부에 원본 또는 대상 데이터베 이스가 상주하는 경우 복제 서버 정책을 공개적으로 액세스 할 수 있게 설정해야 합니다. [Advanced] 섹션에서는 다음 정보를 지정합니다. 파라미터 설명 [Allocated storage (GB)] 과거 작업 로그를 포함하여 AWS DMS 작업 로그에 대한 복 제 서버의 스토리지 양. 또한 AWS DMS에서는 원본에서 대 상으로 복제하는 동안 디스크 스토리지를 사용하여 특정 데 이터를 캐싱합니다. 또한, 스토리지가 많을수록 일반적으로 서버에서 IOPS가 향상됩니다. [Replication Subnet Group] 다중 AZ 구성으로 실행하는 경우 최소 두 개의 서브넷 그룹 이 필요합니다. [Availability zone] 일반적으로 대상 데이터베이스와 동일한 가용 영역에 기본 할당 서버가 있으면 성능이 향상됩니다. VPC Security Group(s) 보안 그룹을 사용하면 VPC에 대한 수신 및 송신을 제어할 수 있습니다. AWS DMS에서는 복제 서버가 시작되는 VPC 에 하나 이상의 보안 그룹을 연결할 수 있습니다. [KMS master key] AWS DMS를 통해 모든 데이터는 KMS 암호화 키를 사용하 여 유휴 상태로 암호화됩니다. 기본적으로 AWS DMS는 복 제 서버에 대한 새 암호 키를 생성합니다. 하지만 기본 키를 사용하도록 선택할 수 있습니다. KMS 마스터 키에 대한 자세한 내용은 암호화 키 설정 및 KMS 권한 지정을 참조하십시오. 5. [Next]를 클릭합니다. 6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니 다. 복제 인스턴스가 생성되는 동안 AWS Management Console을 사용하여 원본과 대상 데이터베이스 엔드포 인트를 지정할 수 있습니다. 그렇지만, 복제 인스턴스는 연결에 사용되기 때문에 복제 인스턴스가 생성된 후 에는 연결을 테스트만할 수 있습니다. 101

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 콘솔을 사용하여 원본 및 대상 데이터베이스 엔드포인트를 지정하려면 1. 원본 Oracle 데이터베이스와 대상 PostgreSQL 데이터베이스에 대한 연결 정보를 지정합니다. 다음 표 는 원본 설정에 대한 설명입니다. 파라미터 설명 [Endpoint Identifier] Orasource 같은 이름을 입력합니다. 소스 엔진 [oracle]을 선택합니다. [Server name] Oracle DB 인스턴스 서버 이름을 입력합니다. Port 데이터베이스 포트. Oracle의 기본값은 1521입니다. [SSL mode] 연결 트래픽에 대해 암호화를 활성화해야 하는 경우 SSL 모 드를 선택합니다. 사용자명 원본 데이터베이스에 연결하는 데 사용할 사용자. [Password] 사용자 암호를 입력합니다. [SID] Oracle 데이터베이스 이름을 입력합니다. 다음 표에서는 고급 원본 설정을 설명합니다. 102

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 파라미터 설명 [Extra connection attributes] AWS DMS의 동작을 변경하거나 기능을 추가하기 위해 엔 드포인트에서 설정할 수 있는 추가 파라미터. Oracle 원본 데이터베이스에 대해 설정할 가장 일반적이고 편리한 파라 미터 중 일부는 다음과 같습니다. 세미콜론(;)을 사용하여 여 러 항목을 서로 구분합니다. addsupplementallogging - 이 파라미터는Y로 설정될 경우 보충 로깅을 자동으로 구성합니다. uselogminerreader - 기본적으로 AWS DMS는 Oracle 데이터베이스에 Logminer를 사용하여 원본 데이 터베이스에서 모든 변경 내용을 캡처합니다. 또 다른 모 드로 Binary Reader가 있습니다. Logminer 대신에 Binary Reader를 사용하는 경우 AWS DMS는 원본 Oracle 데이 터베이스의 보관된 재실행 로그를 복제 서버로 복사하고 전체 로그를 읽어와서 변경 내용을 캡처합니다. Binary Reader 옵션은 AMS에서 Logminer보다 성능 상의 이점을 제공하므로 ASM을 사용하는 경우에는 이 옵션을 권장합 니다. 원본 데이터베이스가 12c이면 Binary Reader 옵션 은 현재 LOB 객체에 대해 Oracle에서 CDC 변경 내용을 캡처하는 유일한 방법입니다. Logminer를 사용하려면 다음을 입력합니다. uselogminerreader=y Binary Reader를 사용하려면 다음을 입력합니다. uselogminerreader=n; usebfile=y [KMS master key] 복제 인스턴스의 스토리지를 암호화하기로 한 경우 KMS 마 스터 키를 입력합니다. 추가 연결 속성에 대한 자세한 내용은 Using Extra Connection Attributes with AWS Database Migration Service를 참조하십시오. 다음 표는 대상 설정에 대한 설명입니다. 파라미터 설명 [Endpoint Identifier] Postgrestarget 같은 이름을 입력합니다. [Target Engine] postgres를 선택합니다. [Servername ] PostgreSQL DB 인스턴스 서버 이름을 입력합니다. Port 데이터베이스 포트. PostgreSQL의 기본값은 5432입니다. [SSL mode] [None]을 선택합니다. 사용자명 대상 데이터베이스에 연결하는 데 사용할 사용자. [Password] PostgreSQL DB 인스턴스의 암호를 입력합니다. 103

6단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 다음은 완료한 페이지의 예입니다. 2. 엔드포인트와 복제 인스턴스가 생성된 후 원본 및 대상 엔드포인트에 대해 [Run test]를 선택하여 각 엔 드포인트 연결을 테스트합니다. 3. 대상 데이터베이스에서 외래 키 제약 조건 및 트리거를 삭제합니다. 전체 로드 프로세스 동안 AWS DMS는 특정 순서대로 테이블을 로드하지 않으므로 상위 테이블 데이터 전에 하위 테이블 데이터가 로드될 수도 있습니다. 따라서 외래 키 제약 조건이 활성화되는 경우 이러한 제약 조건을 위반하게 될 수도 있습니다. 또한 트리거가 대상 데이터베이스에 있는 경우 예기치 않은 방 식으로 AWS DMS에 의해 로드되는 데이터가 변경될 수도 있습니다. 4. 없으면 외래 키 제약 조건과 트리거를 활성화하는 스크립트를 생성합니다. 나중에 마이그레이션된 데이터베이스에 추가하려는 경우에는 이 스크립트만 실행하면 됩니다. 5. (선택 사항) 대상 데이터베이스에 보조 인덱스를 삭제합니다. 104

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 보조 인덱스(모든 인덱스와 마찬가지로)는 로딩 프로세스 중에 유지 관리 및 업데이트되어야 하므로 데 이터를 테이블에 전체 로드하는 속도가 느려질 수 있습니다. 이러한 인덱스를 삭제하면 전체 로드 프로 세스의 성능이 향상될 수 있습니다. 인덱스를 삭제하는 경우 전체 로드를 완료하고 나서 나중에 다시 추 가해야 합니다. 6. [Next]를 선택합니다. 7단계: AWS DMS 마이그레이션 작업 생성 및 실행 AWS DMS 작업을 사용하여 마이그레이션할 스키마와 마이그레이션 유형을 지정할 수 있습니다. 기존 데이 터를 마이그레이션하거나, 지속적 변경 사항을 복제하거나, 또는 데이터 변경 사항만 복제할 수 있습니다. 이 연습에서는 기존 데이터를 마이그레이션하고 지속적인 변경 내용을 복제합니다. 마이그레이션 작업을 생성하려면 1. [Create Task] 페이지에서 작업 옵션을 지정합니다. 다음 표는 설정에 대한 설명입니다. 파라미터 설명 [Task name] 마이그레이션 작업의 이름을 입력합니다. [Task description] 작업 설명을 입력합니다. [Source endpoint] Oracle 소스 엔드포인트를 표시합니다. 계정에 엔드포인트가 두 개 이상이면 목록에서 올바른 엔드 포인트를 선택합니다. [Target endpoint] PostgreSQL 대상 엔드포인트를 표시합니다. 복제 인스턴스 AWS DMS 복제 인스턴스를 표시합니다. [Migration type] [Migrate existing data and replicate ongoing changes] 옵션 을 선택합니다. [Start task on create] 이 옵션을 선택합니다. 이 페이지는 다음과 같이 보여야 합니다. 105

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 2. AWS Schema Conversion Tool을 사용하여 테이블을 이미 생성했으므로 [Task Settings]에서 [Target table preparation mode]에 대해 Do nothing] 또는 [Truncate]를 선택합니다. Oracle 데이터베이스에 LOB가 있는 경우, 모든 테이블에 대한 전체 LOB를 복제하려면 [Include LOB columns in replication]에 대해 [Full LOB mode]를 선택합니다. LOB를 특정 크기까지만 복제하려면 [Limited LOB mode]를 선택합니다. [Max LOB size (kb)]에서 마이그레이션할 LOB의 크기를 지정합니 다. [Enable logging]을 선택하는 것이 좋습니다. 로깅을 활성화할 경우 작업에서 발생하는 오류나 경고를 확 인하고 이러한 문제를 해결할 수 있습니다. 3. [Advanced] 설정을 기본값으로 둡니다. 106

7단계: AWS DMS 마이그레이션 작업 생성 및 실행 4. [Table mappings]를 선택하고 [JSON] 탭을 선택합니다. 다음에는 [Enable JSON editing]을 선택하고 4 단계: AWS Schema Conversion Tool(AWS SCT)을 사용하여 Oracle 스키마를 PostgreSQL로 변환합니 다. (p. 92)의 마지막 단계에서 저장한 테이블 매핑을 입력합니다. 다음은 스키마 이름 및 테이블 이름을 소문자로 변환하는 매핑의 예입니다. { } 5. "rules": [ { "rule-type": "transformation", "rule-id": "100000", "rule-name": "Default Lowercase Table Rule", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" } }, { "rule-type": "transformation", "rule-id": "100001", "rule-name": "Default Lowercase Schema Rule", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } } ] [Create task]를 선택합니다. 작업이 즉시 시작됩니다. [Tasks] 섹션에는 마이그레이션 작업 상태가 나타납니다. 작업을 설정할 때 [Enable logging]을 선택했으면 작업을 모니터링할 수 있습니다. 그리고 나서 다음 작업을 수행하여 CloudWatch 측정치를 확인할 수 있습니다. 진행 중인 데이터 마이그레이션 작업을 모니터링하려면 1. 탐색 창에서 [Tasks]를 선택합니다. 2. 마이그레이션 작업을 선택합니다. 3. [Task monitoring] 탭을 선택하고 이 탭에서 진행 중인 작업을 모니터링합니다. 전체 로드가 완료되고 캐시된 변경 사항이 적용되면 작업이 자체적으로 중지됩니다. 107

8단계: PostgreSQL로 전환 4. 대상 PostgreSQL 데이터베이스에서 이전에 저장한 스크립트를 사용하여 외래 키 제약 조건과 트리거를 활성화합니다. 5. 대상 PostgreSQL 데이터베이스에서 이전에 제거한 경우 보조 인덱스를 다시 생성합니다. 6. AWS DMS 콘솔에서 작업에 대해 [Start/Resume]을 클릭하여 AWS DMS를 시작합니다. AWS DMS 작업은 원본 데이터베이스 변경 내용을 적용하여 대상 PostgreSQL 데이터베이스를 최신 상 태로 유지합니다. AWS DMS는 애플리케이션 마이그레이션을 구현해야 할 시점이 될 때까지 작업의 모 든 테이블을 최신 상태로 유지합니다. 대상이 원본과 거의 비슷해지면 지연 시간이 0이거나 0에 가깝습 니다. 8단계: PostgreSQL로 전환 다음 단계를 수행하여 Oracle 데이터베이스에서 PostgreSQL 데이터베이스로 연결을 전환합니다. PostgreSQL로 전환하려면 1. 스크립트 실행이나 클라이언트 연결 같은 모든 Oracle 데이터베이스 종속성 및 작업을 종료합니다. 다음 쿼리는 결과를 반환하지 않습니다. SELECT MACHINE, COUNT FROM V$SESSION GROUP BY MACHINE; 2. 남은 세션을 나열하여 종료합니다. SELECT SID, SERIAL#, STATUS FROM V$SESSION; ALTER SYSTEM KILL 'sid, serial_number' IMMEDIATE; 3. Oracle 데이터베이스에서 모든 리스너를 종료합니다. 4. AWS DMS 작업을 통해 PostgreSQL 데이터베이스에서 Oracle 데이터베이스의 최종 변경 내용을 적용 합니다. ALTER SYSTEM CHECKPOINT; 5. AWS DMS 콘솔에서 작업에 대해 [Stop]을 클릭하여 AWS DMS 작업을 중지하고 작업을 중지하려 함을 확인합니다. 6. (선택 사항) 롤백을 설정합니다. 표시 중지 문제가 발생하는 경우 반대 방향으로 진행하는 작업을 생성하여 선택적으로 롤백 작업을 설정 할 수 있습니다. 모든 테이블이 두 데이터베이스 사이에서 동기화되어야 하므로 CDC 작업만 설정하면 됩니다. 따라서 외래 키 제약 조건을 비활성화할 필요가 없습니다. 원본 및 대상 데이터베이스가 뒤바뀌 었으므로, 다음 섹션의 지침을 따라야 합니다. 에서 PostgreSQL 데이터베이스를 원본으로 사용 에서 Oracle 데이터베이스를 대상으로 사용 a. 원본 Oracle 데이터베이스에서 트리거를 비활성화합니다. 108

마이그레이션 롤백 SELECT 'ALTER TRIGGER' owner '.' trigger_name 'DISABLE;' FROM DBA_TRIGGERS WHERE OWNER = 'schema_name'; 따라서 외래 키 제약 조건을 비활성화할 필요가 없습니다. CDC 프로세스가 수행되는 동안은 애플 리케이션 사용자가 업데이트할 때와 똑같은 순서대로 외래 키 제약 조건이 업데이트됩니다. b. 엔드포인트가 뒤 바뀐 상태(원본 PostgreSQL 엔드포인트와 대상 Oracle 엔드포인트 데이터베이스) 에서 새 CDC 전용 AWS DMS 작업을 생성합니다. 7단계: AWS DMS 마이그레이션 작업 생성 및 실 행 (p. 105) 단원을 참조하십시오. 롤백 작업의 경우 [Migration type]을 [Replicate data changes only]로, [Target table preparation mode]를 [Do nothing]으로 설정합니다. c. 7. 롤백이 필요할 경우 새 PostgreSQL 데이터베이스에서 원래의 원본 Oracle 데이터베이스로 변경 내 용을 되돌릴 수 있도록 AWS DMS 작업을 시작합니다. PostgreSQL 데이터베이스에 연결하고 트리거를 활성화합니다. ALTER TABLE table_name ENABLE TRIGGER ALL; 8. 롤백을 설정하는 경우 롤백 설정을 완료합니다. a. 새 대상 PostgreSQL 데이터베이스에서 애플리케이션 서비스(스크립트, 클라이언트 소프트웨어 등 포함)를 시작합니다. b. 새 PostgreSQL 데이터베이스에서 Cloudwatch 모니터링을 추가합니다. Monitoring Amazon RDS 섹션을 참조하십시오. 마이그레이션 롤백 적시에 확인할 수 없는 마이그레이션 관련 주요 문제가 있는 경우 마이그레이션을 롤백할 수 있습니다. 이러 한 단계에서는 8단계: PostgreSQL로 전환 (p. 108)에 설명된 대로 롤백 준비가 이미 완료되었다고 가정합 니다. 마이그레이션을 롤백하려면 1. 대상 PostgreSQL 데이터베이스에서 모든 애플리케이션 서비스를 중지합니다. 2. AWS DMS 작업을 통해 남은 변경 내용이 원본 Oracle 데이터베이스로 복제되도록 합니다. 3. PostgreSQL을 Oracle AWS DMS 작업을 중지합니다. 4. 원본 Oracle 데이터베이스에서 모든 애플리케이션을 다시 시작합니다. 문제 해결 원본으로서 Oracle을 사용하고 대상으로서 PostgreSQL을 사용할 때 문제가 나타나는 가장 일반적이 두 영 역은 보충 로깅과 대소문자 구분입니다. 보충 로깅 Oracle을 통해 변경 데이터를 복제하려면 보충 로깅을 활성화해야 합니다. 그렇지만, 데이터베 이스 수준에서 보충 로깅을 활성화할 경우, 때로는 새 테이블을 생성할 때 보충 로깅을 계속 활성화해야 합 니다. 이 문제에 대한 최적의 해결책은 추가 연결 속성을 사용하여 AWS DMS가 보충 로깅을 자동으로 활 성화하도록 허용하는 것입니다. addsupplementallogging=y 109

문제 해결 대소문자 구분: Oracle은 대소문자를 구분하지 않습니다(객체 이름을 따옴표로 묶지 않은 경우). 그렇지만, 텍스트는 대문자로 표시됩니다. 또한, AWS DMS는 기본적으로 대문자로 대상 객체를 명명합니다. 대다수 의 경우에 변환을 사용하여 스키마, 테이블 또는 열 이름을 소문자로 변경해야 합니다. 추가 팁을 보려면 AWS DMS 사용 설명서의 AWS DMS 문제 해결 섹션을 참조하십시오. Oracle별로 문제를 해결하려면, Oracle 문제 해결 섹션을 참조하십시오. Oracle별 문제 해결 PostgreSQL 문제를 해결하려면, PostgreSQL 문제 해결 섹션을 참조하십시오. PostgreSQL별 문제 해결 110

사전 조건 Amazon RDS for Oracle Database를 Amazon Redshift로 마이그레이션 본 연습에서는 (AWS DMS)와 AWS Schema Conversion Tool(AWS SCT) 을 사용하여 다른 유형의 데이터베이스를 Oracle용 Amazon RDS에서 Amazon Aurora로 마이그레이션하는 과정을 안내합니다. 다음은 입문용 실습이므로 모든 시나리오를 다루지 않지만 그러한 마이그레이션에서 따 라야 하는 단계를 이해하는 데 도움이 됩니다. AWS DMS와 AWS SCT가 다른 별개의 도구이며 각기 다른 요구 사항에 부합한다는 점도 잘 알고 있어야 합 니다. 이들 도구는 마이그레이션 프로세스에서 서로 상호작용하지 않습니다. 고급 수준에서 이 마이그레이션 에 수반되는 단계는 다음과 같습니다. 1. AWS SCT를 사용하여 다음을 수행합니다. Oracle에서 Amazon Redshift로의 변환 보고서를 실행하여 스키마 변환에 필요한 문제, 제한 사항 및 작 업을 확인합니다. 스키마 스크립트를 생성하고 대상에서 이것을 적용한 후 AWS DMS를 사용하여 데이터 로드를 실행합 니다. AWS SCT는 절차 및 보기와 같은 객체에 대한 필수 코드 변환을 수행합니다. 2. AWS SCT에서 보고한 문제에 대한 해결책을 확인하고 구현합니다. 3. AWS DMS 데이터 로드에 영향을 줄 수 있는 외래 키 또는 다른 모든 제약을 비활성화합니다. 4. AWS DMS는 전체 로드 접근 방식을 사용하여 원본에서 대상으로 데이터를 로드합니다. AWS DMS가 로 드의 일부로서 대상에서 객체를 생성할 수 있더라도 최소한의 접근 방식에 따라 데이터를 효율적으로 마 이그레이션하므로 전체 스키마 구조가 원본에서 대상으로 복제되지 않습니다. 5. 추가 인덱스 생성과 같은 마이그레이션 후 활동을 수행하여 외래 키를 활성화하고 애플리케이션에서 필요 한 변경 사항을 적용하여 새 데이터베이스를 가리킵니다. 다음 연습에서는 사용자 지정 AWS CloudFormation 템플릿을 사용하여 Oracle 및 Amazon Redshift용 Amazon RDS DB 인스턴스를 생성합니다. 그런 다음 SQL 명령 스크립트를 사용하여 샘플 스키마와 데이터 를 RDS Oracle DB 인스턴스에 설치한 후 Amazon Redshift에 마이그레이션합니다. 이 연습을 완료하기까지 약 2시간이 소요됩니다. 지침에 따라 이 연습이 끝나면 추가 요금이 발생하지 않도 록 리소스를 삭제해야 합니다. 항목 사전 조건 (p. 111) 마이그레이션 아키텍처 (p. 112) 단계별 마이그레이션 (p. 113) 다음 단계 (p. 147) 참조 (p. 147) 사전 조건 이 연습을 완료하려면 다음 사전 요구 사항도 필요합니다. 111

마이그레이션 아키텍처 Amazon RDS, Amazon Redshift, 해당 데이터베이스 기술 및 SQL에 대한 지식. 마이그레이션할 테이블 생성과 마이그레이션 확인을 위한 SQL 쿼리를 포함하는 사용자 지정 스크립트는 다음과 같습니다. SH 스키마를 빌드하는 SQL 문 AWS CloudFormation 템플릿 이 연습의 각 단계마다 관련 파일을 다운로드할 수 있는 링크가 포함되어 있거나 해당 단계에 정확한 쿼리 가 포함되어 있습니다. AWS 리전에서 RDS, (AWS DMS) 인스턴스와 Amazon Redshift 클러스 터를 시작할 수 있도록 해주는 AWS Identity and Access Management (IAM) 자격 증명을 가진 AWS 계정 입니다. IAM 자격 증명에 대한 정보는 IAM 사용자 생성 섹션을 참조하십시오. Amazon Virtual Private Cloud(Amazon VPC) 서비스 및 보안 그룹에 대한 기본 지식. Amazon RDS에서 Amazon VPC를 사용하는 방법에 대한 정보는 가상 사설 클라우드(VPCs) 및 Amazon RDS 섹션을 참조하 십시오. Amazon RDS 보안 그룹에 대한 자세한 내용은 Amazon RDS 보안 그룹을 참조하십시오. VPC에 서 Amazon Redshift 사용에 대한 자세한 내용은 Amazon Virtual Private Cloud(VPC)의 클러스터 관리를 참조하십시오. AWS DMS의 지원 기능 및 제한 사항에 대한 이해 AWS DMS에 대한 자세한 내용은 AWS Database Migration Service란 무엇입니까? 섹션을 참조하십시오. Oracle 및 Amazon Redshift에서 지원되는 데이터 형식 변환 옵션에 대한 정보입니다. 원본으로서 Oracle 용 데이터 형식에 대한 정보는 에서 Oracle 데이터베이스를 원본으로 사 용 을 참조하십시오. 원본으로서 Amazon Redshift 데이터 형식에 대한 정보는 AWS Database Migration Service에서 Amazon Redshift 데이터베이스를 대상으로 사용 을 참조하십시오. AWS DMS에 대한 자세한 내용은 AWS DMS 설명서를 참조하십시오. 마이그레이션 아키텍처 이 예제에서는 AWS CloudFormation을 사용하여 데이터베이스 마이그레이션을 위한 단순 네트워크 토폴로 지를 생성하며, 여기에는 원본 데이터베이스, 복제 인스턴스, 동일한 VPC의 대상 데이터베이스가 포함됩니 다. AWS CloudFormation에 대한 자세한 내용은 CloudFormation 설명서를 참조하십시오. AWS CloudFormation을 통해 본 AWS DMS 연습에 필요한 AWS 리소스를 프로비저닝합니다. 이러 한 리소스에는 VPC 및 Oracle용 Amazon RDS 인스턴스, Amazon Redshift 클러스터가 포함됩니다. CloudFormation을 통해 프로비저닝하므로 프로세스가 간편해져 데이터 마이그레이션과 관련된 작업에 집중 할 수 있습니다. CloudFormation 템플릿에서 스택을 생성하면 다음 리소스를 프로비저닝합니다. 리전에서 퍼블릭 서브넷 2개를 지원하는 CIDR(10.0.0.0/24)을 사용한 VPC, 가용 영역(AZ) 1에서 주소가 10.0.0.0/26인 DBSubnet1, AZ 12에서 주소가 10.0.0.64/26인 DBSubnet2입니다. DBSubnet1과 DBSubnet2를 포함하는 DB 서브넷 그룹입니다. Oracle RDS Standard Edition Two의 배포 옵션 2개는 다음과 같습니다. 라이선스 포함 Single-AZ 설정 db.m3 미디엄 또는 이에 준하는 인스턴스 클래스 포트 1521 기본 옵션 및 파리미터 그룹 이 배포 옵션을 사용한 Amazon Redshift 클러스터는 다음과 같습니다. dc1.large 포트 5439 기본 파라미터 그룹 112

단계별 마이그레이션 입력 파라미터를 기반으로 컴퓨터 또는 0.0.0.0/0(어디에서든 액세스)에서 수신 액세스가 지원되는 보안 그 룹 사용자의 입력이 거의 필요 없도록 CloudFormation 템플릿을 설계했습니다. 최소 권장 구성으로 필요한 AWS 리소스를 프로비저닝합니다. 그렇지만, VPC CIDR 블록과 Amazon RDS 인스턴스 형식과 같은 일부 구성과 파라미터를 변경해야 하는 경우에는 언제든지 템플릿을 업데이트하십시오. AWS Management Console을 사용하여 복제 인스턴스, 엔드포인트 및 작업과 같은 AWS DMS 리소스를 프 로비저닝합니다. 로컬 컴퓨터에 SQL Workbench/J 및 AWS Schema Conversion Tool(AWS SCT)과 같은 클 라이언트 도구를 설치하여 Amazon RDS 인스턴스에 연결합니다. 다음은 이 연습에 해당하는 마이그레이션 아키텍처에 대한 그림입니다. 단계별 마이그레이션 다음 섹션에는 Oracle 데이터베이스의 Amazon RDS를 Amazon Redshift로 마이그레이션하는 단계별 지침 이 나옵니다. 이 단계는 사용자가 이미 앞의 섹션에서 설명한 원본 데이터베이스를 준비했다고 가정합니다. 항목 113

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작 (p. 114) 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 (p. 119) 3단계: Oracle DB Instance와의 연결을 테스트하고 샘플 스키마 생성 (p. 122) 4단계: Amazon Redshift 데이터베이스와의 연결을 테스트합니다. (p. 126) 5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 (p. 127) 6단계: 스키마 변환 검증 (p. 135) 7단계: AWS DMS 복제 인스턴스 생성 (p. 136) 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. (p. 137) 9단계: AWS DMS 마이그레이션 작업 생성 및 실행 (p. 140) 10단계: AWS DMS 마이그레이션이 성공적으로 완료되었는지 확인 (p. 144) 11단계: 연습 리소스 삭제 (p. 146) 1단계: CloudFormation 템플릿을 사용하여 VPC에서 RDS 인스턴스 시작 먼저 이 연습에서 필요한 AWS 리소스를 프로비저닝해야 합니다. 다음 연습에서는 AWS CloudFormation 템플릿을 사용하여 이 연습에 적합한 Amazon RDS 리소스 를 생성합니다. 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/cloudformation에서 AWS CloudFormation 콘솔을 엽니다. 2. [Create New Stack]을 선택합니다. 3. [Select Template ] 페이지에서 [Specify an Amazon S3 template URL ]을 선택하고 다음 URL을 인접한 텍스트 상자에 붙여 넣습니다. https://dms-sbs.s3.amazonaws.com/oracle_redshift_for_dmsdemo.template 114

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 4. [Next]를 선택합니다. [Specify DB Details] 페이지에서 다음과 같이 파라미터 값을 입력합니다. 이 파라미터의 경우... 수행할 작업 [Stack Name ] OracletoRedshiftDWusingDMS를 입력합니다. [OracleDBName] 데이터베이스 고유 이름을 입력합니다. 이름은 문자로 시작 해야 합니다. 기본값은 ORCL입니다. [OracleDBUsername] Oracle 인스턴스를 관리할 관리(DBA) 사용자를 지정합니 다. 기본값은 oraadmin입니다. 115

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 이 파라미터의 경우... 수행할 작업 [OracleDBPassword] 관리 사용자 암호를 입력합니다. 기본값은 입니 다.oraadmin123 RedshiftDBName 데이터베이스 고유 이름을 입력합니다. 이름은 문자로 시작 해야 합니다. 기본값은 test입니다. RedshiftDBUsername 마스터 사용자 암호를 입력합니다. 기본값은 Redshift#123입니다. [ClientIP] 로컬 컴퓨터의 IP 주소를 CIDR(x.x.x.x/32) 형식으로 지정 합니다. whatsmyip.org에서 IP 주소를 가져올 수 있습니다. RDS 인스턴스의 보안 그룹은 이 IP 주소로의 수신을 허용합 니다. 기본값은 어디에서든 액세스 가능한 (0.0.0.0/0)이고, 권장되지 않습니다. 이 연습에서 IP 주소를 사용해야 합니 다. 116

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 5. [Next]를 선택합니다. [Options] 페이지에서 [Next]를 선택합니다. 6. [Review] 페이지에서 세부 정보를 검토하고 올바를 경우 [Create]를 선택합니다. 117

1단계: CloudFormation 템플릿을 사 용하여 VPC에서 RDS 인스턴스 시작 118

7. 8. 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 AWS에서 Amazon RDS Oracle 인스턴스 및 Amazon Redshift 클러스터를 사용하여 스택을 생성하기까 지 약 20분 이상이 소요될 수 있습니다. 스택 생성 후 [OracletoRedshiftDWusingDMS] 스택을 선택하고, [Outputs] 보기를 선택합니다. JDBC 연 결 문자열 [OracleJDBCConnectionString] 및 [RedshiftJDBCConnectionString]을 기록해 두면 이 연습에 서 나중에 Oracle 및 Amazon Redshift 데이터베이스에 연결하는 데 사용할 수 있습니다. 2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 그 다음, 로컬 컴퓨터에 SQL 클라이언트 및 AWS SCT를 설치합니다. 이 연습에서는 마이그레이션 확인을 위해 SQL Workbench/J 클라이언트를 사용하여 RDS 인스턴스에 연결 한다고 가정합니다. 119

2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 SQL 클라이언트 소프트웨어를 설치하려면 1. SQL Workbench/J 웹사이트에서 SQL Workbench/J를 다운로드한 후 로컬 컴퓨터에 설치합니다. 이 SQL 클라이언트는 무료로 제공되는 오픈 소스로서 DBMS에 종속되어 있지 않습니다. 2. Oracle Database 12.1.0.2 JDBC 드라이버(ojdbc7.jar)를 다운로드합니다. 3. Amazon Redshift 드라이버(RedshiftJDBC41-1.1.17.1017.jar)를 다운로드합니다. 4. SQL Workbench/J를 사용하여 다음 설명과 같이 Oracle 및 Amazon Redshift용 JDBC 드라이버를 구성 하여 연결을 설정합니다. 1. SQL Workbench/J에서 [File]을 선택한 후 [Manage Drivers]를 선택합니다. 2. 드라이버 목록에서 [Oracle]을 선택합니다. 3. [Open] 아이콘을 선택하고 나서 이전 단계에서 다운로드한 ojdbc.jar 파일을 선택합니다. [OK]를 선택합니다. 4. 드라이버 목록에서 [Redshift]를 선택합니다. 5. [Open] 아이콘을 선택하고 나서 이전 단계에서 다운로드한 Amazon Redshift JDBC 드라이버를 선 택합니다. [OK]를 선택합니다. 120

2단계: 로컬 컴퓨터에 SQL 도구와 AWS Schema Conversion Tool 설치 그 다음, AWS SCT 및 필수 JDBC 드라이버를 설치합니다. AWS SCT와 필요한 JDBC 드라이버를 설치하려면 1. AWS Schema Conversion Tool 사용 설명서의 AWS Schema Conversion Tool 설치 및 업데이트에서 AWS SCT를 다운로드합니다. 2. 지침에 따라 AWS SCT를 설치합니다. 기본적으로 C:\Program Files\AWS Schema Conversion Tool\AWS 디렉터리에 이 도구가 설치됩니다. 3. AWS SCT를 시작합니다. 4. AWS SCT의 [Settings]에서 [Global Settings]를 선택합니다. 5. [Settings], [Global Settings]를 선택한 후 [Drivers]를 선택하고 나서 [Oracle Driver Path]에서 [Browse]를 선택합니다. Oracle JDBC 드라이버를 찾고 [OK]를 선택합니다. 6. [Amazon Redshift Driver Path]에서 [Browse]를 선택합니다. Amazon Redshift JDBC 드라이버를 찾고 [OK]를 선택합니다. [OK]를 선택하여 대화 상자를 닫습니다. 121

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 3단계: Oracle DB Instance와의 연결을 테스트하고 샘 플 스키마 생성 CloudFormation 스택을 생성한 후 SQL Workbench/J를 사용하여 Oracle DB 인스턴스 연결을 테스트하고 HR 샘플 스키마를 생성합니다. SQL Workbench/J를 사용하여 Oracle DB 인스턴스와의 연결을 테스트하고 샘플 스키마를 생성하 려면 1. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. 다음 정보를 사용하여 새 연 결 프로필을 생성합니다. 이 파라미터의 경우... 수행할 작업 [New profile] 이름 RDSOracleConnection을 입력합니다. 드라이버 Oracle (oracle.jdbc.oracledriver)을 선택합니 다. 122

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 2. 이 파라미터의 경우... 수행할 작업 URL 이전 단계에서 DMSdemo 스택의 출력 세부 정보를 검사했 을 때 기록한 [OracleJDBCConnectionString] 값을 사용합니 다. 사용자명 oraadmin을 입력합니다. [Password] oraadmin123을 입력합니다. 연결을 테스트하려면 [Test]를 선택합니다. [OK]를 선택하여 대화 상자를 닫은 후 [OK]를 선택하여 연결 프로필을 생성합니다. Note 용 Oracle DB 인스턴스에 연결 123

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 연결에 실패한 경우, CloudFormation 템플릿을 생성할 때 할당한 IP 주소가 연결을 시도한 IP 주소인지 확인합니다. 이 문제는 인스턴스에 연결할 때 가장 일반적으로 발생하는 문제입니다. 3. 사용자 지정 스크립트를 사용하여 마이그레이션에 사용할 SH 스키마를 생성합니다. AWS에서 제공한 SQL 스크립트는 https://dms-sbs.s3.amazonaws.com/oracle-hr-schema-build.sql에 있습니다. 1. 텍스트 편집기에서 제공된 SQL 스크립트를 엽니다. 전체 스크립트를 복사합니다. 2. SQL Workbench/J에서 다음 코드를 복사하고 [Statement 1]를 보여 주는 Default.wksp 창에 SQL 스 크립트를 붙여 넣습니다. 3. [SQL]을 선택한 후 [Execute All]을 선택합니다. 124

3단계: Oracle DB Instance와의 연 결을 테스트하고 샘플 스키마 생성 4. 다음 SQL 쿼리를 실행하여 SH 스키마에서 객체 유형과 개수가 생성되었는지 확인합니다. Select OBJECT_TYPE, COUNT(*) from dba_objects where owner='sh' GROUP BY OBJECT_TYPE; 이 쿼리 결과는 다음과 비슷해야 합니다. 125

4단계: Amazon Redshift 데이터 베이스와의 연결을 테스트합니다. OBJECT_TYPE COUNT(*) ----------------+--------INDEX PARTITION 40 TABLE PARTITION 8 TABLE 5 INDEX 15 5. 다음 SQL 쿼리를 실행하여 총 테이블 수와 각 테이블별 행 수를 확인합니다. Select table_name, num_rows from dba_tables where owner='sh' order by 1; 이 쿼리 결과는 다음과 비슷해야 합니다. TABLE_NAME NUM_ROWS -----------+--------CHANNELS 5 CUSTOMERS 8 PRODUCTS 66 PROMOTIONS 503 SALES 553 6. 테이블에서 무결성을 확인합니다. 다음 SQL 쿼리를 실행하여 다른 채널에서 달성한 판매량을 확인합니 다. Select b.channel_desc,count(*) from SH.SALES a,sh.channels b where a.channel_id=b.channel_id group by b.channel_desc order by 1; 이 쿼리 결과는 다음과 비슷해야 합니다. CHANNEL_DESC COUNT(*) -------------+--------Direct Sales 710 Internet 52 Partners 344 Note 이전 예제는 검증 쿼리를 대표합니다. 실제 마이그레이션을 수행할 때 유사한 쿼리를 생성하여 스키 마와 데이터 무결성을 검증해야 합니다. 4단계: Amazon Redshift 데이터베이스와의 연결을 테 스트합니다. 그 다음, Amazon Redshift 데이터베이스와의 연결을 테스트합니다. SQL Workbench/J를 사용하여 Amazon Redshift 데이터베이스와의 연결을 테스트하려면 1. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. [Create a new connection profile] 아이콘을 선택합니다. 아래 나오는 정보를 사용하여 SQL Workbench/J에서 Amazon Redshift 데 이터베이스에 연결합니다. 126

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 2. 이 파라미터의 경우... 수행할 작업 [New profile] 이름 RedshiftConnection을 입력합니다. 드라이버 Redshift (com.amazon.redshift.jdbc42.driver)을 선택합니 다. URL 이전 단계에서 DMSdemo 스택의 출력 세부 정보를 검사했 을 때 기록한 RedshiftJDBCConnectionString 값을 사용합 니다. 사용자명 redshiftadmin을 입력합니다. [Password] Redshift데123을 입력합니다. 연결을 테스트하려면 [Test]를 선택합니다. [OK]를 선택하여 대화 상자를 닫은 후 [OK]를 선택하여 연결 프로필을 생성합니다. Note 연결에 실패한 경우, CloudFormation 템플릿을 생성할 때 할당한 IP 주소가 연결을 시도한 IP 주소인지 확인합니다. 이 문제는 인스턴스에 연결할 때 가장 일반적으로 발생하는 문제입니다. 3. select current_date;와 같은 샘플 SQL 명령을 실행하여 Amazon Redshift DB 인스턴스와의 연결 을 확인합니다. 5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 데이터를 Amazon Redshift로 변환하기 전에 아래 설명과 같이 Oracle 스키마를 Amazon Redshift 스키마로 변환합니다. 127

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift 스키마로 변환하려면 1. 2. AWS SCT를 시작합니다. AWS SCT에서 [File]을 선택하고 나서 [New Project]를 선택합니다. DWSchemaMigrationDemoProject라고 하는 새 프로젝트를 만듭니다. [New Project] 창에 다음 정보 를 입력하고 [OK]를 선택합니다. 이 파라미터의 경우... 수행할 작업 [프로젝트 이름] DWSchemaMigrationDemoProject를 입력합니다. 위치 기본 [Projects] 폴더와 기본 [Data Warehouse (OLAP)] 옵션 을 사용합니다. [Source Database Engine] [Oracle DW]를 선택합니다. [Target Database Engine] [Amazon Redshift]을 선택합니다. [Connect to Oracle]을 선택합니다. [Connect to Oracle] 대화 상자에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 이 파라미터의 경우... 수행할 작업 Type [SID]를 선택합니다. [Server name] Oracle DB 인스턴스에 연결하는 데 사용한 OracleJDBCConnectionString 값을 사용하지 만, JDBC 접두사 정보와 포트 및 데이터베이 스 이름 접미사를 제거합니다. 예를 들어, SQL Workbench/J에서 사용하는 샘플 연결 문자열은 "jdbc:oracle:thin:@abc12345678.cqi87654abc.uswest-2.rds.amazonaws.com:1521:orcl"이 될 수도 있습니다. AWS SCT [Server name]의 경우, "jdbc:oracle:thin:@"과 ":1521:ORCL"을 제거 128

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 이 파라미터의 경우... 수행할 작업 하고 서버 이름: "abc12345678.cqi87654abc.uswest-2.rds.amazonaws.com"만을 사용합니다. 3. [Server port] [1521]을 입력합니다. [Oracle SID] ORCL을 입력합니다. 사용자 이름 oraadmin을 입력합니다. 비밀번호 oraadmin123을 입력합니다. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 Oracle DB 인스턴스와의 연 결을 시작합니다. Oracle DB 인스턴스의 데이터베이스 구조는 다음과 같이 표시됩니다. SH 스키마만을 선택합니다. 129

Note 5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 SH 스키마가 목록에 표시되지 않을 경우, [Actions]를 선택하고 나서 [Refresh from Database] 를 선택합니다. 4. [Connect to Amazon Redshift]를 선택합니다. [Connect to Amazon Redshift] 대화 상자에서 다음 정보를 입력한 후 [Test Connection]을 선택합니다. 이 파라미터의 경우... 수행할 작업 Type [SID]를 선택합니다. [Server name] Amazon Redshift 클러스터에 연결하는 데 사용한 [RedshiftJDBCConnectionString] 값을 사용하지만, JDBC 접두사 정보와 포트 접미사를 제거합니다. 예를 들어, SQL Workbench/J에서 사용하는 샘플 연결 문 자열은 " jdbc:redshift://oracletoredshiftdwusingdmsredshiftcluster-abc123567.abc87654321.uswest-2.redshift.amazonaws.com:5439/test"이 될 수도 있습니다. AWS SCT [Server name] 의 경우, " jdbc:redshift://" 및 :5439/test"를 제거 하고 서버 이름: "oracletoredshiftdwusingdmsredshiftcluster-abc123567.abc87654321.uswest-2.redshift.amazonaws.com"만을 사용합니다. 130

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 이 파라미터의 경우... 수행할 작업 [Server port] [5439]을 입력합니다. 사용자 이름 redshiftadmin을 입력합니다. [Password] Redshift데123을 입력합니다. AWS SCT는 SH 스키마를 분석하고 데이터베이스 마이그레이션 평가 보고서를 생성하여 Amazon Redshift로 변환합니다. 5. [OK]를 선택하여 알림 상자를 닫은 후 [OK]를 선택하여 이 대화 상자를 닫고 Amazon Redshift DB 인스 턴스와의 연결을 시작합니다. 6. [Oracle DW] 보기에서 [SH] 스키마의 컨텍스트 메뉴를 열고(마우스 오른쪽 버튼 클릭) [Create Report] 를 선택합니다. 7. 보고서 요약을 검토하십시오. 보고서를 저장하려면 [Save to CSV] 또는 [Save to PDF]를 선택합니다. 이 보고서에서는 잠재적인 마이그레이션 문제 및 이 문제를 해결하는 조치와 더불어 AWS SCT를 사용 하여 변환할 수 있는 객체 유형에 대해 다룹니다. 이 연습에서는 다음과 같은 항목이 표시됩니다. 131

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 132

8. 9. 5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 [Action Items] 탭을 선택합니다. 이 보고서에서는 잠재적인 마이그레이션 문제 및 이 문제를 해결하는 조치와 더불어 AWS SCT를 사용하여 변환할 수 있는 객체 유형에 대해 다룹니다. 이 연습에서는 다음과 같은 항목이 표시됩니다. [Schemas] 목록에서 [SH] 항목의 컨텍스트 메뉴를 열고(마우스 오른쪽 버튼 클릭) [Collect Statistics]를 선택합니다. AWS SCT는 원본 데이터를 분석하여 대상 Amazon Redshift 데이터베이스를 위한 최적의 키를 권장합니다. 자세한 내용은 AWS Schema Conversion Tool을 위해 통계 수집 또는 업로드를 참조 하십시오. 10. [SH] 스키마의 컨텍스트를 열고(마우스 오른쪽 버튼 클릭) 나서 [Convert schema]를 선택합니다. 11. 확인 메시지에서 [Yes]를 선택합니다. 그런 다음 AWS SCT는 스키마를 대상 데이터베이스 형식으로 변 환합니다. 133

5단계: AWS SCT를 사용하여 Oracle 스키마를 Amazon Redshift로 변환 Note Amazon Redshift 정렬 키와 분산 키 선택은 최적의 성능에 필수적입니다. AWS SCT에서 키 관리를 사용하여 키 선택을 사용자 지정할 수 있습니다. 이 연습에서는 AWS SCT에서 권장하 는 기본값을 사용합니다. 자세한 내용은 AWS Schema Conversion Too을 사용하여 Amazon Redshift 최적화를 참조하십시오. 12. Amazon Redshift 보기에서 [SH] 스키마의 컨텍스트 메뉴를 열고(마우스 오른쪽 버튼으로 클릭) [Apply to database]를 선택하여 스키마 스크립트를 대상 Amazon Redshift 인스턴스에 적용합니다. 13. [SH] 스키마에서 컨텍스트 메뉴를 열고(마우스 오른쪽 버튼으로 클릭) [Refresh from Database]를 선택 합니다. 134

6단계: 스키마 변환 검증 이제 데이터베이스 스키마가 변환되어 원본에서 대상으로 가져올 수 있습니다. 6단계: 스키마 변환 검증 스키마 변환을 검증하려면, SQL Workbench/J를 사용하여 Oracle과 Amazon Redshift 데이터베이스에 나오 는 객체를 비교합니다. SQL Workbench/J를 사용하여 스키마 변환을 검증하려면 1. SQL Workbench/J에서 [File]을 선택한 후 [Connect window]를 선택합니다. 이전 단계에서 생성한 RedshiftConnection을 선택합니다. [OK]를 선택합니다. 2. 다음 스크립트를 실행하여 대상 Amazon Redshift 데이터베이스에서 객체 형식 개수와 SH 스키마 개수 를 확인합니다. 이 값은 원본 Oracle 데이터베이스의 객체 수와 일치해야 합니다. SELECT 'TABLE' AS OBJECT_TYPE, TABLE_NAME AS OBJECT_NAME, TABLE_SCHEMA AS OBJECT_SCHEMA FROM information_schema.tables WHERE TABLE_TYPE = 'BASE TABLE' AND OBJECT_SCHEMA = 'sh'; 이 쿼리는 다음과 비슷한 내용을 출력해야 합니다. object_type object_name object_schema ------------+-------------+-------------TABLE channels sh TABLE customers sh TABLE products sh TABLE promotions sh TABLE sales sh 3. 다음 쿼리를 사용하여 Amazon Redshift 클러스터에 생성된 정렬 및 분산 키를 확인합니다. set search_path to '$user', 'public', 'sh'; SELECT tablename, "column", TYPE, encoding, distkey, sortkey, "notnull" FROM pg_table_def WHERE (distkey = TRUE OR sortkey <> 0); 쿼리 결과는 AWS SCT 키 관리를 사용하여 선택한 분산 키(distkey)와 정렬 키(sortkey)를 반영합니 다. tablename column type encoding distkey sortkey notnull -----------+---------------------+-----------------------------+----------+--------+---------+-------channels channel_id numeric(38,18) none true 1 true customers cust_id numeric(38,18) none false 4 true customers cust_gender character(2) none false 1 true 135

7단계: AWS DMS 복제 인스턴스 생성 customers cust_year_of_birth 3 true customers cust_marital_status 2 false products prod_id 4 true products prod_subcategory 3 true products prod_category 2 true products prod_status 1 true promotions promo_id 1 true sales prod_id 4 true sales cust_id 3 true sales time_id 1 true sales channel_id 2 true sales promo_id 5 true smallint none false character varying(40) none false integer none true character varying(100) none false character varying(100) none false character varying(40) none false integer none true numeric(38,18) none false numeric(38,18) none false timestamp without time zone none true numeric(38,18) none false numeric(38,18) none false 7단계: AWS DMS 복제 인스턴스 생성 앞의 설명과 같이 원본과 대상 데이터베이스에서 스키마 구조를 검증한 후 이 연습의 핵심 부분인 데이터 마 이그레이션으로 진행합니다. 다음 그림은 마이그레이션 프로세스의 상위 수준 보기를 보여줍니다. DMS 복제 인스턴스는 원본과 대상 간에 실제 데이터 마이그레이션을 수행합니다. 복제 인스턴스도 마이그 레이션 중에 트랜잭션 로그를 캐시합니다. 복제 인스턴스가 갖는 CPU와 메모리 용량은 마이그레이션에 필 요한 전체 시간에 영향을 줍니다. AWS DMS 복제 인스턴스를 생성하려면 1. 2. 3. 4. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/dms/에서 AWS DMS 콘솔 을 열고, [Create Migration]을 선택합니다. AWS Identity and Access Management(IAM) 사용자로 로그 인한 경우 AWS DMS에 액세스하기 위한 적절한 권한이 있어야 합니다. 필요한 권한에 대한 자세한 내 용은 AWS DMS 사용에 필요한 IAM 권한을 참조하십시오. [Create migration]를 선택하여 데이터베이스 마이그레이션을 시작합니다. [Welcome] 페이지에서 [Next]를 선택합니다. [Create replication instance] 페이지에서 다음과 같이 복제 인스턴스 정보를 지정합니다. 이 파라미터의 경우... 수행할 작업 이름 [DMSdemo-repserver]를 입력합니다. 136

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 5. 이 파라미터의 경우... 수행할 작업 설명 DMS 데데 데데 데데와 같은 간략한 설명을 입력합니다. 인스턴스 클래스 [dms.t2.medium]을 선택합니다. 이 인스턴스 클래스는 작은 테이블 집합을 마이그레이션하기에 충분히 큽니다. VPC CloudFormation 스택에서 생성된 VPC인 OracletoRedshiftusingDMS를 선택합니다. 다중 AZ [No]를 선택합니다. [Publicly accessible] 이 항목을 선택한 상태로 둡니다. [Advanced] 섹션에서 기본 설정은 그대로 두고, [Next: Tag Instance]를 선택합니다. 8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니 다. 복제 인스턴스가 생성되는 동안 AWS Management Console을 사용하여 원본과 대상 데이터베이스 엔드포 인트를 지정할 수 있습니다. 그렇지만, 복제 인스턴스는 연결에 사용되기 때문에 복제 인스턴스가 생성된 후 에는 연결을 테스트만할 수 있습니다. AWS 콘솔을 사용하여 원본 또는 대상 데이터베이스 엔드포인트를 지정하려면 1. 원본 Oracle 데이터베이스와 대상 Amazon Redshift 데이터베이스에 대한 연결 정보를 지정합니다. 다음 표는 원본 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Endpoint Identifier] Orasource(Amazon RDS Oracle 엔드포인트)를 입력합니 다. 소스 엔진 [oracle]을 선택합니다. [Server name] Oracle DB 인스턴스 이름을 입력합니다. 이 이름은 "abc123567.abc87654321.uswest-2.rds.amazonaws.com"와 같이 AWS SCT에서 사용한 [Server name] 값입니다. Port [1521]을 입력합니다. [SSL mode] [None]을 선택합니다. 사용자명 oraadmin을 입력합니다. 비밀번호 oraadmin123을 입력합니다. SID ORCL을 입력합니다. 다음 표는 대상 설정에 대한 설명입니다. 137

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 이 파라미터의 경우... 수행할 작업 [Endpoint Identifier] Redshifttarget(Amazon Redshift 엔드포인트)를 입력합 니다. [Target Engine] Redshift를 선택합니다. [Servername ] Amazon Redshift DB 인스턴스 이름을 입력합니다. 이 이름은 "oracletoredshiftdwusingdmsredshiftcluster-abc123567.abc87654321.uswest-2.redshift.amazonaws.com"와 같이 AWS SCT 에 사용된 [Server name] 값입니다.. Port [5439]을 입력합니다. [SSL mode] [None]을 선택합니다. 사용자명 redshiftadmin을 입력합니다. [Password] Redshift데123을 입력합니다. 데이터베이스 이름 [test]를 입력합니다. 완료한 페이지는 다음과 같아야 합니다. 138

8단계: AWS DMS 원본과 대상 엔드포인트를 생성합니다. 2. [Replication instance created successfully.] 상태가 표시될 때가지 기다립니다. 3. 원본과 대상 연결을 테스트하려면, 원본과 대상 연결에서 [Run Test]를 선택합니다. 4. [Next]를 선택합니다. 139

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 9단계: AWS DMS 마이그레이션 작업 생성 및 실행 AWS DMS 작업을 사용하여 마이그레이션할 스키마와 마이그레이션 유형을 지정할 수 있습니다. 기존 데이 터를 마이그레이션하거나, 지속적 변경 사항을 복제하거나, 또는 데이터 변경 사항만 복제할 수 있습니다. 이 연습에서는 기존 데이터만을 마이그레이션합니다. 마이그레이션 작업을 생성하려면 1. [Create Task] 페이지에서 작업 옵션을 지정합니다. 다음 표는 설정에 대한 설명입니다. 이 파라미터의 경우... 수행할 작업 [Task name] migrateshschema를 입력합니다. 복제 인스턴스 DMSdemo-repserver(이전 단계에서 생성한 AWS DMS 복제 인스턴스)를 보여줍니다. [Source endpoint] orasource(oracle 엔드포인트용 Amazon RDS)를 표시합 니다. [Target endpoint] redshifttarget(amazon Redshift 엔드포인트)를 표시합 니다. [Migration type] [Migrate existing data] 옵션을 선택합니다. [Start task on create] 이 옵션을 선택합니다. 이 페이지는 다음과 같이 보여야 합니다. 140

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 2. [Task Settings] 섹션에서 다음 표에서와 같이 설정을 지정합니다. 이 파라미터의 경우... 수행할 작업 [Target table preparation mode] [Do nothing]을 선택합니다. [Include LOB columns in replication] [Limited LOB mode]를 선택합니다. [Max LOB size (kb)] 기본값(32)을 수락합니다. 이 섹션은 다음과 같아야 합니다. 141

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 3. [Selection rules] 섹션에서 다음 표에서와 같이 설정을 지정합니다. 이 파라미터의 경우... 수행할 작업 스키마 이름 [Enter a schema]를 선택합니다. 스키마 이름의 형식 [SH%]를 입력합니다. 테이블 이름의 형식 Type %. Action [Include]를 선택합니다. 이 섹션은 다음과 같아야 합니다. 142

9단계: AWS DMS 마이그레이션 작업 생성 및 실행 4. [Add selection rule]을 선택합니다. 5. [Create task]를 선택합니다. 5. [Create task]를 선택합니다. 작업이 즉시 시작됩니다. [Tasks] 섹션에는 마이그레이션 작업 상태가 나타납 니다. 143

10단계: AWS DMS 마이그레이션 이 성공적으로 완료되었는지 확인 10단계: AWS DMS 마이그레이션이 성공적으로 완료되 었는지 확인 마이그레이션 작업이 완료되면, 작업 결과를 예상 결과와 비교할 수 있습니다. 마이그레이션 작업 결과를 예상 결과와 비교하려면 1. 탐색 창에서 [Tasks]를 선택합니다. 2. 마이그레이션 작업(migrateSHschema)을 선택합니다. 3. 다음 그림과 같이 [Table statistics] 탭을 선택합니다. 144

10단계: AWS DMS 마이그레이션 이 성공적으로 완료되었는지 확인 4. SQL Workbench/J를 사용하여 Amazon Redshift 인스턴스에 연결하고 나서 데이터베이스 테이블을 Oracle에서 Amazon Redshift로 마이그레이션했는지 여부를 확인하기 위해 다음 그림과 같이 SQL 스크 립트를 실행합니다. select "table", tbl_rows from svv_table_info where SCHEMA = 'sh' 145

11단계: 연습 리소스 삭제 order by 1; 결과는 다음과 비슷한 모습이어야 합니다. table tbl_rows -----------+--------channels 5 customers 8 products 66 promotions 503 sales 1106 5. 이전 쿼리의 테이블 출력과 행 수가 RDS Oracle에서 예상한 수치와 일치하는지 확인하기 위해, 이전 단 계의 결과와 현재 결과를 비교합니다. 6. 다음 쿼리를 실행하여 테이블에서 관계를 확인합니다. 이 쿼리는 10명이 넘는 직원이 있는 부서를 확인 합니다. Select b.channel_desc,count(*) from SH.SALES a,sh.channels b where a.channel_id=b.channel_id group by b.channel_desc order by 1; 이 쿼리는 다음과 비슷한 내용을 출력해야 합니다. channel_desc count -------------+-----Direct Sales 355 Internet 26 Partners 172 7. 열 압축 인코딩 확인 DMS는 Amazon Redshift COPY 작업을 사용하여 데이터를 로드합니다. 기본적으로 빈 대상 테이블에 로드할 때마다 COPY 명령은 자동 압축을 적용합니다. 이 연습의 샘플 데이터는 자동 압축을 적용할 수 있을 만큼 충분히 크지 않습니다. 큰 데이터 집합을 마이그레이션할 때 COPY는 자동 압축을 적용합니 다. Amazon Redshift 테이블에서 자동 압축에 대한 자세한 내용은 자동 압축을 사용한 테이블 로드를 참조 하십시오. 압축 인코딩을 보려면, 다음 쿼리를 실행합니다. SELECT * FROM pg_table_def WHERE schemaname = 'sh ; 이제 Oracle DB 인스턴스용 Amazon RDS에서 Amazon Redshift로의 데이터베이스 마이그레이션을 완료했 습니다. 11단계: 연습 리소스 삭제 이 연습을 완료한 뒤에는 다음 단계를 수행하여 이 연습에서 사용된 추가 AWS 리소스에 요금이 부과되지 않 도록 다음 단계를 수행합니다. 일부 리소스가 다른 리소스에 대한 종속성이 있는 경우 이 리소스는 삭제할 수 없기 때문에 단계를 순서대로 수행해야 합니다. 146

다음 단계 AWS DMS 리소스를 삭제하려면 1. 2. 3. 4. 탐색 창에서 [Tasks]를 선택하고, 마이그레이션 작업(migratehrschema)을 선택한 후 [Delete]를 선택 합니다. 탐색 창에서 [Endpoints]를 선택하고, Oracle 소스 엔드포인트(orasource)를 선택하고 나서 [Delete]를 선택합니다. Amazon Redshift 대상 엔드포인트(redshifttarget)를 선택하고 나서 [Delete]를 선택합니다. 탐색 창에서 [Replication instances]를 선택하고, 복제 인스턴스(DMSdemo-repserver)를 선택하고 나 서 [Delete]를 선택합니다. 그런 다음 AWS CloudFormation 스택 DMSdemo를 삭제해야 합니다. AWS CloudFormation 스택을 삭제하려면 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/cloudformation에서 AWS CloudFormation 콘솔을 엽니다. 2. IAM 사용자로 로그인한 경우 AWS CloudFormation에 액세스하기 위한 적절한 권한이 있어야 합니다. CloudFormation 스택 OracletoRedshiftDWusingDMS를 선택합니다. 3. [ Actions]에서 [Delete stack]을 선택합니다. 스택 상태가 DELETE_IN_PROGRESS로 바뀌고, AWS CloudFormation이 OracletoRedshiftDWusingDMS 스택과 관련된 리소스를 정리합니다. AWS CloudFormation이 리소스 정 리를 마치면 목록에서 스택을 제거합니다. 다음 단계 다음 기능을 포함하여 이 연습에 포함되지 않은 AWS DMS의 다른 여러 기능을 살펴볼 수 있습니다. 데이터의 지속적 복제를 위한 AWS DMS 변경 데이터 캡처(CDC) 기능입니다. 마이그레이션 프로세스의 일부로서 변환을 지정하고 선택한 스키마에 적용할 수 있는 변환 작업입니다. 자세한 내용은 the AWS DMS 설명서를 참조하십시오. 참조 다음 설명서와 샘플 스키마는 이 연습에서 참조로서 유용할 수 있습니다. AWS DMS 설명서 AWS SCT 설명서 Amazon Redshift 설명서 SH 스키마를 빌드하는 SQL 문 AWS CloudFormation 템플릿 Oracle 샘플 스키마 147

MySQL 호환 데이터베이스를 AWS로 마이그레이션 Amazon Web Services(AWS)에는 AWS에서 MySQL 호환 데이터베이스를 실행할 수 있는 다양한 서비스가 마련되어 있습니다. Amazon Relational Database Service(Amazon RDS)는 MySQL, MariaDB 및 Amazon Aurora MySQL 등 MySQL 호환 데이터베이스를 지원합니다. AWS Elastic Cloud Computing Service(EC2)는 MySQL 호환 데이터베이스를 실행하는 플랫폼입니다. 마이그레이션 원본 솔루션 RDS MySQL DB 인스턴스 Amazon RDS MySQL DB 스냅샷의 데이터를 Amazon Aurora MySQL DB 클러스터로 직접 마이그레이션할 수 있습니다. 자세한 내용은 Amazon RDS MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클 러스터로 데이터 마이그레이션 (p. 159) 단원을 참조하십시오. Amazon RDS 외부의 MySQL 데이터베이스 InnoDB 또는 MyISAM 테이블스페이스를 지원하는 데이터베이스인 경 우, 다음과 같은 옵션으로 데이터를 Amazon Aurora MySQL DB 클러스 터로 마이그레이션할 수 있습니다. mysqldump 유틸리티로 데이터 덤프를 만들고 그 데이터를 기존 Amazon Aurora MySQL DB 클러스터로 가져올 수 있습니다. 데이터베이스에서 Amazon S3(S3) 버킷으로 원본 파일을 복사한 다음 해당 파일에서 Amazon Aurora MySQL DB 클러스터를 복원할 수 있 습니다. mysqldump를 사용하여 데이터를 마이그레이션하는 것보다 이 방법이 훨씬 더 빠를 것입니다. 자세한 내용은 mysqldump를 사용하여 MySQL에서 Amazon Aurora MySQL로 마이그레이션 (p. 159) 단원을 참조하십시오. MySQL과 호환되지 않는 데이 터베이스 (AWS DMS)를 사용하여 MySQL 데이터베이스의 데이터를 마이그레이션할 수도 있습니다. 그러나 크기가 매우 큰 데이터베이스의 경우, Amazon S3를 사용하여 외부 MySQL 데이터베이스의 데이터를 Amazon Aurora MySQL로 마이그레 이션 (p. 149)의 설명과 같이 데이터베이스의 소스 파일을 복사한 다음 해당 파일을 Amazon Aurora MySQL DB 인스턴스로 복원하면 데이터 마이그레이션 시간을 대폭 줄일 수 있습니다. AWS DMS에 대한 자세한 내용은 AWS 데이터베이스 마이그레이션 서 비스란 무엇입니까?를 참조하십시오. 148

Amazon S3를 사용하여 외부 MySQL 데이터베이스 의 데이터를 Amazon Aurora MySQL로 마이그레이션 MySQL 호환 데이터베이스를 Amazon Aurora MySQL로 마이그레 이션 InnoDB 또는 MyISAM 테이블스페이스를 지원하는 데이터베이스인 경우, 다음과 같은 옵션으로 데이터를 Amazon Aurora MySQL DB 클러스터로 마이그레이션할 수 있습니다. mysqldump 유틸리티로 데이터 덤프를 만들고 그 데이터를 기존 Amazon Aurora MySQL DB 클러스터로 가져올 수 있습니다. 자세한 내용은 mysqldump를 사용하여 MySQL에서 Amazon Aurora MySQL로 마이 그레이션 (p. 159) 단원을 참조하십시오. 데이터베이스에서 S3 버킷으로 소스 파일을 복사한 다음 해당 파일에서 Amazon Aurora MySQL DB 클러 스터를 복원할 수 있습니다. mysqldump를 사용하여 데이터를 마이그레이션하는 것보다 이 방법이 훨씬 더 빠를 것입니다. 자세한 내용은 Amazon S3를 사용하여 외부 MySQL 데이터베이스의 데이터를 Amazon Aurora MySQL로 마이그레이션 (p. 149) 단원을 참조하십시오. Amazon S3를 사용하여 외부 MySQL 데이터베이스 의 데이터를 Amazon Aurora MySQL로 마이그레이 션 소스 MySQL 버전 5.5 또는 5.6 데이터베이스에서 S3 버킷으로 소스 파일을 복사한 다음 해당 파일에서 Amazon Aurora MySQL DB 클러스터를 복원할 수 있습니다. mysqldump를 사용하여 데이터를 마이그레이션하는 것보다 이 옵션이 훨씬 더 빠를 수 있습니다. mysqldump를 사용하면 모든 명령을 다시 실행하여 소스 데이터베이스의 스키마와 데이터를 새 Amazon Aurora MySQL DB 클러스터에 다시 만들기 때문입니다. Amazon Aurora MySQL에서는 소스 MySQL 데이 터 파일을 복사하는 즉시 그 파일을 DB 클러스터의 데이터로 사용할 수 있습니다. Note 아시아 태평양(뭄바이) 리전에서는 S3 버킷의 백업 파일에서 Amazon Aurora MySQL DB 클러스터 를 복원하는 방법을 사용할 수 없습니다. Amazon Aurora MySQL가 데이터베이스에서 모든 것을 복원하는 것은 아닙니다. 소스 MySQL 또는 MariaDB 데이터베이스에서 다음 항목의 데이터베이스 스키마와 값을 저장한 다음, 복원한 Amazon Aurora MySQL DB 클러스터가 생성되면 여기에 추가해야 합니다. 사용자 계정 함수 저장 프로시저 시간대 정보. 시간대 정보는 Amazon Aurora MySQL DB 클러스터의 로컬 운영 체제에서 로드됩니다. 사전 조건 데이터를 S3 버킷으로 복사하고 그 파일로 DB 클러스터를 복원하려면 먼저 다음과 같이 해야 합니다. 149

사전 조건 로컬 서버에 Percona XtraBackup을 설치합니다. Amazon Aurora MySQL가 사용자의 S3 버킷에 대신 액세스할 수 있도록 허용합니다. Percona XtraBackup 설치 Amazon Aurora MySQL는 Percona XtraBackup을 사용하여 만든 파일로 DB 클러스터를 복원할 수 있습 니다. Percona 웹 사이트(https://www.percona.com/doc/percona-xtrabackup/2.4/installation)에서 Percona XtraBackup을 설치하십시오. 필요한 권한 MySQL 데이터를 Amazon Aurora MySQL DB 클러스터로 마이그레이션하려면 몇 가지 권한이 필요합니다. Amazon RDS에서 S3 버킷으로 새 클러스터를 만들도록 요청하는 사용자는 AWS 계정의 버킷을 나열할 권한이 있어야 합니다. 사용자에게 이러한 권한을 부여하려면 AWS Identity and Access Management(IAM) 정책을 사용합니다. Amazon RDS는 Amazon Aurora MySQL DB 클러스터를 만들 때 사용된 파일을 저장해 둔 S3 버킷에 대신 액세스하기 위해 권한을 요구합니다. IAM 서비스 역할을 사용하여 Amazon RDS에 필요한 권한을 부여합 니다. 요청한 사용자에게는 AWS 계정의 IAM 역할을 나열할 권한도 있어야 합니다. 요청한 사용자가 IAM 서비스 역할을 만들거나 Amazon RDS에 IAM 서비스 역할 생성(콘솔 사용)을 요청하 기 위해서는 AWS 계정의 IAM 역할을 만들 권한이 그 사용자에게 있어야 합니다. 예를 들어, 다음 IAM 정책은 콘솔을 사용하여 IAM 역할을 나열하고, IAM 역할을 만들고, 해당 계정의 S3 버 킷을 나열하는 데 필요한 최소한의 권한을 사용자에게 부여합니다. { } "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:listroles", "iam:createrole", "iam:createpolicy", "iam:attachrolepolicy", "s3:listbucket", "s3:listobjects" ], "Resource": "*" } ] 또한 사용자가 IAM 역할을 S3 버킷과 연결하려는 경우, IAM 사용자에게 해당 IAM 역할에 대한 iam:passrole 권한이 있어야 합니다. 관리자는 이 권한으로 사용자가 S3 버킷에 연결할 수 있는 IAM 역할 을 제한하게 됩니다. 예를 들어 다음 IAM 정책은사용자가 S3Access라는 역할을 S3 버킷과 연결할 수 있도록 허용합니다. { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowS3AccessRole", "Effect":"Allow", "Action":"iam:PassRole", 150

사전 조건 } ] } "Resource":"arn:aws:iam::123456789012:role/S3Access" IAM 서비스 역할 생성 [Create a New Role] 옵션을 선택하여 Amazon RDS Management Console에서 역할을 만들도록 할 수 있습 니다(이 주제 후반부에서 설명). 이 옵션을 선택하고 새 역할의 이름을 지정하면 Amazon RDS가 그 이름으로 S3 버킷에 액세스하는 데 필요한 IAM 서비스 역할을Amazon RDS 만듭니다. 또는 다음 절차에 따라 수동으로 역할을 만들 수도 있습니다. Amazon RDS가 S3에 액세스할 수 있도록 IAM 역할을 만들려면 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니 다. 2. 왼쪽 탐색 창에서 [Roles(역할)]를 선택합니다. 3. [Create New Role]을 선택하고 새 역할에 대해 [Role Name] 값을 지정한 다음 [Next Step]을 선택합니 다. 4. [AWS Service Roles]에서 [Amazon RDS]를 찾아 [Select]를 선택합니다. 5. [Attach Policy] 단계에서 연결할 정책을 선택하지 않습니다. 그 대신 [Next Step]을 선택합니다. 6. 7. 역할 정보를 검토한 후 [Create Role]을 선택합니다. 역할 목록에서 새로 만든 역할의 이름을 선택합니다. [Permissions] 탭을 선택합니다. 8. [Inline Policies]를 선택합니다. 새 역할에는 정책이 연결되어 있지 않기 때문에 정책을 만들라는 메시지 가 나타납니다. 링크를 클릭하여 새 정책을 만듭니다. 9. [Set Permissions] 페이지에서 [Custom Policy]와 [Select]를 차례로 선택합니다. 10. [Policy Name]을 S3-bucket-policy와 같이 입력합니다. [Policy Document]에 대해 다음 코드를 추가 하여 <bucket name>을 액세스를 허용할 S3 버킷 이름으로 바꿉니다. 파일 이름 접두사를 정책 문서의 일부분으로 포함시킬 수도 있습니다. 접두사를 지정하는 경우, Amazon Aurora MySQL는 S3 버킷에서 지정된 접두사로 시작되는 파일을 사용하여 DB 클러스터를 만듭니다. 접 두사를 지정하지 않는 경우, Amazon Aurora MySQL는 S3 버킷의 모든 파일을 사용하여 DB 클러스터를 만듭니다. 접두사를 지정하려면 아래의 <prefix>를 파일 이름의 접두사로 바꿉니다. 접두사 뒤에 별표(*)를 붙이 십시오. 접두사를 지정하지 않으려면 별표만 지정하면 됩니다. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:listbucket", "s3:getbucketlocation" ], "Resource": [ "arn:aws:s3:::<bucket name>" ] }, { "Effect": "Allow", "Action": [ "s3:getobject" ], "Resource": [ "arn:aws:s3:::<bucket name>/<prefix>*" 151

1단계: DB 클러스터로 복원할 파일 백업 } ] } ] 11. [Apply Policy]를 선택합니다. 1단계: DB 클러스터로 복원할 파일 백업 S3에서 복원하여 Amazon Aurora MySQL DB 클러스터를 만들 수 있는 MySQL 데이터베이스 파일의 백업을 만들려면 Percona Xtrabackup 유틸리티(innobackupex)를 사용하여 데이터베이스를 백업합니다. 예를 들어, 다음 명령을 실행하면 MySQL 데이터베이스 백업을 만들고 /s3-restore/backup 폴더에 백업 파일을 저장합니다. innobackupex --user=myuser --password=<password> --no-timestamp /s3-restore/backup 백업을 파일 하나로 압축하려면(필요하면 분할 가능) --stream 옵션을 사용하여 다음 형식 중 하나로 백업 을 저장하면 됩니다. Gzip(.gz) tar(.tar) Percona xbstream(.xbstream) 예를 들어 다음 명령을 실행하면 Gzip 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. 표시되 는 파라미터 값은 작은 테스트 데이터베이스용이므로, 자신의 해당 시나리오에 필요한 파라미터 값을 결정합 니다. innobackupex --user=myuser --password=<password> --stream=tar \ /mydata/s3-restore/backup split -d --bytes=512000 \ - /mydata/s3-restore/backup3/backup.tar.gz 예를 들어 다음 명령을 실행하면 tar 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. innobackupex --user=myuser --password=<password> --stream=tar \ /mydata/s3-restore/backup split -d --bytes=512000 \ - /mydata/s3-restore/backup3/backup.tar 예를 들어 다음 명령을 실행하면 xbstream 파일 여러 개로 된 MySQL 데이터베이스 백업이 만들어집니다. innobackupex --stream=xbstream \ /mydata/s3-restore/backup split -d --bytes=512000 \ - /mydata/s3-restore/backup/backup.xbstream S3는 버킷에 업로드되는 파일 크기를 5TB(테라바이트)로 제한합니다. 데이터베이스의 백업 데이터가 5TB를 초과하는 경우, split 명령을 사용하여 백업 파일을 각각 5TB 미만의 파일 여러 개로 나누어야 합니다. Amazon Aurora MySQL에서는 Percona Xtrabackup을 사용하여 부분 백업을 만들 수 없습니다. 데이터베이 스의 소스 파일을 백업할 때 --include, --tables-file 또는 --databases 옵션을 사용하여 부분 백업 을 만들 수 없습니다. 자세한 내용은 innobackupex 스크립트을(를) 참조하십시오. Amazon Aurora MySQL는 파일 이름을 기준으로 백업 파일을 사용합니다. 파일 형식에 따라 백업 파일의 이름에 적절한 파일 확장명을 지정해야 합니다. 예를 들어, Percona xbstream 형식으로 저장된 파일에는.xbstream을 지정합니다. 152

2단계: Amazon S3 버킷에 파일 복사 Amazon Aurora MySQL는 자연적인 번호 순서뿐 아니라 알파벳 순서로도 백업 파일을 사용합니다. innobackupex 명령을 실행할 때는 항상 split 옵션을 사용하여 적절한 순서로 백업 파일을 작성하고 이 름을 붙여야 합니다. 2단계: Amazon S3 버킷에 파일 복사 Percona Xtrabackup 유틸리티를 사용하여 MySQL 데이터베이스를 백업한 뒤에는 백업 파일을 S3 버킷으로 복사할 수 있습니다. 파일을 만들고 S3 버킷에 업로드하는 방법에 대한 자세한 내용은 Amazon S3 Getting Started Guide의 Getting Started with Amazon Simple Storage Service을(를) 참조하십시오. 3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 Amazon RDS 콘솔에서 Amazon S3 버킷의 백업 파일을 복원하여 새로운 Amazon Aurora MySQL DB 클러 스터를 만들 수 있습니다. S3 버킷의 파일로 Amazon Aurora MySQL DB 클러스터를 복원하려면 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔 을 엽니다. 2. RDS 대시보드에서 [Restore Aurora MySQL DB Cluster from S3]를 선택합니다. 3. [Specify Source Backup Details]에서 다음을 지정합니다. 옵션 수행할 작업 소스 엔진 Amazon Aurora MySQL는 현재 mysql 데이터베이스 엔진 에 대해서만 백업 파일로 복원하는 것을 지원합니다. [Source Engine Version] 백업 파일을 만들었던 MySQL 데이터베이스의 버전을 지정 합니다(예: 5.6.22). MySQL 버전 5.5 및 5.6가 지원됩니다. [Select S3 Bucket] 백업 파일이 저장되어 있는 S3 버킷을 선택합니다. [S3 Bucket Prefix (Optional)] S3 버킷에 저장된 파일의 파일 경로 접두사를 지정합니다. [S3 Bucket Prefix]는 선택 사항입니다. 접두사를 지정하지 않는 경우, Amazon Aurora MySQL는 S3 버킷의 루트 폴더 에 있는 모든 파일을 사용하여 DB 클러스터를 만듭니다. 접 두사를 지정하는 경우, Amazon Aurora MySQL는 S3 버킷에 서 지정된 접두사로 전체 경로가 시작되는 파일을 사용하여 DB 클러스터를 만듭니다. Amazon Aurora MySQL는 백업 파일을 찾기 위해 S3 버킷의 하위 폴더를 탐색하지 않습니다. [S3 버킷 접두사]로 확인된 폴더의 파일만 사용합니다. S3 버킷의 하위 폴더에 백업 파 일을 저장하는 경우, 파일이 저장되어 있는 폴더의 전체 경 로를 나타내는 접두사를 지정해야 합니다. 예를 들어 S3 버킷의 backups 하위 폴더에 백업 파일 을 저장했고 여러 세트의 백업 파일이 각각 자체 디렉터 리(gzip_backup1, gzip_backup2 등)에 들어 있는 경 우, gzip_backup1 폴더의 파일로 복원하려면 접두사 backups/gzip_backup1을 지정해야 할 것입니다. [IAM Role] Amazon Aurora MySQL가 S3에 대신 액세스할 수 있도록 승 인하기 위해 만든 IAM 역할을 선택합니다. IAM 역할을 아직 153

3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 옵션 수행할 작업 만들지 않았다면 [Create a New Role]을 선택하여 만들 수 있습니다. 4. [Next Step(다음 단계)]을 클릭합니다. 5. [Specify DB Details] 페이지에서 DB 클러스터 정보를 지정합니다. 다음 표는 DB 인스턴스 설정을 나타 냅니다. 옵션 수행할 작업 DB 인스턴스 클래스 DB 클러스터의 각 인스턴스 처리 및 메모리 요건을 정의 한 DB 인스턴스 클래스를 선택합니다. Aurora MySQL 는 db.r3.large, db.r3.xlarge, db.r3.2xlarge, db.r3.4xlarge 및 db.r3.8xlarge DB 인스턴스 클래스 를 지원합니다. 모든 DB 인스턴스 클래스 옵션에 대한 자세 한 내용은 Amazon RDS 설명서를 참조하십시오. 다중 AZ 배포 장애 조치 지원을 위해 다른 가용 영역에서 Aurora MySQL 복제본을 생성할지 여부를 결정합니다. 다중 가용 영역 작업 에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시 오. DB Instance Identifier DB 클러스터의 기본 인스턴스 이름을 입력합니다. 이 식별 자는 DB 클러스터의 기본 인스턴스의 엔드포인트 주소로 사 용됩니다. DB 인스턴스 식별자는 다음과 같은 제약 조건이 있습니다. 1~63자의 영숫자 문자 또는 하이픈으로 구성되어야 합니 다. 첫 번째 문자는 글자이어야 합니다. 하이픈으로 끝나거나 하이픈이 2개 연속으로 이어져서는 안 됩니다. 각 리전별로 AWS 계정 1개의 모든 DB 인스턴스는 고유해 야 합니다. Master Username 영숫자 문자를 사용해 DB 클러스터에 로그인하기 위 해 마스터 사용자 이름으로 사용할 이름을 입력합니다. 마스터 사용자 이름 계정에 기본적으로 부여되는 권한 은 다음과 같습니다. create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, create user, process, show databases, grant option. [Master Password] 마스터 사용자 암호로 인쇄 가능한 ASCII 문자(/, " 및 @ 제 외) 8-41자를 포함하는 암호를 입력합니다. [Specify DB Details] 페이지의 일반적인 모습은 다음과 같습니다. 154

3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 6. 마스터 암호를 확인한 후 [Next]를 선택합니다. 7. [Configure Advanced Settings] 페이지에서 Aurora MySQL DB 클러스터 설정을 추가로 사용자 지정할 수 있습니다. 다음 표는 DB 클러스터의 고급 설정을 나타냅니다. 옵션 수행할 작업 VPC DB 클러스터를 호스팅할 VPC를 선택합니다. Amazon RDS 에서 VPC를 생성하도록 하려면 [Create a New VPC]를 선택 합니다. 자세한 내용은 이번 주제에서 전반부 을(를) 참조하 십시오. [Subnet Group] DB 클러스터에 사용할 DB 서브넷 그룹을 선택합니다. Amazon RDS에서 DB 서브넷 그룹을 생성하게 하려면 [Create a New DB Subnet Group]을 선택합니다. 자세한 내 용은 이번 주제에서 전반부 을(를) 참조하십시오. Publicly Accessible DB 클러스터에 퍼블릭 IP 주소를 할당하려면 [Yes]를 선택 하고, 그렇지 않으면 [No]를 선택합니다. DB 클러스터의 인 스턴스는 퍼블릭과 프라이빗 DB 인스턴스를 모두 혼합하여 사용할 수 있습니다. 퍼블릭 액세스가 불가능하도록 DB 인 스턴스를 숨기는 방법에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시오. [Availability Zone] 특정 가용 영역의 지정 여부를 결정합니다. 가용 영역 작업 에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시 오. 155

3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 옵션 수행할 작업 VPC Security Group(s) VPC 보안 그룹을 한 개 이상 선택하여 DB 클러스터에 대 한 네트워크 액세스를 보안합니다. Amazon RDS에서 VPC 보안 그룹을 생성하게 하려면 [Create a New VPC Security Group]을 선택합니다. 자세한 내용은 이번 주제에서 전반부 을(를) 참조하십시오. DB Cluster Identifier 선택한 리전에 속한 계정 고유의 DB 클러스터 이름을 입력 합니다. 이 식별자는 DB 클러스터에 대한 클러스터 엔드포 인트 주소로 사용됩니다. 클러스터 엔드포인트에 대한 정보 는 Amazon RDS 설명서 를 참조하십시오. DB 클러스터 식별자는 다음과 같은 제약 조건이 있습니다. 1~63자의 영숫자 문자 또는 하이픈으로 구성되어야 합니 다. 첫 번째 문자는 글자이어야 합니다. 하이픈으로 끝나거나 하이픈이 2개 연속으로 이어져서는 안 됩니다. 리전별로 모든 DB 클러스터에 대해 AWS 계정당 고유해 야 합니다. Database Name 데이터베이스의 이름을 최대 8자의 영숫자 문자로 입력합니 다. 이름을 입력하지 않으면 Amazon RDS가 DB 클러스터에 서 생성하려고 하는 데이터베이스를 생성하지 않습니다. Database Port 애플리케이션과 유틸리티가 데이터베이스에 액세스할 때 사용할 포트를 지정합니다. Aurora MySQL DB 클러스터는 MySQL 포트, 3306이 기본 포트로 지정됩니다. 일부 기업에 서는 방화벽이 기본 MySQL 포트 연결을 차단하는 경우도 있습니다. 이처럼 기업 방화벽이 기본 포트를 차단할 경우 새로운 DB 클러스터에 다른 포트를 선택해야 합니다. Parameter Group 파라미터 그룹을 선택합니다. Aurora MySQL는 사용할 수 있는 기본 파라미터 그룹이 있거나, 고유의 파라미터 그룹을 생성할 수도 있습니다. 파라미터 그룹에 대한 자세한 내용은 Amazon RDS 설명서 를 참조하십시오. Option Group 옵션 그룹을 선택합니다. Aurora MySQL는 사용할 수 있는 기본 옵션 그룹이 있거나, 고유의 옵션 그룹을 생성할 수도 있습니다. 옵션 그룹에 대한 자세한 내용은 Amazon RDS 설명서 를 참조하십시오. [Enable Encryption] 이 DB 클러스터에 대해 비활성화되어 있는 암호화를 활성화 하려면[Yes]를 선택합니다. 자세한 내용은 Amazon RDS 설 명서를 참조하십시오. Priority 인스턴스의 장애 조치 우선 순위를 선택합니다. 값을 선택하 지 않을 경우 기본값은 tier-1입니다. 기본 인스턴스 장애로 부터 복원할 때 이 우선 순위에 따라 승격할 Aurora MySQL Replicas 순서가 결정됩니다. 자세한 내용은 Amazon RDS 설명서를 참조하십시오. [Backup Retention Period] Aurora MySQL가 데이터베이스 백업 사본을 보존하는 기간 을 1~35일로 선택합니다. 백업 사본은 데이터베이스를 특정 시점으로 정확히 복원(PITR)하는 데 사용됩니다. 156

3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 옵션 수행할 작업 Enable Enhanced Monitoring DB 클러스터가 실행되는 운영 체제에 대한 실시간 수집 지표를 활성화하려면 [Yes]를 선택합니다. 자세한 내용은 Amazon RDS 설명서를 참조하십시오. Granularity 이 옵션은 [Enable Enhanced Monitoring]을 [Yes]로 설정한 경우에만 사용할 수 있습니다. DB 클러스터에 대해 지표를 수집하는 간격(초)을 설정합니다. Auto Minor Version Upgrade MySQL DB 엔진의 마이너 버전 업그레이드가 있을 때 Aurora MySQL DB 클러스터가 자동으로 업그레이드를 실행 하도록 하려면 [Yes]를 선택합니다. [Auto Minor Version Upgrade] 옵션은 Amazon Aurora MySQL DB 클러스터에 대해 MySQL 엔진 마이너 버전으로 의 업그레이드에만 적용됩니다. 시스템 안정성 유지를 위한 정기 패치에는 적용되지 않습니다. 유지 관리 기간 시스템 유지 관리를 실행하는 기간을 주 단위로 선택합니다. [Configure Advanced Settings] 페이지의 일반적인 모습은 다음과 같습니다. 157

3단계: S3 버킷에서 Aurora MySQL DB 클러스터 복원 158

8. mysqldump를 사용하여 MySQL에서 Amazon Aurora MySQL로 마이그레이션 [Launch DB Instance]를 선택하여 Aurora MySQL DB 인스턴스를 실행한 다음 [Close]를 선택하여 마법 사를 닫습니다. Amazon RDS 콘솔의 DB 인터페이스 목록에 새 DB 인스턴스가 나타납니다. DB 인스턴스를 만들고 사 용할 준비가 될 때까지 DB 인스턴스의 상태는 [creating]입니다. 상태가 [available]로 변경되면 DB 클러 스터의 기본 인스턴스에 연결할 수 있습니다. DB 인스턴스 클래스와 할당된 저장소에 따라 새 인스턴스 를 사용할 수 있을 때까지 몇 분 정도 걸릴 수 있습니다. 새로 생성된 클러스터를 보려면 Amazon RDS 콘솔에서 [Clusters]를 선택합니다. 자세한 내용은 Amazon RDS 설명서를 참조하십시오. 클러스터의 포트와 엔드포인트를 기록합니다. 읽기 또는 쓰기 작업을 수행하는 애플리케이션은 모두 JDBC 및 ODBC 연결 문자열에 이 클러스터의 엔드포인트와 포트를 사용합니다. mysqldump를 사용하여 MySQL에서 Amazon Aurora MySQL로 마이그레이션 mysqldump 유틸리티로 데이터 덤프를 만들고 그 데이터를 기존 Amazon Aurora MySQL DB 클러스터로 가 져올 수 있습니다. Amazon Aurora MySQL는 MySQL과 호환되는 데이터베이스이므로 mysqldump 유틸리티를 사용하여 MySQL 또는 MariaDB 데이터베이스에서 기존의 Amazon Aurora MySQL DB 클러스터로 데이터를 복사할 수 있습니다. Amazon RDS MySQL DB 인스턴스에서 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션 다음과 같은 방법으로 Amazon RDS 스냅샷의 데이터를 Amazon Aurora MySQL DB 클러스터로 마이그레이 션(복사)할 수 있습니다. Note Amazon Aurora MySQL는 MySQL과 호환되기 때문에 MySQL 데이터베이스와 Amazon Aurora MySQL DB 클러스터 사이에 복제를 설정하면 MySQL 데이터베이스에서 데이터를 마이그레이션할 수 있습니다. 이때 MySQL 데이터베이스에서 실행되는 MySQL 버전은 5.5 이후를 사용하는 것이 좋 습니다. 159

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 Amazon RDS MySQL DB 인스턴스의 DB 스냅샷을 마이그레이션하면 Aurora MySQL DB 클러스터를 생성 할 수 있습니다. 새로운 DB 클러스터는 원본 Amazon RDS MySQL DB 인스턴스의 데이터로 채워집니다. 이 때 DB 스냅샷은 MySQL 5.6 기반 Amazon RDS DB 인스턴스를 통해 생성한 스냅샷이어야 합니다. DB 스냅샷을 마이그레이션하는 방법은 수동과 자동이 있습니다. DB 클러스터를 생성한 후에는 옵션으로 Aurora MySQL 복제본을 생성할 수도 있습니다. 일반적으로 다음 단계를 반드시 따라야 합니다. 1. Amazon Aurora MySQL DB 클러스터에 프로비저닝할 공간 크기를 결정합니다. 자세한 내용은 Amazon RDS 설명서를 참조하십시오. 2. 콘솔을 사용하여 Amazon RDS MySQL 5.6 인스턴스의 리전에 스냅샷을 생성합니다 3. DB 스냅샷이 DB 클러스터와 동일한 리전에 속하지 않을 때는 Amazon RDS 콘솔을 사용하여 DB 스냅샷 을 해당 리전으로 복사합니다. DB 스냅샷 복사에 대한 자세한 정보는 Amazon RDS 설명서 를 참조하십 시오. 4. 콘솔을 사용하여 DB 스냅샷을 마이그레이션한 후 MySQL 5.6의 원본 DB 인스턴스와 동일한 데이터베이 스로 Amazon Aurora MySQL DB 클러스터를 생성합니다. Warning Amazon RDS는 AWS 계정마다 스냅샷 사본을 한 번에 각 리전의 스냅샷 사본 하나로 제한합니다. 필요한 공간 크기 MySQL DB 인스턴스의 스냅샷을 Aurora MySQL DB 클러스터로 마이그레이션할 때는 Aurora MySQL에서 마이그레이션 전에 Amazon EBS(Amazon Elastic Block Store) 볼륨을 사용하여 스냅샷의 데이터 형식을 결 정합니다. 마이그레이션을 위해 데이터 형식을 결정할 때 공간이 추가로 필요한 경우가 간혹 있습니다. 따라 서 데이터를 DB 클러스터로 마이그레이션할 경우, 다음과 같은 지침과 제한 사항을 준수해야 합니다. Amazon Aurora MySQL에서 64TB까지 스토리지를 지원하기는 하지만 스냅샷을 Aurora MySQL DB 클러 스터로 마이그레이션하는 프로세스는 스냅샷의 EBS 볼륨 크기로 제한됩니다. 따라서 마이그레이션할 수 있는 스냅샷의 최대 크기는 6TB입니다. MyISAM 테이블이 아니거나 압축되지 않은 테이블은 최대 크기가 6TB로 제한됩니다. MyISAM 테이블이 있는 경우 테이블을 Aurora MySQL와 호환될 테이블로 변환하기 위한 볼륨 추가 공간이 Aurora MySQL에 필요합니다. 테이블이 압축된 경우에는 Aurora MySQL 클러스터 볼륨에 저장하기 전에 압축된 테이블을 확장하기 위한 볼륨 추가 공간이 Aurora MySQL에 필요합니다. 이 추가 공간 요구 사항 때문에 MySQL DB 인스턴스에서 마이그레이션하는 MyISAM 테이블과 압축된 테이블이 크기가 3TB를 넘지 않는지 확인해야 합니다. 데이터를 Amazon Aurora MySQL로 마이그레이션하는 데 필요한 공간 크기 줄이기 데이터를 Amazon Aurora MySQL로 마이그레이션하기 전에 데이터베이스 스키마 설정을 변경할 수 있습니 다. 이렇게 수정하는 이유는 다음과 같은 경우에 도움이 되기 때문입니다. 마이그레이션 프로세스의 속도를 높이고 싶은 경우 프로비저닝에 필요한 공간을 정확히 모르는 경우 데이터 마이그레이션을 시도했지만 프로비저닝 공간 부족으로 마이그레이션이 실패한 경우 데이터베이스를 Amazon Aurora MySQL로 마이그레이션하는 프로세스를 개선하려면 다음과 같은 설정 변 경이 가능합니다. 160

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 Important 이 업데이트는 반드시 프로덕션 인스턴스가 아닌 프로덕션 데이터베이스의 스냅샷에서 새롭게 복구된 DB 인스턴스에 실행해야 합니다. 그런 다음, 새로운 DB 인스턴스의 스냅샷에서 Amazon Aurora MySQL DB 클러스터로 데이터를 마이그레이션하면 프로덕션 데이터베이스의 서비스 중단 을 방지할 수 있습니다. 테이블 유형 제한 또는 지침 MyISAM 테이블 Amazon Aurora MySQL는 InnoDB 테이블만 지원합니다. 데이터베이 스에 MyISAM 테이블이 있으면 이 테이블은 Amazon Aurora MySQL로 마이그레이션하기 전에 변환해야 합니다. 이 때, 마이그레이션 절차 중 MyISAM에서 InnoDB로 변환하려면 추가 공간이 필요합니다. 공간이 부족할 가능성을 줄이거나 마이그레이션 프로세스 속도를 높 이려면 MyISAM 테이블을 마이그레이션하기 전에 모두 InnoDB 테 이블로 변환해야 합니다. 이렇게 변환되는 InnoDB 테이블의 크기는 Amazon Aurora MySQL에서 해당 테이블에 요구하는 크기와 동일합니 다. MyISAM 테이블을 InnoDB로 변환하는 명령은 다음과 같습니다. alter table <schema>.<table_name> engine=innodb, algorithm=copy; 압축된 테이블 Amazon Aurora MySQL에서는 압축된 테이블 (ROW_FORMAT=COMPRESSED로 만든 테이블)이 지원되지 않습니다. 공간이 부족할 가능성을 줄이거나 마이그레이션 프로세스 속도 를 높이려면 ROW_FORMAT을 DEFAULT, COMPACT, DYNAMIC 또는 REDUNDANT로 설정하여 압축된 테이블을 확장합니다. 자세한 내용은 https://dev.mysql.com/doc/refman/5.6/en/innodb-row-format.html을 참 조하십시오. 기존 MySQL DB 인스턴스에서 다음 SQL 스크립트를 사용하면 데이터베이스에 있는 MyISAM 테이블 또는 압축된 테이블의 목록을 표시할 수 있습니다. ----- This script examines a MySQL database for conditions that will block migrating the database into an Amazon Aurora MySQL DB. It needs to be run from an account that has read permission for the INFORMATION_SCHEMA database. -- Verify that this is a supported version of MySQL. select msg as `==> Checking current version of MySQL.` from ( select 'This script should be run on MySQL version 5.6. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as T where major_minor <> 506; -- List MyISAM and compressed tables. Include the table size. select concat(table_schema, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`, 161

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)" from INFORMATION_SCHEMA.TABLES where ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' ); 스크립트를 실행하면 다음 예제와 비슷한 결과를 출력합니다. 이 예제는 MyISAM에서 InnoDB로 변환해야 하는 두 개의 테이블을 보여 줍니다. 그 밖에도 출력 화면에는 각 테이블의 크기도 메가바이트(MB) 단위로 나 옵니다. +---------------------------------+------------------+ ==> MyISAM or Compressed Tables Approx size (MB) +---------------------------------+------------------+ test.name_table 2102.25 test.my_table 65.25 +---------------------------------+------------------+ 2 rows in set (0.01 sec) 콘솔을 사용한 DB 스냅샷 마이그레이션하기 Amazon RDS MySQL DB 인스턴스의 DB 스냅샷을 마이그레이션하면 Aurora MySQL DB 클러스터를 생성 할 수 있습니다. 새로운 DB 클러스터는 원본 Amazon RDS MySQL DB 인스턴스의 데이터로 채워집니다. 이 때 DB 스냅샷은 MySQL 5.6 기반 Amazon RDS DB 인스턴스를 통해 생성한 스냅샷이며 암호화되지 않아야 합니다. DB 스냅샷 생성에 대한 자세한 정보는 Amazon RDS 설명서 를 참조하십시오. 데이터를 찾고자 하는 AWS 리전에 DB 스냅샷이 없을 때는 Amazon RDS 콘솔을 사용하여 DB 스냅샷을 해 당 리전으로 복사합니다. DB 스냅샷 복사에 대한 자세한 정보는 Amazon RDS 설명서 를 참조하십시오. 콘솔을 사용하여 DB 스냅샷을 마이그레이션할 경우, 콘솔에서 DB 클러스터와 기본 인스턴스 모두를 생성하 는 데 필요한 작업이 따릅니다. AWS Key Management Service(AWS KMS) 암호화 키를 사용하여 새 Aurora MySQL DB 클러스터가 "저장 상태"에서 암호화되도록 선택할 수도 있습니다. 이 옵션은 암호화되지 않은 DB 스냅샷에만 가능합니다. 콘솔을 사용하여 MySQL 5.6 DB 스냅샷을 마이그레이션하는 방법 1. AWS Management 콘솔에 로그인한 다음 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔 을 엽니다. 162

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 2. [Snapshots]를 선택합니다. 3. [Snapshots] 페이지에서 Aurora MySQL DB 클러스터로 마이그레이션하려는 스냅샷을 선택합니다. 4. [Migrate Database]를 선택합니다. 5. [Migrate Database] 페이지에서 다음과 같이 값을 설정합니다. DB Instance Class:: 데이터베이스에 필요한 스토리지와 용량을 가진 DB 인스턴스 클래스를 선택합 니다(예: db.r3.large). Aurora MySQL 클러스터 볼륨은 데이터베이스의 데이터가 늘어날수록 자 동으로 증가하며 최대 크기는 64테라바이트(TB)입니다. 따라서 현재 스토리지 요구 사항에 맞는 DB 인스턴스 클래스를 선택해야 합니다. [DB Instance Identifier]: 선택한 리전의 계정에 대해 고유한 DB 클러스터 이름을 입력합니다. 이 식별 자는 DB 클러스터에 속한 인스턴스의 엔드포인트 주소로 사용됩니다. 선택한 리전 및 DB 엔진을 포 함(예: aurora-cluster1)하는 등 이름에 지능적 요소를 추가할 수도 있습니다. DB 인스턴스 식별자는 다음과 같은 제약 조건이 있습니다. 1~63자의 영숫자 문자 또는 하이픈으로 구성되어야 합니다. 첫 번째 문자는 글자이어야 합니다. 하이픈으로 끝나거나 하이픈이 2개 연속으로 이어져서는 안 됩니다. AWS 리전별로 AWS 계정 하나당 모든 DB 인스턴스는 고유해야 합니다. [VPC]: 기존 VPC가 있는 경우, VPC 식별자(예: vpc-a464d1c1)를 선택하여 해당 VPC를 Amazon Aurora MySQL DB 클러스터에 사용할 수 있습니다. 기존 VPC 사용에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시오. 기존 VPC가 없다면 [Create a new VPC]를 선택하여 Amazon RDS에서 VPC를 새로 생성하도록 할 수 있습니다. [Subnet Group]: 기존 서브넷 그룹이 있으면 해당 서브넷 그룹 식별자(예: gs-subnet-group1)를 선 택하여 Amazon Aurora MySQL DB 클러스터에 그 서브넷 그룹을 사용할 수 있습니다. 163

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 기존 서브넷 그룹이 없다면 [Create a new subnet group]을 선택하여 Amazon RDS에서 서브넷 그룹 을 새로 생성하도록 할 수 있습니다. [Publicly Accessible]: VPC에 있는 리소스만 DB 클러스터의 인스턴스에 액세스할 수 있도록 하려면 [No]를 선택합니다. 퍼블릭 네트워크에 있는 리소스가 DB 클러스터의 인스턴스에 액세스할 수 있도록 하려면 [Yes]를 선택합니다. 기본값은 [Yes]입니다. Note 퍼블릭 서브넷에서는 프로덕션 DB 클러스터가 필요 없을 수도 있습니다. 애플리케이션 서버 만 DB 클러스터에 액세스하기 때문입니다. DB 클러스터가 퍼블릭 서브넷에 필요 없는 경우 에는 [Publicly Accessible]을 [No]로 설정합니다. [Availability Zone]: Aurora MySQL DB 클러스터의 기본 인스턴스를 호스팅할 가용 영역을 선택합니 다. Amazon RDS에서 가용 영역을 선택하게 하려면 [No Preference]를 선택합니다. [Database Port]: DB 클러스터의 인스턴스에 연결할 때 사용할 기본 포트를 입력합니다. 기본값은 3306입니다. Note 기업 방화벽 뒤에 있어서 MySQL 기본 포트인 3306 같은 기본 포트에 액세스하지 못할 수 도 있습니다. 이런 경우에는 기업 방화벽이 허용하는 포트 값을 입력합니다. 나중에 Aurora MySQL DB 클러스터에 연결할 때도 필요하므로 이 포트 값을 기억해야 합니다. Enable Encryption: 새 Aurora MySQL DB 클러스터를 "저장 상태"에서 암호화하려면 [Yes]를 선택합 니다. [Yes]를 선택하면 [Master Key] 값으로 AWS KMS 암호화 키를 선택해야 합니다. [Auto Minor Version Upgrade]: MySQL DB 엔진의 부 버전 업그레이드가 있을 때 Aurora MySQL DB 클러스터가 자동으로 업그레이드를 실행하도록 하려면 [Yes]를 선택합니다. [Auto Minor Version Upgrade] 옵션은 Amazon Aurora MySQL DB 클러스터에 대해 MySQL 엔진 마 이너 버전으로의 업그레이드에만 적용됩니다. 시스템 안정성 유지를 위한 정기 패치에는 적용되지 않 습니다. 164

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 165

RDS MySQL 스냅샷을 Aurora MySQL로 마이그레이션 6. [Migrate]를 선택하여 DB 스냅샷을 마이그레이션합니다. 7. [Instances]를 선택한 다음 화살표 아이콘을 선택하여 DB 클러스터 세부 정보를 표시하고 마이그레이션 진행 상황을 모니터링합니다. 세부 정보 페이지를 보면 DB 클러스터의 기본 인스턴스에 연결하는 데 사 용할 클러스터 엔드포인트가 표시됩니다. Amazon Aurora MySQL DB 클러스터 연결에 대한 자세한 내 용은 Amazon RDS 설명서를 참조하십시오. 166