이 문서에서는 온프레미스 또는 기타 클라우드 환경에서 데이터베이스를 Google Cloud로 마이그레이션하는 클라우드 설계자를 위한 다운타임이 거의 0에 가까운 데이터베이스 마이그레이션의 개념, 원칙, 용어, 아키텍처를 소개합니다.
이 문서는 2부로 구성된 시리즈 중 1부입니다. 2부에서는 장애 시나리오를 포함하여 마이그레이션 프로세스를 설정하고 실행하는 방법을 설명합니다.
데이터베이스 마이그레이션은 데이터베이스 마이그레이션 서비스를 사용하여 하나 이상의 소스 데이터베이스에서 하나 이상의 대상 데이터베이스로 데이터를 마이그레이션하는 프로세스입니다. 마이그레이션이 완료되면 소스 데이터베이스의 데이터 세트가 대상 데이터베이스에 완전히 상주하지만 재구성될 수 있습니다. 그러면 소스 데이터베이스에 액세스한 클라이언트가 대상 데이터베이스로 전환되고 소스 데이터베이스가 종료됩니다.
다음 다이어그램은 이 데이터베이스 마이그레이션 프로세스를 보여줍니다.
이 문서에서는 아키텍처 측면에서 데이터베이스 마이그레이션을 설명합니다.
- 데이터베이스 마이그레이션과 관련된 서비스 및 기술
- 동종 데이터베이스 마이그레이션과 이기종 데이터베이스 마이그레이션의 차이점
- 마이그레이션 다운타임 허용 범위의 절충안 및 선택
- 마이그레이션 중에 예기치 않은 오류가 발생하는 경우 대체를 지원하는 설정 아키텍처
특정 데이터베이스 마이그레이션 기술을 설정하는 방법은 이 문서에서 설명하지 않습니다. 대신 기본, 개념, 원칙 측면에서 데이터베이스 마이그레이션에 대해 소개합니다.
아키텍처
다음 다이어그램은 일반적인 데이터베이스 마이그레이션 아키텍처를 보여줍니다.
데이터베이스 마이그레이션 서비스는 Google Cloud 내에서 실행되며 소스 데이터베이스와 대상 데이터베이스 모두에 액세스합니다. 여기에는 2가지 유형이 나와 있습니다. (a)는 온프레미스 데이터 센터 또는 원격 클라우드의 소스 데이터베이스에서 Spanner와 같은 관리형 데이터베이스로의 마이그레이션을 보여줍니다. (b)는 Compute Engine의 데이터베이스로의 마이그레이션을 보여줍니다.
대상 데이터베이스의 유형(관리형 및 비관리형)과 설정은 다르지만 데이터베이스 마이그레이션 아키텍처와 구성은 두 경우 모두 동일합니다.
용어
이 문서에서 가장 중요한 데이터 마이그레이션 관련 용어는 다음과 같습니다.
소스 데이터베이스: 하나 이상의 대상 데이터베이스로 마이그레이션할 데이터가 포함된 데이터베이스입니다.
대상 데이터베이스: 하나 이상의 소스 데이터베이스에서 마이그레이션된 데이터를 수신하는 데이터베이스입니다.
데이터베이스 마이그레이션: 마이그레이션이 완료된 후 소스 데이터베이스 시스템을 종료하기 위해 소스 데이터베이스에서 대상 데이터베이스로의 데이터 마이그레이션입니다. 전체 데이터 세트 또는 하위 집합이 마이그레이션됩니다.
동종 마이그레이션: 소스 데이터베이스와 대상 데이터베이스가 동일한 제공업체의 동일한 데이터베이스 관리 시스템인 경우 소스 데이터베이스에서 대상 데이터베이스로의 마이그레이션입니다.
이기종 마이그레이션: 소스 데이터베이스와 대상 데이터베이스가 서로 다른 제공업체의 서로 다른 데이터베이스 관리 시스템인 경우 소스 데이터베이스에서 대상 데이터베이스로의 마이그레이션입니다.
데이터베이스 마이그레이션 시스템: 소스 데이터베이스 및 대상 데이터베이스에 연결하고 소스 데이터베이스에서 대상 데이터베이스로 데이터 마이그레이션을 수행하는 소프트웨어 시스템 또는 서비스입니다.
데이터 마이그레이션 프로세스: 소스 데이터베이스에서 대상 데이터베이스로 데이터를 전송하여 전송 중에 데이터를 변환하기 위해 데이터 마이그레이션 시스템에서 실행하는 구성 또는 구현 프로세스입니다.
데이터베이스 복제: 소스 데이터베이스를 종료하지 않고 소스 데이터베이스에서 대상 데이터베이스로 데이터를 지속적으로 전송합니다. 데이터베이스 복제(데이터베이스 스트리밍이라고도 함)는 지속적인 프로세스입니다.
데이터베이스 마이그레이션 분류
다른 클래스에 속하는 다양한 유형의 데이터베이스 마이그레이션이 있습니다. 이 섹션에서는 이러한 클래스를 정의하는 기준을 설명합니다.
복제와 마이그레이션 비교
데이터베이스 마이그레이션에서는 소스 데이터베이스에서 대상 데이터베이스로 데이터를 이동합니다. 데이터가 완전히 마이그레이션되면 소스 데이터베이스를 삭제하고 클라이언트 액세스를 대상 데이터베이스로 리디렉션합니다. 대상 데이터베이스에 예기치 않은 문제가 발생하는 경우 소스 데이터베이스를 대체 조치로 유지하는 경우가 있습니다. 그러나 대상 데이터베이스가 안정적으로 작동하면 결국 소스 데이터베이스를 삭제하게 됩니다.
반대로 데이터베이스 복제를 사용하면 소스 데이터베이스를 삭제하지 않고 소스 데이터베이스에서 대상 데이터베이스로 데이터를 계속 전송할 수 있습니다. 데이터베이스 복제를 데이터베이스 스트리밍이라고도 합니다. 정의된 시작 시간은 있지만 일반적으로 정의된 완료 시간은 없습니다. 복제가 중지되거나 마이그레이션될 수 있습니다.
이 문서에서는 데이터베이스 마이그레이션만 설명합니다.
부분 마이그레이션과 전체 마이그레이션 비교
데이터베이스 마이그레이션은 데이터의 완전하고 일관된 전송입니다. 전송될 초기 데이터 세트를 전체 데이터베이스 또는 부분 데이터베이스(데이터베이스의 데이터 하위 집합)와 그 이후에 소스 데이터베이스 시스템에서 커밋된 모든 변경사항으로 정의합니다.
이기종 마이그레이션과 동종 마이그레이션 비교
동종 데이터베이스 마이그레이션은 동일한 데이터베이스 기술의 소스 데이터베이스와 대상 데이터베이스 간의 마이그레이션입니다. 예를 들어 MySQL 데이터베이스에서 MySQL 데이터베이스로의 마이그레이션이나 Oracle® 데이터베이스에서 Oracle 데이터베이스로의 마이그레이션이 여기에 해당합니다. 동종 마이그레이션에는 PostgreSQL과 같은 자체 호스팅 데이터베이스 시스템에서 PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB와 같은 관리형 버전으로의 마이그레이션도 포함됩니다.
동종 데이터베이스 마이그레이션에서는 소스 데이터베이스와 대상 데이터베이스의 스키마가 동일할 가능성이 높습니다. 스키마가 다를 경우 마이그레이션 중에 소스 데이터베이스의 데이터를 변환해야 합니다.
이기종 데이터베이스 마이그레이션은 다양한 데이터베이스 기술의 소스 데이터베이스와 대상 데이터베이스 간의 마이그레이션입니다. 예를 들어 Oracle 데이터베이스에서 Spanner로의 마이그레이션이 여기에 해당합니다. 이기종 데이터베이스 마이그레이션은 동일한 데이터 모델 간(예: 관계형에서 관계형으로) 또는 다른 데이터 모델 간(예: 관계형에서 키-값 모델로)에 진행될 수 있습니다.
다른 데이터베이스 기술 간에 마이그레이션할 때 반드시 다른 데이터 모델이 필요하지는 않습니다. 예를 들어 Oracle, MySQL, PostgreSQL, Spanner는 모두 관계형 데이터 모델을 지원합니다. 하지만 Oracle, MySQL, PostgreSQL과 같은 다중 모델 데이터베이스는 서로 다른 데이터 모델을 지원합니다. 데이터 모델이 소스 데이터베이스와 대상 데이터베이스에서 동일하기 때문에 거의 또는 전혀 변환하지 않고도 다중 모델 데이터베이스에 JSON 문서로 저장된 데이터를 MongoDB로 마이그레이션할 수 있습니다.
동종 마이그레이션과 이기종 마이그레이션의 차이점은 데이터베이스 기술을 기반으로 하지만, 관련된 데이터베이스 모델을 기반으로 분류할 수도 있습니다. 예를 들어 둘 모두 관계형 데이터 모델을 사용하면 Oracle 데이터베이스에서 Spanner로의 마이그레이션은 동종 마이그레이션이고, Oracle에 JSON 객체로 저장된 데이터가 Spanner에서 관계형 모델로 마이그레이션되는 경우에는 이기종 마이그레이션입니다.
데이터 모델별로 마이그레이션을 분류하면 관련된 데이터베이스 시스템에 따라 분류할 때보다 데이터를 마이그레이션하는 데 필요한 복잡성과 노력을 더 정확하게 표현할 수 있습니다. 그러나 업계에서 일반적으로 사용되는 분류 방법은 관련된 데이터베이스 시스템을 기반으로 하므로 나머지 섹션은 이러한 차이점을 기반으로 합니다.
마이그레이션 다운타임: 0 vs. 최소 vs. 상당 시간
데이터 세트를 소스 데이터베이스에서 대상 데이터베이스로 마이그레이션한 후 클라이언트 액세스를 대상 데이터베이스로 전환하고 소스 데이터베이스를 삭제합니다.
소스 데이터베이스에서 대상 데이터베이스로 클라이언트를 전환하는 프로세스는 다음과 같습니다.
- 계속 처리를 진행하기 위해 클라이언트가 소스 데이터베이스에 대한 기존 연결을 종료하고 대상 데이터베이스에 대한 새 연결을 만들어야 합니다. 이상적으로는 연결을 종료하는 것이 가장 좋습니다. 즉, 진행 중인 트랜잭션을 불필요하게 롤백하지 않아도 됩니다.
- 소스 데이터베이스에서 연결을 종료한 후에는 모든 변경사항이 캡처되도록 소스 데이터베이스에서 대상 데이터베이스로 나머지 변경 사항을 마이그레이션해야 합니다(드레이닝).
- 대상 데이터베이스가 제대로 작동하고 클라이언트가 정의된 서비스 수준 목표(SLO) 내에서 작동하는지 테스트해야 할 수 있습니다.
마이그레이션에서 클라이언트가 진정한 제로 다운타임을 달성하는 것은 불가능합니다. 클라이언트가 요청을 처리할 수 없는 경우가 있습니다. 하지만 클라이언트가 여러 가지 방법으로 요청을 처리할 수 없는 기간을 최소화할 수 있습니다(제로에 가까운 다운타임).
- 클라이언트를 전환하기 상당 시간 전에 대상 데이터베이스에 대해 읽기 전용 모드로 테스트 클라이언트를 시작할 수 있습니다. 이 방법을 사용하면 테스트가 마이그레이션과 동시에 이루어집니다.
- 전환 기간에 가까워지면 마이그레이션되는 데이터 양(즉, 소스 데이터베이스와 대상 데이터베이스 간 이동)을 최대한 작게 구성할 수 있습니다. 이 단계는 소스 데이터베이스와 대상 데이터베이스 간의 차이가 적기 때문에 드레이닝 시간이 단축됩니다.
- 대상 데이터베이스에서 작업하는 새 클라이언트를 소스 데이터베이스에서 작업하는 기존 클라이언트와 동시에 시작할 수 있는 경우, 모든 데이터가 드레이닝되는 즉시 새 클라이언트를 실행할 준비가 되므로 전환 시간을 단축할 수 있습니다.
전환하는 동안 제로 다운타임을 달성하는 것은 비현실적이지만 진행 중인 데이터 마이그레이션과 동시에 활동을 시작하여 다운타임을 최소화할 수 있습니다.
일부 데이터베이스 마이그레이션 시나리오에서는 상당한 다운타임이 허용됩니다. 일반적으로 이러한 허용은 비즈니스 요구사항에 기인합니다. 이 경우 방법을 간소화할 수 있습니다. 예를 들어 동종 데이터베이스 마이그레이션을 사용하면 데이터를 수정할 필요가 없습니다. 내보내기 및 가져오기 또는 백업 및 복원이 완벽한 방법입니다. 이기종 마이그레이션을 사용하면 데이터베이스 마이그레이션 시스템이 마이그레이션 중에 소스 데이터베이스 시스템의 업데이트를 처리할 필요가 없습니다.
하지만 데이터베이스 마이그레이션 및 후속 테스트를 수행하기에 충분히 긴 다운타임을 허용해야 합니다. 이 다운타임을 명확하게 설정할 수 없거나 허용할 수 없을 정도로 긴 경우 다운타임을 최소화하는 마이그레이션을 계획해야 합니다.
데이터베이스 마이그레이션 카디널리티
대부분의 경우 단일 소스 데이터베이스와 단일 대상 데이터베이스 간에 데이터베이스 마이그레이션이 수행됩니다. 이러한 경우 카디널리티는 1:1(직접 매핑)입니다. 즉, 소스 데이터베이스는 대상 데이터베이스를 변경하지 않고 마이그레이션됩니다.
그러나 직접 매핑이 유일한 방법은 아닙니다. 다른 카디널리티에는 다음이 포함됩니다.
- 통합(n:1). 통합에서는 여러 소스 데이터베이스에서 더 적은 수의 대상 데이터베이스(또는 하나의 대상)로 데이터를 마이그레이션합니다. 이 방법을 사용하면 데이터베이스 관리를 간소화하거나 확장할 수 있는 대상 데이터베이스를 사용할 수 있습니다.
- 배포(1:n). 배포에서는 하나의 소스 데이터베이스에서 여러 대상 데이터베이스로 데이터를 마이그레이션합니다. 예를 들어 리전 데이터가 포함된 대규모 중앙 집중식 데이터베이스를 여러 리전 대상 데이터베이스로 마이그레이션해야 하는 경우 이 방법을 사용할 수 있습니다.
- 재배포(n:m). 재배포에서는 여러 소스 데이터베이스에서 여러 대상 데이터베이스로 데이터를 마이그레이션합니다. 크기가 매우 다른 샤드가 포함된 샤딩된 소스 데이터베이스가 있는 경우 이 방법을 사용할 수 있습니다. 재분배는 샤드를 나타내는 여러 대상 데이터베이스에 샤딩된 데이터를 균등하게 배포합니다.
데이터베이스 마이그레이션은 단순히 데이터를 마이그레이션하는 것 외에도 데이터베이스 아키텍처를 다시 설계하고 구현할 수 있는 기회를 제공합니다.
마이그레이션 일관성
데이터베이스 마이그레이션은 일관적일 것으로 기대합니다. 마이그레이션 컨텍스트에서 일관성은 다음을 의미합니다.
- 전체. 마이그레이션하도록 지정된 모든 데이터가 실제로 마이그레이션됩니다. 지정된 데이터는 소스 데이터베이스의 모든 데이터 또는 데이터의 하위 집합일 수 있습니다.
- 중복 없음. 각 데이터는 한 번만 마이그레이션됩니다. 대상 데이터베이스에 중복 데이터가 마이그레이션되지 않습니다.
- 정렬됨. 소스 데이터베이스의 데이터 변경사항은 소스 데이터베이스에서 변경된 사항과 동일한 순서로 대상 데이터베이스에 적용됩니다. 이러한 측면은 데이터 일관성을 보장하는 데 중요합니다.
마이그레이션 일관성을 설명하는 또 다른 방법은 마이그레이션이 완료된 후 소스 데이터베이스와 대상 데이터베이스 간의 데이터 상태가 동일하다는 것입니다. 예를 들어 관계형 데이터베이스의 직접 매핑이 포함된 동종 마이그레이션에서는 소스 데이터베이스와 대상 데이터베이스에 동일한 테이블과 행이 있어야 합니다.
마이그레이션 일관성을 설명하는 이 방법은 모든 데이터 마이그레이션이 소스 데이터베이스의 트랜잭션을 대상 데이터베이스에 순차적으로 적용하는 것을 기반으로 하지 않으므로 중요합니다. 예를 들어 소스 데이터베이스를 백업하고 백업을 사용하여 소스 데이터베이스 콘텐츠를 대상 데이터베이스에 복원할 수 있습니다(현저한 다운타임이 있는 경우).
활성-수동 마이그레이션과 활성-활성 마이그레이션 비교
중요한 차이점은 소스 데이터베이스와 대상 데이터베이스가 모두 쿼리 처리를 수정할 수 있는지 여부입니다. 활성-수동 데이터베이스 마이그레이션에서는 마이그레이션 중에 소스 데이터베이스를 수정할 수 있지만 대상 데이터베이스는 읽기 전용 액세스만 허용합니다.
활성-활성 마이그레이션은 마이그레이션 중에 소스 데이터베이스와 대상 데이터베이스 모두에 쓰기를 지원합니다. 이러한 유형의 마이그레이션에서는 충돌이 발생할 수 있습니다. 예를 들어 소스 데이터베이스와 대상 데이터베이스의 동일한 데이터 항목이 의미상 서로 충돌하도록 수정되는 경우 충돌을 해결하려면 충돌 해결 규칙을 실행해야 할 수 있습니다.
활성-활성 마이그레이션에서는 충돌 해결 규칙을 사용하여 모든 데이터 충돌을 해결할 수 있어야 합니다. 그렇지 않으면 데이터 불일치가 발생할 수 있습니다.
데이터베이스 마이그레이션 아키텍처
데이터베이스 마이그레이션 아키텍처는 데이터베이스 마이그레이션을 실행하는 데 필요한 다양한 구성요소를 설명합니다. 이 섹션에서는 일반적인 배포 아키텍처를 소개하고 데이터베이스 마이그레이션 시스템을 별도의 구성요소로 취급합니다. 또한 데이터 마이그레이션을 지원하는 데이터베이스 관리 시스템의 기능과 많은 사용 사례에 중요한 비기능적 속성에 대해서도 설명합니다.
배포 아키텍처
데이터베이스 마이그레이션은 온프레미스 또는 다른 클라우드와 같은 모든 환경에 있는 소스 데이터베이스와 대상 데이터베이스 간에 발생할 수 있습니다. 각 소스 데이터베이스와 대상 데이터베이스는 서로 다른 환경에 있을 수 있습니다. 모두 동일한 환경에 배치할 필요는 없습니다.
다음 다이어그램은 여러 환경이 포함된 배포 아키텍처의 예시입니다.
DB1과 DB2는 두 개의 소스 데이터베이스이고 DB3과 Spanner는 대상 데이터베이스입니다. 이 데이터베이스 마이그레이션에는 2개의 클라우드와 2개의 온프레미스 데이터 센터가 포함됩니다. 화살표는 호출 관계를 나타냅니다. 데이터베이스 마이그레이션 서비스는 모든 소스 및 대상 데이터베이스의 인터페이스를 호출합니다.
여기에서 설명하지 않는 특별한 경우는 데이터베이스에서 동일한 데이터베이스로 데이터를 마이그레이션하는 것입니다. 이 특별한 경우는 데이터 마이그레이션에만 데이터베이스 마이그레이션 시스템을 사용하고 여러 환경에서 서로 다른 시스템 간에 데이터를 마이그레이션하는 데는 사용하지 않습니다.
기본적으로 데이터베이스 마이그레이션에는 다음 세 가지 방법이 있습니다.
데이터베이스 마이그레이션 시스템
데이터베이스 마이그레이션 시스템은 데이터베이스 마이그레이션의 핵심입니다. 시스템은 소스 데이터베이스에서 실제 데이터 추출을 실행하고, 데이터를 대상 데이터베이스로 전송하고, 필요에 따라 전송 중에 데이터를 수정합니다. 이 섹션에서는 일반적인 데이터베이스 마이그레이션 시스템 기능에 대해 설명합니다. 데이터베이스 마이그레이션 시스템 예시에는 Database Migration Service, Striim, Debezium, tcVision, Cloud Data Fusion이 있습니다.
데이터 마이그레이션 프로세스
데이터베이스 마이그레이션 시스템의 핵심 기술 구성 요소는 데이터 마이그레이션 프로세스입니다. 데이터 마이그레이션 프로세스는 개발자가 지정하며, 데이터가 추출되는 소스 데이터베이스, 데이터가 마이그레이션되는 대상 데이터베이스, 마이그레이션 중에 데이터에 적용되는 데이터 수정 로직을 정의합니다.
하나 이상의 데이터 마이그레이션 프로세스를 지정하고 마이그레이션 요구에 따라 순차적으로 또는 동시에 실행할 수 있습니다. 예를 들어 독립적인 데이터베이스를 마이그레이션하면 해당 데이터 마이그레이션 프로세스가 동시에 실행될 수 있습니다.
데이터 추출 및 삽입
데이터베이스 시스템의 변경사항(삽입, 업데이트, 삭제)은 두 가지 방법, 즉 트랜잭션 로그를 기반으로 한 데이터베이스 지원 변경 데이터 캡처(CDC)와 데이터베이스 관리 시스템의 쿼리 인터페이스를 사용하는 데이터 자체의 차등 쿼리를 사용하여 삭제할 수 있습니다.
트랜잭션 로그 기반 CDC
데이터베이스 지원 CDC는 쿼리 인터페이스와 별도의 데이터베이스 관리 기능을 기반으로 합니다. 한 가지 방법은 트랜잭션 로그(예: MySQL의 바이너리 로그)를 기반으로 합니다. 트랜잭션 로그에는 데이터의 변경 사항이 올바른 순서로 포함되어 있습니다. 트랜잭션 로그는 연속 읽기가 지원되므로 모든 변경사항을 관찰할 수 있습니다. 데이터베이스 마이그레이션의 경우 CDC를 통해 각 변경사항이 표시되고 이후에 손실 없이 올바른 순서로 대상 데이터베이스로 마이그레이션되므로 이 로깅은 매우 유용합니다.
CDC는 데이터베이스 관리 시스템에서 변경사항을 캡처하는 데 선호되는 방법입니다. CDC는 데이터베이스 자체에 내장되어 있으며 시스템에 대한 부하 영향이 가장 적습니다.
차등 쿼리
모든 변경사항을 올바른 순서로 관찰할 수 있는 데이터베이스 관리 시스템 기능이 없는 경우 차등 쿼리를 대안으로 사용할 수 있습니다. 이 방법에서는 데이터베이스의 각 데이터 항목에 타임스탬프 또는 시퀀스 번호가 포함된 추가 속성이 있습니다. 데이터 항목이 변경될 때마다 변경 타임스탬프가 추가되거나 시퀀스 번호가 증가합니다. 폴링 알고리즘은 마지막 실행 이후 또는 사용한 마지막 시퀀스 번호 이후의 모든 데이터 항목을 읽습니다. 폴링 알고리즘에서 변경사항이 파악되면 현재 시간 또는 시퀀스 번호를 내부 상태에 기록한 다음 변경사항을 대상 데이터베이스에 전달합니다.
이 방법은 삽입 및 업데이트에 문제 없이 작동하지만 삭제는 데이터베이스에서 데이터 항목을 삭제하므로 삭제는 신중하게 설계해야 합니다. 데이터가 삭제된 후에는 폴러가 삭제되었음을 감지할 수 없습니다. 데이터가 삭제되었음을 나타내는 추가 상태 필드(논리 삭제 플래그)를 사용하여 삭제를 구현합니다. 또는 삭제된 데이터 항목을 하나 이상의 테이블로 수집할 수 있으며, 폴러는 해당 테이블에 액세스하여 삭제가 발생했는지 확인합니다.
차등 쿼리에 대한 변형은 변경 데이터 캡처를 참조하세요.
차등 쿼리는 스키마 및 기능 변경을 포함하므로 가장 선호되지 않는 방법입니다. 데이터베이스를 쿼리하면 클라이언트 로직 실행과 관련이 없는 쿼리 로드도 추가됩니다.
어댑터 및 에이전트
데이터베이스 마이그레이션 시스템은 소스 및 데이터베이스 시스템에 액세스해야 합니다. 어댑터는 액세스 기능을 캡슐화하는 추상화입니다. 가장 간단한 형태의 어댑터는 JDBC를 지원하는 대상 데이터베이스에 데이터를 삽입하기 위한 JDBC 드라이버일 수 있습니다. 더 복잡한 경우 어댑터는 대상 환경(에이전트라고도 함)에서 실행되어 로그 파일과 같은 기본 제공 데이터베이스 인터페이스에 액세스합니다. 이보다 더 복잡한 경우 어댑터 또는 에이전트는 다른 소프트웨어 시스템과 인터페이싱하여 결과적으로 데이터베이스에 액세스합니다. 예를 들어 에이전트가 Oracle GoldenGate에 액세스하면 결과적으로 Oracle 데이터베이스에 액세스합니다.
소스 데이터베이스에 액세스하는 어댑터 또는 에이전트는 데이터베이스 시스템의 설계에 따라 CDC 인터페이스 또는 차등 쿼리 인터페이스를 구현합니다. 두 경우 모두 어댑터 또는 에이전트가 데이터베이스 마이그레이션 시스템에 대한 변경사항을 제공하며, 변경사항이 CDC 또는 차등 쿼리에 의해 캡처된 경우 데이터베이스 마이그레이션 시스템은 인식되지 않습니다.
데이터 수정
일부 사용 사례에서는 소스 데이터베이스에서 수정되지 않은 대상 데이터베이스로 데이터가 마이그레이션됩니다. 이러한 직접 마이그레이션은 일반적으로 동종 간에 이루어집니다.
그러나 많은 사용 사례에서는 마이그레이션 프로세스 중에 데이터를 수정해야 합니다. 일반적으로 스키마에 차이가 있거나 데이터 값에 차이가 있거나 전환 중에 데이터를 정리할 수 있는 경우 수정이 필요합니다.
다음 섹션에서는 데이터 변환, 데이터 보강 또는 상관관계, 데이터 축소 또는 필터링 등 데이터 마이그레이션에 필요할 수 있는 몇 가지 수정 유형에 대해 설명합니다.
데이터 변환
데이터 변환은 소스 데이터베이스의 일부 또는 전체 데이터 값을 변환합니다. 몇 가지 예를 들면 다음과 같습니다.
- 데이터 유형 변환. 소스 데이터베이스와 대상 데이터베이스 간의 데이터 유형이 동일하지 않은 경우가 있습니다. 이러한 경우 데이터 유형 변환은 유형 변환 규칙에 따라 소스 값을 대상 값으로 변환합니다. 예를 들어 소스의 타임스탬프 유형이 대상의 문자열로 변환될 수 있습니다.
- 데이터 구조 변환. 데이터 구조 변환은 동일한 데이터베이스 모델의 구조 또는 다른 데이터베이스 모델 간의 구조를 수정합니다. 예를 들어 관계형 시스템에서는 소스 테이블 하나를 두 개의 대상 테이블로 분할하거나 여러 소스 테이블을 조인을 사용하여 하나의 대상 테이블로 비정규화할 수 있습니다. 소스 데이터베이스의 1:n 관계는 Spanner에서 상위/하위 관계로 변환될 수 있습니다. 소스 문서 데이터베이스 시스템의 문서는 대상 시스템의 관계형 행 집합으로 분할될 수 있습니다.
- 데이터 값 변환. 데이터 값 변환은 데이터 유형 변환과 별개입니다. 데이터 값 변환은 데이터 유형을 변경하지 않고 값을 변경합니다. 예를 들어 현지 시간대는 UTC(협정 세계시)로 변환됩니다. 또는 문자열로 표시된 짧은 우편번호(5자리)는 긴 우편번호(5자리 뒤에 대시 뒤에 4자리, ZIP+4라고도 함)로 변환됩니다.
데이터 보강 및 상관관계
데이터 변환은 추가 관련 참조 데이터를 참조하지 않고 기존 데이터에 적용됩니다. 데이터 보강을 사용하면 소스 데이터가 대상 데이터베이스에 저장되기 전에 추가 데이터를 쿼리하여 소스 데이터를 보강합니다.
- 데이터 상관관계. 소스 데이터의 상관관계를 파악할 수도 있습니다. 예를 들어 두 소스 데이터베이스에 있는 두 테이블의 데이터를 결합할 수 있습니다. 예를 들어 하나의 대상 데이터베이스에서 고객 데이터와 주문 데이터가 서로 다른 두 개의 소스 데이터베이스에서 발생하는 모든 공개, 완료, 취소 주문에 연결할 수 있습니다.
- 데이터 보강. 데이터 보강은 참조 데이터를 추가합니다. 예를 들어 우편번호에 해당하는 도시 이름을 추가하여 우편번호만 포함된 레코드를 보강할 수 있습니다. 우편번호와 해당 도시 이름이 포함된 참조 테이블은 이 사용 사례에 액세스하는 정적 데이터 세트입니다. 참조 데이터는 동적일 수도 있습니다. 예를 들어 모든 알려진 고객 목록을 참조 데이터로 사용할 수 있습니다.
데이터 축소 및 필터링
데이터 변환의 또 다른 유형은 소스 데이터를 대상 데이터베이스로 마이그레이션하기 전에 축소하거나 필터링하는 것입니다.
- 데이터 축소. 데이터 축소는 데이터 항목에서 속성을 삭제합니다. 예를 들어 데이터 항목에 우편번호가 있으면 다시 계산할 수 있거나 더 이상 필요하지 않으므로 해당 도시 이름이 필요하지 않을 수 있으므로 삭제됩니다. 도시 이름이 시간에 따라 변경되더라도 사용자가 입력한 도시 이름을 기록해야 하므로 이 정보가 보관되는 경우가 있습니다.
- 데이터 필터링. 데이터 필터링은 데이터 항목을 모두 삭제합니다. 예를 들어 취소된 모든 주문이 삭제되고 대상 데이터베이스로 이전되지 않을 수 있습니다.
데이터 조합 또는 재조합
데이터가 다른 소스 데이터베이스에서 다른 대상 데이터베이스로 마이그레이션되는 경우 소스 데이터베이스와 대상 데이터베이스 간에 데이터를 다르게 결합해야 할 수 있습니다.
고객과 주문이 서로 다른 두 개의 소스 데이터베이스에 저장되어 있다고 가정해 보겠습니다. 한 소스 데이터베이스에는 모든 주문이 포함되고 두 번째 소스 데이터베이스에는 모든 고객이 포함됩니다. 마이그레이션 후 고객과 주문은 단일 대상 데이터베이스가 아니라 각각 데이터 파티션이 포함된 여러 대상 데이터베이스의 단일 대상 데이터베이스 스키마 내에 1:n 관계로 저장됩니다. 각 대상 데이터베이스는 리전을 나타내며 해당 리전에 있는 모든 고객과 주문을 포함합니다.
대상 데이터베이스 주소 지정
대상 데이터베이스가 하나만 있는 경우가 아니라면 마이그레이션되는 각 데이터 항목을 올바른 대상 데이터베이스로 전송해야 합니다. 대상 데이터베이스를 처리하는 몇 가지 방법은 다음과 같습니다.
- 스키마 기반 주소 지정. 스키마 기반 주소 지정은 스키마를 기반으로 대상 데이터베이스를 결정합니다. 예를 들어 고객 컬렉션의 모든 데이터 항목 또는 고객 테이블의 모든 행은 이 정보가 여러 소스 데이터베이스에 배포되더라도 고객 정보를 저장하는 동일한 대상 데이터베이스로 마이그레이션됩니다.
- 콘텐츠 기반 라우팅. 콘텐츠 기반 라우팅(예: 콘텐츠 기반 라우터 사용)은 데이터 값을 기반으로 대상 데이터베이스를 결정합니다. 예를 들어 중남미 리전에 있는 모든 고객은 해당 리전을 나타내는 특정 대상 데이터베이스로 마이그레이션됩니다.
데이터베이스 마이그레이션 시 두 가지 유형의 주소를 동시에 사용할 수 있습니다. 사용된 주소 유형에 관계없이 대상 데이터베이스에 올바른 스키마가 있어야 데이터 항목이 저장됩니다.
전송 중인 데이터의 지속성
데이터베이스 마이그레이션 시스템 또는 데이터베이스 마이그레이션 시스템을 실행하는 환경은 마이그레이션 중에 장애가 발생할 수 있으며 전송 중인 데이터가 손실될 수 있습니다. 장애가 발생하면 데이터베이스 마이그레이션 시스템을 다시 시작해야 하고 소스 데이터베이스에 저장된 데이터를 일관되고 완전하게 대상 데이터베이스로 마이그레이션해야 합니다.
복구의 일환으로 데이터베이스 마이그레이션 시스템은 마지막으로 마이그레이션된 데이터 항목을 식별하여 소스 데이터베이스에서 추출을 시작할 위치를 결정해야 합니다. 장애 발생 시 재개하려면 시스템에서 마이그레이션 진행을 내부 상태로 유지해야 합니다.
여러 가지 방법으로 상태를 유지할 수 있습니다.
- 데이터베이스를 수정하기 전에 추출된 모든 데이터 항목을 데이터베이스 마이그레이션 시스템에 저장한 다음 수정된 버전이 대상 데이터베이스에 저장되면 데이터 항목을 삭제할 수 있습니다. 이 방법을 사용하면 데이터베이스 마이그레이션 시스템에서 추출 및 저장되는 항목을 정확하게 결정할 수 있습니다.
- 전송 중인 데이터 항목에 대한 참조 목록을 유지할 수 있습니다. 한 가지 방법은 상태 속성과 함께 각 데이터 항목의 기본 키 또는 기타 고유 식별자를 저장하는 것입니다. 장애가 발생한 후에는 이 상태가 시스템을 일관되게 복구하기 위한 기초가 됩니다.
- 장애가 발생한 후 소스 데이터베이스와 대상 데이터베이스를 쿼리하여 소스 데이터베이스 시스템과 대상 데이터베이스 시스템 간의 차이를 확인할 수 있습니다. 추출할 다음 데이터 항목은 차이에 따라 결정됩니다.
상태를 유지하는 다른 방법은 특정 소스 데이터베이스에 따라 다를 수 있습니다. 예를 들어 데이터베이스 마이그레이션 시스템은 소스 데이터베이스에서 가져오는 트랜잭션 로그 항목과 대상 데이터베이스에 삽입되는 트랜잭션 로그 항목을 추적할 수 있습니다. 장애가 발생하면 마지막으로 삽입된 항목부터 마이그레이션을 다시 시작할 수 있습니다.
전송 중 데이터의 지속성은 오류 또는 장애 이외의 다른 이유로 중요합니다. 예를 들어 소스 데이터베이스의 데이터를 쿼리하여 상태를 확인할 수 없습니다. 예를 들어 소스 데이터베이스에 큐가 포함된 경우 해당 큐의 메시지가 특정 시점에 삭제되었을 수 있습니다.
하지만 전송 중 데이터의 지속성을 위한 또 다른 사용 사례는 데이터의 대형 창 처리입니다. 데이터를 수정하는 동안 데이터 항목은 서로 독립적으로 변환될 수 있습니다. 하지만 데이터 수정은 여러 데이터 항목에 따라 달라집니다(예: 매일 처리되는 데이터 항목의 번호 지정, 매일 0에서 시작).
전송 중 데이터의 지속성을 위한 최종 사용 사례는 데이터베이스 시스템이 소스 데이터베이스에 다시 액세스할 수 없을 때 데이터를 수정하는 동안 데이터의 반복성을 제공하는 것입니다. 예를 들어 다양한 수정 규칙으로 데이터 수정을 다시 실행한 다음 결과를 확인하고 초기 데이터 수정과 비교해야 할 수 있습니다. 잘못된 데이터 수정으로 인해 대상 데이터베이스의 불일치를 추적해야 하는 경우 이 방법이 필요할 수 있습니다.
완전성 및 일관성 확인
데이터베이스 마이그레이션이 완료되고 일관성이 있는지 확인해야 합니다. 이렇게 하면 각 데이터 항목이 한 번만 마이그레이션되고 소스 및 대상 데이터베이스의 데이터 세트가 동일하며 마이그레이션이 완료됩니다.
데이터 수정 규칙에 따라 데이터 항목이 추출되지만 대상 데이터베이스에 삽입되지 않을 수 있습니다. 따라서 소스 데이터베이스와 대상 데이터베이스를 직접 비교하는 것은 완전성과 일관성을 확인하는 확실한 방법이 아닙니다. 하지만 데이터베이스 마이그레이션 시스템에서 필터링된 항목을 추적하는 경우 소스 및 대상 데이터베이스를 필터링된 항목과 함께 비교할 수 있습니다.
데이터베이스 관리 시스템의 복제 기능
동종 마이그레이션의 특수한 사용 사례는 대상 데이터베이스가 소스 데이터베이스의 복사본인 경우입니다. 특히 소스 데이터베이스와 대상 데이터베이스의 스키마가 동일하고 데이터 값이 동일하며 각 소스 데이터베이스가 대상 데이터베이스와 직접 매핑(1:1)됩니다.
이 경우 대부분의 데이터베이스 관리 시스템에 제공되는 기본 제공 복제 기능을 사용해서 하나의 데이터베이스를 다른 데이터베이스로 복제할 수 있습니다.
데이터 복제에는 논리적 및 물리적 복제의 두 가지 유형이 있습니다.
논리적 복제: 논리적 복제의 경우 데이터베이스 객체의 변경사항이 복제 식별자(일반적으로 기본 키)를 기반으로 전송됩니다. 논리적 복제의 장점은 유연하고, 세부적이고, 맞춤설정이 가능하다는 것입니다. 일부 경우에는 논리적 복제를 통해 여러 다른 데이터베이스 엔진 버전 간에 변경사항을 복제할 수 있습니다. 많은 데이터베이스 엔진에서 논리적 복제 필터가 지원되며, 이를 통해 복제할 데이터 집합을 정의할 수 있습니다. 중요한 단점은 논리적 복제로 인해 일부 성능 오버헤드가 발생할 수 있고 지연 시간이 물리적 복제보다 일반적으로 높다는 것입니다.
물리적 복제: 반면에, 물리적 복제는 데이터 블록 수준에서 작동하며 낮은 복제 지연 시간과 높은 성능을 제공합니다. 대규모 데이터 세트의 경우 물리적 복제가 더 직관적이고 효율적일 수 있으며 특히 비관계형 데이터 구조에서 효율적일 수 있습니다. 하지만 맞춤설정이 불가능하며 데이터베이스 엔진 버전에 크게 의존합니다.
예를 들어 MySQL 복제, PostgreSQL 복제(pdlogical 참조), Microsoft SQL Server 복제가 있습니다.
하지만 데이터 수정이 필요하거나 직접 매핑 이외의 카디널리티가 있는 경우 이러한 사용 사례를 해결하기 위해 데이터베이스 마이그레이션 시스템의 기능이 필요합니다.
커스텀 데이터베이스 마이그레이션 기능
데이터베이스 마이그레이션 시스템 또는 데이터베이스 관리 시스템을 사용하는 대신 데이터베이스 마이그레이션 기능을 빌드하는 이유는 다음과 같습니다.
- 모든 세부정보를 완벽하게 제어해야 합니다.
- 데이터베이스 마이그레이션 기능을 재사용하려고 합니다.
- 비용을 줄이거나 기술 사용 공간을 간소화하려고 합니다.
마이그레이션 기능을 빌드하기 위한 구성 요소는 다음과 같습니다.
- 내보내기 및 가져오기: 다운타임이 고려되지 않는 경우 데이터베이스 내보내기 및 데이터베이스 가져오기를 사용하여 동종 데이터베이스 마이그레이션에서 데이터를 마이그레이션할 수 있습니다. 하지만 내보내기 및 가져오기를 수행하려면 데이터를 내보내기 전에 소스 데이터베이스를 정지하여 업데이트를 방지해야 합니다. 그렇지 않으면 변경사항이 내보내기에서 캡처되지 않을 수 있으며 대상 데이터베이스가 소스 데이터베이스의 정확한 복사본이 되지 않습니다.
- 백업 및 복원: 내보내기 및 가져오기의 경우와 같이 백업 및 복원을 위해서는 백업에 모든 데이터와 최근의 변경사항이 포함되도록 소스 데이터베이스를 중지해야 하기 때문에 다운타임이 발생합니다. 다운타임은 대상 데이터베이스에서 복원이 완료될 때까지 계속됩니다.
- 차등 쿼리: 데이터베이스 스키마 변경이 옵션인 경우 쿼리 인터페이스에서 데이터베이스 변경사항을 쿼리할 수 있도록 스키마를 확장할 수 있습니다. 마지막 변경 시간을 나타내는 추가 타임스탬프 속성이 추가됩니다. 데이터 항목의 삭제 여부를 나타내는 추가 삭제 플래그를 추가할 수 있습니다(논리적 삭제). 이 두 변경사항을 사용하면 일정한 간격으로 실행되는 폴러가 마지막 실행 이후의 모든 변경사항을 쿼리할 수 있습니다. 변경사항은 대상 데이터베이스에 적용됩니다. 추가 방식은 변경 데이터 캡처에서 설명합니다.
다음은 커스텀 데이터베이스 마이그레이션을 빌드할 수 있는 몇 가지 옵션입니다. 커스텀 솔루션은 구현을 가장 유연하게 제어할 수 있지만, 데이터베이스 마이그레이션 중에 발생할 수 있는 버그, 확장성 제한, 기타 문제를 해결하기 위해 지속적인 유지보수가 필요합니다.
데이터베이스 마이그레이션에 대한 추가 고려사항
다음 섹션에서는 데이터베이스 마이그레이션과 관련하여 중요한 비기능적 측면을 간략하게 설명합니다. 이러한 측면에는 오류 처리, 확장성, 고가용성, 재해 복구가 포함됩니다.
오류 처리
데이터베이스 마이그레이션 중에 장애가 발생하면 데이터가 손실되거나 데이터베이스 변경사항이 순서대로 처리되지 않아야 합니다. 데이터 무결성은 장애 원인(예: 시스템 버그, 네트워크 중단, VM 비정상 종료, 영역 장애)에 관계없이 보존되어야 합니다.
데이터 손실은 마이그레이션 시스템이 소스 데이터베이스에서 데이터를 검색하고 일부 오류로 인해 대상 데이터베이스에 저장하지 않는 경우 발생합니다. 데이터가 손실되면 대상 데이터베이스가 소스 데이터베이스와 일치하지 않으므로 불일치하고 불완전합니다. 완전성 및 일관성 확인 기능은 이 상태를 플래그로 표시합니다(완전성 및 일관성 확인).
확장성
데이터베이스 마이그레이션에서 마이그레이션 시간은 중요한 측정항목입니다. 제로 다운타임 마이그레이션(최소 다운타임 맥락)에서 소스 데이터베이스가 계속 변경되는 동안 데이터 마이그레이션이 수행됩니다. 적절한 시간 내에 마이그레이션하려면 데이터 전송 속도가 특히 소스 데이터베이스 시스템 규모가 클 경우에는 소스 데이터베이스 시스템의 업데이트 속도보다 훨씬 빨라야 합니다. 전송 속도가 높을수록 데이터베이스 마이그레이션이 더 빨리 완료됩니다.
소스 데이터베이스 시스템이 정지되어 수정되지 않는 경우 통합할 변경사항이 없으므로 마이그레이션 속도가 빨라질 수 있습니다. 동종 데이터베이스에서는 백업 및 복원 또는 내보내기 및 가져오기 기능을 사용할 수 있고 파일 전송이 확장되므로 마이그레이션 시간이 상당히 빠를 수 있습니다.
고가용성 및 재해 복구
일반적으로 소스 데이터베이스와 대상 데이터베이스는 고가용성으로 구성됩니다. 기본 데이터베이스에는 장애가 발생하면 기본 데이터베이스로 승격되는 해당 읽기 복제본이 있습니다.
영역에 장애가 발생하면 계속 사용할 수 있도록 소스 데이터베이스 또는 대상 데이터베이스를 다른 영역으로 장애 조치합니다. 데이터베이스 마이그레이션 중에 영역에 장애가 발생하면 액세스하는 여러 소스 데이터베이스 또는 대상 데이터베이스에 액세스할 수 없게 되므로 마이그레이션 시스템 자체가 영향을 받게 됩니다. 마이그레이션 시스템을 장애가 발생한 후 실행되는 새로 승격된 기본 데이터베이스에 다시 연결해야 합니다. 데이터베이스 마이그레이션 시스템이 다시 연결되면 대상 데이터베이스에 있는 데이터의 완전성과 일관성을 보장하도록 마이그레이션 자체를 복구해야 합니다. 마이그레이션 시스템은 재개할 위치를 결정하기 위해 마지막으로 일관된 전송을 결정해야 합니다.
데이터베이스 마이그레이션 시스템 자체에 장애가 발생하면(예: 실행되는 영역에 액세스할 수 없게 되는 경우) 복구해야 합니다. 복구 방법 중 하나는 콜드 재시작입니다. 이 방법에서는 데이터베이스 마이그레이션 시스템이 운영 영역에 설치되고 다시 시작됩니다. 해결해야 할 가장 큰 문제는 마이그레이션 시스템에서 장애가 발생하기 전에 마지막으로 일관된 데이터 전송을 확인하고 해당 시점부터 계속해서 대상 데이터베이스에서 데이터 완전성과 일관성을 보장해야 한다는 것입니다.
데이터베이스 마이그레이션 시스템이 고가용성으로 사용 설정된 경우 장애 조치를 수행하고 이후에 계속 처리할 수 있습니다. 데이터베이스 마이그레이션 시스템의 제한된 다운타임이 중요한 경우 데이터베이스를 선택하고 고가용성을 구현해야 합니다.
데이터베이스 마이그레이션 복구 측면에서 재해 복구는 고가용성과 매우 유사합니다. 데이터베이스 마이그레이션 시스템은 다른 영역에서 새로 승격된 기본 데이터베이스에 다시 연결하는 대신 다른 리전(장애 조치 리전)에 있는 데이터베이스에 다시 연결해야 합니다. 데이터베이스 마이그레이션 시스템 자체에도 마찬가지입니다. 데이터베이스 마이그레이션 시스템이 실행되는 리전에 액세스할 수 없게 되면 데이터베이스 마이그레이션 시스템을 다른 리전으로 장애 조치하고 마지막으로 일관된 데이터 전송을 계속해야 합니다.
문제
여러 가지 문제로 인해 대상 데이터베이스의 데이터가 일치하지 않을 수 있습니다. 일반적으로 피해야 할 문제는 다음과 같습니다.
- 순서 위반. 수평 확장을 통해 마이그레이션 시스템의 확장성을 달성하면 여러 데이터 전송 프로세스가 동시에 실행됩니다. 소스 데이터베이스 시스템의 변경사항은 커밋된 트랜잭션에 따라 정렬됩니다. 트랜잭션 로그에서 변경사항을 선택하는 경우 마이그레이션 중에 순서를 유지해야 합니다. 동시 데이터 전송은 기본 프로세스 간에 속도가 다르기 때문에 순서를 변경할 수 있습니다. 데이터가 소스 데이터베이스에서 수신되는 순서와 동일한 순서로 대상 데이터베이스에 삽입되어야 합니다.
- 일관성 위반. 차등 쿼리를 사용하면 소스 데이터베이스에 커밋 타임스탬프가 포함된 추가 데이터 속성이 있습니다. 커밋 타임스탬프는 소스 데이터베이스에서 변경 관리를 설정하기 위해서만 적용되므로 대상 데이터베이스에는 커밋 타임스탬프가 없습니다. 대상 데이터베이스에 대한 삽입은 타임스탬프가 일관되어야 합니다. 즉, 동일한 타임스탬프가 있는 모든 변경사항이 동일한 삽입, 업데이트, 업데이트 삽입 트랜잭션에 있어야 합니다. 그렇지 않으면 일부 변경사항이 삽입되고 동일한 타임스탬프가 있는 다른 변경사항이 삽입되지 않으면 대상 데이터베이스의 상태가 일시적으로 일관되지 않을 수 있습니다. 처리를 위해 대상 데이터베이스에 액세스할 수 없는 경우에는 임시 상태가 일관되지 않아도 문제가 되지 않습니다. 그러나 테스트에 사용되는 경우 일관성이 가장 중요합니다. 또 다른 측면은 소스 데이터베이스에서 타임스탬프 값 생성과 이 값과 이 값이 설정된 트랜잭션의 커밋 시간의 상관 관계입니다. 트랜잭션 커밋 종속 항목으로 인해 이전 타임스탬프가 있는 트랜잭션이 이후 타임스탬프가 있는 트랜잭션 이후에 나타날 수 있습니다. 두 가지 트랜잭션 간에 차등 쿼리가 실행되면 이전 타임스탬프가 있는 트랜잭션이 표시되지 않으므로 대상 데이터베이스와 일치하지 않게 됩니다.
- 누락되거나 중복된 데이터. 일부 데이터가 기본 복제본과 장애 조치 복제본 간에 복제되지 않는 경우 장애 조치가 발생하면 신중하게 복구해야 합니다. 예를 들어 소스 데이터베이스가 장애 조치되고 모든 데이터가 장애 조치 복제본에 복제되지 않습니다. 동시에 데이터는 장애가 발생하기 전에 대상 데이터베이스로 마이그레이션됩니다. 장애 조치 후 새로 승격된 기본 데이터베이스는 데이터 변경 측면에서 대상 데이터베이스보다 뒤쳐집니다(flashback이라 함). 마이그레이션 시스템은 이러한 상황을 인식하고 대상 데이터베이스와 소스 데이터베이스가 일관된 상태로 복구되도록 복구해야 합니다.
- 로컬 트랜잭션. 소스 데이터베이스와 대상 데이터베이스가 동일한 변경사항을 수신하도록 하려면 일반적으로 클라이언트가 데이터 마이그레이션 시스템을 사용하는 대신 소스 데이터베이스와 대상 데이터베이스 모두에 쓰는 것이 좋습니다. 이 방식에는 여러 가지 문제가 있습니다. 한 가지 문제는 두 데이터베이스 쓰기가 두 개의 개별 트랜잭션이라는 점입니다. 첫 번째 작업이 완료된 후 두 번째 작업이 완료되기 전에 오류가 발생할 수 있습니다. 이 시나리오에서는 복구해야 하는 데이터가 일치하지 않습니다. 또한 일반적으로 여러 클라이언트가 있으며 조정되지 않습니다. 클라이언트는 소스 데이터베이스 트랜잭션 커밋 순서를 알지 못하므로 해당 트랜잭션 순서를 구현하는 대상 데이터베이스에 쓸 수 없습니다. 클라이언트가 순서를 변경하여 데이터 불일치가 발생할 수 있습니다. 모든 액세스가 조정된 클라이언트를 거치지 않고 모든 클라이언트가 대상 트랜잭션 순서를 보장하지 않는 한, 이 방법은 대상 데이터베이스와 일치하지 않는 상태가 될 수 있습니다.
일반적으로 주의해야 할 다른 문제가 있습니다. 데이터 불일치를 초래할 수 있는 문제를 찾는 가장 좋은 방법은 가능한 모든 장애 시나리오를 반복하는 완전한 장애 분석을 수행하는 것입니다. 데이터베이스 마이그레이션 시스템에서 동시 실행이 구현된 경우 가능한 모든 데이터 마이그레이션 프로세스 실행 순서를 검사하여 데이터 일관성을 유지해야 합니다. 고가용성 또는 재해 복구(또는 둘 다)가 구현된 경우 가능한 모든 장애 조합을 검사해야 합니다.
다음 단계
- 데이터베이스 마이그레이션: 개념 및 원칙(2부) 읽기
- 다음 문서에서 데이터베이스 마이그레이션 알아보기
- 데이터베이스 마이그레이션 가이드에 대한 자세한 내용은 데이터베이스 마이그레이션 참조
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.