> For the complete documentation index, see [llms.txt](https://docs.tibero.com/prosync/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tibero.com/prosync/administration/extract/key-features/tsc-standby-synchronization.md).

# TSC Standby Synchronization

Tibero Standby Cluster(TSC) 환경에서 Standby DB를 Source로 하는 동기화 구성과 운영 방법을 안내한다.

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의 장애 전환 이후에도 재설치 없이 동기화를 이어갈 수 있다.

## 지원 범위

| 구분        | 지원 대상                                                         |
| --------- | ------------------------------------------------------------- |
| Source DB | Tibero (Single TSC, TAC-TSC — Primary와 Standby의 노드 수가 동일한 구성) |
| 대상 프로세스   | Extract, Llob                                                 |

{% hint style="warning" %}
**주의**

TSC Standby 동기화는 Tibero Source에서만 사용할 수 있다. Oracle, PostgreSQL Source에서는 `ENABLE_TSC_STANDBY=Y`를 사용할 수 없다.

또한 ProSync가 연동하는 Standby DB는 Primary DB에 직접 연결된 1개여야 하며, TAC-TSC는 Primary와 Standby의 노드 수가 동일한 구성만 지원한다. 1:N(Broadcasting) Standby 구성과 Cascading Standby 구성의 제약은 아래 '제약사항'을 참고한다.
{% endhint %}

## 동작 구조

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

| 파라미터                     | 역할                                                                       |
| ------------------------ | ------------------------------------------------------------------------ |
| SRC\_DB\_NAME            | Standby 별칭. Redo Log 읽기, Llob Flashback 조회, 복구 상태 조회에 사용한다.              |
| SRC\_LOCAL\_SID          | Standby 인스턴스 직결 별칭. Archive Log 정보 조회와 TAC-TSC의 인스턴스 판별에 사용한다.           |
| SRC\_PRIMARY\_DB\_NAME   | Primary 별칭. Source DB 측 메타데이터 조회/변경 작업에 사용한다.                            |
| SRC\_PRIMARY\_LOCAL\_SID | Primary 인스턴스 직결 별칭(Extract 전용). Dummy Transaction, Logfile Switch에 사용한다. |

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

| 작업                  | 정상 TSC 상태                | Failover 이후     |
| ------------------- | ------------------------ | --------------- |
| Redo Log 읽기         | SRC\_DB\_NAME            | SRC\_DB\_NAME   |
| Llob Flashback 조회   | SRC\_DB\_NAME            | SRC\_DB\_NAME   |
| PRS\_TXINFO 조회/저장   | SRC\_PRIMARY\_DB\_NAME   | SRC\_DB\_NAME   |
| 동기화 테이블 추가/삭제       | SRC\_PRIMARY\_DB\_NAME   | SRC\_DB\_NAME   |
| Supplemental Log 변경 | SRC\_PRIMARY\_DB\_NAME   | SRC\_DB\_NAME   |
| Dummy Transaction   | SRC\_PRIMARY\_LOCAL\_SID | SRC\_LOCAL\_SID |
| Logfile Switch      | SRC\_PRIMARY\_LOCAL\_SID | SRC\_LOCAL\_SID |

{% hint style="info" %}
**참고**

Dummy Transaction과 Logfile Switch는 인스턴스 직결 별칭이 설정되어 있지 않으면 각각 SRC\_PRIMARY\_DB\_NAME(정상 상태), SRC\_DB\_NAME(Failover 이후)을 사용한다.
{% endhint %}

### TAC-TSC 구성의 별칭 배치

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 인스턴스로 직접 접속하는 별칭으로 설정한다.

## 사전 준비

### TIP 파일 설정 확인

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

### Standby DB 상태 확인

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

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

```sql
ALTER DATABASE OPEN READ ONLY CONTINUE RECOVERY;
```

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

```sql
SELECT DATABASE_ROLE FROM V$DATABASE;
```

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

### 계정 권한 확인

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

```sql
SELECT DATABASE_ROLE FROM V$DATABASE;
SELECT MIN(RECOVERED_TSN) FROM V$STANDBY;
SELECT INSTANCE_NUMBER FROM V$INSTANCE;
```

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

{% hint style="info" %}
**참고**

여기에 나열한 조회 권한은 Source DB가 Tibero인 경우 `SRC_INSTALL_USER`에 부여해야 하는 최소 권한으로 설치했다면 설치 과정에서 ProSync 계정에 자동으로 부여되므로, 별도로 추가 부여할 필요가 없다. 최소 권한 목록은 [Instance 설치](/prosync/installation/prosync/instance.md) 페이지를 참고한다.
{% endhint %}

### 메타데이터 객체 위치 확인

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

## 설정 파라미터

`ENABLE_TSC_STANDBY=[Y|N]`

| 파라미터                     | 설명                                                                                                                                                                                                                      |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ENABLE\_TSC\_STANDBY     | TSC Standby 동기화 사용 여부를 설정한다. `Y`로 설정하면 읽기 별칭과 쓰기 별칭을 분리하여 동작한다. 기본값은 `N`이며, `SRC_DB_TYPE=TIBERO`에서만 사용할 수 있다. (적용: Extract, Llob)                                                                                       |
| SRC\_PRIMARY\_DB\_NAME   | 정상 TSC 상태에서 Source DB 측 메타데이터 작업을 수행할 Primary 별칭을 설정한다. `ENABLE_TSC_STANDBY=Y`인 경우 반드시 설정해야 한다. (적용: Extract, Llob)                                                                                                     |
| SRC\_PRIMARY\_LOCAL\_SID | Dummy Transaction, Logfile Switch와 같이 특정 인스턴스에서 수행해야 하는 작업에 사용할 Primary 인스턴스 직결 별칭을 설정한다. 설정하지 않으면 SRC\_PRIMARY\_DB\_NAME을 사용한다. TAC-TSC 환경에서는 Extract 프로세스별로 해당 Redo Thread를 소유한 Primary 인스턴스의 별칭을 설정한다. (적용: Extract) |

## 설정 예시

### Extract 설정

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

```
SRC_DB_TYPE=TIBERO
SRC_DB_NAME=tibero_s
SRC_LOCAL_SID=tibero_s

ENABLE_TSC_STANDBY=Y
SRC_PRIMARY_DB_NAME=tibero_p
SRC_PRIMARY_LOCAL_SID=tibero_p
```

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

```
# ext1
SRC_DB_NAME=tibero_s
SRC_LOCAL_SID=tibero_s1
ENABLE_TSC_STANDBY=Y
SRC_PRIMARY_DB_NAME=tibero_p
SRC_PRIMARY_LOCAL_SID=tibero_p1

# ext2
SRC_DB_NAME=tibero_s
SRC_LOCAL_SID=tibero_s2
ENABLE_TSC_STANDBY=Y
SRC_PRIMARY_DB_NAME=tibero_p
SRC_PRIMARY_LOCAL_SID=tibero_p2
```

### Llob 설정

```
SRC_DB_TYPE=TIBERO
SRC_DB_NAME=tibero_s

ENABLE_TSC_STANDBY=Y
SRC_PRIMARY_DB_NAME=tibero_p
```

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

### 설치 구성

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

```
SRC_DB_TYPE=TIBERO
SRC_DB_NAME=tibero_s              # Standby 별칭

USE_TSC=Y
SRC_PRIMARY_DB_NAME=tibero_p      # Primary 별칭

# (TAC-TSC) SRC_DB_ALIAS_N과 병렬인 Primary 인스턴스별 별칭 (선택)
SRC_PRIMARY_DB_ALIAS_0=tibero_p1
SRC_PRIMARY_DB_ALIAS_1=tibero_p2

# (Cluster) Thread별 Standby 인스턴스 직결 별칭
SRC_DB_CNT=2
SRC_DB_ALIAS_0=tibero_s1
SRC_DB_ALIAS_1=tibero_s2
```

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

* Primary 별칭 접속 확인 및 별칭 중복 검증
* Source DB 측 설치 DDL/DML의 Primary 수행 (Archive Log 정보 조회는 Standby에서 수행)
* 생성되는 Extract/Llob config에 TSC 파라미터 자동 기입

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

```
SRC_DB_TYPE=TIBERO
SRC_DB_NAME=tibero_s
ENABLE_TSC_STANDBY=Y
SRC_PRIMARY_DB_NAME=tibero_p
```

## 동작 방식

### 안전 추출 경계

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 Flashback 조회 대기

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

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

## Failover 동작

### 정상 TSC 상태

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

### Primary 장애, Standby 미승격

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

### Standby 승격 감지

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

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

### Old Primary 복귀

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

## 제약사항

* TSC Standby 동기화는 Tibero Source 전용이다.
* TAC-TSC는 Primary와 Standby의 노드 수가 동일해야 한다.
* Standby DB는 read-only 모드로 open되어 있어야 한다.
* Failover 이후 이전 Primary로의 자동 Switchback은 지원하지 않는다.
* 복구 상태 대기(안전 추출, Llob Flashback)는 별도 timeout 없이 `_TCP_CONNECT_INTERVAL` 주기로 계속 재시도한다.

{% hint style="warning" %}
**주의**

**1:N(Broadcasting) Standby 구성과 Cascading Standby 구성의 하위 Standby 연동은 지원하지 않는다.**

ProSync는 SRC\_DB\_NAME과 SRC\_PRIMARY\_DB\_NAME 두 별칭의 1:1 역할 전환만 추적하므로, 연동하지 않은 다른 DB로 역할 전환이 일어나면 이를 감지하지 못하고 Primary Routing(쓰기 라우팅 전환)이 불가능하다.

* 1:N(Broadcasting) Standby: Primary 하나에 `LOG_REPLICATION_DEST_N`으로 Standby를 여러 개 연결하는 구성이다. Failover 시 TSN이 가장 높은 Standby가 Primary로 승격되어 승격 대상을 예측할 수 없으므로 New Primary를 감지할 수 없다. 또한 각 Standby가 동일한 Redo Log를 보유하므로 여러 Standby에 Extract 프로세스를 각각 기동하면 Target DB에 DML이 중복 반영될 수 있다. 이 구성은 지원하지 않는다.
* Cascading Standby: `STANDBY_ENABLE_CASCADING=Y`로 Standby가 다른 Standby에 Redo Log를 중계하는 구성이다. Primary DB에 직접 연결된 최상단 Standby에 연동하는 것은 지원한다. 다만 하위 Standby(다른 Standby로부터 Redo Log를 중계받는 Standby)에 연동하는 것은 cascade 단계에 따른 지연이 있고 상위 Standby의 역할 전환을 감지할 수 없으므로 지원하지 않는다.
  {% endhint %}

## 로그 확인

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

```
TSC standby source enabled
TSC source DB role transition detected
waiting for TSC safe extraction TSN
TSC promotion detected while waiting for safe TSN; reopen current log
TSC promotion detected while waiting for log; reopen current log
waiting for TSC standby recovery before LLOB flashback read
TSC source DB is primary; skip recovered TSN wait
TSC has no writable source DB route
TSC primary source DB role validation failed
TSC writable source DB connection failed
TSC source DB role validation failed; ensure the TSC standby DB is open in read-only mode
```

## 문제 상황별 확인 항목

### 기동에 실패하는 경우

* `SRC_DB_TYPE=TIBERO`인지 확인한다.
* `ENABLE_TSC_STANDBY=Y`일 때 `SRC_PRIMARY_DB_NAME`이 설정되어 있는지 확인한다.
* Standby DB가 read-only 모드로 open되어 있는지 확인한다.
* `SRC_DB_NAME`과 `SRC_PRIMARY_DB_NAME` 별칭이 서로 바뀌지 않았는지 확인한다.

### 추출 또는 Llob 조회가 지연되는 경우

`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 복구 지연 여부를 확인한다.

### Primary 장애 후 쓰기 작업이 진행되지 않는 경우

* `SRC_DB_NAME`의 역할이 아직 `STANDBY`인지 확인한다. Standby가 승격되지 않았다면 쓰기 작업을 보내지 않는 것이 정상 동작이다.
* Failover가 완료되어 `SRC_DB_NAME`의 역할이 `PRIMARY`가 되었는지 확인한다.

### TAC-TSC에서 특정 Extract만 동기화가 반영되지 않는 경우

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

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