피드로 돌아가기
Three PostgreSQL Master/Replica Discovery Problems — and How to Solve Them
Dev.toDev.to
Database

HTTP 기반 상태 관리 서비스 pg-status를 통한 PostgreSQL 토폴로지 동적 제어

Three PostgreSQL Master/Replica Discovery Problems — and How to Solve Them

krylosov-aa2026년 6월 14일24intermediate

Context

PostgreSQL Master/Replica 구조에서 Failover 시 Master 주소의 동적 식별 및 Replica의 Replication Lag 관리에 따른 데이터 정합성 문제 발생. libpq의 순차적 연결 방식은 불필요한 TCP 핸드셰이크를 유발하며 DNS 캐싱과 HAProxy의 LSN 인식 불가로 인해 정밀한 Read-Your-Writes 보장이 어려움.

Technical Solution

  • 메모리 기반 상태 저장소와 HTTP API를 결합한 경량 서비스 pg-status 도입을 통한 조회 오버헤드 제거
  • 백그라운드 폴링 방식을 통한 전 호스트의 Master 여부, 생존 상태, Lag 정보를 미리 수집하여 응답 지연 최소화
  • LSN(Log Sequence Number) 기반의 필터링 로직을 구현하여 특정 트랜잭션 이후의 데이터를 보유한 Replica만 선별하는 정밀 라우팅 지원
  • HMAC 서명을 통한 LSN 값 변조 방지로 클라이언트 사이드 공격 벡터 차단 및 보안성 확보
  • 시간(ms) 및 바이트(bytes) 단위의 이중 임계값 설정으로 서비스 요구사항에 맞는 적응형 Replica 선택 구조 설계

- Read-Your-Writes 보장이 필요한 시나리오에서 LSN 기반의 동적 라우팅 검토 - DB 드라이버 레벨의 순차적 탐색(Sequential Scanning)으로 인한 연결 지연 시간 측정 및 외부 상태 관리 서비스 고려 - 클라이언트 전달 LSN 값의 무결성 검증을 위한 HMAC 적용 여부 확인 - 분석용 쿼리와 사용자 프로필 조회 쿼리의 허용 Lag 임계값을 분리하여 Replica 부하 분산 최적화

원문 읽기