1. Overview

CTF / TAF 선택지와 설정 방법



2. Descriptions

2.1 CTF (Connection Time Failover)

연결하려는 DB Listener TCP 통신 Connection Timeout 에 따라, 접속을 실패하면 다른 접속가능한 DB Listener 를 탐색한다.


(1). WebLogic

WebLogic에서는 MultiDataSource(MDS)를 사용하면 된다.

WebLogic에서 CTF 를 관리하는 주체가 된다.

정확한 동작 메커니즘(Plugin Flow-Diagram 같은)은 문서상에 존재하지 않는다.


(2). JDBC Driver Level

MDS를 사용하지 않는 경우에는, RAC DB가 필요하며, RAC DB설치시 CTF 는 기본 제공된다.

GenericDataSource(GDS)를 사용하며, JDBC Url String에 CTF URL Parameter를 제공하면 된다.

JDBC Driver Level 수준에서 CTF를 관리하는 주체가 된다.

정확한 동작 메커니즘은 구글링을 해봐야 겠으며,

"SR 3-22940040811 : [XX저축은행] 데이터소스 Suspending , Created 메시지 교차 반복"

답변상에서는 MDS와 GDS+CTF 동작 방식이 크게 차지 있지는 않다고 언급한다.



2.2 TAF (Transparent Application Failover)

(1). JDBC Driver Level

TAF는 RAC 설치 및 추가 구성을 필요로 한다.


접속문제는 CTF로 해결이 가능하다.

이때 처리중이던 작업을 어떻게 컨트롤할 것인가를 TAF에서 지원한다.

TAF의 옵션을 통해 이 기능을 살펴보면,

1
2
3
4
5
6

# tnsnames.ora
...
    (FAILOVER_MODE =
    (TYPE = SELECT)
    (METHOD = BASIC)
...

TYPE 에는 SELECT와 SESSION 을 설정할 수 있다.

  • SESSION : 수행중이던 SQL 문장은, 모두 FAIL 되고, 다른 정상 rac node에서 처음부터 다시 실행된다.
  • SELECT : 수행중이던 Select SQL 문장은 (다른 DML은 불가능), 다른 정상 rac node에서 이어서 실행된다.

즉, 모든 DML의 Failover를 위해서는 SESSION 방식을 쓰면 되나, 모두 Rollback 후에 다시 쿼리를 재실행 해야 한다.

단순히 조회프로그램의 경우에는 SELECT 방식을 쓰면, 이어서 (Fetch 처리 중 Open Cursor) 처리가 가능하다.


METHOD 에는 BASIC과 Preconnect 를 설정할 수 있다.

  • BASIC : 장애 발생 시, 다른 rac node 연결 생성.
  • Preconnect : 장애를 대비하여, 미리 백업 rac node 연결 생성.
  • Failover 참고



2.3 선택지

(1). OCI / THIN

TAF, CTF 방식을 사용하려면 OCI 환경이어야 한다고 하지만,

WebLogic의 THIN 환경에서 불가능하지 않다.


OCI는 접속 Client를 내가 가지고 있고, 내 환경의 tns ora 파일에 접속 정보를 CTF / TAF 파라메터로 기입하는 것으로 이해된다.

THIN 방식에서는 JDBC THIN URL String 작성 시, CTF 또는 TAF (Failover=On 과 같은..) 파라메터 기입하는 것으로 이해된다.


요약하면,

TAF가 구성된 RAC가 있는 경우.

WebLogic에서 CTF + TAF 두 가지 기능 모두 활용할 수 있다.


OCI / THIN 에 대한 내용을 기재한 이유로는,

"SR 3-22940040811 : [XX저축은행] 데이터소스 Suspending , Created 메시지 교차 반복" SR 담당자가

Full Support 를 위해서는 OCI 방식에서만 지원된다는 식으로 이야기를 하였기 때문에 찾아보고 정리..



(2). MDS 와 RAC CTF 의 차이점
  • MDS는 각각의 DS를 개별적으로 관리할 수 있다.
  • DS#1 장애 시, 알고리즘 Failover 일경우, DS#1 의 모든 요청을 Closed 하고 DS#1을 Suspending 한다.
  • DS#1 에서 Closed 된 에러들은 클라이언트에게 모두 전달된다.
    • 어플리케이션 레벨에서 이 에러를 받아들일지, 다시 re-try 할지 제어해야 한다.
    • 에러를 별도로 처리하지 않고 클라이언트에게 전달하면, 클라이언트는 새로고침을 해야만 한다.
  • 이후, DS#1 장애 복구 시, MDS는 그전부터 주기적으로 정상 여부를 테스트를 해왔을 것이며 DS#1 re-enabled 된 후에는, DS#1로 다시 Routing 을 한다. 아직까지 처리가 끝나지 않아 Pool로 회수되지 않은 DS#2의 세션들은 곧 DS#1 로 복귀된다.


MDS의 Failover 동작 방식 참고](https://docs.oracle.com/middleware/1213/wls/JDBCA/jdbc_multidatasources.htm#JDBCA224)

MDS의 Failback 동작 방식 참고


Failback을 참고하여 이해해보면, 장애 DB node가 다시 연결이 가능할 경우, 향후 연결 요청(새로운 커넥션 풀 생성을 의미하는 것으로 이해)은 복구된 첫번째 DB node로 연결된다고 설명된다. MDS 뿐만 아니라, 일반 DS를 사용시에도 Failback은 가능할 것으로 보이는데, 위 웰컴저축은행 SR에서 담당자가 통화상으로 Failback은 MDS만 가능하다고 하였다.