FAQ

데이터 rebalance 수행 중인 테이블에 대해 LOCK이 걸리지 않습니다.

해당 테이블에 transaction이 발생하면 해당 트랜잭션은

Journaling을 통해 디스크로 기록이 되고, rebalance 완료 이후

저널링된 트랜잭션들을 수행하는 방식입니다.

다만. 마지막 Journal data (default 10MB) 를 반영할땐 해당 테이블에 lock 을 겁니다

또한 데이터의 양이나 테이블에 따라

시스템 과부하를 완전히 피하지는 못하므로,

비교적 트랜잭션이 적은 시간대에 작업을 진행할 것을 권고드립니다.

GOLDILOCKS는 온라인 Scale In/Out이 가능합니다.

새로운 클러스터 그룹을 추가할 경우, 그에 따른 shard data 의 재분배가 일어나게 되는데 이 재분배 시간은 데이터 양, HW 스펙에 따라 매우 달라집니다.

shard를 이동시키거나 데이터 동기화를 하게 될 경우 해당 노드에 cpu, network 부하가 일어날 수 있습니다.

또한 rebalance 과정중 마지막 journal data (default 10MB) 를 처리할 경우 테이블 lock 을 잡게 되므로 비교적 트랜잭션이 적은 시간대에 작업을 진행할 것을 권고드립니다

아닙니다. Client설정만으로도 Active-Standby로 사용할 수 있습니다

Goldilocks Cluster는 기본적으로 Active-Active으로 사용할 수 있습니다.

DML을 수행하는 Client를 한쪽으로만 모은다면 Active-Standby로 사용할 수 있습니다

또한, Global Connection을 사용하고 있다면 'LOCALITY_MEMBER_POLICY' 프로퍼티로 A-A/ A-S를 조정할 수 있습니다.

Goldilocks의 Cluster 환경에서, Group 내의 모든 멤버는 같은 데이터를 가지고 있고,

Shared Nothing 구조이기 때문에 노드의 장애 시 다른 노드를 통해 지속적인 운영이 가능합니다.

예를 들어, 1by2로 구성된 환경에서 G1N1 장비에 장애가 발생하더라도

동일한 데이터를 갖는 G1N2로 Failover가 진행됩니다.

이는 gmaster의 Failover Thread에 의해 진행되며,

장애 노드에 대한 Offline 처리, Coordinator 선정 등의 Failover를 처리합니다.

Coordinator란, 클러스터 시스템 내 데이터 정합성을 보장하기 위한 개념으로,

commit/rollback 처리를 담당하는 Master 개념으로 볼 수 있습니다.

클러스터 구성 시 자동 failover/failback 을 제공합니다.

한 그룹에 대해 두 멤버가 존재하는 환경에서, (이를 G1N1, G1N2라 칭함)

G1N1 로 connection/session 을 맺고 있는 도중,

G1N1 노드에 장애가 발생할 경우 glocator 또는 location 파일에 정의된

alternative 정보( G1N2 정보 )를 이용해 G1N2 로의 connection이 진행됩니다.

또한 G1N1 복구 시, G1N2 으로의 connection이 자동으로 G1N1 노드로 옮겨지는 것은 아니며

G1N2 의 장애 시 동일한 방법으로 G1N1 로의 connection이 진행됩니다.

그러므로 보통 atlernative 정보는 모든 노드에 대한 정보를 기록합니다.

DB 서비스 중단 없이 운영 가능합니다.

자주 묻는 질문