High Availability (HA) 구성 가이드
GOLDILOCKS LITE는 공유메모리 기반의 빠른 성능을 목표로 개발되었다. 따라서 사용자 운용환경에 맞춰 데이터 안정성 보장과 고가용성을 위해 디스크 로깅 방식을 선택적으로 사용할 수 있다.
모든 데이터가 공유메모리에 보존되므로 기본적인 환경에서는 데이터가 유실되지 않는다. 그러나 OS fatal, memory fault, 정전과 같은 하드웨어 장애가 발생할 경우 데이터가 유실될 수 있으므로 이에 대비하여 아래에서 설명하는 방식으로 운영할 수 있다. 단, 해당 방식으로 운영할 경우 기본적인 메모리 운영방식에 비해 성능이 저하될 수 있다는 점을 감안해야 한다.
디스크 로깅 방식
일반적인 RDBMS들과 유사하게 메모리에 변경되는 모든 사항들을 디스크 로깅 형태로 저장하고 주기적인 체크포인트를 통해 데이터 파일을 생성/ 관리하여 데이터를 복구할 수 있도록 운영하는 방법이다.
LITE_SAN
고가용성을 위해 디스크 로깅 방식으로 운영할 경우 active/ standby 형태로 서버를 구성하고 디스크를 공유하는 방식을 권장한다. 평소에는 active에서 운영하면서 장애가 발생할 경우 공유된 디스크를 standby로 mount하여 데이터를 복구하고 서비스를 재개하는 형식의 운영 방법이다.
설정 방법
다음의 프로퍼티를 설정해야 한다.
Property name | 설명 | Value |
|---|---|---|
DBM_DISK_LOG_ENABLE | 디스크 로깅 활성화 여부 | true |
DBM_DISK_LOG_DIR | 디스크 로그파일이 생성될 위치 | 절대경로 |
DBM_DISK_LOG_FILE_SIZE | 디스크 로그파일 한 개당 최대 크기 | 최소 100M 이상 권장 |
DBM_DISK_DATA_FILE_DIR | 데이터 파일이 생성될 위치 | 절대경로 |
위 프로퍼티들을 설정하면 각 세션당 로그 파일이 생성된다. I/O가 발생할 때 세션간 트랜잭션 순서에 대한 disk I/O 경합이 최소화 되도록 병렬 로깅과 순서에 영향을 받지 않는 복구 메커니즘을 통해 체크포인트 시점마다 생성된 로그파일을 데이터 파일에 반영한다.
기본 로깅 설정은 세션이 commit을 호출할 때마다 I/O을 발생시킨다. 위와 같은 형태는 로깅에 대한 경합을 최소화할 수 있지만 I/O 호출을 빈번하게 발생시킨다. 따라서 만일 다음과 같이 설정할 경우 이를 공유 메모리에 로깅하고 주기적으로 디스크로 flush 시키는 형태로 운영할 수도 있다.
Property name | 설명 | Value |
|---|---|---|
DBM_LOG_CACHE_MODE | Cache mode 설정 여부이다. | 1: NVDIMM을 이용한다. 2: 공유메모리를 이용한다. |
DBM_LOG_CACHE_COUNT | 로그를 기록할 메모리 segment를 몇 개로 운용할지 설정한다. | NVDIMM의 경우 해당 NVDIMM의 개수 |
DBM_LOG_CACHE_SIZE | 로그를 기록할 메모리 segment 한 개당 최대 크기이다. | NVDIMM의 경우 해당 NVDIMM의 크기 |
DBM_LOG_CACHE_FLUSH_INTERVAL | 메모리로부터 강제로 디스크로 flush를 수행하는 주기이다. | 최소 3초 이상 |
DBM_LOG_CACHE_EMPTY_INTERVAL | 메모리에서 빈 로그 블록을 만날 경우 얼마만큼 대기한 후에 이 빈 블록을 무시할지를 설정한다. | 최소 3초 이상 |
위와 같이 cache mode를 설정하면 세션이 commit 시점에 로그를 파일에 바로 기록하지 않고 공유 메모리나 NVDIMM 장치에 기록한다. 이 과정에서 자신의 로그를 기록할 위치를 할당받는 순간에 경합이 발생할 수 있지만 기본적으로 디스크에 기록하는 기본 설정에 비해 성능이 더 나을 수 있다. NVDIMM은 비 휘발성 메모리를 의미하며 정전이 되더라도 자체 배터리와 SSD 조합을 통해 데이터를 보존할 수 있다. 사용자는 NVDIMM 장치를 사용하여 성능과 안정성을 최대화 할 수 있다.
Cache segment에 기록된 트랜잭션 로그들은 dbmLogFlusher라는 process에 의해 디스크의 로그 파일 형태로 기록이 된다. 따라서 dbmLogFlusher의 동작이 느리거나 cache segment size를 너무 작게 설정하면 cache에 로그를 기록할 공간을 할당하기 위해 트랜잭션 대기가 발생할 수 있으므로 cache segment 크기와 dbmLogFlusher의 동작 주기를 적절하게 설정해야 한다.
추가적으로 사용자가 로그에 대해 archiving 동작을 설정하려면 다음 프로퍼티들을 설정해야 한다.
Property name | 설명 | Value |
|---|---|---|
DBM_ARCHIVE_ENABLE | archive 운영 설정 여부 | true |
DBM_ARCHIVE_PATH | archiving 될 로그가 저장될 경로 | 절대경로 |
Archive mode를 설정하면 dbmCkpt라는 process에 의해 체크포인트가 동작할 때 반영 완료된 로그파일이 DBM_ARCHIVE_PATH로 이동된다. 만일 이 설정이 false로 되어 있으면 해당 로그파일은 자동으로 삭제된다.
관련 Process
디스크 로깅 방식으로 운영하려면 항상 다음과 같은 프로세스들이 구동되어야 한다.
Process name | 설명 |
|---|---|
dbmCkpt | 체크포인트를 수행하여 기록이 완료된 로그 파일을 정리하고 데이터 파일을 생성한다. |
dbmLogFlusher | Log cache mode를 설정할 때 메모리의 로그를 디스크의 로그 파일 형태로 기록한다. (Cache mode가 아니면 구동하지 않는다.) |
제약사항
다른 모든 메모리 DBMS와 마찬가지로 트랜잭션 로그를 메모리에 기록하고 주기적인 디스크 I/O를 통해 로그 파일을 만든다. 그러나 이 동작 주기 중간에 장애가 발생하면 직전 동작이 완료된 직후 발생한 메모리 상의 모든 트랜잭션 로그는 유실된다. 이를 방지하기 위해 성능이 매우 느려지는 것을 감수하고 DBM_DISK_COMMIT_WAIT 라는 프로퍼티를 제공한다. 이 프로퍼티는 로그를 기록할 때마다 해당 로그가 디스크로 완전히 flush 된다는 것을 보장한다. 이 설정은 디스크 기반의 DBMS와 비교하여 변경 연산을 처리할 때 성능 차이가 없으므로 고성능이 목적인 환경에서는 권장하지 않는다.
고려사항
응용 프로그램 코드 변경
메모리 기반인지 디스크 기반인지에 따라 코드를 변경할 필요는 없다.
HW 용량
다음 사항들을 고려해야 한다.
HW 고려 대상 | 설명 |
|---|---|
Memory size | Cache mode로 운영할 때 segment의 합계만큼 할당한다. |
LogFile 보관 용량 | 체크포인트 동작 주기에 따라 필요한 보관 용량이다. |
DataFile 보관 용량 | 체크포인트에 의해 생성되는 데이터 파일을 보관하는데 필요한 용량이다. |
Archive 보관 용량 | 체크포인트가 archive file을 보관할 때 필요한 용량이다. |
Log cache mode에서 공유 메모리를 설정하여 운영할 경우 기존 데이터 저장공간 외에 별도의 로그 저장 공간이 생성되는데 이 공간은 dbmLogFlusher에 의해 비워질 때까지 유지되므로 공간을 충분하게 할당해야 한다.
dbmCkpt에 의해 체크포인트가 발생하면 해당 시점에 대량의 I/O가 발생한다. 이는 system 성능에 영향을 미칠 수 있으므로 유휴 시간에 처리하는 방식을 고려할 수 있는데 이 경우 로그 파일이 지속적으로 증가하게 되므로 이를 보관할 수 있는 용량을 확보해야 한다.
장애 복구
디스크 로깅 방식에서 장애 복구는 다음 절차대로 진행된다. 여기서 각 예제는 active 장애가 발생하여 standby로 전환하는 경우에 대해 설명한다. 반대의 경우도 동일한 절차를 통해 failback 할 수 있다.
디스크를 standby로 전환한다.
Standby에서 dbmCkpt를 통해 강제로 체크포인트를 수행한다.
Standby에서 "startup" 명령을 통해 데이터를 복구한다.
데이터를 확인한 후에 서비스를 재개한다.
2번 단계는 직전 체크포인트 시점까지의 로그 파일만 데이터 파일에 반영된 상태이므로 이후에 기록된 로그 파일 전부를 디스크로 반영하려면 강제로 체크포인트를 수행하여 데이터 파일을 완성해야 한다. 그렇지 않으면 마지막 체크포인트 시점의 로그 파일까지만 반영되므로 데이터 정합성이 깨진다.
3번 단계는 dbmMetaManager를 구동한 후 내부에서 "startup" 명령을 수행하여 전체 instance/ table의 모든 데이터를 복구하는 과정이다. 따라서 standby는 초기화된 상태이어야 한다.
장애 복구의 과정들은 Linux의 failover를 담당하는 제품 내 failover script 상에 2, 3 단계별 명령어를 각각 등록하여 자동화할 수 있다.
REPLICATION 방식
GOLDILOCKS LITE는 네트워크를 이용한 실시간 이중화 방식을 제공한다. SYNC와 ASYNC라는 두 가지 유형으로 동작을 설정할 수 있다.
SYNC 방식은 트랜잭션이 커밋되는 시점에 standby 측에 데이터가 반영된 후 client가 응답을 받는 구조이다.
ASYNC 방식은 트랜잭션이 커밋되는 시점에 buffer에 누적하고 client가 응답을 받는 구조이다. Buffer에 누적된 동기화 데이터는 다음과 같이 특정 조건에 맞을 경우 전송된다.
이중화 버퍼를 모두 기록하여 더 이상 기록할 수 없는 경우 전송
이중화 버퍼가 기록된 이후 1초 이내에 추가적 기록이 없는 경우 전송
이중화 운영을 위한 환경설정
각각의 master/ slave 측에서는 다음과 같은 환경 변수 등이 설정 되어야 한다.
[ MASTER 측 ] DBM_REPL_ENABLE=1 DBM_REPL_TARGET_PRIMARY_IP=xxx.xxx.xxx.xxx DBM_REPL_TARGET_PORT=29001
[ SLAVE 측 ] DBM_REPL_LISTEN_PORT = 29001
이중화 대상 테이블 등록 및 dbmReplica 구동
이중화 대상은 전송 측인 master에서 등록한다.
dbmMetaManager(DEMO)> CREATE REPLICATION TABLE t2, t3; success dbmMetaManager(DEMO)> SELECT * FROM dic_repl_table; --------------------------------------------------------------------------------- INST_NAME : DEMO TABLE_NAME : T2 --------------------------------------------------------------------------------- INST_NAME : DEMO TABLE_NAME : T3 --------------------------------------------------------------------------------- 2 row selected
이중화 수신 측인 slave에서는 dbmReplica를 구동한다.
shell> dbmReplica -i demo
사용자 프로그램의 동작
응용 프로그램에서는 dbmInitHandle을 수행하는 시점에 이중화를 준비한다. 이 과정에서 개별 프로그램은 내부적으로 이중화 관련 전송 로그 반영 여부에 대한 Ack 수신 thread를 생성한다. dbmPrepareTable을 수행하는 과정에서 테이블이 이중화 대상인지 판별한다. dbmCommit 시점에서 이전에 수행된 DML 중에 테이블이 이중화 대상인 것들만 모아 slave로 전송한다.
이중화 동기화 mode | Description |
|---|---|
ASYNC | commit 시점에 slave에 반영 여부를 확인하지 않는다. |
SYNC | commit 시점에 slave에 반영된 결과를 확인한다. |
이중화 동기화 mode는 성능과 관련된 설정이다. Local transaction의 성능이 중요한 경우 async로 설정하고, 데이터 동기화 수준이 더 중요한 경우라면 sync로 설정한다. 이 설정은 환경 변수로도 제어할 수 있으므로 프로그램마다 동기화 수준을 개별로 제어할 수 있다.
미전송 로그 반영
네트워크 장애가 발생했을 때 이중화로 전송이 불가능한 시점에는 master 측에서 각 세션들이 직접 미전송 로그를 기록한다. 장애가 복구된 후 사용자가 직접 이중화 로그 전송 처리 명령을 수행하면 데이터는 slave에 반영된다. 만일 미전송 로그를 공유 디스크에 기록하도록 설정하면 slave측에서는 미전송 로그를 직접 반영한 후 서비스를 재개할 수 있도록 하는 기능을 제공한다.