프로세스 Crash / Thread 장애

ProSync 프로세스의 signal 처리에는 일반적인 Unix 데몬과 다른 특성이 있다.

• SIGSEGV, SIGBUS, SIGILL, SIGFPE 등의 fault가 발생하면 core 파일 대신 $PRS_HOME/var 하위의 prosync.out.<pid> 파일에 callstack이 기록된다.

• Control Thread가 아닌 worker thread에서 crash가 발생하면 해당 thread만 종료될 수 있다. 따라서 프로세스 PID가 살아 있어도 필수 thread가 DEAD 상태일 수 있다.

• SIGINT, SIGTERM, SIGHUP 신호는 무시된다. 지원되는 종료 방법은 Admin의 SHUTDOWN 명령이다.

프로세스가 비정상 동작하거나 응답하지 않는 경우 다음 순서로 점검한다.

1. $PRS_HOME/var 하위에서 prosync.out.<pid> 파일을 찾아 callstack을 확인한다.

2. STATUS <inst_id> 명령으로 모든 thread의 상태를 확인한다. 프로세스가 running이라도 개별 thread가 죽어 있을 수 있다.

3. 필요 시 ALLOCDUMP, TRACEDUMP

설치 시 생성되는 cfg 파일에는 PRS_PWD=#encrypted와 같이 기록되는데, #encrypted는 암호화된 암호 문자열이 아니라 실제 암호를 wallet 파일에서 읽으라는 표시(sentinel)다.

암호가 저장되는 wallet 파일은 다음과 같다.

운영 시 다음 사항을 지켜야 한다.

• 설정 파일(config)만 다른 노드로 복사해서는 프로세스를 기동할 수 없다. 노드 이관 시에는 wallet 파일을 함께 이관해야 한다.

• wallet 파일은 백업 대상에 포함해야 하며, 파일 권한은 ProSync 운영 계정만 읽을 수 있도록 관리한다.

• DB 비밀번호를 변경한 경우에는 wallet을 다시 생성해야 한다.

• TDE를 사용하는 경우 .wallet

Llob 프로세스는 Apply 프로세스의 요청에 따라 read Thread 에서 해당 시점(TSN 또는 SCN)의 llob 데이터에 대한 select 쿼리를 수행하기 때문에, 해당 시점에 대한 정보가 없는 경우(flashback 쿼리 실패) 현재 시점을 기준으로 조회하며 이때, 현재 시점에 해당 row가 존재하지 않는다면 조회를 실패할 수 있다.

Apply 프로세스에서 최대 20개의 Replay Thread 를 사용하여 동기화를 수행할 수 있고, 모든 Thread 에서 llob 데이터가 존재하는 테이블을 동기화 한다면 Llob 프로세스에서 모든 요청을 처리하는데 지연이 발생할 수 있다.

이때, LLOB_THREAD_CNT 파라미터를 사용하여 Apply 프로세스의 요청을 분배해 성능을 개선할 수 있다.

추출한 시점의 TSN(SCN)으로 flashback 쿼리를 수행할 수 없으면서 현재 해당 row가 존재하지 않는다면 llob 데이터 조회가 실패하고 ProSync는 해당 row 동기화를 계속해서 재시도한다.

성능

Apply 프로세스는 Extract 프로세스가 전달한 변경 데이터를 TX별로 정리 후 commit 요청된 시점부터 Target DB에 반영하며 주로 DB에 쿼리를 수행한 후 결과를 기다리는 과정에서 지연이 발생한다.

지연을 방지하기 위해, Target DB에 반영 쿼리를 수행하는 APPLY_NUM 파라미터를 조절하여 Thread 수를 늘려 성능을 개선할 수 있다.

장애

반영 실패

Source DB에서 추출한 변경 데이터에 대해 Target DB에 반영할 수 없는 경우, ProSync는 실패한 DML을 성공할 때 까지 다시 시도한다.

사용자는 해당 데이터가 반영될 수 있도록 Target DB를 수정하거나 DCR 기능 또는 DISCARD 기능을 사용하여 우회할 수 있다.

메모리 과점유

ProSync는 TX에 대해 commit 또는 rollback 이전까지 반영을 시작하지 않기 때문에 commit 없이 변경 데이터를 계속해서 전달받는 경우, Apply 프로세스에서 사용하는 메모리가 증가할 수 있다.

이때, 메모리 조절용 파라미터를 설정하여 사용하는 메모리를 조절할 수 있다.

MEMORY_CTRL_STOP_SIZE/MEMORY_CTRL_RESUME_SIZE

Replay Thread 에서 완료되지 않은 TX들의 총 메모리 크기가 MEMORY_CTRL_STOP_SIZE 파라미터의 값을 넘는 경우 extract 프로세스에서 보내는 chunk를 수신하지 않는다.

이후, Replay Thread 에서 동기화를 수행하여 완료되지 않은 TX들의 총 메모리 크기가 MEMORY_CTRL_RESUME_SIZE 값보다 낮아지는 경우 다시 Extract 프로세스에서 보내는 chunk를 수신한다.

MERGE_BLOCK_CNT/MERGE_RESUME_CNT

TAC/RAC 환경에서 특정 extract 프로세스의 chunk만 계속해서 수신 받는 경우, stmt수가 MERGE_BLOCK_CNT 파라미터의 값을 넘는 경우 해당 extract 프로세스에서 보내는 chunk를 수신하지 않는다.

이후, 다른 extract 프로세스들에게 chunk를 수신 받아 처리되지 못한 stmt수가 MERGE_RESUME_CNT 값보다 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.

extract 프로세스에서 수신한 chunk에 대해, const Thread 에서 처리하지 못한 TX들의 총 메모리 크기가 CHUNK_TOTAL_SIZE 파라미터의 값을 넘는 경우 extract 프로세스에서 보내는 chunk를 수신하지 않는다.

이후, const Thread 가 처리하지 못한 메모리 크기가 파라미터 값의 절반 이하로 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.

apply 프로세스의 Const Thread 메모리에서 관리하는 tx정보들의 크기를 관리하는 파라미터로 commit이 오지 않은 stmt들 정보가 TX_HASH_SIZE를 넘어가는 경우 가장 큰 TX부터 part파일 생성 후 메모리에서 제거하며 해당 값보다 사용하는 메모리가 낮아질 때 까지 반복한다.

Log Switch 감지 시, const Thread 에서 아직 commit되지 않은 tx정보를 재기동 상황에서도 유지하기 위해 txh 파일을 생성한다. 이때, txh 파일의 최대 개수 또는 파일들의 합의 최대 크기를 설정할 수 있다.

TX_HASH_FILE_MODE 파라미터를 통해 제한 방식을 설정할 수 있으며, 각 Extract별로 txh의 크기나 개수를 계산한다.

TX_HASH_SIZE 이상으로 const Thread 에서 TX 정보들이 쌓이게 되는 경우, 메모리 관리를 위해 part파일을 작성하고 메모리에서 제거하게 되며 관련된 TX가 commit 또는 rollback되기 전까지 partfile은 제거되지 않는다. 따라서, 한 TX가 끝나지 않는 경우 디스크 사용량이 계속해서 증가할 수 있다.

Apply의 복구 상태는 Target DB의 PRS_LCT(마지막 반영 TX 정보), PRS_COMMITTED_TX_LIST(commit 완료 TX 목록), 그리고 $PRS_HOME/var/<instance>/tx의 txh_*/txl_* 파일(미완료 TX)로 나누어 관리된다. 각 저장소의 역할은 Apply Process의 ''를 참고한다.

Apply를 재기동하면 Ext와의 재연결 과정(handshake)에서 Apply에 저장된 이력 정보를 Ext에 전달하여 재추출 시작점을 결정한다. Ext는 그 지점부터 다시 추출하므로 일부 구간의 레코드가 재전송될 수 있으며, 이미 반영이 완료된 트랜잭션은 PRS_COMMITTED_TX_LIST를 통해 중복 반영 여부를 판정하여 건너뛴다.

또한 반영 오류로 특정 DML이 계속 재시도되는 동안에는 해당 TX가 반영 완료로 기록되지 않으므로, 복구 기준점(PRS_LCT)도 그 이전 상태로 유지된다.

log switch 시점에 아직 commit이 도달하지 않은 트랜잭션은 $PRS_HOME/var/<instance>/tx의 txh_*/txl_* 파일로 export되며, 재기동 시 import되어 이어서 처리된다.

Source DB에 데이터를 삽입할 때는 해당 DB의 Character Set과 일치하는 Terminal 및 OS의 LANG 환경변수 설정이 반드시 필요하다.

LANG 설정이 Source DB의 Character Set과 일치하지 않으면, ProSync가 데이터를 추출할 때 잘못된 인코딩으로 인식하게 되어, Target DB로 전송 시 문자 깨짐 또는 손상된 데이터가 저장될 수 있다.

따라서, Source DB에 데이터를 입력하는 시스템의 LANG 환경 변수는 Source DB의 Character Set과 정확히 일치시켜야 하며, 시스템 관리자 또는 사용자 환경에서도 일관된 문자셋 설정이 유지되어야 한다.

Trigger가 설정된 테이블을 동기화할 경우, Trigger로 인해 예상치 못한 데이터 중복이 발생할 수 있다. 예를 들어, 다음과 같은 Trigger가 Source DB와 Target DB에 존재한다고 가정한다.

위와 같은 환경에서 TEST.T1 테이블을 동기화할 경우, 다음과 같은 흐름이 발생할 수 있다.

1. Source DB에서 TEST.T1 테이블에 INSERT 수행 -> Trigger 작동 -> TEST.T2에도 데이터 삽입

2. 동기화 과정에서 Target DB에 TEST.T1 INSERT 반영 -> Target DB의 Trigger 작동 -> TEST.T2에도 동일한 데이터 삽입

3. 또한, Source DB에서 추출된 TEST.T2의 INSERT 문이 Target DB에 반영되면서 중복 삽입 발생

이로 인해 Target DB의 TEST.T2 테이블에는 중복된 데이터가 저장될 수 있다.

따라서 ProSync 동기화 로직 상 정합성이 틀어질 수 있기 때문에 Target DB에는 Trigger가 존재해서는 안 된다.

Oracle To Tibero 동기화의 경우, 이미 데이터가 존재하는 테이블에 ALTER TABLE DDL 수행 시 오라클 내부 동작으로 인해 DPI(Direct Path Insert)가 발생하며 Unique Constraints Violation이 발생할 수 있다.

예를 들어, 아래와 같은 형상의 테이블이 존재하며, 다음과 같은 흐름으로 진행된다고 가정한다.

이 때, ALTER TABLE 구문으로 인해 오라클 내부에서 DPI가 발생하며 데이터를 복사하는 과정이 수행되는데, 해당 DPI 구문이 동기화 테이블과 같은 OBJ_ID를 가지고 있어 함께 동기화가 진행되며 Unique Constraints Violation이 발생한다.

해당 오류 발생 시 DISCARD_EC 파라미터에 UNIQUE VIOLATION Error code를 기재하여 우회할 수 있다.

ProSync 운영 중 장애 발생 시, 분석을 위해 현상 발생한 프로세스의 5레벨 로그와 config를 첨부해야 하며 장애 유형에 따라 다음 정보를 추가적으로 요청할 수 있다.

성능

Extract 프로세스는 Redo Log 파일을 읽어 변경 데이터를 추출하기 때문에, 디스크 읽기 속도가 성능에 영향을 줄 수 있으며 변경 데이터는 Chunk 형태로 Apply 프로세스에 전송하기 때문에, 네트워크 속도가 영향을 줄 수 있다.

ProSync 파라미터에 따라 성능이 변화할 수 있다.

1. 로그 레벨(LOG_LEVEL)이 높다면, disk write가 많아짐에 따라 성능이 저하될 수 있다.

2. 데이터 압축 기능을 사용한다면, 데이터 압축을 위한 동작이 추가됨에 따라 성능이 저하될 수 있다.

3. 데이터 암호화 기능을 사용한다면, 데이터 암호화를 위한 동작이 추가됨에 따라 성능이 저하될 수 있다.

ProSync는 적절한 반영 쿼리 생성을 위해 테이블의 DD image 변경이 발생하는 시점에 Trigger를 통해 내부 패키지를 수행하여 메타 테이블을 업데이트한다.

DDL 메타데이터는 DML 변경 데이터와 별도의 경로로 전달된다. Source에서 DDL이 수행되면 설치 시 생성된 trigger(PRS_DDL_TRG, PostgreSQL은 event trigger)가 PRS_DD_META 패키지/함수를 호출하여 PRS_DDL_HIST 테이블에 기록하고, Extract가 PRS_DDL_HIST를 polling하여 DD version을 갱신한 뒤 Apply로 전달한다. 자세한 흐름은 제품 설계의 를 참고한다.

메타 테이블 업데이트는 필요한 정보가 있는 시스템 테이블을 조회하여 동기화 할 Object들의 정보를 메타 테이블에 insert하는 방식으로 설치 시점에 PRS_USER에 적절한 권한이 부여되지만, 사용 중인 PRS_USER에게서 필요한 권한을 회수한다면 해당 동작을 수행하지 못해 장애가 발생할 수 있다.

ProSync가 사용하는 PRS_DDL_HIST에서 오류가 발생했는지 확인할 수 있으며 해당 테이블에 오류가 발생한 경우, PRS_USER의 권한 변경이 있는지 확인이 필요하다.

다음 항목을 점검하면 DDL 메타데이터 경로의 장애를 진단할 수 있다.

1. PRS_DDL_HIST에 오류 내용이 기록되어 있는지 확인한다.

2. 최근 수행한 DDL이 PRS_DDL_HIST에 기록되고 있는지(기록 정체 여부)를 확인한다.

3. 설치 시 생성된 trigger와 package(PRS_DDL_TRG, PRS_DD_META 등)가 유효한 상태인지 확인한다.

Extract 프로세스는 여러 파일에 대한 읽기 또는 쓰기 권한이 필요하다.

• 변경 데이터 읽기 위해 Redo Log와 Archive Log들에 대한 읽기 권한이 필요하다.

• 로그 작성을 위해 LOG_DIR, LOG_BACKUP_DIR 파라미터 경로에 대한 쓰기 권한이 필요하다.

• 이전 Redo Log에서 commit되지 않은 tx정보를 저장하는 tlr(olr) 파일을 작성하기 위해 $PRS_HOME/var/[instance_name]/lr[node_num] 경로에 대한 읽기/쓰기 권한이 필요하다.

Log Reader가 특정 변경 데이터에 대한 처리를 하지 못한다면, 버그 리포트 후 새로운 바이너리로 교체가 필요하다.

정합성 불일치를 감수하고 동기화를 진행하려면 설치 안내서의 을 참고하여 문제되는 Redo Log를 넘기거나 corrupted lcr이 추출된 경우 _LR_SKIP_CORRUPTED_LCR 파라미터를 통해 넘길 수 있다.

ProSync 운영 중 문제가 발생하면 프로세스 로그, 로그 리더 트레이스, 덤프 파일 등 여러 곳의 진단 정보를 조합해 원인을 분석한다. 본 문서는 증상별로 어떤 진단 도구를 사용해야 하는지, 각 도구의 출력이 어디에 생성되고 어떻게 읽는지를 안내한다.

증상별 진단 도구 선택

인스턴스의 모든 진단 정보는 $PRS_HOME/var/<인스턴스ID>/ 아래에 모인다. Agent 프로세스는 별도로 $PRS_HOME/var/agent/<Agent ID>/ 를 사용한다.

로그 디렉터리는 각 프로세스 cfg 의 LOG_DIR 파라미터가 지정한다. 설치 시 기본값은 $PRS_HOME/var/<인스턴스ID>/log (Agent 는 $PRS_HOME/var/agent/<Agent ID>/log) 이다.

프로세스 기동 시 로그 파일 앞부분에 OS 정보(uname -a)와 사용 중인 cfg 파일 전체 내용이 ProSync configurations 블록으로 기록된다. 문제 분석 시 실제 적용된 파라미터 값을 이 블록에서 먼저 확인한다.

LOG_LEVEL 파라미터(1~5, 기본값 3)가 기록할 메시지의 상세 수준을 결정한다. 설정한 값 이하 레벨의 메시지만 기록된다.

로그 파일이 LOG_FILE_SIZE(기본 100MB)를 넘으면 LOG_BACKUP_DIR 로 이동되고 새 파일이 열린다. 설치 시 기본 백업 디렉터리는 프로세스별로 분리된다 (Extract <LOG_DIR>/ext_backup, Apply <LOG_DIR>/apply_backup, Llob <LOG_DIR>/llob_backup, Agent <LOG_DIR>/backup). 백업 파일명은 원래 이름 뒤에 시각이 붙는다 (예: agent_trace.log.260721_143000.123456). 백업 파일들의 총 크기가 LOG_BACKUP_SIZE 를 넘으면 가장 오래된 파일부터 삭제되며, 기본값 0 은 삭제하지 않음(무제한 보관) 을 뜻하므로 디스크 용량 관리가 필요한 환경에서는 값을 지정한다.

컬럼 값 깨짐을 분석할 때는 히든 파라미터 _PRS_FULL_HEX_DUMP=Y 를 cfg 파일에 직접 추가하고 (템플릿에 없는 파라미터다) 프로세스를 재기동한다. LOG_LEVEL=5 와 함께 사용하면 값 전체가 16바이트 단위 여러 줄로 출력되고, Apply 의 batch INSERT/UPDATE/DELETE 실행 직전에 바인드 값 전체 덤프(NEW COLS DUMP, OLD COLS DUMP 등)가 추가로 기록된다.

LR_TRACE_LVL(1~5, 기본값 2) 이 로그 리더 트레이스의 상세 수준을 결정하며, 값이 높을수록 상세하다. 소스 DB 가 Oracle 또는 Tibero 인 Extract 에만 적용되고, PostgreSQL 소스에는 사용되지 않는다.

재기동 없이 변경할 수 있다. 파싱 문제 분석 시 레벨을 올려 문제 구간을 재현한 뒤 기본값으로 되돌린다.

prs_adm 에서 실행하는 진단 명령 요약이다. 명령어 기본 사용법은 을 참고한다.

Apply 가 느릴 때 어떤 replay 스레드가 어떤 SQL 에서 시간을 쓰고 있는지 확인한다.

Applying... <경과시간>(ms) 인 스레드가 현재 SQL 을 적용 중인 것이다. Completed 스레드에도 Query 블록이 출력되는데, 이는 현재 실행 중이 아니라 마지막으로 실행한 SQL 이다. 특정 스레드의 경과시간이 계속 크다면 해당 SQL(대상 테이블의 인덱스 유무, lock 대기 등)을 점검한다. MONITOR 는 인스턴스의 1번 Apply 프로세스를 대상으로 한다.

Apply 가 메모리에 들고 있는 상태를 파일로 남긴다. 소스·타겟 간 DD 불일치나 트랜잭션 대기 상태 분석에 사용한다.

종류를 생략하면 전체를 덤프한다. 같은 이름의 기존 파일은 덮어쓴다.

프로세스 내부의 스레드별 성능 카운터(호출 횟수·처리량·소요시간)를 스냅샷으로 남기고, 두 스냅샷의 차이를 리포트로 출력한다. "부하 구간에서 어느 스레드·어느 단계가 병목인가"를 확인하는 도구다.

프로세스의 메모리 할당 현황(할당자 계층별 사용량)을 덤프한다. 메모리 사용량이 계속 증가할 때 어느 모듈이 점유 중인지 확인하는 용도다.

var/<인스턴스ID>/alloc/ 에 PROSYNC_DUMP_<inst>_Apply.<PID>.<시각> 파일이 생성된다. 접속 DB 가 Tibero 인 경우 DB 클라이언트 라이브러리 메모리를 담은 CLI_DUMP_* 파일이 추가로 생성된다.

다음 두 가지로 확인한다.

1. 콜스택 덤프 파일 존재 여부 — $PRS_HOME/var/<인스턴스ID>/prosync.out.<PID> (Agent 는 var/agent/<Agent ID>/prosync.out.<PID>). 이 파일은 크래시가 있었을 때만 생성된다.

2. 프로세스 로그의 FATAL 메시지 — 크래시 시 다음 순서로 기록된다.

STATUS <인스턴스ID> 명령으로도 프로세스 내 스레드별 상태를 확인할 수 있다.

같은 프로세스에서 크래시가 반복되면 한 파일에 누적(append)된다. 함수명은 근사 매칭이므로 오프셋이 실제와 다를 수 있다. 버그 리포트 시 이 파일과 로그의 Signal ... caught 메시지를 함께 전달한다. 리포트 항목은 를 참고한다.

ProSync 프로세스는 SIGTERM/SIGINT/SIGHUP 을 무시한다. 일반 kill 이나 Ctrl-C 로는 종료되지 않으며, 정상 종료 수단은 prs_adm 의 SHUTDOWN 명령이다 (불가피한 경우에만 kill -9 를 사용한다).

개발 지원이 필요한 크래시 분석 시, 히든 파라미터 _SLEEP_ON_SIG=Y 를 cfg 에 추가하고 재기동하면 크래시 시그널을 받은 스레드가 종료되지 않고 대기 상태로 남아 gdb attach 가 가능하다.

진단 관련 파라미터 대부분은 재기동 없이 변경할 수 있다.

• 프로세스 타입을 생략하면 인스턴스의 모든 프로세스에 전송된다. 파라미터를 지원하지 않는 프로세스는 not supported. 로 응답하므로, 대상 프로세스를 명시하는 것을 권장한다.

• 변경값은 메모리에만 반영된다. 프로세스를 재기동하면 cfg 파일 값으로 되돌아가므로, 영구 변경은 cfg 파일도 함께 수정한다.

• 성공 시 Process Apply(num :'1') changed parameter('LOG_LEVEL' = '5'). 형태로 출력된다.

런타임 변경이 가능한 파라미터는 프로세스별로 다음과 같이 제한되며, 목록에 없는 파라미터는 not supported. 오류가 반환된다.

각 파라미터의 의미와 유효 범위는 를 참고한다.