GOLDILOCKS 는 XA 트랜잭션간 데이터 소실을 방지하기 위해 2단계 커밋을 지원합니다.



사진은 G1, G2 그룹에 대해 글로벌 트랜잭션이 발생한 뒤 커밋을 수행했을 때의 로직입니다.


Prepare Commit 단계

1. APP 는 G1N2 노드에 Prepare Commit Protocol 을 전송합니다.

2. G1N2 노드는 자기자신 노드에 Prepare Commit 을 수행함과 동시에 Global Coordinator 인 G1N1 장비로 Prepare Commit Protocol 을 전송합니다.

3. G1N1 장비는 트랜잭션에 참여하는 모든 노드의 cserver 에 Prepare Commit Protocol 을 전송합니다.

4. 응답받은 각 장비는 Prepare Commit 을 수행 후 G1N2 장비로 응답 프로토콜을 전송합니다.

5. 모든 장비로부터 Prepare Commit Protocol 을 받은 G1N2 장비는 APP 로 Prepare Commit 되었다는 응답을 전송합니다.


Commit 단계

6. APP 는 G1N2 노드에 Commit Protocol 을 전송합니다.

7. G1N2 노드는 자기자신 노드에 Commit 을 수행함과 동시에 Global Coordinator 인 G1N1 장비로 Commit Protocol 을 전송합니다.

8. G1N1 장비는 트랜잭션에 참여하는 모든 노드의 cserver 에 Commit Protocol 을 전송합니다.

9. 응답받은 각 장비는 Commit 을 수행 후 G1N2 장비로 응답 프로토콜을 전송합니다.

10. 모든 장비로부터 Commit Protocol 을 받은 G1N2 장비는 APP 로 Commit 되었다는 응답을 전송합니다.



GOLDILOCKS 는 CLUSTER_ASYNC_COMMIT 프로퍼티 설정을 통해 다음 2가지중 한가지를 선택할 수 있습니다.

 1. 요청한 APP 으로부터 위의 단계를 전부 수행후 응답

 2. 요청한 APP 으로부터 드라이버 노드 COMMIT 후 APP 으로 바로 응답

블로그 이미지

사용자 꽁담

GOLDILOCKS CLUSTER 는 트랜잭션의 종류에 따라 명칭 및 동작 방식이 다릅니다.


 명칭

 트랜잭션의 범위

 동작 방식

 Global Transaction

 전체 노드의 전체 멤버

 트랜잭션의 상태를 Prepare 로 변경

 트랜잭션이 기록한 모드 로그가 디스크로 반영 후 응답을 Global Coordinator 에 전송

    :: 복구 시 리두로그로부터 Commit 혹은 Rollback 을 판단

 Global Coordinator 는 클라이언트에 응답

 Global Commit

 

 클러스터 전체 노드의 전체 멤버에 커밋프로토콜 전송

 전송한 멤버로부터 응답을 받을 때 까지 대기

 비동기로 수행 가능

 Domain Transaction

 특정 노드의 전체 멤버

 트랜잭션의 상태를 Prepare 로 변경

 트랜잭션이 기록한 모든 로그가 디스크로 반영 전 응답을 Global Coordinator 에 전송

 Global Coordinator 는 클라이언트에 응답

 Domain Commit 

 클러스터 특정 노드의 전체 멤버에 커밋프로토콜 전송

 전송한 멤버로부터 응답을 받을 때 까지 대기

 비동기로 수행 가능

 Local Transaction

 특정 멤버

 트랜잭션의 상태를 Prepare 로 변경 후 클라이언트에 바로 응답

 Local Commit

 

 커밋후 클라이언트에 바로 응답




Global Transaction




Domain Transaction


블로그 이미지

사용자 꽁담

GOLDILOCKS 는 유저와 스키마가 1:N 의 관계를 가집니다.

유저는 스키마를 0개 부터 1개 이상을 소유할 수 있습니다.


유저별로 스키마를 소유할 수 있는 방법에 대한 그림입니다.



타 DBMS 의 경우의 유저와 스키마의 관계는 다음과 같습니다.


 DBMS

 USER : SCHEMA 관계

 Oracle

 1 : 1

 MySQL

 1 : 1

 Postgres

 1 : N


블로그 이미지

사용자 꽁담

GOLDILOCKS Cluster 에서는 모든 멤버의 데이터의 통일성을 위해 Global Secondary Index 를 지원합니다.


Global Secondary Index 란

Cluster 환경의 각 멤버들의 레코드의 GRID ( Global Row Identifier ) 값을 Key 로 구성한 B-Tree 인덱스 입니다.

Global Secondary Index 가 없는 테이블에 대해서는 LIMIT, FETCH 같은 Non-Deterministic DML 을 지원하지 않습니다.


GRID

각 멤버들의 동일한 레코드에 대해서 구분할 수 있는 Unique 한 값으로, 데이터가 최초 저장될 때 할당되어 모든 멤버들에게 전파되어 함께 저장됩니다.

레코드의 값이 갱신되거나 Shard Key 가 변경되어도 GRID 값은 변하지 않습니다.





다음 그림처럼, LIMIT 이나 FETCH 절은 GRID 에 의해 순서를 보장받을 수 있습니다.


테이블에 Global Secondary Index 유무는 아래 쿼리로 확인할 수 있습니다.

gSQL> SELECT TABLE_OWNER, TABLE_SCHEMA, TABLE_NAME FROM ALL_GSI_PLACE;

TABLE_OWNER TABLE_SCHEMA      TABLE_NAME
----------- ----------------- ------------------------
SYS         DICTIONARY_SCHEMA DBC_TABLE_TYPE_INFO
SYS         DICTIONARY_SCHEMA DBC_TABLE_TYPE_INFO
SYS         DICTIONARY_SCHEMA JDBC_CLIENT_PROPS
SYS         DICTIONARY_SCHEMA JDBC_CLIENT_PROPS
SYS         DICTIONARY_SCHEMA IMPLEMENTATION_INFO_BASE
SYS         DICTIONARY_SCHEMA IMPLEMENTATION_INFO_BASE
TEST        PUBLIC            T1
TEST        PUBLIC            T1
TEST        PUBLIC            T2
TEST        PUBLIC            T2
TEST        PUBLIC            T3
TEST        PUBLIC            T3
TEST        PUBLIC            T4
TEST        PUBLIC            T4
TEST        PUBLIC            T5
TEST        PUBLIC            T5

16 rows selected.


블로그 이미지

사용자 꽁담

GOLDILOCKS 는 godlilocks_home 과 goldilocks_data 경로에 운영에 필요한 파일들을 보관합니다.



goldilocks_home


 폴더

 설명

 admin

 메타 스키마 정보를 담은 파일이 있는 폴더

 bin

 바이너리 파일이 있는 폴더

 include

 헤더 파일이 있는 폴더

 lib

 라이브러리 파일이 있는 폴더

 license

 라이센스 파일이 있는 폴더

 msg

 에러메세지 파일이 있는 폴더

 sample

 SQL, ODBC, JDBC, Embedded-SQL 등의 샘플 파일이 있는 폴더

 script 스크립트 폴더



goldilocks_data


 폴더

 설명

 archive_log

 아카이브 로그파일이 있는 폴더

 backup

 백업 파일이 있는 폴더

 conf

 데이터베이스 프로퍼티를 설정하는 파일이 있는 폴더

 db

 데이터 파일이 있는 폴더

 journal

 

 trc

 시스템 로그가 있는 폴더

 wal

 컨트롤, 리두로그 파일이 있는 폴더


블로그 이미지

사용자 꽁담

GOLDILOCKS 는 구동까지 아래 단계를 거쳐가며, 각 단계별로 할 수 있는 작업이 나뉘어져 있습니다.


STANDALONE 에서는 INIT - NOMOUNT - MOUNT - OPEN

CLUSTER 에서는 INIT - NOMOUNT - MOUNT - LOCAL OPEN - GLOBAL OPEN  단계를 지원합니다.



각 단계별로 가기 위한 쿼리는 아래 사진과 같습니다.




GOLDILOCKS 는 각 단계별로 다음과 같은 작업을 수행합니다.


 

 STANDALONE

 CLUSTER

 INIT

 

 

 NOMOUNT

 데몬 gmaster 를 구동

 데몬 gmaster 를 구동

 MOUNT

 복구를 위한 control file 을 읽음

 복구를 위한 control file 을 읽음

 OPEN

 LOCAL OPEN

 data file 로부터 테이블스페이스 내용을 로딩,

 redo log file 들을 이용하여 복구,

 index 재구축

 dictionary cache 생성

 data file 로부터 테이블스페이스 내용을 로딩,

 redo log file 들을 이용하여 복구,

 index 재구축

 dictionary cache 생성

 GLOBAL OPEN

 

 cluster 간의 session 을 연결,

 shard map 정리,

 Coordinator 관리자 선정


블로그 이미지

사용자 꽁담

CYCLONE



GOLDILOCKS 는 이중화를 위해 CDC 방식의 cyclone 프로그램을 지원합니다.


cyclone 프로세스가 Master 데이터베이스로부터, Slave 데이터베이스로 반영까지의 단계는 다음과 같습니다.

1. Master 데이터베이스에 쿼리가 수행됩니다.

2. 수행된 쿼리는 리두로그 파일에 기록됩니다.

3. cyclone master 는 리두로그 파일에 기록된 쿼리를 전용버퍼에 캡쳐합니다.

4. cyclone slave 의 Applier 들은 버퍼에 들어있는 내용을 Slave 데이터베이스에 반영합니다.




CDC 방식은 비동기 방식만을 지원하기 때문에 데이터베이스간의 동기화 시간차가 발생하게 됩니다.



CYCLONE 을 사용하기 위해서는, 다음의 제약사항이 필요합니다.

1. 데이터베이스는 아카이브 모드로 운영되어야 합니다.

2. Cyclone Master 대상 테이블은 SUPPLEMENTAL LOGGING 이 필요합니다.

3. Cyclone Master, Slave 대상 테이블은 반드시 PRIMARY KEY 가 필요합니다.

4. Cyclone Master, Slave 대상 테이블의 메타 정보는 동일하여야 합니다.

5. Cyclone Master, Slave 대상 테이블의 PRIMARY KEY 업데이트는 지원하지 않습니다.

6. Cyclone Master, Slave 의 DDL 작업은 허용하지 않습니다.

블로그 이미지

사용자 꽁담

GOLDILOCKS 의 모든 작업들은 메모리 상에서 진행되며, INSTANCE 크기는 프로퍼티 파일에 지정된 프로퍼티에 의해 결정됩니다.


INSTANCE 는 SSA 영역과 TABLESPACE 영역으로 나뉘어집니다.


SSA 는 Shared Memory Static Area 의 약자이며, 프로세스간 공용으로 사용되는 정보를 담고있습니다.

TABLESPACE 는 한개 이상의 데이터파일들로 구성되어 있으며, 객체들을 저장합니다.


PSA 는 Private Static Area 의 약자이며, 각 세션마다 독립적으로 사용하는 힙 메모리 영역입니다.

PSA 는 INSTANCE 의 크기에 영향을 미치지 않습니다.




블로그 이미지

사용자 꽁담

GOLDILOCKS 는 Shared-Nothing 구조의 완벽한 Scale-Out 이 가능한 클러스터 데이터베이스 입니다.


각 Node 별 다수개의 Member 를 구성할 수 있으며,

각 Node 의 Member 들 끼리는 동일한 데이터를 가지고 있습니다.



GOLDILOCKS Cluster 는 cdispatcher, cserver 의 추가 프로세스를 가지고 있습니다.

cdispatcher 는 멤버, 노드 간 효율적인 통신을 위한 프로세스입니다.

cserver 는 멤버, 노드 간 데이터의 저장 및 관리를 위한 프로세스입니다.



블로그 이미지

사용자 꽁담

GOLDILOCKS 는 세션접속을 위해 DA 모드, CS 모드 를 제공합니다.


DA ( = Direct Access ) 모드는 세션이 GOLDILOCKS INSTANCE 의 공유메모리에 직접 접근하여 세션의 요청을 처리하는 방식입니다.

CS ( = Client Server ) 모드는 세션이 GOLDILOCKS 에서 제공하는 gserver 프로세스와 TCP 통신을 통해 사용자의 요청을 처리하는 방식입니다.


CS 모드는 다시 DEDICATED, SHARED 모드로 나뉘어집니다.

DEDICATED 모드는 하나의 세션에 대해 하나의 gserver 프로세스가 구동되어 세션의 요청을 처리하는 방식입니다.

SHARED 모드는 gdispatcher 와 gserver 프로세스가 항상 구동되어 있으며, 다수의 세션에 대응하여 요청을 처리하는 방식입니다.





블로그 이미지

사용자 꽁담