[Tibero] 이중화 개요

티베로의 이중화 구성으로는 총 3가지 종류가 있다. 

1. HA(High Availibility)

2. TSC(Tibero Standby Cluster)

3. TAC(Tibero Active Cluster)

아래 표는 이중화들을 간단하게 구분한 표이다. 

	Active-Standby 구성인가?	Active-Active 구성인가?	공유 스토리지를 사용하는가?
HA	O	X	O (File System)
TSC	O	X	X
TAC	X	O	O (Raw Device)

 

 

[HA구성] 

•서버장애를 대비해 Standby 인스턴스를 준비하고 있는 방식

•동작되고 있는 티베로 서버가 장애를 일으키면 Standby 서버가 동작하는 방식

•추가로 한 개의 서버와 공유볼륨, 클러스터웨어가 필요

 

[HA엔진 설치 위치에 따른 차이] 

 

[TSC 개요] 

•Tibero Standby  서버는 물리적으로 독립된 장소에 원본 데이터베이스의 복사본을 트랜잭션 단위로 보관

•복사할 대상이 되는 원본 데이터베이스를 Primary DB라 하고, 복사된 데이터가 저장되는 데이터베이스를 Standby DB라 함

•TSC의 원리는 Primary에서 생성된 Redo 로그를 배경 프로세스가 Standby로 전송하고, Standby는 Redo 로그를 이용해 Primary의 모든 변화를 똑같이 반영

•데이터의 복사를 통해 Primary는 서비스가 요청한 데이터 처리에 실패했을 경우 Standby의 데이터를 활용해 해당 서비스를 신속히 재개 가능

•Primary의 서버만으로는 손상된 데이터를 복구를 할 수 없는 경우에도 쉽게 대처 가능

•예를 들어, Primary의 서버의 디스크가 손상된 경우 Standby를 통해 손상된 데이터를 보호 가능

 

[TSC에서 사용하는 특수 프로세스]

[TSC 로그 전송 방식]

[Primary 설정 및 운용] 

[Standby 설정 및 운용] 

[Standby의 read only 모드] 

[TSC Failover] 

[TSC 클라이언트 설정] 

[TSC 정보 조회] 

[TSC 제약사항] 

 

[TAC] 

TAC 구성은 control file과 data file을 공유하여 사용하며, 각 instance를 관리하는데 필요한 redo, undo, arch 등은 각각의 instacne가 가지고 있게 된다. 각각의 instanc는 CM이 관리하게 되며 INTER-CONNECT를 통해 정보를 공유한다.

 

[TAC 특징] 

REDO LOG

반면 TAC에서는 공유 디스크에서 데이터 접근의 경합을 최소화하기 위해 Redo 로그 및 Undo에 대해서는 인스턴스마다 별도의 파일을 가지고 있어야 한다.

 Redo 로그 그룹 번호는 데이터베이스 전체에서 유일해야 함

주의할 점은 Redo 로그 그룹의 번호는 Redo 스레드 내에서가 아니라 데이터베이스 전체에서 유일해야 하므로 이미

사용된 0,1,2를 사용할 수 없다. 또한, 최소한 두 개 이상의 Redo 로그 그룹이 존재해야만 해당 Redo 스레드를 활성화.

복구 실행 시 

T2는 다운시키고 T1에서는 mount 상태로 한다. 

T1에 T1, T2  아카이브로그를 모두 넣어놓고 복구시킨다. 

복구가 끝나면 T2는 다시 올리기만 하면 된다. 

→ T1, T2는 그저 인스턴스 이기 때문에 T2는 그저 올리기만 한다.

 

RAW DEVICE 

DML 작업 시 select 비중이 늘어날 수록 raw device와 file system의 성능 차이는 없고 insert, update, delete 비중이 많을 수록 raw device 성능이 극대화된다.

 

TBCM

[HA과 TAC 비교] 

*GPFS