10. 제약 사항

이 장을 마치면: GritDB 1.1의 설계상 제약과 지원 범위의 경계를 안다. 각 제약의 영향과 대응도 안다.

  • 이 장은 설계와 지원 범위의 경계만 싣는다. 버전별 변경 사항은 릴리스 노트에 있다. 절차 안에서만 걸리는 조건(설정 값, 등록, 분석계 단계)은 그 절에 있다.
  • 항목 형식: 수치(10.2)는 항목 | 제한 종류 | 제한값 | 조정이다. 플랫폼, 호환, 저장 구조(10.1, 10.3, 10.4)는 제약 | 영향 | 대응 | 확인 방법이다. 운영 규칙(10.5)은 제약 | 영향 | 대응이다. 1.1에 없는 기능(10.6)은 기능 | 대응이다.

10.1 플랫폼

제약 영향 대응 확인 방법
cx16과 sse4_2가 있는 x86-64 미달 서버에서는 GritDB가 기동하지 않는다. 설치 스크립트는 경고만 낸다 서버 선정 단계 확인 QuickStart 2장 ①
glibc ≥ min_glibc 미달 시 실행 불가 OS 선정 단계 확인 QuickStart 2장 ②
OS가 보는 전체 메모리(free -m의 total) 8192 이상 미달 시 GritDB 엔진이 기동하지 않는다. 이름이 8 GB인 서버는 보통 모자란다 서버 선정 단계 확인 free -m
OS: Ubuntu 24.04 LTS 그 밖의 OS와 컨테이너는 지원 환경 밖이다 서버 선정 단계 cat /etc/os-release
단일 서버 이중화나 다중 노드 구성 없음 10.6, 대기 서버는 8.7 —

10.2 수치 한계

항목 제한 종류 제한값 조정
설치 경로 길이 고정(unix socket 한도) 80자 불가
열 수, 이름 길이, 값 크기 고정(PostgreSQL) 1600열, 63바이트, 1 GB 불가
등록 테이블 수 — 상한 없음 —
분석 질의 이력의 질의 문장 고정 앞 1024자(전문은 datafiles/query_text_archive.jsonl에 있다) 불가
동시 분석 세션 실행 파생 vCPU 수 × 4 vCPU
접속 수 조정 가능(PostgreSQL) 일반 계정이 쓰는 수는 max_connections − superuser_reserved_connections(기본 3) − reserved_connections(기본 0) − GritDB 내부 접속(grit_surfer.catalog.read_threads + 2, 기본 6, 7.1)이다 ALTER SYSTEM. 바꾸면 5.6의 shm_limit_mb 경고를 본다
max_worker_processes 고정(GritDB) 256 이하(상한 고정). 넘으면 GritDB가 기동하지 않는다 256 안에서 ALTER SYSTEM(6.4.1의 5번)
한 트랜잭션 행 수 파생(서버 메모리, 바꾸는 설정 없음) 엔진 로그 Tier-3 (RowVersion 줄의 max=(6.8) 그 절반 아래로 나눠 commit한다. 넘는 초기 복사나 운영 DB 배치는 지원 문의를 한다
검증한 vCPU 수 — 실측 뒤 —
파일 열기 한도 OS 의존 65536 이상 OS 설정(1.4)

10.3 PostgreSQL 호환 범위

제약 영향 대응 확인 방법
PostgreSQL 추가 모듈(contrib, 예: pg_stat_statements)이 설치 파일에 없다 그 모듈을 쓰는 감시나 진단을 할 수 없다 7장 점검, A.6 진단 쿼리, 분석 질의 이력(6.5) SELECT name FROM pg_available_extensions ORDER BY 1;이 내는 목록에 없다
다른 preload 확장과 함께 쓰는 구성은 1.1에서 시험하지 않았다 동작을 보장하지 않는다 필요하면 지원 문의(0장)를 한다. 필수 블록의 shared_preload_libraries는 바꾸지 않는다(5.2) SHOW shared_preload_libraries;가 gritsurfer를 낸다
정렬은 C 고정이다(설치가 정한다) 정렬 결과가 ko_KR, en_US 정렬과 다르다 TEMPLATE template0으로 다른 정렬의 데이터베이스를 만들지 않는다(1.8) SELECT datname, datcollate, datctype FROM pg_database;가 C와 C.UTF-8을 낸다
시간대: 분석 세션 조회는 세션 시간대(SET timezone)를 쓰지 않는다 timestamptz 값이 일반 세션과 다르게 나올 수 있다 응용의 시간대를 서버와 맞춘다. AT TIME ZONE으로 맞춘다(1.8과 6.6) SHOW timezone;을 응용과 서버에서 비교한다
numeric: 정밀도를 정하지 않았거나 38을 넘는 열은 분석 세션에서 근사값이다 금액과 수량 합계가 일반 세션과 다를 수 있다 numeric(p, s)(p ≤ 38)로 만든다(6.2) 6.2 정밀도 점검 쿼리가 0행을 낸다
분석 세션 결과는 avg 정밀도, numeric 자릿수, real 열의 sum, char(n)의 octet_length, concat, timestamptz 출력이 PostgreSQL과 다를 수 있다 같은 SELECT의 결과가 두 세션에서 다르다 정확한 값이 필요하면 일반 세션 또는 /*+ engine=pg */(6.6) 같은 SELECT를 두 세션에서 실행해 비교한다
restart_after_crash는 꺼져 있고 바꿀 수 없다 백엔드 하나가 비정상 종료하면 GritDB 전체가 정지한다 4.3 순서로 다시 기동한다 SHOW restart_after_crash;가 off를 낸다
pg_upgrade와 pg_basebackup 백업은 GritDB에 쓰지 않는다 GritDB 데이터를 다루지 않는다 업그레이드는 3장, 백업은 8장(A.1과 8.3) —
논리 복제: GritDB는 받는 쪽(분석계, subscription)만 GritDB를 publication 원본으로 쓰는 구성은 다루지 않는다. 운영 DB의 물리 복제(스트리밍 대기 서버)나 pg_createsubscriber로도 받지 않는다(1.1과 6.4) 분석계는 6.4 —
gritsurfer_session_mode는 접속 옵션으로만 켠다 계정과 데이터베이스 기본값이나 SET으로 켤 수 없다 드라이버의 접속 옵션(6.6) SHOW gritsurfer_session_mode;
등록 테이블이나 데이터베이스를 DROP한 트랜잭션은 PREPARE TRANSACTION이 불가하다 2단계 commit을 쓰는 도구의 그 트랜잭션이 실패한다 DROP은 2단계 commit 밖에서 한다(6.3) 오류 문구(6.3)

10.4 GritDB 저장 구조 관련

제약 영향 대응 확인 방법
등록 테이블: REPLICA IDENTITY FULL 미설정 시 등록 거부 등록 전 설정 \d+ <테이블>
등록은 등록 전에 있던 행을 GritDB 엔진으로 옮기지 않는다 데이터가 있는 테이블을 등록하면 분석 세션 결과에 등록 전 행이 빠진다 테이블이 비어 있을 때 등록한다. 분석계로 붙일 때는 subscription(CREATE SUBSCRIPTION) 전에 등록한다 같은 count(*)를 일반 세션과 분석 세션에서 비교한다(분석 세션에서는 반영 확인 뒤, 엔진 강제, 6.6.1)
등록 여부는 접속마다 처음 확인한 값을 접속이 끝날 때까지 쓴다 등록이나 해제 전에 그 테이블에 쓴 접속은 바뀐 등록 여부를 모른다(변경이 넘어가지 않거나 계속 넘어간다) 등록하거나 해제한 뒤 그 테이블을 쓰는 접속과 복제 작업자를 다시 연다(6.3) 재접속 전과 후에 같은 count(*)를 일반 세션과 분석 세션에서 비교한다(분석 세션에서는 반영 확인 뒤, 엔진 강제, 6.6.1)
등록: 지원하는 열 형식만(15종, 6.2) 지원하지 않는 형식의 열이 있으면 등록 거부(ERROR) 등록 전 열 형식 확인 등록 함수의 오류 문구
등록: 열을 지운 적이 없는 테이블만 열을 지운 적이 있으면(DROP COLUMN) 등록 거부(ERROR) 테이블을 다시 만든 뒤 등록(6.7과 6.2) pg_attribute의 attisdropped 행 수(6.2)
분석 세션의 조회는 cold file에 반영된 데이터를 읽는다 방금 commit한 변경이 분석 세션 조회 결과에 바로 보이지 않을 수 있다 최신 값이 꼭 필요한 조회는 일반 세션(pg)에서 한다(6.6). 분석계면 운영 DB에서 한다 같은 SELECT를 일반 세션과 분석 세션에서 실행해 결과를 비교한다
TRUNCATE와 구조 변경(DDL)은 GritDB 엔진에 반영하지 않는다 분석 세션 결과가 일반 세션과 달라진다 6.7 “대신 할 일”, 분석계는 그 테이블 다시 받기(6.4.2) 같은 count(*) 비교(6.6)
  • 반영 지연은 보통 약 12초이고, 100번 중 99번은 약 22초 안이다(자체 시험). 분석계면 운영 DB에서 복제되는 시간이 더해진다. 반영을 확인하려면 6.6.1을 본다.

10.5 운영 규칙

제약 영향 대응
기동과 정지는 gritdb-start와 gritdb-stop 전용이다 pg_ctl 단독 기동 시 약 60초 뒤 종료 QuickStart 6장 금지 1
데이터: datafiles/ 한 묶음 일부만 교체나 삭제 시 기동 불가 QuickStart 6장 금지 2와 8장 백업 단위
데이터: 같은 실경로 설치 뒤 datafiles/ 실경로(재배치 대상과 mount 지점 포함)를 바꾸면 cold file을 잃는다 경로를 바꾸지 않는다. 복구도 같은 경로로 한다(8.4)
gritsurfer_slot 유지 삭제 시 GritDB 데이터 불일치와 기동 불가 가능 QuickStart 6장 금지 3
GritDB 서버에 max_slot_wal_keep_size를 설정하지 않는다 복구용 복제 슬롯이 무효가 되면 GritDB가 기동하지 않을 수 있다 기본값(-1)을 유지한다. pg_wal은 디스크로 계획한다(1.3). 분석계의 상한은 운영 DB 쪽에 둔다(6.4.3)
wal_level = logical 고정 변경 시 GritDB 동작 불가 5장 필수 블록
분석계 publication에는 복제 키가 있는 테이블만 이름으로 넣는다 복제 키가 없는 테이블을 넣으면 운영 DB에서 그 테이블의 UPDATE와 DELETE가 오류로 멈춘다 6.4.1의 2번과 3번
분석계 테이블: 운영 DB와 같은 기본 키 없으면 수정과 삭제 적용이 멈추고 운영 DB에 WAL이 쌓인다 6.4.1의 6번
분석계 subscription: streaming = off on과 parallel은 1.1에서 쓰지 않는다 6.4.1의 8번
분석계는 백업 복원 대신 다시 받는다 백업으로 복원하면 백업 뒤의 운영 DB 변경이 빠진다 8.6 다시 받기(8.4)
한 트랜잭션: 상한(6.8)의 절반 아래(분석계 초기 복사와 운영 DB 배치 포함) 넘으면 GritDB가 멈추고(PostgreSQL 포함), 분석계는 다시 띄워도 또 멈춘다 나눠 commit한다. 넘는 테이블이나 배치는 지원 문의를 한다(6.4와 6.8)
restart_after_crash를 설정하지 않는다 postgresql.conf에 쓰면 기동 실패 5.3
새 데이터베이스는 template1을 복제해 만든다 template0 복제 DB에는 확장이 없다 6장 6.1
postgres 데이터베이스 유지 지우거나 이름을 바꾸면 기동 불가 6.1
GritDB 내부 테이블(postgres 데이터베이스의 gritdb 스키마)을 고치거나 잠그지 않는다(superuser 포함). 등록 목록의 gritdb.grit_surfer_heartbeat도 해제하거나 삭제하지 않는다 GritDB가 멈출 수 있다 조회는 6.5 함수로만 한다
로그에 SQL 원문 기록 가능 반출 시 데이터 노출 9장 9.7
즉시 정지: core 파일 디스크를 수십 GB 쓸 수 있다 4.2와 9.6
OS의 RemoveIPC를 끈다(서비스 계정이 일반 계정일 때) 서비스 계정이 로그아웃하면 GritDB 공유 메모리가 지워진다 1.4 ⑤

10.6 1.1 에 없는 기능

기능 대응
GritDB 이중화(standby, HA, DR)와 다중 노드 단일 서버와 백업(8장). 분석계는 운영 DB에서 다시 받는다(8.6). 대기 서버는 수동이다(8.7)
GritDB 엔진 메모리 크기 설정 물리 메모리 비율로 정해진다(1.3과 5.5)
등록 대상 자동 선정 운영자가 등록한다(6.2)
작업 부하와 자원 그룹 동시 실행 한도 고정(6.9)
암호 정책(복잡도와 실패 잠금) PostgreSQL 기본(VALID UNTIL)과 11.10
감사 전용 확장 PostgreSQL 로그 설정(11.9)
데이터 가리기(redaction) 반출 때 가린다(9.7)
자료 수집 도구 QuickStart 7.4 수동 수집
자동 재기동과 무중단 재시작 4.3과 계획 정지(4.7)
기존 PostgreSQL에 GritDB 붙이기 새로 설치한 GritDB로 분석계 구성(6.4)
실행 중 백업, 파일시스템 스냅샷 백업, WAL 보관 시점 복구(PITR) 정지 후 백업(8.2). 되살릴 수 있는 시점은 마지막 백업이다(8.3)
연결 암호화(TLS), 외부 인증(LDAP, PAM, GSSAPI), 저장 데이터 암호화 11.8
상태 확인 명령과 서버 부팅 때 기동 파일 4.5와 4.6
메트릭 수집 엔드포인트 7장 점검과 A.6 진단 쿼리

문제가 생기면

  • 제약을 어겼을 때 나타나는 증상은 TroubleShooting을 본다.

더 알아보기