Process 설명

Extract 프로세스는 Source DB의 변경 로그를 추출하여 Apply 프로세스로 전달하는 동작을 수행한다.

Source DB가 Tibero 또는 Oracle인 경우, redo log를 읽어 변경 로그를 추출하므로 반드시 redo log에 접근 가능한 위치(일반적으로 Source DB가 존재하는 장비)에서 기동되어야 한다.

Source DB가 PostgreSQL인 경우에는 WAL logical replication 연결(network)을 통해 변경 로그를 추출하므로 반드시 Source DB 서버에 기동될 필요는 없으며, Source DB에 network로 접속할 수 있고 replication 권한이 있는 위치라면 기동할 수 있다.

변경의 최소 단위는 LCR로, 레코드 단위의 변경을 의미하며 네트워크 부하를 고려하여 여러 LCR을 Chunk로 만들어 Apply 프로세스에 전달한다.

Threads

Control Thread

기동 시 다른 Thread 시작, 메시지 수신 및 전송 등의 작업을 수행한다.

Resource Thread

프로세스의 CPU/Memory 사용량을 수집한다. ProSync 매니저 사용 시, Agent 프로세스를 통해 수집한 값을 ProSync 매니저로 전송한다.

Worker Thread

동기화 테이블 추가, 동기화 할 테이블 및 컬럼들의 정보인 DD image 조회, DB의 상태 파악을 위한 dummy tx 생성 등 변경 데이터 추출과는 상관없는 메타데이터 조회나 수정과 같은 작업을 수행한다.

또한 Apply 프로세스로 나가는 연결(connect)은 Worker Thread가 수행하며, 연결된 소켓은 Control Thread에 전달되어 이후 통신에 사용된다.

추출한 변경을 Text 파일로 출력하는 SAM 기능을 수행한다.

변경 데이터를 추출하고 이를 Chunk형태로 만든 뒤 Control 스레드를 통해 Apply 프로세스에 전달한다.

Source DB가 Tibero 또는 Oracle인 경우 Log Reader 라이브러리를 사용해 redo log에 접근하며, PostgreSQL인 경우 logical replication 연결을 통해 WAL을 읽는다. 비정상 종료, Apply 프로세스 재연결 등의 장애 상황 발생 시, 마지막으로 읽고 있던 redo를 처음부터 다시 읽기 시작한다.

추출 시작 지점은 Apply 프로세스에 저장되어 있기 때문에, Apply 프로세스와 연결 전까진 추출을 시작하지 않는다.

ProSync는 Archiving되지 않은 온라인 Redo Log는 추출하지 않고, Archiving이 완료된 Archive Log만을 추출하여 Apply 프로세스로 전달할 수 있다.

EXTRACT_ARCHIVE_LOG_ONLY=[Y|N]

ProSync는 특정 사용자에 의해서 발생된 DML 및 DDL을 동기화에서 제외할 수 있는 기능을 제공한다.

양방향 동기화

같은 테이블에 대해 Source DB에서 Target DB로, Target DB에서 Source DB로 동기화 하도록 2개의 ProSync 인스턴스를 사용하여 구성할 수 있다. 이 경우, 별 다른 설정이 없다면 상대방의 PRS_USER가 반영한 동기화 데이터가 다시 추출되어 Source DB로 전송될 수 있다.

Redo Log에는, tx에 대해 이를 수행 한 User를 알 수 있는 정보가 있으며 ProSync는 이 정보를 활용해 상대방의 PRS_USER로 EXCLUDE_USER 파라미터를 설정하여 이미 반영한 데이터를 재반영하는 현상을 막을 수 있다.

사용

다음은 TEST 사용자와 PRS_USER 사용자를 동기화에서 제외하는 예제이다.

EXCLUDE_USER=PRS_USER,TEST

Source DB가 Tibero, Oracle인 경우, 암호화된 테이블에 대한 동기화를 지원한다. 암호화된 테이블 동기화를 위해서는 복호화를 위한 Wallet file 접근 권한이 필요하다.

TDE_FOR_EXT=[Y|N] TDE_WALLET_FILE=file_path TDE_WALLET_PWD=wallet_password TDE_FOR_APPLY=[Y|N] TDE_FOR_TABLESPACE=[Y|N]

Source DB가 Tibero인 경우, 압축된 테이블에 대한 동기화를 지원한다. 압축 테이블의 변경 데이터는 Redo Log에 압축 심볼 참조 형태로 기록되며, Extract 프로세스는 Supplemental Log에 포함된 심볼 매핑 정보를 이용하여 이를 원본 값으로 복원한 후 동기화한다.

압축 테이블 동기화를 위한 별도의 파라미터 설정은 필요하지 않으며, 다음 조건을 만족하면 자동으로 동작한다.

• 동기화 대상 테이블에 Supplemental Logging이 설정되어 있어야 한다.

• Source DB(Tibero)와 ProSync 모두 압축 테이블 동기화를 지원하는 버전이어야 한다.

SQL> CREATE TABLE TEST.T_COMP (C1 VARCHAR(2000), C2 NUMBER) COMPRESS FOR OLTP;
SQL> ALTER TABLE TEST.T_COMP ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

지원 범위

ProSync는 Extract 프로세스에서 Apply 프로세스로 데이터를 전송할 때 네트워크 부하 감소를 위한 데이터 압축을 사용할 수 있다.

ENABLE_NETWORK_COMPRESS=[Y|N] NETWORK_COMPRESS_LEVEL=compress_level

동기화할 object들의 Type, Owner, Name, 등록 시기를 저장한다.

tlr(olr)파일의 위치, seq 정보를 저장한다.

tlr(olr)파일은 Redo Log를 모두 읽고 다음 Log를 읽기 전 아직 commit되지 않은 tx 정보를 저장한 파일로 ProSync는 Begin이 없는 tx에 대해서는 추출하지 않기 때문에, 기동 시점에 따라 누락되는 tx가 없도록 이전 Redo Log를 읽었을 때 아직 commit되지 않은 tx정보를 저장한다.

발생한 DDL의 시점, DDL 종류, 메타 테이블 업데이트 여부, 이후 ProSync가 사용하는 DD의 Sequence 정보를 저장한다.

Source DB가 Oracle이며 Log Miner를 사용하여 동기화 하는 경우 사용한다. DD 정보를 저장한 dict파일 정보를 저장한다.

Source DB에 존재하는 USER들의 이름과 USER_ID를 저장한다. User Filtering 기능을 사용하기 위해 저장한다.

ProSync는 Extract 프로세스에서 Apply 프로세스로 데이터를 전송할 때 보안을 위한 데이터 암호화를 사용할 수 있다.

AES-256-CBC 암호화를 사용하며 Redo(Archive)log 에서 추출한 변경 데이터에 대한 암호화만을 제공한다.

ENABLE_NETWORK_ENCRYPT=[Y|N]

ProSync는 Source 데이터베이스의 Sequence 객체 값을 Target 데이터베이스로 실시간 동기화하는 기능을 제공한다. Sequence의 NEXTVAL이 호출되며 속성값이 갱신될 때 마다 Target으로 전달된다.

ProSync는 Source Oracle이 ASM(Automatic Storage Management)을 사용하는 환경에서 ASM Diskgroup에 저장된 Redo Log와 Archive Log를 추출할 수 있다.

ASM Diskgroup의 파일은 운영체제 파일 시스템에 그대로 노출되지 않으므로 일반적인 파일 읽기로는 접근할 수 없다. Extract 프로세스는 ASM 인스턴스에 직접 접속하여 Diskgroup 경로(+로 시작하는 경로)의 로그 파일을 읽는다.

지원 범위

Extract 프로세스는 읽으려는 로그 파일의 경로를 보고 읽기 경로를 결정한다.

경로에 따라 읽기 경로가 결정되므로 Redo Log와 Archive Log 중 일부만 ASM Diskgroup에 저장된 혼합 구성에서도 사용할 수 있다. ASM 사용 여부를 지정하는 별도의 파라미터는 없으며, ASM 접속 정보를 설정하면 ASM 경로의 파일에 대해 ASM 읽기가 사용된다.

ASM 경로의 로그를 읽을 때 Extract 프로세스는 ASM 인스턴스에 ASM_IO_WORKERS 개수만큼 병렬 I/O Worker 세션을 만든다. 각 Worker는 로그 파일 읽기만 수행하고, 읽어온 Redo의 분석은 로그 리더가 별도로 수행한다.

ASM_IO_WORKERS는 Extract 프로세스 기동 시에만 반영되므로, 값을 변경한 경우 Extract 프로세스를 재기동해야 한다.

Extract 프로세스가 ASM 인스턴스에 접속할 별칭을 tnsnames.ora에 등록한다. 이 별칭을 ASM_DB_NAME에 설정한다.

ASM 접속 계정은 ASM 인스턴스에 접속하여 Diskgroup의 파일을 읽을 수 있어야 하므로 SYSASM 권한을 가진 계정을 사용한다.

등록한 별칭으로 접속이 되는지 확인한다.

Redo Log와 Archive Log가 ASM Diskgroup에 저장되어 있는지 확인한다. 경로가 +로 시작하면 ASM 로그 추출 설정이 필요하다.

ASM_PWD=#encrypted는 암호화된 문자열 자체가 아니라, 실제 비밀번호를 wallet 파일에서 읽으라는 표시(sentinel)이다. 따라서 config 파일만 다른 노드로 복사해서는 프로세스를 기동할 수 없으며 wallet 파일(var/<instance>/.wallet_asm)을 함께 이관해야 한다.

설치 config 파일에 ASM 접속 정보를 설정하면 설치 과정에서 ASM 구성이 반영된다.

ASM 접속 정보를 설정하고 설치하면 다음이 수행된다.

• ASM_PWD 암호화 및 wallet 파일 저장

• 생성되는 Extract config에 ASM 파라미터 자동 기입

설치 후 생성된 Extract config에 다음 값이 기입되어 있는지 확인한다.

Extract 프로세스는 활성 Online Redo Log의 경로가 ASM Diskgroup 경로인 경우 ASM 인스턴스 접속을 통해 해당 파일을 읽는다. 읽기는 I/O Worker 세션이 병렬로 수행하고, 로그 리더는 읽어온 블록의 Redo를 분석하여 LCR을 생성한다.

Archive Log는 다음 순서로 위치를 결정한다.

1. ARCHIVE_LOG_DIR이 설정된 경우 해당 디렉터리에서 Archive Log 파일을 먼저 찾는다.

2. 해당 디렉터리에서 찾지 못하거나 ARCHIVE_LOG_DIR이 설정되지 않은 경우 V$ARCHIVED_LOG 조회 결과의 ASM 경로(+DISKGROUP/...)로 접근한다.

ARCHIVE_LOG_DIR은 절대 경로의 디렉터리만 유효한 값이다. 따라서 log_archive_dest가 FRA(USE_DB_RECOVERY_FILE_DEST)이거나 ASM Diskgroup(+...)인 표준 ASM 구성에서는 설치 과정에서 ARCHIVE_LOG_DIR에 값이 기입되지 않으며, Archive Log 위치는 위의 순서에 따라 운영 중에 결정된다.

ASM_PWD는 암호화되어 인스턴스의 wallet 파일(var/<instance>/.wallet_asm)에 저장된다. wallet 파일은 백업 대상에 포함해야 하며, ASM 접속 계정의 비밀번호를 변경한 경우 wallet을 다시 생성해야 한다.

• ASM 로그 추출은 Source Oracle 전용이다.

• ASM_IO_WORKERS는 Extract 프로세스 기동 시에만 적용된다. 운영 중 변경하려면 프로세스를 재기동해야 한다.

• ASM_IO_WORKERS는 최대 8까지 설정할 수 있다.

ProSync는 Tibero Standby Cluster(이하 TSC) 환경에서 Standby DB를 Source로 하는 동기화를 지원한다.

TSC 환경에서 Extract 프로세스와 Llob 프로세스는 Redo Log 읽기와 Flashback 조회를 Standby DB에서 수행하고, Source DB에 쓰기가 필요한 메타데이터 작업은 쓰기 가능한 Primary DB로 라우팅한다. Failover로 Standby DB가 Primary로 승격되면 쓰기 라우팅을 승격된 DB로 자동 전환한다.

Standby DB에서 추출을 수행하므로 운영 중인 Primary DB의 부하를 줄일 수 있고, Source DB의 장애 전환 이후에도 재설치 없이 동기화를 이어갈 수 있다.

지원 범위

TSC Standby 동기화에서 각 접속 별칭(Alias)의 역할은 다음과 같다.

정상 TSC 상태와 Failover 이후의 작업별 라우팅은 다음과 같다.

TAC-TSC 환경에서는 Primary TAC의 Redo Thread 수만큼 Extract 프로세스를 기동한다. 이때 별칭은 다음과 같이 배치한다.

• 모든 Extract 프로세스와 Llob 프로세스의 SRC_DB_NAME은 같은 Standby 별칭을 사용한다.

• Extract 프로세스별 SRC_LOCAL_SID는 해당 Redo Thread의 로그를 기록하는 Standby 인스턴스로 직접 접속하는 별칭으로 설정한다. Extract 프로세스는 이 접속에서 인스턴스 번호를 조회하여 활성 Standby Log를 읽을 접속 지점을 결정하므로, 이 별칭이 다른 인스턴스를 가리키면 활성 Standby Log의 변경분을 읽지 못한다.

• Extract 프로세스별 SRC_PRIMARY_LOCAL_SID는 해당 Redo Thread를 소유한 Primary 인스턴스로 직접 접속하는 별칭으로 설정한다.

TSC 환경을 Source로 사용하는 경우 ProSync용 TIP 파일 설정은 Primary DB와 Standby DB 모두(TAC-TSC는 모든 노드)에 적용되어 있어야 한다. Failover 이후에는 승격된 Standby DB가 Redo를 생성하는 추출 소스가 되기 때문이다. 설정 항목은 페이지를 참고한다.

Standby DB는 read-only 모드로 open되어 있어야 한다. read-only 모드가 아니면 접속이 거부된다.

RECOVERY 모드로 운영 중인 Standby DB는 다음 명령으로 복구를 중단하지 않고 read-only 세션을 허용하도록 전환할 수 있다.

Standby 별칭으로 접속하여 역할을 확인한다. 정상 TSC 상태의 기대값은 STANDBY이다.

Primary 별칭으로 접속하여 역할이 PRIMARY인지 함께 확인한다.

ProSync Source 계정은 TSC 역할과 Standby 복구 상태를 조회할 수 있어야 한다.

TAC-TSC 환경에서는 GV$INSTANCE, GV$PARAMETERS 조회 권한도 필요하다. 두 뷰는 활성 Standby Log를 읽을 인스턴스별 접속 지점을 결정하는 데 사용한다. 권한이 없으면 기동 시 역할 검증, Failover 감지, 복구 상태 대기 등이 실패하거나 재시도 상태에 머무를 수 있다.

PRS_OBJ_LIST, PRS_TXINFO 등 ProSync가 Source DB에 생성하는 메타데이터 객체는 쓰기 가능한 Primary DB에 생성되어 있어야 한다. 설치 구성에서 USE_TSC=Y를 설정하면 설치 과정의 Source DB 측 객체 생성 작업이 Primary에서 수행된다.

ENABLE_TSC_STANDBY=[Y|N]

Single TSC 구성의 예시는 다음과 같다.

TAC-TSC(2 Thread) 구성에서는 Extract 프로세스별로 인스턴스 직결 별칭을 다르게 설정한다.

SRC_PRIMARY_LOCAL_SID는 Extract 전용 파라미터이므로 Llob 설정에는 넣지 않는다.

설치 config 파일에 USE_TSC=Y를 설정하면 설치 과정에서 TSC 구성이 자동으로 반영된다.

USE_TSC=Y로 설치하면 다음이 수행된다.

• Primary 별칭 접속 확인 및 별칭 중복 검증

• Source DB 측 설치 DDL/DML의 Primary 수행 (Archive Log 정보 조회는 Standby에서 수행)

• 생성되는 Extract/Llob config에 TSC 파라미터 자동 기입

설치 후 생성된 process config에 다음 값이 기입되어 있는지 확인한다.

Standby DB에서 추출할 때 Extract 프로세스는 전체 Redo Thread의 MIN(RECOVERED_TSN)(안전 추출 TSN)까지만 LCR을 전송한다. Failover 승격 시 복구로 재적용되지 않을 수 있는 Redo가 Target DB에 먼저 반영되는 것을 막기 위한 경계이다.

LCR의 TSN이 안전 추출 TSN을 넘으면 Standby 복구가 따라올 때까지 대기한 뒤 전송하며, 대기는 _TCP_CONNECT_INTERVAL 주기로 재시도한다.

PRS_TXINFO의 조회/저장, 동기화 테이블 추가/삭제 시의 Source DB 측 작업(PRS_OBJ_LIST 등록, Supplemental Log 변경 등), Dummy Transaction, Logfile Switch는 쓰기 가능한 라우팅 경로에서 수행된다. 정상 TSC 상태에서는 Primary 별칭에서 수행되고, Failover 이후에는 승격된 Standby 별칭에서 수행된다.

조회와 저장은 항상 같은 DB 접속(쓰기 라우팅이 가리키는 DB)을 사용한다. 정상 TSC 상태에서는 조회도 Primary 별칭에서 수행하며 Standby에서 조회하지 않는다. 이는 Standby 복구 지연으로 인해 Primary에 저장한 메타데이터를 Standby에서 조회하지 못하는 불일치를 막기 위한 동작이다.

Llob 프로세스는 Standby DB에서 Flashback 조회를 수행한다. Standby 복구가 Flashback 조회 시점(AS OF SCN)보다 늦으면 잘못된 값을 읽을 수 있으므로, 조회 전에 전체 Redo Thread의 MIN(RECOVERED_TSN)이 조회 시점 이상이 될 때까지 대기한다.

Failover 이후 Source 별칭이 이미 PRIMARY인 경우에는 대기를 생략한다.

SRC_DB_NAME의 역할이 STANDBY, SRC_PRIMARY_DB_NAME의 역할이 PRIMARY인 상태이다. 쓰기 라우팅은 Primary 별칭을 가리킨다.

SRC_DB_NAME이 여전히 STANDBY인데 Primary 역할 조회가 실패하면 ProSync는 Standby에 쓰기 작업을 보내지 않는다. 쓰기 라우팅은 Primary 방향을 유지한 채 재접속을 재시도한다. 이는 Standby에 메타데이터 쓰기를 보내지 않기 위한 안전 동작이다.

쓰기 작업 직전, 로그 대기 중, 안전 추출 TSN 대기 중에 SRC_DB_NAME의 역할이 PRIMARY로 확인되면 Failover 승격으로 판단한다. 이후 쓰기 라우팅과 읽기 라우팅이 모두 승격된 SRC_DB_NAME으로 통합되고, 기존 DB 접속은 새 라우팅 기준으로 재연결된다.

Extract 프로세스는 승격을 감지하면 읽고 있던 로그를 마지막 안전 지점부터 다시 열고 트랜잭션 추적 상태를 초기화하여, 승격 이전 로그 기준의 상태가 이월되어 변경분이 유실되는 것을 방지한다.

한 번 승격 상태로 전환되면 이전 Primary가 다시 PRIMARY로 돌아와도 ProSync는 실행 중 자동으로 라우팅을 되돌리지 않는다(자동 Switchback 미지원). 이전 Primary로 복귀하려면 TSC 구성 상태와 ProSync 설정을 확인한 뒤 명시적으로 재기동해야 한다.

• TSC Standby 동기화는 Tibero Source 전용이다.

• TAC-TSC는 Primary와 Standby의 노드 수가 동일해야 한다.

• Standby DB는 read-only 모드로 open되어 있어야 한다.

• Failover 이후 이전 Primary로의 자동 Switchback은 지원하지 않는다.

운영 중 다음 로그 키워드로 TSC 동작 상태를 확인할 수 있다.

• SRC_DB_TYPE=TIBERO인지 확인한다.

• ENABLE_TSC_STANDBY=Y일 때 SRC_PRIMARY_DB_NAME이 설정되어 있는지 확인한다.

• Standby DB가 read-only 모드로 open되어 있는지 확인한다.

waiting for TSC safe extraction TSN 또는 waiting for TSC standby recovery 로그가 지속되면 Standby 복구가 지연되고 있는 것이다.

• Standby에서 SELECT MIN(RECOVERED_TSN) FROM V$STANDBY 값이 전진하는지 확인한다.

• 특정 Redo Thread의 복구만 지연되고 있는지 확인한다. 전체 Thread의 최솟값 기준으로 대기하므로 한 Thread만 늦어도 대기한다.

• Redo 전송 또는 Standby 복구 지연 여부를 확인한다.

• SRC_DB_NAME의 역할이 아직 STANDBY인지 확인한다. Standby가 승격되지 않았다면 쓰기 작업을 보내지 않는 것이 정상 동작이다.

• Failover가 완료되어 SRC_DB_NAME의 역할이 PRIMARY가 되었는지 확인한다.

특정 Extract 프로세스의 변경분만 Target DB에 반영되지 않으면 활성 Standby Log를 잘못된 접속 지점으로 읽고 있을 수 있다.

• 해당 Extract 프로세스의 SRC_LOCAL_SID가 그 Redo Thread의 로그를 기록하는 Standby 인스턴스 직결 별칭인지 확인한다.