Apply Process

Process 설명

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

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

Threads

Apply 프로세스는 위와 같은 구조를 가지고 있다. 앞서 Inter Processes/Threads Communication에서 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

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 사용량을 실시간으로 수집한다. 수집된 내용은 로그상에 계속해서 남게 되며, ProSync 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 ProSync 매니저로 전송한다.

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

Apply는 재기동이나 재연결 이후에도 중복 반영 없이 이어서 동기화할 수 있도록 복구 상태를 여러 저장소에 나누어 관리한다.

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

재기동 유형별 복구 절차와 장애 시나리오는 를 참고한다.