1 of 17

Mapping

본 장에서는 Map 파라미터를 통해 설정할 수 있는 Resolution Rule (DCR)과 Schema Mapping을 위한 DDL 설정에 대해 알아본다. Mapping은 기본적으로 테이블명, 컬럼명에 대한 Mapping을 지원한다.

MAP Rule

테이블, 컬럼 매핑 기능을 사용하기 위한

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

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

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

인자

설명

Flow Control

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

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

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

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

Performance

ProSync는 Apply 프로세스 지연 시 모든 곳에 지연이 발생하게 된다. 이 때문에 성능을 올릴 수 있는 수단들이 존재한다. 본 장에선 Performance 측면에서 설정할 수 있는 Configuration들에 대해 알아본다.

Batch Execution

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

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

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

같은 형태의 쿼리
Batch로 모았을 때의 한계

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

Parallel Execution (Parallel Replay)

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

의존성 체크는 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가 잘 풀려야 병렬 반영이 가능하다. 이로 인해 숫자를 올린다고 반드시 올린 숫자만큼 정비례하게 증가하지 못하는 경우도 발생한다.

Where Clause

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만 사용할지에 대한 여부를 파라미터로 관리한다.

Parameter 관련

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

주의

Data Conflict Rule(DCR) 관련

옵션을 사용할 경우 USE_PK_FOR_WHERE 옵션은 무시된다. 동기화의 논리 구조상 Conflict를 찾는 것이 우선이기 때문에 ProSync에선 두 옵션 간에 이와 같은 우선순위를 둔다.

Conflict

데이터 충돌 발생 시, 처리방안에 대해 확인한다.

Data Conflict Rule (DCR)

MAP Rule에서 소개한 Data Conflict Rule의 시나리오들을 정리한다. 옵션을 설정하는 방법은 해당 문서를 참고한다.

DCR의 제약사항

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

Prosync는 where절에 lob column은 확인하지 않으므로, 비교 시 해당 column의 데이터가 다르더라도 다른 column 값이 동일하다면 성공적으로 dml을 수행한다.

DCR - MIN/MAX 설정 후 동일한 값으로 dml 수행 시, 비교 로직에서 충돌을 유발하지 않으므로 양측 노드에서 정상 dml을 수행한다.

시나리오

Resolve By Source

1. Insert

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

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

2. Update

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

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

3. Delete

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

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

Resolve By Target

1. Insert

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

2. Update

Row가 없는 상황이 맞다고 판단하기 때문에 별도의 작업 없이 해당 처리를 건너뛴다.

위 두 경우에 대한 조합으로 볼 수 있다. 상황에 따라 Source 기준 또는 Target 기준에 맞춰 수행하는 시나리오다. 기준이 되는 것이 Database 단위가 아닌 Column 내 데이터의 대소 비교로 이루어진다는 점이 다르고, 이에 따라 충돌 처리 동작은 위의 Source / Target과 동일하게 작동한다.

History

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

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

Sequential Access Method (SAM)

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

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

구분

지원 타입

Tibero

NUMBER, CHAR, VARCHAR, DATE, TIME, TIMESTAMP, INTERVAL YEAR TO MONTH, INTERVAL DAY TO SECOND, CLOB, TIMESTAMP WITH TIMEZONE, TIMESTAMP WITH LOCAL TIMEZONE, BINARY_FLOAT, BINARY_DOUBLE

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

Parameter

설명

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

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

항목

표현값

의미

항목

표현값

설명

항목

표현값

설명

DML Error Report

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

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

파라미터

설명

APPLY_TO_REPORT

Dml Error Report 기능의 사용 여부를 결정한다. (Y|N)

Y : report file에 row by row로 DML이 남게 된다. (기본값)
N : report file에 row by row로 DML이 남지 않는다.

DML History

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

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

참고

다음의 타입들에 대해선 이 기능을 제공하지 않는다.

아래의 타입이 있는 테이블의 경우에는 컬럼의 값이 NULL로 기록된다.

LONG

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

Parameter

설명

RECORD_HISTORY

추가적으로 동기화 대상 테이블에 추가적인 column들이 필요하다.

column

설명

*statement template file 설정* stmt { op: %O op code: %o owner: %W table name: %N sgmt id: %I tsn: %T wrap no: %R log seq: %L set: %s where: %w values: %v ddl/dml string: %D } *column template file 설정* col { name: %N values: %V column count: %n } *INSERT STATEMENT 결과 예제* INSERT) stmt { op:INSERT op code:0 owner:PRS_TEST table name:VARCHAR_T sgmt id:26424 tsn:26362394 wrap no:43 log seq:2102 set: where: values: col { name:C1 values:1 column count:0 } col { name:VCHAR_COL values:VARCHAR column count:1 } ddl/dml string:INSERT INTO "PRS_TEST"."VARCHAR_T" ("C1", "VCHAR_COL") VALUES (1, VARCHAR) } *UPDATE STATEMENT 결과 예제* UPDATE) stmt { op:UPDATE op code:2 owner:PRS_TEST table name:NVARCHAR_T sgmt id:26436 tsn:26362421 wrap no:87 log seq:2103 set: col { name:NVCHAR_COL values:NVARCHAR2 column count:1 } where: col { name:C1 values:10 column count:0 } col { name:NVCHAR_COL values:NVCHAR column count:1 } values: ddl/dml string:UPDATE "PRS_TEST"."NVARCHAR_T" SET NVCHAR_COL = NVARCHAR2 WHERE C1 = 10 AND NVCHAR_COL = NVCHAR } *DELETE STATEMENT 결과 예제* DELETE) stmt { op:DELETE op code:1 owner:PRS_TEST table name:NVARCHAR_T sgmt id:26436 tsn:26362437 wrap no:175 log seq:2103 set: where: col { name:C1 values:10 column count:0 } col { name:NVCHAR_COL values:NVARCHAR2 column count:1 } values: ddl/dml string:DELETE FROM "PRS_TEST"."NVARCHAR_T" WHERE C1 = 10 AND NVCHAR_COL = NVARCHAR2 } *DDL STATEMENT 결과 예제* DDL) stmt { op:DDL op code:9 owner:PRS_TEST table name:NVARCHAR_T sgmt id: tsn:26362654 wrap no:332 log seq:2103 set: where: values: ddl/dml string:truncate table nvarchar_t }