Change Data Capture(이하 CDC)는 변경된 데이터를 peer 측 서버로 전달해주는 기능을 하는 소프트웨어를 의미한다. 데이터에는 정형 데이터, 반정형 데이터 혹은 비정형 데이터를 모두 포함한다.

일반적인 Migration 솔루션과는 다르게 CDC는 변경 부분에 대해서만 전달함으로써 처리량이 적어 Throughput 등에 있어서 큰 이점을 얻을 수 있다.

ProSync는 TmaxTibero의 CDC 솔루션이다. 현재 제공되는 데이터 타입은 정형 데이터, 즉 RDBMS에 대한 동기화만을 제공하고 있으며 실시간성이 높고, 이력 관리를 통한 장애 복구나 ProSync Manager를 통한 정합성 검사 등의 기능을 제공하고 있다.

앞서 설명한 프로세스 개요 및 설계 구조가 실제 운영 환경 내 구성에 적용되는 사항을 이해하면 설치 절차 및 파라미터 변경 사항을 정확히 파악할 수 있다.

Single to Single 구성 예시

아래와 같은 구성을 권장한다.

가장 기본적인 ProSync의 구성도로, 추출하고자 하는 위치에 관련 프로세스가 기동되고, 반영하고자 하는 위치에 반영프로세스가 기동되는 구조이다. Agent 프로세스의 경우 프로세스들을 모니터링하기 때문에 환경별로 1개씩 기동된다.

편의를 위해 아래와 같은 구성 또한 가능하다.

모든 프로세스를 추출쪽으로 옮겨놓은 구성으로, 설치 및 운영이 매우 간단하다. 하지만 Apply가 Target쪽에 쿼리를 전달한다는 측면에서 네트워크 쓰루풋에 손해를 볼 수 있으며, 하드웨어 자원들도 모두 공유되기 때문에 권장되는 구성은 아니다.

Cluster to Single/Cluster 구성 예시

Active-Active 구성의 Cluster DB는 Shared Storage가 필수이기 때문에, Shared Storage와 DB Server를 분리하여 작성한다.

반영 쪽이 Cluster인지 여부는 크게 중요하지 않다. 각 DB별 연결정보 파일 (tnsnames.ora 나 tbdns.tbr 파일 등)을 통해 Cluster 쪽 연결 정보를 추상화하여 접속하기 때문에 반영할 수 있는 DB와 연결만 되면 된다.

ProSync Architecture

ProSync는 위와 같은 설계를 가지고 있다. 전체 설계에 대한 간단한 요약을 하면 아래와 같다.

Extract 프로세스는 추출 데이터베이스( SRC DB )에서 데이터베이스 변경 로그(database change log)를 추출한다. 변경 로그는 DB 종류에 따라 다르다. Tibero와 Oracle은 Redo Log를 읽고, PostgreSQL은 WAL(logical decoding)을 읽는다. 추출은 각 DB별 Log Reader Library를 통해 진행하며, 필요한 경우, 각 DB별로 제공하는 별도의 로그 분석 기능을 통해 추출을 진행하기도 한다. 추출된 데이터는 Apply 프로세스로 전달된다.

데이터는 보통 레코드 단위 (쉽게 말해 DML 단위)로 남게 되며, 해당 데이터는 Apply 프로세스에서 트랜잭션별로 취합해 반영해주어야 한다. 따라서 Apply 프로세스는 레코드들을 전달받아 트랜잭션별로 모아둔다. commit에 해당하는 레코드가 오게되면, 트랜잭션을 반영시킨다.

Data Flow

ProSync의 Data Flow를 기준으로 살펴보면 조금 더 상세한 과정을 볼 수 있다.

Extract 프로세스는 레코드를 chunk 단위로 모아 Apply 프로세스로 전달한다. 전달받은 Apply 프로세스는 각 레코드들을 트랜잭션 단위로 모아준다. commit 레코드가 올 경우 반영 데이터베이스(TAR DB) 로 반영하게 된다.

DDL Metadata Flow

위의 Data Flow는 DML 변경 데이터(change log) 기준의 경로이다. DDL의 메타데이터는 이와 분리된 별도의 경로로 전달된다.

Source DDL 수행
  -> PRS_DDL_TRG (Tibero/Oracle trigger) / PostgreSQL event trigger
  -> PRS_DD_META package/function 호출
  -> PRS_DDL_HIST 테이블에 기록
  -> Extract가 PRS_DDL_HIST를 polling하여 DD version 갱신
  -> Extract가 DD 정보를 Apply로 전달
  -> Apply의 Construct/Replay Thread가 DD 교체

DDL 동기화가 정상적으로 동작하려면 설치 시 Source DB에 생성되는 trigger와 package가 유효해야 한다. 관련 오류와 정체 상태의 진단 방법은 를 참고한다.

ProSync는 프로세스 간 통신은 TCP를 사용하고, 스레드 간 통신은 Pipe를 사용한다.

어떤 종류의 프로세스건, Main 스레드는 반드시 존재하고 (ProSync에선 CTH 혹은 Control Thread 라고 부른다.) 해당 스레드가 다른 스레드와의 통신을 모두 담당한다. 즉, A라는 스레드에서 B라는 스레드와 직접 통신하는 것은 불가능하고, 반드시 Main 스레드를 거쳐서 통신하게 되어 있다.

또한 프로세스 간 통신은 TCP로만 진행된다. 소켓의 accept는 각 프로세스의 Main 스레드가 담당하지만, 모든 connect를 Main 스레드가 수행하는 것은 아니다. 예를 들어 Extract 프로세스에서 Apply 프로세스로 나가는 연결은 Write Thread(WTHR)가 connect를 수행한 뒤, 연결된 소켓을 Main 스레드에 전달하여 이후의 통신을 관리하게 한다.

전체 프로세스들의 기능과 구조를 간단하게 설명한다.

Data Flow 를 기준으로 설명했던 프로세스는 주로 Extract 프로세스와 Apply 프로세스이다. 이 두 프로세스가 ProSync의 핵심 프로세스이나, 프로세스 전체를 관리하고 데이터를 수집하여 모니터링 툴에 전달해주는 등의 기능을 해주는 Agent 프로세스나 Long 혹은 Lob 데이터 처리를 위해 별도로 구성된 Llob 프로세스, Agent 프로세스를 통해 실제 프로세스에 명령을 내리는 Admin 프로세스의 구성을 이해하면 이후에 언급되는 내용을 이해하기 쉽다.

전체 구성을 보면 아래와 같다.

각 프로세스에 대한 역할은 아래와 같다.

Agent 프로세스를 통해 다른 프로세스에게 명령을 내린다. Agent 에게 내린 명령과 리턴을 터미널에서 출력한다고 이해할 수 있다.

명령어 목록은 매뉴얼을 참고한다.

프로세스 관리에 들어가는 다양한 업무를 여기서 모두 수행한다. 대표적으로 아래와 같은 작업들이 있다.

• 프로세스 기동 / 종료

• 프로세스 별 리소스 모니터링

• 프로세스 설정 변경

이외에도 관리에 해당하는 작업은 모두 이곳에서 작업을 수행해준다.

CDC 에 있어서 변경 데이터를 캡쳐하는 프로세스이다. RDBMS의 변경 로그(Tibero/Oracle: Redo Log, PostgreSQL: WAL)를 보고 데이터를 추출하는 작업을 수행한다.

변경된 데이터를 peer쪽에 반영하는 작업을 수행한다.

RDBMS에서 사용되는 Long 혹은 Lob 과 같은 큰 단위의 데이터는 변경분의 데이터도 크다. 따라서 데이터가 리두에 남는다 하여도, 트랜잭션 말미에는 데이터가 삭제가 되거나 혹은 크게 변경될 가능성이 있다.

트랜잭션 단위로 봤을 땐, 마지막 형상의 데이터만 알아도 ACID를 유지하는 데에는 아무 문제가 없다. 모든 변경분의 데이터를 추적하지 않아도 ACID가 유지가 된다는 뜻은 처리성능(Throughput)을 불필요하게 희생하면서까지 연산을 수행할 필요는 없다는 의미이다.

Llob 프로세스에서 주로 수행하는 일은 Commit 이 들어온 시점에 Flashback 쿼리를 수행하여 해당 시점 즉 트랜잭션이 종료되는 시점에서의 데이터만 조회하여 Apply 에서 발생하는 데이터 처리량을 줄이고, 전체 동기화 과정에서의 부하를 줄여주는 프로세스이다.