View a markdown version of this page

마이그레이션 옵션 세부 정보 - AWS 권장 가이드
1. 오프라인 백업 및 복원2. HADR 장애 조치3. 트랜잭션 로그 전송을 사용한 온라인 백업 및 복원4. Q Replication5. SQL 복제6. AWS DMS7. 서드 파티 복제 도구8. InfoSphere Optim 고성능 언로드 및 로드9. LOAD FROM CURSOR10. db2move스키마 마이그레이션

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

마이그레이션 옵션 세부 정보

다음 섹션에서는 이전 섹션의 다이어그램에 해당하는 옵션에 대한 세부 정보를 제공합니다.

1. 오프라인 백업 및 복원

네이티브 Db2 백업은 전체 데이터베이스를 백업합니다. 모든 호스트에 데이터베이스를 다시 생성(복원)하는 데 사용할 수 있습니다.

  • 오프라인 백업 및 복원은 데이터베이스를 온프레미스에서 AWS로 마이그레이션하는 가장 기본적인 방법입니다.

  • Db2 온프레미스 데이터베이스는 리틀 엔디안 플랫폼에 있어야 합니다.

  • 오프라인 백업을 수행하고, 백업 이미지를 Amazon S3로 전송하며, 백업에서 데이터베이스를 복원하려면 가동 중지 시간이 필요합니다.

2. HADR 장애 조치

Db2 고가용성 재해 복구(HADR)는 기본 데이터베이스라는 소스 데이터베이스에서 대기 데이터베이스라는 대상 데이터베이스로 데이터 변경 사항을 복제하여 고가용성 솔루션을 제공합니다. HADR은 최대 3개의 원격 대기 서버를 지원합니다.

  • HADR 장애 조치는 리틀 엔디안 플랫폼에서 실행되는 비DPF 인스턴스에 가장 적합합니다.

  • 소스 데이터베이스의 모든 트랜잭션은 로깅되어야 합니다.

  • HADR은 로그 스트리밍을 통해 소스 데이터베이스(기본 데이터베이스)에서 대상 데이터베이스(대기 데이터베이스)로의 데이터 변경 사항 복제를 지원합니다. HADR은 기본 데이터베이스와 대기 데이터베이스 간 통신에 TCP/IP를 사용합니다.

  • 전체 비즈니스 검증 후 가동 중단 없이 HADR을 중단할 수 있으며 온프레미스의 Db2 데이터베이스를 폐기할 수 있습니다.

3. 트랜잭션 로그 전송을 사용한 온라인 백업 및 복원

오프라인 백업 및 복원(옵션 1)과 달리 온라인 백업에는 소스 데이터베이스의 가동 중지 시간이 필요하지 않습니다. 소스 데이터베이스의 백업이 완료된 후 데이터베이스 트랜잭션 로그를 사용하여 대상 데이터베이스에 변경 사항을 적용합니다. 

  • 트랜잭션 로그 전송과 함께 백업 및 복원을 사용하는 방식이 리틀 엔디안 플랫폼에 있는 Db2 DPF 인스턴스에 가장 적합합니다. Db2 DPF 데이터베이스 크기는 큰 경향이 있으므로 정기 백업 및 복원(옵션 1)의 중단 시간이 12시간을 초과할 수 있습니다. HADR은 Db2 DPF 데이터베이스에서 지원되지 않습니다.

  • 소스 데이터베이스의 모든 트랜잭션은 로깅되어야 합니다.

  • 트랜잭션 로그 전송과 함께 백업 및 복원을 사용하여 중단 기간을 최소화할 수 있습니다.

  • 로그 전송을 통한 백업 및 복원은 비DPF 인스턴스에서도 사용할 수 있습니다. 그러나 장애 조치 옵션이 있는 HADR은 비DPF 인스턴스에서 더 쉽게 구현할 수 있습니다.

  • HADR 장애 조치(옵션 2)와 달리 역방향 동기화는 자동으로 수행되지 않습니다. 수동으로 설정합니다.

  • 전체 비즈니스 검증 후 온프레미스 Db2 데이터베이스를 폐기할 수 있습니다.

4. Q Replication

Q Replication은 IBM MQ 메시지 대기열을 사용하여 소스 데이터베이스와 대상 데이터베이스 사이에서 트랜잭션을 전송하는 지연 시간이 짧은 대용량 복제 솔루션입니다.

가장 일반적인 구성이 다음 다이어그램에 나와 있습니다.

IBM MQ 및 Site-to-Site VPN을 통해 EC2 기반 Db2에 연결하는 Db2 온프레미스를 보여주는 아키텍처 다이어그램.

IBM MQ는 Db2와 동일한 서버에서 실행됩니다. 두 개의 IBM MQ 인스턴스가 있습니다. 하나는 온프레미스 서버에 있고 다른 하나는 Amazon EC2에 있습니다. 캡처 프로그램은 소스 데이터베이스에서 실행됩니다. 트랜잭션 로그를 읽고 커밋된 변경 사항(삽입, 업데이트 또는 삭제)을 IBM MQ 온프레미스로 전송합니다. IBM MQ 온프레미스는 AWS Site-to-Site VPN 를 통해 Amazon EC2 기반 IBM MQ로 메시지를 보냅니다. 적용 프로그램은 대상 데이터베이스가 있는 EC2 인스턴스에서 실행됩니다. 먼저 테이블에서 전체 로드를 수행합니다. 그런 다음 Amazon EC2 기반 IBM MQ에서 변경 데이터 메시지를 읽고 대상 테이블에 적용합니다.

  • Db2 온프레미스는 소스이고 Amazon EC2 기반 Db2는 대상입니다. 두 데이터베이스 모두 온라인 상태입니다.

  • 온프레미스 Db2 데이터베이스는 모든 플랫폼 패밀리에 있을 수 있습니다.

  • 소스 데이터베이스의 모든 트랜잭션은 로깅되어야 합니다.

  • IBM MQ는 고성능, 고가용성 및 보장된 메시지 전송을 제공합니다.

  • 대상 데이터베이스에서 변경 사항이 커밋되면 IBM MQ에서 메시지가 삭제됩니다.

  • 양방향 복제는 폴백 옵션입니다. 그러나 추가 설정이 필요합니다.

  • 스키마 마이그레이션이 필요합니다. 자세한 내용은 스키마 마이그레이션 섹션을 참조하세요.

  • Q Replication에는 버전 11.5부터 추가 라이선스가 필요합니다.

  • 전환에 성공하면 복제를 중지하고 IBM MQ 인스턴스를 폐기합니다. 원하는 경우 온프레미스 데이터베이스를 폐기할 수도 있습니다.

5. SQL 복제

SQL Replication은 캡처, 적용, GUI 및 CLI 인터페이스, 알림 모니터와 같은 주요 구성 요소로 구성됩니다.

캡처 프로그램은 소스 데이터베이스에서 실행됩니다. 트랜잭션 로그를 읽고 커밋된 변경 사항(삽입, 업데이트 또는 삭제)을 변경된 데이터(CD) 테이블에 저장합니다. 각 소스 테이블에 대해 하나의 CD 테이블이 있습니다.

작업 단위의 Db2 커밋 지점은 작업 단위(UOW) 테이블에 저장됩니다. 사용자가 지정한 시점에 캡처 프로그램은 CD 및 UOW 테이블에 더 이상 필요하지 않은 데이터를 삭제합니다. 이를 프루닝이라고 합니다.

적용 프로그램은 대상 데이터베이스에서 실행됩니다. 소스 데이터베이스에 연결하고 CD 테이블에 저장된 데이터를 가져오며 가져온 행을 하나 이상의 유출 파일에 저장한 다음 대상 데이터베이스에 적용합니다.

  • 온프레미스 Db2 데이터베이스는 모든 플랫폼 패밀리에 있을 수 있습니다.

  • 소스 데이터베이스의 모든 트랜잭션은 로깅되어야 합니다.

  • 각 쓰기는 여러 번 실행되어야 하므로(기반 테이블, CD 테이블 및 UOW 테이블에서) 소스 데이터베이스의 오버헤드는 높은 것으로 간주됩니다. 일반적으로 쓰기 트래픽이 적은 시스템에는 SQL Replication을 사용하는 것이 좋습니다.

  • 양방향 복제는 폴백 옵션입니다. 그러나 추가 설정이 필요합니다.

  • 스키마 마이그레이션이 필요합니다. 자세한 내용은 스키마 마이그레이션 섹션을 참조하세요.

  • Q Replication과 달리 SQL Replication은 모든 Db2 에디션에 포함되어 있습니다. 추가 라이선스가 필요하지 않습니다.

  • 전환이 성공하면 복제를 중지하고 원하는 경우 온프레미스 데이터베이스를 폐기합니다.

6. AWS DMS

AWS Database Migration Service (AWS DMS)는 가동 중지 시간을 최소화하고 데이터 손실 없이 데이터베이스 및 분석 워크로드를 AWS 안전하게 로 이동하는 데 도움이 되는 관리형 마이그레이션 및 복제 서비스입니다.

  • AWS DMS 복제 인스턴스는 데이터베이스 마이그레이션을 수행합니다.

  • AWS DMS 소스 및 대상 엔드포인트를 사용하면 AWS DMS 인스턴스가 마이그레이션을 위해 소스 및 대상 데이터베이스를 연결할 수 있습니다.

  • AWS DMS 작업은 소스 엔드포인트에 연결하고 대상 엔드포인트에 데이터를 복제합니다.

  • 소스에서 대상으로 데이터가 정확히 마이그레이션되는지 확인하기 위해 데이터 검증을 활성화할 수 있습니다.

  • Amazon CloudWatch를 사용하여 로깅을 활성화할 수 있습니다.

7. 서드 파티 복제 도구

Infosphere CDC, Qlik Replicate, Precisely real-time CDC, Oracle GoldenGate와 같은 서드 파티 복제 도구는 Db2 for LUW의 데이터 마이그레이션을 대상으로 지원할 수 있습니다.

Qlik Replicate의 경우 Db2 for LUW를 Open Database Connectivity(ODBC) 대상으로 설정해야 합니다.

8. InfoSphere Optim 고성능 언로드 및 로드

InfoSphere Optim 고성능 언로드는 Db2 엔진을 우회하고 물리적 파일에서 직접 데이터를 언로드합니다.

  • Optim 고성능 언로드는 일반적으로 Db2 EXPORT 명령보다 몇 배 빠르게 Db2 데이터를 언로드할 수 있습니다. 디스크에서 직접 데이터 파일을 읽어 Db2 데이터베이스 관리자를 우회할 수 있습니다. 또한 제어 파일에서 여러 SELECT 문 또는 여러 파일 형식을 지정할 때 Db2 테이블을 여러 번 스캔하지 않습니다.

  • Optim 고성능 언로드는 백업 이미지에서 Db2 데이터를 언로드할 수도 있습니다. 즉, 다른 시스템에서 Optim 고성능 언로드를 실행하여 소스 데이터베이스 서버에 대한 성능 영향을 줄일 수 있습니다. 이는 대규모 기록 테이블 또는 테이블 파티션에 매우 유용합니다.

  • 데이터 출력 파일은 Db2 EC2 서버에서 액세스할 수 있는 Amazon S3로 전송할 수 있습니다.

  • Db2 로드는 Amazon S3에 대한 직접 액세스를 지원합니다. 예를 들어 다음 명령을 사용할 수 있습니다.

    db2 load from DB2REMOTE://<storage access alias>//<storage-path>/<file-name> replace into mytable

  • 스키마 마이그레이션이 필요합니다. 자세한 내용은 스키마 마이그레이션 섹션을 참조하세요.

  • InfoSphere Optim 고성능 언로드에는 추가 라이선스가 필요합니다.

9. LOAD FROM CURSOR

LOAD FROM CURSOR는 데이터를 파일로 언로드하지 않고 대상의 테이블을 소스로 사용하는 Db2 로드 유틸리티 옵션입니다.

  • 대상 데이터베이스에 페더레이션 링크를 생성하고 소스 데이터베이스에 연결해야 합니다.

  • 각 테이블에 대해 온프레미스 소스 테이블에 링크하는 별명이 생성됩니다. 많은 테이블이 관련된 경우 자동화 스크립트를 사용하여 별명 및 로드 문을 생성하는 것이 좋습니다.

  • LOAD FROM CURSOR는 스테이징 스토리지를 우회하며 병렬로 실행하도록 테이블을 서로 다른 스트림으로 분리할 수 있습니다. 로드가 많은 경우 네트워크 정체를 모니터링하는 것이 좋습니다.

  • 커서 정의에서 SELECT 문을 조작하여 전체 테이블을 선택하거나, 로드하지 않으려는 데이터를 건너뛰거나, 범위 기반 파티션 테이블을 여러 로드 문(예: 분기별 및 월별)으로 분할할 수 있습니다.

  • 스키마 마이그레이션이 필요합니다. 자세한 내용은 스키마 마이그레이션 섹션을 참조하세요.

10. db2move

db2move 명령은 EXPORT, IMPORT 또는 LOAD 모드에서 사용하면 Db2 데이터베이스 간에 많은 테이블을 쉽게 이동할 수 있습니다.

  • 스키마 마이그레이션이 필요합니다. 자세한 내용은 스키마 마이그레이션 섹션을 참조하세요.

  • db2move 명령을 사용하여 테이블의 데이터를 파일로 언로드하고 데이터를 Db2 테이블로 로드할 수 있습니다. db2move 유틸리티가 소스 데이터베이스의 모든 테이블을 다운로드하여 몇 개의 명령으로 대상 데이터베이스에 로드할 수 있기 때문에 유용합니다.

  1. LOB가 있는 소스 데이터베이스의 모든 테이블을 <lob-path>로 내보내려면 다음 명령을 실행합니다.

    db2move <db-name> export -l /<lob-path>/<lobfile>

  2. 파일을 Amazon S3로 전송합니다. 그러면 Db2 EC2 서버에서 파일을 검색할 수 있습니다.

  3. 모든 테이블을 대상 데이터베이스에 로드하려면 다음 명령을 실행합니다.

    db2move <db-name> load -l /<lob-path>/<lobfile>

스키마 마이그레이션

백업 및 복원, HADR 장애 조치, 로그 전송을 사용한 백업 및 복원(옵션 1~3)의 경우 스키마 마이그레이션이 데이터 마이그레이션에 포함됩니다. 추가 단계는 필요하지 않습니다.

논리적 복제 및 빅 엔디안 마이그레이션(옵션 4~10)의 경우 대상에서 데이터베이스와 스키마를 수동으로 생성해야 합니다. 마이그레이션 중에 소스의 스키마 변경은 피하는 것이 좋습니다. 실제 중단 시간이 훨씬 짧지만 마이그레이션에는 며칠이 걸릴 수 있습니다.

소스 서버에서 다음을 수행합니다.

  1. db2look 유틸리티를 사용하여 데이터 정의 언어(DDL)를 추출하고 출력을 db2look.ddl에 저장하세요.

  2. Amazon S3로 db2look.ddl을 전송하세요.

대상 서버에서 다음을 수행합니다.

  1. Amazon S3에서 db2look.ddl을 가져오세요.

  2. 외래 키 제약 조건을 제거하고 제약 조건 및 CREATE TRIGGER 문을 확인하세요. 이를 별도의 파일로 저장하세요. db2look 출력이 이러한 명령문을 그룹화하기 때문에 이 프로세스는 어렵지 않습니다.

  3. 외래 키 없이 데이터베이스와 스키마를 생성하고 제약 조건 및 트리거를 확인하세요.

  4. GENERATED ALWAYS가 GENERATED BY DEFAULT인 ID 열이 있는 테이블을 변환하세요.

  5. 논리적 복제 옵션 4, 5, 6, 7의 경우 복제를 시작하세요. 전체 로드가 완료된 후 외래 키를 다시 생성하고 제약 조건을 확인할 수 있습니다. 그러나 전환 전에 트리거를 다시 생성해야 합니다.

  6. 옵션 8, 9, 10의 경우 데이터 로드가 완료된 후 외래 키를 다시 생성하고 제약 조건 및 트리거를 확인하세요.

  7. 4단계에서 변경한 ID 열이 있는 테이블을 GENERATED ALWAYS로 되돌리세요.

  8. 전환 전에 ID 열과 시퀀스를 리시드하세요.