양방향 동기화 관련 준비사항

ProSync의 양방향 동기화는 사용 중인 데이터베이스에 따라 설정이 달라진다.

ProSync의 양방향 동기화에서 가장 중요한 것은 아래와 같다.

그림 1. Duplicated Redo

한쪽 프로싱크에서 추출된 Change Data를 반영하게 되면, Target Database의 관점에선 변경 분의 데이터가 생성된 것이기 때문에 Redo 상에 이 이력을 남기게 된다. 만약 이 내용을 반대쪽 ProSync가 추출하여 Source Database로 넘기게 된다면, 이 내용은 중복 반영될 수 있다.

따라서 중복 처리를 방어하기 위한 동작이 필요하며, ProSync는 DB 별로 다른 정책을 정의하여 양방향 동기화를 지원한다.

Target Tibero의 경우

Tibero를 Target Database로 하는 경우, Redo Log상에 남는 Database Session정보를 가지고 걸러낼 수 있다. Extract 입장에선 다른 ProSync의 Apply프로세스가 이 DML을 반영했다는 정보만 확인하면 되기 때문에, EXCLUDE_USER라는 파라미터에 다른 ProSync들의 Apply프로세스가 사용하는 ProSync User ID만 설정해주면 된다.

그림 2. Tibero Bi-directional Syncing

Target Oracle의 경우

Oracle을 Target Database로 하는 경우, Redo Log상에 있는 정보로 모두 걸러낼 수가 없다. 따라서 ProSync의 특징을 이용해서 Transaction단위로 처리하게 된다.

ProSync는 Apply 과정에서 PRS_COMMITTED_TX_LIST 라는 이름의 메타테이블에 트랜잭션 별 이력을 올리도록 되어있는데, 반대쪽 ProSync 입장에선 이 테이블을 건드리는 부하들에 대해선 모두 Rollback 처리를 하면 된다.

Rollback또한 DB에 부하를 주는 것이 아닌 Apply Process 에서 확인할 수 있는 Construct의 TX_HASH 에서 모두 처리가 가능하여, 메모리 작업으로 Rollback이 가능하다.

그림 3. Oracle Bi-directional Syncing

참고

Taget Database로서 Tibero, Oracle에 대한 보다 상세한 내용은 User Filtering 에서 확인한다.

Last updated