FAQ

Sharding key는 어떤 컬럼으로 구성해야하나요?

Sharding Key의 적합한 컬럼을 찾는 방법은 어플리케이션의 쿼리에 따라 다릅니다 주로 공통적으로 사용하는 조인 키 또는 where 절의 조건 키로 설정합니다 composite sharding key로 할 경우 원하는 성능에 못미칠 수 있습니다
Active - Active 로 사용하다가 Active-Standby로 사용하려면 DB를 재구축해야하나요?

아닙니다. Client설정만으로도 Active-Standby로 사용할 수 있습니다 Goldilocks Cluster는 기본적으로 Active-Active으로 사용할 수 있습니다. DML을 수행하는 Client를 한쪽으로만 모은다면 Active-Standby로 사용할 수 있습니다 또한, Global Connection을 사용하고 있다면 'LOCALITY_MEMBER_POLICY' 프로퍼티로 A-A/ A-S를 조정할 수 있습니다.
cluster system에서 파일 저장 방식은 어떻게 되나요?

제어 파일, 데이터 파일, 로그 파일은 클러스터 멤버 각각 저장합니다. 백업 파일은 사이트 정책에 따라 다르지만 일반적으로 그룹마다 백업 파일을 저장합니다.
Sharding key의 제약조건이 있나요?

Shared table에 대한 Primary Key , Unique 제약 조건, Unique Index는 Sharding key를 포함해야합니다
운영중에 Scale In/Out이 가능하나요? (데이터 분배 및 동기화 시간, 예측되는 부하)

GOLDILOCKS는 온라인 Scale In/Out이 가능합니다. 새로운 클러스터 그룹을 추가할 경우, 그에 따른 shard data 의 재분배가 일어나게 되는데 이 재분배 시간은 데이터 양, HW 스펙에 따라 매우 달라집니다. shard를 이동시키거나 데이터 동기화를 하게 될 경우 해당 노드에 cpu, network 부하가 일어날 수 있습니다. 또한 rebalance 과정중 마지막 journal data (default 10MB) 를 처리할 경우 테이블 lock 을 잡게 되므로 비교적 트랜잭션이 적은 시간대에 작업을 진행할 것을 권고드립니다
Rebalance 시 해당 테이블에 lock이 발생하나요?

데이터 rebalance 수행 중인 테이블에 대해 LOCK이 걸리지 않습니다. 해당 테이블에 transaction이 발생하면 해당 트랜잭션은 Journaling을 통해 디스크로 기록이 되고, rebalance 완료 이후 저널링된 트랜잭션들을 수행하는 방식입니다. 다만. 마지막 Journal data (default 10MB) 를 반영할땐 해당 테이블에 lock 을 겁니다 또한 데이터의 양이나 테이블에 따라 시스템 과부하를 완전히 피하지는 못하므로, 비교적 트랜잭션이 적은 시간대에 작업을 진행할 것을 권고드립니다.
cluster 구성에서 한 Group의 모든 멤버가 장애가 났을 경우 데이터 접근이 가능한가?

한 Group의 모든 멤버가 장애가 났을 경우, 해당 그룹의 데이터는 접근이 불가능 합니다. 해당 그룹을 제외한 데이터로의 쿼리 수행만 가능합니다.
Cluster 구성 노드 중 일부가 종료 되었을 때, Cluster System은 정상 동작하나요?

Goldilocks의 Cluster 환경에서, Group 내의 모든 멤버는 같은 데이터를 가지고 있고, Shared Nothing 구조이기 때문에 노드의 장애 시 다른 노드를 통해 지속적인 운영이 가능합니다. 예를 들어, 1by2로 구성된 환경에서 G1N1 장비에 장애가 발생하더라도 동일한 데이터를 갖는 G1N2로 Failover가 진행됩니다. 이는 gmaster의 Failover Thread에 의해 진행되며, 장애 노드에 대한 Offline 처리, Coordinator 선정 등의 Failover를 처리합니다. Coordinator란, 클러스터 시스템 내 데이터 정합성을 보장하기 위한 개념으로, commit/rollback 처리를 담당하는 Master 개념으로 볼 수 있습니다.
cluster 구성 노드 중 일부가 종료 되었을 때, Connection은 자동 Failover 가 되나요/ 서비스 중단이 있나요?

클러스터 구성 시 자동 failover/failback 을 제공합니다. 한 그룹에 대해 두 멤버가 존재하는 환경에서, (이를 G1N1, G1N2라 칭함) G1N1 로 connection/session 을 맺고 있는 도중, G1N1 노드에 장애가 발생할 경우 glocator 또는 location 파일에 정의된 alternative 정보( G1N2 정보 )를 이용해 G1N2 로의 connection이 진행됩니다. 또한 G1N1 복구 시, G1N2 으로의 connection이 자동으로 G1N1 노드로 옮겨지는 것은 아니며 G1N2 의 장애 시 동일한 방법으로 G1N1 로의 connection이 진행됩니다. 그러므로 보통 atlernative 정보는 모든 노드에 대한 정보를 기록합니다. DB 서비스 중단 없이 운영 가능합니다.
백업 방안으로는 어떤 것들이 있나요?

백업 방안은 Hot(Online) Backup, Cold(Offline) Backup 등이 있으며, 그 중 Hot Backup을 가장 많이 사용합니다. 이는 DB 운영 중 백업하는 방식으로, 일반적으로 사용하는 ALTER DATABASE BEGIN / END BACKUP 명령어를 이용한 방식입니다. archive log mode여야 하며 tablespace, datafile 관련 연산들은 수행할 수 없습니다
Memory의 data를 Disk로 내리는(flush) 시점이 언제인가요?

Disk에 flush하는 시점은 Redo Log File에 내리는 시점이며, gmaster의 Page Flusher Thread가 dirty page들을 배분/제어하고 Log Flusher Thread가 온라인 Redo Log File에 주기적으로 적재합니다. background 에서 수행이 되므로 서비스에 영향은 없습니다
Goldilocks가 사용하는 메모리는 어떤 것이 있나요?

• GOLDILOCKS의 메모리 할당량은 다음과 같습니다. 1. TABLESPACE 크기 A. 각 TABLESPACE의 총합만큼의 메모리를 사용합니다. i. DICTIONARY Tablespace ii. UNDO Tablespace iii. DATA Tablespace iv. TEMP Tablespace 2. SSA( SHARED STATIC AREA ) 영역 A. 시스템의 모든 세션에서 공유하는 정보들이 저장되는 메모리 영역입니다. (이 중 Log buffer와 Plan cache는 프로퍼티를 이용해 제어 가능) i. Log buffer ii. Plan cache iii. Dictionary cache iv. Session pool v. Lock pool vi. Transaction pool 3. PSA( PRIVATE STATIC AREA ) 영역 A. 세션마다 독립적으로 사용하는 heap 메모리 영역입니다. 4. gserver A. ggserver 프로세스가 차지하는 메모리 B. gserver 하나당 약 13~15MB 할당합니다.
DML은 Auto Commit으로 동작하나요?

DML autocommit 관련 부분은 DB단이 아닌 커넥션 단의 설정이며 ODBC/JDBC 모두 표준이 디폴트 autocommit 모드입니다. 저희 Goldilocks는 이러한 DBC 표준을 따르기 때문에 디폴트가 autocommit 입니다. commit & rollback 을 명시하여 사용할 경우 다음과 같이 autocommit을 off할 수 있습니다. <ODBC> SQLSetConnectAttr( sDbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, SQL_IS_UINTEGER ); <JDBC> con.setAutoCommit(false);
각 SQL에서 사용되었던 바인드 변수는 확인 가능한가요?

매뉴얼 확인 TRACE_LOG_ID 값을 설정하여 로그에 기록 가능 성공한 SQL 질의 출력 여부, 실패한 SQL 질의 출력 여부, 실행 계획 출력 여부, 실행 형태 (direct/prepare) 출력 여부, Bind 값 출력 여부, 구간별 수행시간 출력 여부 일반적으로 GOLDILOCKS trace log는 발생 시간, 프로세스명, 스레드id 등과 함께 해당 내용이 기록됩니다. 로그와 관련된 서버 프로퍼티들은 다음과 같습니다. - TRACE_ALTER_SYSTEM : alter system 관련 구문에 대한 내용을 trace file에 기록하며, 이는 DML 성능에 영향을 주지 않습니다. - TRACE_DDL : DDL구문에 대한 SQL문을 trace file에 기록하며, 이 역시 DML 성능에 영향을 주지 않습니다. - TRACE_LOG_ID : 상기 적어주신 내용에 맞춰 flag 에 따라 출력 정보를 결정합니다.
실행계획을 보려면 \explain plan을 항상 입력해야 하나요? Oracle의 SET AUTOT TRACEONLY 설정과 유사한게 있나요?

다음과 같은 gsql/gsqlnet 옵션으로 설정할 수 있습니다. \SET AUTOTRACE ON
ddl script를 보는 방법이 있나요?

gsql/gsqlnet에선 \ddl_table \ddl_procedure 등 \ddl_* 구문으로 확인이 가능합니다 외부 tool에서는 아래의 명령으로 확인 가능합니다 SELECT * FROM ALL_SOURCE ; SELECT * FROM ALL_SOURCE WHERE 1 = 1 AND NAME = <object_name> ;
Failover 로 인해 장애 노드에 연결되어있던 Session이 다른 노드로 연결 될 경우, 어떤처리를 해야하나요?

ODBC, JDBC단에 FAILOVER_TYPE을 Session으로 했을 경우 , DB 노드 장애시 장애노드에서 진행중인 트랜잭션은 자동으로 정상 노드에서 처리됩니다 다만, 아래와 같은 에러가 발생했을 경우 prepare 수행 없이 execute 수행하는 로직을 추가하시면 됩니다. ODBC일 경우 - 19068(Retry the transactional operations) JDBC일 경우 - 21047(Retry the transactional operations again)