ProSync에는 DML 이력을 확인할 수 있는 다양한 기능들이 있다. config파일에서 로그 레벨을 5레벨로 높이면, 반영하고 있는 SQL과 Bind할 Value들이 byte array 형태로 남게 된다. 다만 로그 레벨을 반드시 높여야 한다는 점과, bind value들이 별도로 남으므로 실제 SQL로 바로 처리할 수 없다는 단점이 있다.

본 장에서는 위와 같은 상황에서 확인할 수 있는 SAM(Sequential Access Method) 파일 기능과 DML 에러 발생 시의 report 파일, DML 이력 확인 기능 등에 대하여 기술한다.

ProSync의 Flow Control을 위해 사용되는 기능들을 정리한 문서이다. 데이터가 동기화되는 일련의 과정이 안정적으로 운영되기 위해선 데이터 처리 속도가 관건이다.

처리가 너무 느리다면 동기화 로직 상 데이터는 계속해서 쌓이게 된다. 쌓인 데이터를 계속해서 메모리에 적재하면 당연히 문제가 발생하기 때문에 임계값을 통해 데이터를 파일로 저장하거나 일시적으로 지연시키는 동작이 수행된다.

또한 처리 속도를 올리기 위해서 사용되는 기능들도 존재한다. 처리 속도가 빠르면 그만큼 추출한 데이터가 실시간성이 높게 반영이 된다는 의미이므로, 이 부분을 고려하여 환경 설정을 하는 것이 좋다.

마지막으로 에러가 발생했을 때, 정합성을 위해 기본적으로 동기화가 멈추게 되어있는데, 이렇게 되면 데이터가 더이상 처리될 수 없어서 영구적인 지연이 발생할 수 있다. 따라서 에러가 발생했을 때, 이를 자동으로 생략하거나 Rule에 맞춰서 데이터를 처리하는 방법에 대해서도 알아본다.

Process 설명

Apply 프로세스는 제품 설계에서도 언급했듯이 Chunk 단위로 레코드를 전달받고 해당 레코드를 트랜잭션별로 모아준다. 트랜잭션에 Commit이 오면 해당 트랜잭션은 실제 반영 단계에 들어가 대상이 되는 데이터베이스로 반영된다.

본 장에서는, 실제 apply 프로세스의 구조를 상세히 설명한다.

Threads

Apply 프로세스는 위와 같은 구조를 가지고 있다. 앞서 에서 ProSync의 기본 Thread 구조를 언급한 바 있는데, Apply도 마찬가지로 Main이 되는 Control Thread가 있고 이외에 Worker Thread들이 Control Thread 하위 계층에 구성되어 있다.

동기화에 필요한 Thread는 Construct Thread와 Replay Thread로 크게 두 가지이며, 나머지는 모두 Worker Thread로 구분된다.

Control Thread

Control Thread는 다른 프로세스와 마찬가지로 모든 통신과 관련된 Multiplexing I/O를 담당한다. 리눅스에선 epoll을 사용하며, 플랫폼별로 k-queue나 pollset 등 각 운영체제에 알맞은 Mux I/O 기능을 사용하도록 설계되어 있다.

Construct Thread는 _Chunk_로 들어오는 레코드 데이터들에 대해 트랜잭션으로 재조립한다. Construct라는 말의 의미는 트랜잭션을 다시 조립(Construct)하기 때문에 사용된다고 생각하면 된다.

각 레코드에는 본인이 속한 트랜잭션을 구분할 수 있는 일종의 key 값이 존재하는데, 이게 트랜잭션의 ID 일명 (xid)라고 불린다.

Construct는 레코드의 xid 값을 보고 트랜잭션별로 재조립한다.

Replay Thread는 Commit 레코드가 도달하여 Construct로부터 조립이 완료된 트랜잭션을 전달받는다. 전달받은 트랜잭션은 Commit 레코드의 DB Time(Oracle의 SCN / Tibero의 TSN / ..)에 맞게 직렬화되어 반영되거나, 트랜잭션 내 레코드들의 의존성을 모두 체크하여 병렬로 처리된다.

병렬로 처리하게 될 경우 Replay Thread의 개수가 많아지게 되며, 각 스레드가 DB의 한 세션을 담당하게 된다. 병렬 처리 가능 여부는 Control Thread에서 실시간으로 판단하며, 병렬 처리가 가능할 때 여러 Replay Thread에 일감을 부여하게 된다.

프로세스의 CPU / Memory 사용량을 실시간으로 수집한다. 수집된 내용은 로그상에 계속해서 남게 되며, 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.

프로세스에서 발생하는 트랜잭션의 시간당 처리량, 일종의 Throughput을 계산한다. 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.

Data Conflict를 확인하려면 Row를 특정할 수 있어야 한다. ProSync에서는 이에 대한 기준을 Primary key로 두고 있다. Primary key 로 인해 충돌이 발생할 경우, Source Database, Target Database, Column Min(Max) 기준으로 데이터 Conflict에 대한 처리를 결정한다.

Insert문에서 충돌이 발생한다는 것은, 이미 데이터가 존재한다는 의미이다. 따라서 존재하는 데이터를 모두 Source Database 기준으로 맞춰주어야 한다.

Insert문을 Update로 변경하여 Conflict 을 해소해준다.

Update에서의 데이터 충돌은 원하는 Row가 없다는 의미이다.

Update문을 Insert로 변경하여 Conflict 을 해소해준다.

Delete에서의 데이터 충돌 또한 마찬가지로 Row가 없다는 의미가 된다.

Delete에 대한 추가적인 처리가 없이 넘어가면 된다.

Insert문의 충돌은 이미 데이터가 있을 때 발생하는데, Target Database 기준으로 맞춰야 하므로, 별도의 작업 없이 해당 처리를 건너뛴다.

DML DISCARD

ProSync가 동기화 과정 속에 DML을 Target DB에 반영 중 에러가 발생할 수 있다. 일반적인 경우에는 ProSync가 해당 DML에 대한 반영을 성공할 때 까지 재시도하게 된다.

해당 기능을 사용하면 특정한 에러에 대해 재시도하는 대신 해당 DML에 대한 반영을 생략하고 이후의 동기화를 진행하도록 설정할 수 있다.

또한 DISCARD 기능이 발생한 이력을 기록하는 Discard file 을 작성할 수 있다.

해당 기능을 사용하기 위해선 config 파일에 다음과 같은 Parameter를 설정해야 한다.

DISCARD_YN=[Y|N]
DISCARD_EC=2 10007 8033
DISCARD_FILE_YN=[Y|N]

DISCARD_FILE_DIR=/directory/to/save/file
DISCARD_FILE_SIZE=200M
DISCARD_BACKUP_DIR=/directory/to/save/backup/file
DISCARD_BACKUP_SIZE=10G

DDL도 DML과 마찬가지로 Target DB에 반영 중 에러가 발생할 수 있다. 일반적인 경우에는 ProSync가 해당 DDL에 대한 반영을 성공할 때 까지 재시도하게 된다.

해당 기능을 사용하면 재시도하는 대신 해당 DDL에 대한 반영을 생략하고 이후의 동기화를 진행하도록 설정할 수 있다.

또한 DISCARD 기능이 발생한 이력을 기록하는 Discard file 을 작성할 수 있다.

해당 기능을 사용하기 위해선 config 파일에 다음과 같은 Parameter를 설정해야 한다.

APPLY 프로세스가 동기화 진행 중 DML 반영을 실패 또는 장애 상황이 발생했을 때 일정 횟수를 재시도 한 뒤 report 파일로 write하는 기능이다.

DML에 관해서만 기록이 가능하며, APPLY 프로세스의 config 파일인 [inst_id]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

데이터가 처음 생성되는 위치는 Source DB의 Redo Log이다. Redo Log에서 발생된 데이터를 Extract 가 추출하여 Chunk 단위로 데이터를 적재한다.

적재된 데이터는 TCP Socket을 통해 전송이 된다. Non Blocking 통신이기 때문에 전체 데이터에 대한 전송이 실패하면, 이후의 데이터들은 Non Blocking Queue에 쌓이게 된다. 이 Queue에 쌓인 데이터는 커널로부터 반대쪽 TCP Recv Buffer가 비어있다는 신호가 올 때, 순서대로 다시 데이터를 보내게 된다.

Apply는 받은 데이터를 모두 객체화 (역직렬화) 하여 TX_HASH에 쌓이게된다. xid 는 트랜잭션 고유의 id 를 의미하며, ACID를 지켜주기 위해 트랜잭션의 커밋까진 이 위치에서 데이터를 계속 보관한다. 트랜잭션의 커밋이 들어오면 해당 트랜잭션은 Target Database에 반영이 가능한 상태로 판단하고 Replay Queue로 데이터를 넘겨준다.

Wait Queue에 쌓인 데이터는 트랜잭션들이 커밋된 순서에 맞게 Target Database로 반영이 된다. 이 때 반영 중인 트랜잭션과 반영 대기 중인 트랜잭션이 있을 텐데, 이들간의 의존성 검사를 통하여 시간 순서에 맞고, 의존성이 없는 트랜잭션들은 병렬 처리하여 성능을 높인다.

TX_HASH 에 데이터가 계속 쌓인다면 Out of Memory 를 피할 수가 없다. 따라서 특정 임계치를 넘어갈 경우 Part File이라는 이름으로 된 파일을 생성하여 이 위치로 데이터를 옮겨준다.

데이터를 옮기는 기준은 현재 TX_HASH

Batch Execution은 RDBMS 상에서 우리가 사용하는 Batch 관련 API라고 이해하는 것이 용이하다. DML 각각을 모두 쿼리 형태로 변환하여 전달하기보단, 같은 형태의 쿼리라면 데이터를 Batch단위로 모아서 서버에서 사용하도록 하는 기능이다.

이 기능을 사용하면 Insert 와 같은 DML이 연속해서 들어올 때, Target Database 의 성능을 향상 시킬 수 있다. 이를 통해 데이터 처리 속도를 증가 시키고 동기화 속도를 끌어 올려줄 수 있다.

하지만 제약사항도 존재하는 기능으로, 아래와 같은 두가지 관점에서 고려할 수 있다.

• 같은 형태의 쿼리

• Batch로 모았을 때의 한계

ProSync는 한 트랜잭션에서 DML이 연속해서 들어올 때 이 순서를 임의대로 바꾸지 않는다. 입력되는 모든 쿼리를 순서대로 적용해야 정합성이 깨지지 않는다는 대전제 때문에 이와 같이 처리가 된다.

커밋이 요청 트랜잭션은 반영을 할 수 있으면 반영을 하고, 반영을 할 수 없으면 큐에서 대기하게 된다. 반영 가능 여부는 반영하고자 하는 트랜잭션과 반영 중인 트랜잭션 간의 의존성 체크를 통해 서로 독립적일 경우 반영이 가능하다고 판단한다.

의존성 체크는 Table과 Row 단위 모두 확인을 한다. 트랜잭션은 레코드로 이루어져 있고, 레코드에는 레코드가 접근하는 Row가 정해져 있기 때문에, 해당 데이터를 기반으로 다른 트랜잭션과 의존 관계인지 여부를 판단한다.

의존성 확인 동작은 RedBlack Tree(RBT)와 Linked List로 관리가 되고 있다. Table 단위로 RBT를 확인하고, Table이 확인되면, 해당 Table 노드 내의 RBT에서 Row를 확인한다. 이 위치엔 Linked List가 존재하며, 트랜잭션은 해당 List에 의존성 객체(TX Dependency )를 달아 놓는다.

이 동작을 통해 트랜잭션이 접근하는 모든 Row에 대한 Linked List에 TX Dependency가 등록이 된다. 반영 중인 트랜잭션이나 반영 대기 중인 트랜잭션 모두 이 구조 안에서 관리된다.

반영 가능 여부는 트랜잭션의 모든 TX Dependency가 Linked List의 front에 존재하는 지의 여부로 확인한다. 하나라도 front에 존재하지 않는다면 반영이 불가능하고, 앞서 반영 중인 트랜잭션의 완료를 대기하게 된다.

반영이 가능한 경우는 위 그림과 같이 모든 의존성 체크를 했을 때 Linked List 상에 TX Dependency 가 가장 앞선 경우이다.

만약 위 그림과 같이 xid: 111인 트랜잭션이 아직 반영이 끝나지 않았다면 대기하게 된다. 반영이 완료된 트랜잭션은 위 Linked list에서 제거가 되고, xid: 112가 반영 가능하게 되면 반영 작업을 진행한다.

관련 파라미터는 REPLAY_THREAD_CNT 로, 해당 값이 올라가면 병렬 세션의 수가 많아진다. 하지만 위 로직에서 알 수 있듯이 결국 RBT 내에서 Table, Row단위로 TX Dependency가 잘 풀려야 병렬 반영이 가능하다. 이로 인해 숫자를 올린다고 반드시 올린 숫자만큼 정비례하게 증가하지 못하는 경우도 발생한다.

APPLY 프로세스에서 DML 반영 시 MAP 파라미터로 지정한 History 테이블에 반영된 history 를 남기는 기능이다.

해당 기능을 사용하기 위해서는 기존 ProSync 동기화를 진행하는 인스턴스 이외에 DML History 기능 작동을 위한 인스턴스가 추가로 하나 더 필요하다.

APPLY 프로세스의 config 파일인 [inst_id]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

Redo Log는 물리적인 위치에 대한 변경분이 남는다. RDBMS (주로 Oracle, Tibero) 에서는 row 데이터가 ROW_ID 라는 고유의 값을 가지게 되는데, 이 ID에는 데이터 파일의 위치, 파일 내 데이터 블록의 위치, 블록 내 row의 위치 에 대한 정보가 저장되어있다.

ProSync는 이 물리적으로 정해진 ROW_ID만 가지고는 Target Database에서 정확하게 어떤 row인지 판별할 수가 없다. 왜냐하면 데이터 파일도 다를 것이고, 블록 위치나 row 위치 정보도 모두 다르기 때문에 ROW_ID로는 서로 다른 Database의 row를 매칭 시키기가 어렵다.

따라서 SUPPLEMENTAL_LOGGING옵션 등을 통해 row 데이터의 추가적인 정보를 Redo Log상에 함께 남기게 된다. 예를 들면, 사용자가 Where Clause에 1개의 Column정보만 넣었다고 하더라도, Redo Log에는 해당 Row 내에 있는 모든 Column 정보가 다 남도록 해준다.

Target Database와 Apply 프로세스는 이 정보를 가지고 쿼리를 재구축한다. 다만 이렇게 되면, Primary key 를 가지고 있는 테이블 입장에선 불필요한 다른 컬럼 정보들을 Where Clause에 입력해주는 경우가 생긴다. Database의 플랜 별로 최적화되어 잘 처리될 수도 있지만, 불필요한 상황 자체를 방어하기 위해 ProSync에선 Primary key만 사용할지에 대한 여부를 파라미터로 관리한다.

USE_PK_FOR_WHERE 이 파라미터를 사용하면 Primary key가 있는 테이블에 대한 Update나 Delete 시에 Where Clause에는 Primary key만 입력하게된다.

ProSync는 동기화 과정 중에 전달하는 세그먼트를 파일에 순차적으로 기록할 수 있다. APPLY 프로세스에서 Target DB에 반영하는 STATEMENT 를 파일에 저장할 수 있는데, 이를 SAM 기능이라고 한다.

다음은 SAM 기능을 지원하는 데이터 타입이다.

[INST_ID]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

본 절에서는 TX_SAM_TEMPLATE, STMT_SAM_TEMPLATE, COL_SAM_TEMPLATE 파라미터에서 사용할 템플릿을 설정하는 방법에 대해 서술한다.

템플릿 구성요소는 '% + 알파벳 하나(대소문자 구분)"으로 구성하며, 이렇게 구성된 표현값을 치환하여 Sam File에 출력한다.

ProSync 사용자는 적용 프로세스의 설정 파일에서 DDL 파라미터를 설정할 수 있다. DDL 파라미터는 동기화 할 DDL에 대한 설정이다.

DDL 파라미터는 하나 이상의 DDL Rule 문장으로 구성된다. DDL Rule에는 DDL 동기화를 포함/배제할 대상과 DDL 종류를 명시할 수 있다.

사용법

DDL=([SET] [RANGE], TYPE=('[DDL OPERATION] [DDL OBJECT]', ...))

다음은 Source DB에 따라 설정 가능한 [DDL OPERATION]과 [DDL OBJECT]의 조합이다.

다음은 모든 스키마에 대해서 모든 종류의 DDL 동기화를 하지만, 스키마 EXCLUDED_USR의 모든 테이블에 대한 DDL 동기화는 배제하는 예제이다.

다음은 동기화 대상 테이블에 대해 TABLE을 대상으로 하는 DDL을 동기화하고, INCLUDED_USR의 모든 오브젝트 이름에 대해 INDEX를 대상으로 하는 DDL을 동기화한다. 반면, 오브젝트 이름이 EXCLUDED_USR.IDX1일 경우 INDEX를 대상으로 하는 DDL을 동기화하지 않는다.

다음은 SRCUSR의 모든 테이블에 대해 TYPE에 해당되는 DDL을 동기화하지만, SRCUSR.T1에 대해서는 DROP TABLE과 CREATE TABLE에 해당되는 DDL을 동기화하지 않는다.

• DDL 문장 크기 동기화 할 DDL 문장의 각 요소는 128글자를 넘을 수 없다.

• 설정 전 확인 DDL 파라미터의 대상과, 동기화 할 DDL 종류가 정확한지 Wildcard를 고려하여 확인하고 설정한다. 다른 DB나 대상에게 먼저 적용해보고 설정하는 것을 권장한다.

• CREATE TABLE 이후 동기화 CREATE TABLE에 대한 DDL 동기화 후 생성된 테이블을 DML 동기화 하려면 수동으로 동기화 대상 추가를 해야한다. 반면 DDL은 Rule에 의해 생성된 직후부터 동기화 될 수 있으므로 주의한다.

• implicit DDL CREATE TABLE에 대한 DDL 동기화 실행 중 컬럼의 PRIMARY KEY로 인해 INDEX 생성이 되는 것처럼 명시되지 않은 DDL을 implicit DDL이라 하며, 동기화 설정할 때 이를 주의한다.

테이블, 컬럼 매핑 기능을 사용하기 위해서는 $PRS_HOME/config 디렉터리의 Apply config file인 '[INST_ID]_apply1.cfg'를 설정한다.

다음은 설정해야 할 파라미터에 대한 설명이다.

기본 MAP 파라미터에 Source DB의 특정 테이블을 Target DB의 특정 테이블로 동기화하기 위한 규칙을 설정한다.