Oracle RAC + ASM 환경에서 Debezium(LogMiner) 기반 CDC 구성

1. 개요

본 문서는 Oracle RAC(Real Application Clusters) + ASM(Automatic Storage Management) 환경에서

Debezium Oracle Connector(LogMiner 기반) 를 활용하여 CDC(Change Data Capture) 를 수행하기 위한 구성 방법과

그때 고려해야 하는 아키텍처 설계 요소를 공식 문서 기준으로 정리한다.

Debezium Oracle Connector는 기본적으로

• Oracle LogMiner 를 기반으로 redo 로그를 분석
• 트랜잭션 변화를 Kafka 이벤트로 변환
• 정합성과 순서 보장을 유지
• 하는 방식으로 동작한다.

그러나 RAC + ASM 환경에서는 로그 파일의 위치, 인스턴스 간 동기화, redo thread 구조 등으로 인해

싱글 인스턴스 환경과 다른 제약 조건이 존재한다.

2. Oracle RAC와 ASM의 구조적 특징

Debezium CDC 구성 시 반드시 고려해야 할 핵심 아키텍처 요소

2.1 Oracle RAC 구조

Oracle RAC는 하나의 데이터베이스를 여러 노드(instance)에서 동시에 액세스하도록 설계된 클러스터 구조다.

RAC 특징

• 여러 Oracle instance + 하나의 DB
• 각 instance는 자신만의 redo thread 를 가짐
• 각 redo thread는 여러 개의 online redo log group을 가짐
• 모든 redo log는 결국 ASM 디스크그룹 위에 저장됨

LogMiner 관점에서 중요한 RAC 포인트

1. Redo Thread가 Instance별로 분리되어 있다(공식 문서에서 Debezium LogMiner는 RAC 전체 모니터링을 지원하지 않음)
2. → Debezium은 “하나의 인스턴스가 생성한 redo thread만” 읽어야 한다
3. FAL / ARCn 프로세스가 인스턴스별로 동작한다
4. → archive log가 RAC 환경에서 instance별로 분리되며 경로가 달라질 수 있다
5. Redo switch 간격이 인스턴스별로 다름
6. → CDC 안정성을 위해 특정 인스턴스의 redo 를 고정적으로 읽어야 함

Debezium 공식 결론

Debezium Oracle Connector(LogMiner)는 RAC 전체를 동시에 읽는 기능을 지원하지 않는다.

반드시 “단일 인스턴스에 연결”하는 방식으로 구성해야 한다.

(Reference: Debezium Docs → Oracle Connector → Limitations)

2.2 ASM(Automatic Storage Management)의 구조

ASM은 Oracle redo, datafile, controlfile을 raw disk 기반으로 자동 스트라이핑/미러링하는 스토리지 계층이다.

CDC 관점에서 중요한 ASM 특징

1. redo logfile 경로가 ‘물리 파일 경로’가 아니다

   +DATA/ORCL/ONLINELOG/group_1.261.123456789
   

   → OS 파일 경로로 접근할 수 없으며,
2. ASM instance + Oracle instance 조합으로만 접근 가능.
3.  
4. LogMiner는 Oracle 서버 프로세스가 redo block을 읽어 Debezium에 전달하므로→ ASM의 구조는 Debezium에 직접 영향 없음.
5. Debezium은 redo 파일을 직접 읽지 않는다.
6. 그러나 archive log 접근 시에는 instance가 해당 archive를 열 수 있어야 한다로그 전파가 지연되면 LogMiner가 archive open 실패를 발생시킴.
7. RAC 환경에서는 Archive log 가 인스턴스별로 다를 수 있고

3. Debezium Oracle(LogMiner) CDC 구성 방식

3.1 반드시 “특정 RAC 인스턴스 하나”에 연결해야 함

공식 문서 기준:

LogMiner 기반 Debezium Connector는 RAC 환경에서 단일 인스턴스 전용이다.

RAC 전체의 redo thread를 병합하는 기능은 제공하지 않는다.

그 이유는 다음과 같다:

1. LogMiner는 하나의 세션이 하나의 redo thread만 읽는다
2. RAC 각 노드의 redo는 서로 다른 thread 번호를 가짐
3. RAC 인스턴스 간 redo switch 타이밍이 다름
4. archive log는 특정 인스턴스에서만 존재할 수 있음 (thread 간 동기화 지연 발생)

결론

Debezium → Oracle RAC 연결 시

• 특정 노드의 SCAN이 아닌
• 그 인스턴스가 있는 리스너(Local Listener)에 직접 연결해야 한다.

예시:

"database.url": "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=racnode1-vip)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ORCL1)))"

3.2 Archive Log를 사용하지 않는 구성에서는 더욱 단일 인스턴스 고정 필요

RAC + ASM 환경에서 archive log가 instance 간 공유되지 않으면:

• Debezium이 인스턴스 A에 연결했는데
• redo switch 후 archive가 인스턴스 B에만 존재하면
• → LogMiner가 "file not found" 오류 발생

따라서 archive log 미사용 환경에서는

무조건 real-time online redo 기반 + 단일 인스턴스 고정 구성이 필수이다.

3.3 최소 권한 및 DB 세션 구성

Debezium에서 요구하는 최소 권한은 공식 문서 기준:

• SELECT_CATALOG_ROLE
• EXECUTE_CATALOG_ROLE
• SELECT on V_$DATABASE, V_$LOG, V_$LOGFILE, V_$ARCHIVED_LOG, V_$TRANSACTION
• LOGMINING 권한

RAC 환경에서도 동일하나

V_$LOGFILE / V_$ARCHIVED_LOG 에서 thread 번호 필터링이 정확히 적용되어야 함.

4. ASM + RAC 환경에서 Debezium CDC가 동작하는 원리

4.1 Debezium은 redo 파일을 직접 읽지 않는다

(LogMiner가 redo block을 읽어 Debezium에 전달)

즉:

• ASM의 물리 파일 접근 문제는 Debezium과 무관
• Debezium은 SQL 기반으로 LogMiner 조회를 수행

예시 LogMiner 쿼리:

SELECT OPERATION_CODE, CSF, STATUS, INFO, COMMIT_SCN, SCN, SQL_REDO FROM V$LOGMNR_CONTENTS

Oracle 서버 프로세스가 내부적으로 ASM에서 redo block을 읽어 LogMiner에 올린다.

4.2 RAC에서는 Thread 번호가 고정되어 있어야 한다

각 RAC 인스턴스는 고유한 redo thread 번호를 가진다.

예:

Instance 1 → Thread 1 Instance 2 → Thread 2

Debezium은 시작 시 LogMiner session 내부에서 특정 thread의 redo만 읽도록 고정된다.

→ 인스턴스가 바뀌면 안 됨

→ SCAN Listener 사용하면 안 됨

5. Debezium CDC 구성 절차 (RAC + ASM 전용)

5.1 Preferred Node 고정

Debezium은 반드시 하나의 RAC 노드를 선호(prefer)하도록 설정한다.

database.url → LOCAL LISTENER ONLY 예:   racnode1-vip:1521

5.2 RAC 서비스 구성 시 아래 옵션 필수

Oracle FAN / SCAN 은 사용하지 말고

서비스에 다음 옵션을 해제한다:

• Load balancing: OFF
• Failover: OFF
• Preferred instance: 1개만 지정

예시:

srvctl modify service -db ORCL -service CDC_SERVICE -preferred ORCL1 -available ORCL2

이렇게 하면 Debezium은 항상 ORCL1에서 실행되고

ORCL1 인스턴스의 redo thread만 읽는다.

5.3 ASM 파일 접근 문제 해결

LogMiner는 Oracle 내부 프로세스가 ASM 파일을 읽기 때문에

별도의 OS 접근 권한은 필요 없다.

단, RAC 환경에서는:

• archive log가 모든 instance에서 OPEN 가능해야 함
• redo switch 마다 thread 대기 상태가 없어야 함

Archive log를 공유 ASM 디스크 그룹(+ARCHIVE)으로 생성해두면

LogMiner가 어느 인스턴스에서든 archive를 열 수 있다.

6. 구성의 이유

1. LogMiner는 RAC 전체의 redo 병합을 지원하지 않음

LogMiner 자체가 single-thread mining 구조

→ Debezium 또한 single thread 기반

2. RAC의 thread별 redo를 혼합하면 순서 보장이 깨짐

CDC는 strict sequential ordering 이 필수

→ thread 간 SCN 충돌 가능

3. Archive Log는 instance 간 생성 시점이 다름

한 인스턴스에서 생성한 archive가

다른 인스턴스에서 아직 보이지 않을 수 있음

→ ORA-00308, ORA-00310 발생

4. SCAN Listener는 연결 인스턴스가 바뀌는 문제가 있음

CDC는 연결 인스턴스 일관성이 절대적으로 필요함

→ 부하분산 = CDC 장애

7. 최종 아키텍처 다이어그램 (텍스트 버전)

+---------------+        +--------------------+ |  Debezium     |  ----> | RAC Node 1 (ORCL1) | |  Kafka Connect|        |  Thread 1 Redo     | +---------------+        +--------------------+       |                          ^       | (No SCAN)                |       | direct JDBC              |       |                          | +---------------+        +--------------------+ |   Kafka       |        | RAC Node 2 (ORCL2) | |   Cluster     |        |  Thread 2 Redo     | +---------------+        +--------------------+

Debezium은 ORCL1만 연결한다.

8. 결론

Oracle RAC + ASM 환경에서 Debezium(LogMiner) 기반 CDC를 구축하려면

다음 원칙을 반드시 따라야 한다:

1. Debezium은 단일 RAC 인스턴스에만 연결할 것
2. SCAN Listener를 사용하지 말고 Local Listener로 고정 연결
3. RAC 서비스는 preferred instance로 고정 구성
4. Archive Log는 모든 instance에서 접근 가능해야 함(ASM 공유)
5. redo thread는 혼합되지 않아야 하며 특정 thread만 mining

이 구성은 Debezium 공식 문서에서도 권고하는 방식이며,

Oracle RAC/ASM의 구조적 특성을 고려할 때

논리적으로 일관성이 유지되는 CDC 구성 방법이다.

 

9. 참조

https://debezium.io/documentation

https://groups.google.com/g/debezium

https://docs.oracle.com