PostgreSQL

PostgreSQL 설계 · 이중화 · 튜닝 · 이관

확장성과 표준 준수로 상용 DB의 대안이 된 PostgreSQL. 자동 장애조치가 되는 HA 클러스터, 시점 복구가 되는 백업, 근거 기반 튜닝, Oracle·Tibero에서의 전환까지 맡겨 주세요.

Architecture

권장 HA 아키텍처

가장 널리 쓰이는 오픈소스 조합: Patroni + 분산 합의 저장소(DCS) + PgBouncer/HAProxy + pgBackRest.

Patroni는 etcd·Consul·ZooKeeper 같은 DCS를 이용해 리더를 선출하고, 프라이머리 장애 시 가장 적합한 복제본을 자동 승격합니다. 애플리케이션은 HAProxy(또는 VIP)를 통해 항상 현재 프라이머리로 연결되고, PgBouncer가 커넥션 수를 제어합니다.

WAL은 pgBackRest로 지속 아카이빙되어, 전체 백업 + WAL 재적용으로 원하는 시점까지 복구할 수 있습니다.

  • DCS는 홀수(3대 이상) 노드로 구성해 분할 뇌(split-brain)를 방지
  • 동기/비동기 복제는 RPO와 쓰기 지연 사이의 트레이드오프로 결정
  • 읽기 부하는 복제본으로 분산(애플리케이션의 지연 허용도 확인)
  • 장애조치·스위치오버를 정기 리허설
그림. PostgreSQL 고가용성 참조 구성 (예시 — 규모·RPO에 따라 조정)

Scope

PostgreSQL 서비스 범위

설치·설계

버전 선택(지원 주기 고려), 패키지/소스 설치, 디렉터리·테이블스페이스·파라미터 표준, 확장(extension) 정책.

HA·복제

스트리밍 복제(물리), 논리 복제(publication/subscription), Patroni 자동 장애조치, 복제 슬롯 관리.

백업·PITR

pgBackRest·Barman·pg_basebackup, WAL 아카이빙, 복구 목표 시점 지정 복구와 정기 검증.

튜닝

shared_buffers·work_mem·WAL·체크포인트, autovacuum, 실행 계획·인덱스·파티셔닝.

모니터링

pg_stat_statements·pg_stat_activity·대기 이벤트, 복제 지연, bloat, Grafana/PMM 대시보드.

업그레이드

pg_upgrade(--link 등) 또는 논리 복제를 이용한 저중단 메이저 업그레이드.

보안

SCRAM-SHA-256 인증, pg_hba.conf 최소 허용, 역할 설계, TLS, 행 수준 보안(RLS), pgaudit.

Oracle·Tibero 이관

ora2pg 평가·변환, PL/SQL → PL/pgSQL, 데이터 검증, 성능 재튜닝.

Replication

복제 방식 비교

PostgreSQL 복제·HA 선택지
방식특징적합한 용도유의 사항
스트리밍 복제WAL을 바이트 단위로 전송하는 물리 복제. 동기/비동기 선택HA, 읽기 복제본, DR메이저 버전·플랫폼이 같아야 함
논리 복제테이블 단위 변경 데이터를 publication/subscription으로 전송부분 복제, 메이저 업그레이드, 통합DDL·시퀀스는 별도 처리 필요
PatroniDCS 기반 리더 선출·자동 장애조치·구성 관리운영 HA 표준DCS 가용성과 펜싱 설계가 핵심
PgBouncer경량 커넥션 풀러(session/transaction/statement 모드)커넥션 폭증 완화transaction 모드에서 세션 상태 기능 제약 확인

Backup & PITR

백업·시점 복구(PITR)

전체 백업 + WAL 아카이브가 있으면 장애 직전·오작업 직전 시점으로 되돌릴 수 있습니다. 백업은 복구해 봐야 백업입니다.

pgBackRest 기반 PITR 예시 (PostgreSQL 12+)
# 1) 서비스 중지 후 목표 시점으로 복원
sudo systemctl stop postgresql
sudo -u postgres pgbackrest --stanza=main --delta \
     --type=time "--target=2026-10-20 13:55:00+09" \
     --target-action=promote restore
# 2) 기동 후 복구 완료 확인
sudo systemctl start postgresql
psql -c "select pg_is_in_recovery();"   -- f 이면 승격 완료
pg_stat_statements 상위 쿼리 확인
-- postgresql.conf: shared_preload_libraries = 'pg_stat_statements'
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT queryid, calls,
       round(total_exec_time::numeric, 1) AS total_ms,
       round(mean_exec_time::numeric, 2)  AS mean_ms,
       rows, left(query, 80) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;
예시는 표준 옵션 기준입니다. 실제 적용 시 stanza 이름, 저장소 위치, 시간대, PostgreSQL 버전에 맞춰 검증된 런북으로 수행합니다.

Tuning

성능 튜닝 포인트

인스턴스·설정

  • 메모리: shared_buffers, work_mem, maintenance_work_mem, effective_cache_size
  • WAL·체크포인트: max_wal_size, checkpoint_timeout, wal_compression
  • autovacuum 임계값·워커 수, 대형 테이블별 개별 설정
  • 커넥션 수 제한 + PgBouncer 풀링
  • OS: huge pages, 스토리지 I/O 스케줄러, 파일시스템 마운트 옵션

쿼리·스키마

  • EXPLAIN (ANALYZE, BUFFERS)로 실행 계획 검증
  • 복합·부분·커버링 인덱스, 사용되지 않는 인덱스 정리
  • 선언적 파티셔닝과 파티션 프루닝
  • 통계 정보(ANALYZE, 확장 통계) 관리
  • N+1·과도한 ORM 쿼리 등 애플리케이션 패턴 개선

Migration

Oracle · Tibero → PostgreSQL 이관

상용 DB 운영 경험이 있는 DBA가 호환성 차이를 미리 짚어 드립니다.

  1. 평가

    ora2pg 리포트로 오브젝트·PL/SQL 규모와 변환 난이도 산정

  2. 스키마 변환

    타입(NUMBER·DATE 등)·시퀀스·파티션·제약조건 매핑

  3. 코드 변환

    패키지·프로시저·트리거를 PL/pgSQL로, 애플리케이션 SQL 수정

  4. 데이터 이관

    전체 적재 후 변경분 동기화 방식 결정, 건수·체크섬 검증

  5. 성능 검증

    업무 대표 쿼리 실행 계획 비교·튜닝

  6. 전환

    리허설 → 컷오버 → 안정화 모니터링

ora2pg는 Oracle 대상 도구입니다. Tibero는 Oracle 호환 DBMS이지만 도구 직접 연결 지원 여부는 환경마다 확인이 필요하며, 필요 시 스키마 추출·변환을 별도 절차로 진행합니다.

Lifecycle

버전 수명주기 체크 (2026년 10월 기준)

  • 커뮤니티는 각 메이저 버전을 최초 릴리스 후 5년간 지원합니다.
  • 2026년 10월 현재 지원 버전: 18 · 17 · 16 · 15 · 14 — PostgreSQL 14는 2026년 11월 12일 지원 종료 예정
  • PostgreSQL 19는 2026년 10월 RC 단계(정식 출시 전)입니다. 운영 도입은 GA 이후 검증을 권장합니다.
  • 항상 해당 메이저의 최신 마이너 버전 적용을 권장합니다.
출처: postgresql.org Versioning Policy. 일정은 변경될 수 있으니 적용 전 공식 페이지를 확인하세요.

FAQ

자주 묻는 질문

Patroni 없이 스트리밍 복제만으로는 부족한가요?

복제 자체는 PostgreSQL 기본 기능으로 충분하지만, 장애 감지·승격·기존 프라이머리 격리·연결 전환은 별도 도구가 필요합니다. Patroni는 이를 자동화하는 대표적인 오픈소스입니다.

PgBouncer는 꼭 필요한가요?

커넥션 수가 많거나 짧은 연결이 반복되는 환경에서 효과가 큽니다. 다만 transaction 풀링 모드에서는 세션 단위 기능(일부 prepared statement 사용 방식, 세션 변수 등) 제약을 확인해야 합니다.

무중단 메이저 업그레이드가 가능한가요?

논리 복제로 새 버전 클러스터를 동기화한 뒤 짧은 전환 시간만으로 넘어가는 방식이 일반적입니다. 중단 허용 시간이 있다면 pg_upgrade가 더 단순합니다.

Oracle에서 넘어오면 성능이 떨어지지 않나요?

옵티마이저·락·트랜잭션 동작이 달라 일부 쿼리는 재작성이나 인덱스 조정이 필요합니다. 이관 전후 대표 쿼리를 비교해 튜닝까지 포함해 진행합니다.

클라우드와 데이터베이스, 지금 상태부터 함께 점검해 보시겠어요?

사용 중인 클라우드·DB 버전·구성과 고민을 알려주시면 진단 범위와 진행 방식을 제안드립니다.