PostgreSQL은 우선 Active- Active로 HA 구성이 불가능하며, Active- Active 운영 난이도가 매우 높아서 보통 Active-Stanby로 HA를 구성한다.
Pgpool-II -+ watchdog는 PostgreSQL을 고가용성(HA)으로 운영하기 위한 구성이다.
Pgpool-II은 PostgreSQL 앞단에 놓이는 미들웨어로, DB 연결 관리·로드밸런싱·실시간 복제 감지를 담당한다. Pgpool-II에 내장된 watchdog는 pgpool 노드끼리 서로 생존 여부를 감시하고, 장애 발생 시 자동 Failover와 VIP 전환을 수행한다.
Pgpool-II의 주요 기능
읽기/쓰기 분리(Read/Write Splitting): SQL을 파싱하여 쓰기 작업은 Primary로, 읽기 작업은 Replica로 자동 라우팅한다.
SQL를 스스로 까보고 알아서 Select는 Replica로 그 외 Insert, Delete, Update는 Primary로 보낸다. 다만 이 과정에서 SQL을 직접 파싱하기에 오버헤드가 발생할 수 있다.
쿼리 캐시(Query Cache): 동일한 쿼리의 결과를 메모리에 캐싱하여 응답 속도를 높인다.
고가용성(HA) 지원: Health check 기반의 자동 Failover(Standby 승격)와, Watchdog 기반의 가상 IP(VIP)/active pgpool 관리를 통해 HA를 구성한다.
Streaming Replication
Primary(DB 메인)가 생성한 WAL 로그를 Standby(DB 대기)가 실시간으로 받아 적용해 데이터를 계속 동일하게 유지하는 복제 방식이다. 이것은 Streaming replication은 Postgresql 자체 기능으로써, Pgpool-II 미들웨어를 사용하지 않아도 가능하다.
Pgpool-II 미들웨어는 Standby 서버가 여러대일 경우 복제 지연 상태를 감지해서 어느 Standby 서버로 보낼지 라우팅한다.
Failover
Primary 서버가 장애로 죽었을 때, Standby를 자동으로 Primary로 승격해서 서비스가 계속되도록 하는 동작이다.
Failover는 pgpool + watchdog이 수행한다. watchdog은 pgpool 미들웨어 자체의 장애 감지하고 리더를 선출해서 Active pgpool로 VIP를 이동시킨다. pgpool Health check가 Primary 장애를 감지하면, pgpool은 failover_command에 등록된 스크립트를 실행해 특정 Standby를 Primary로 승격시키고, 내부 backend status 테이블을 갱신한다. failover_command는 한번 작성해두면 자동화 가능하다.
Online Recovery
죽었던 Active DB 노드를 최신 데이터로 재동기화해 Standby로 복귀시키는 작업으로 수동으로 스크립트( recovery_1st_stage_command, pgpool_remote_start)를 실행해주어야한다.
pgpool의 health check가 죽었던 Active DB 노드가 살아났다는 것은 감지할 수 있지만, 결국 관리자가 pcp_recovery_node 명령으로 복구 스크립트를 직접 실행하여 Standby로 복구시키고 죽었던 동안 격차가 벌어진 데이터를 동기화해줘야한다. 즉 온라인 복구는 자동화가 불가능하다.
⭐ HA 용어 정의
| 용어 | 역할 | 목적 |
| Streaming Replication | 데이터 실시간 복제 | Standby를 최신 상태로 유지 |
| Failover | Standby → Primary 승격 | 장애 시 서비스 지속 |
| Online Recovery | 복구된 노드 재동기화, 재편입 | 클러스터 구조 복원 |
⭐ 기능별 수행 주체
| 기능 | 실제 수행 주체 |
| Streaming Replication | PostgreSQL 자체 기능 |
| Failover | pgpool (스크립트 실행 - 자동화 가능) |
| Online Recovery | pgpool (스크립트 실행 - 수동 실행) |
| pgpool 미들웨어 생존 감시 및 VIP 이동 | watchdog |
⭐ 감시 판단 주체
| 감시 대상 | 판단 주체 | 메커니즘 |
| PostgreSQL DB 노드 생존 | pgpool (health check) | 다중 pgpool일 경우 watchdog 통신망으로 합의(quorum) 가능 |
| pgpool 미들웨어 자체 생존 | watchdog | watchdog 간 heartbeat |
내가 설치와 설정을 하면서 참고한 사이트이다.
추후에 pigsty라는 local aws rds postgre 오픈소스를 알게되었는데 이걸로 구성하면 Online Recovery를 포함하여 모든 설정을 자동화 할 수 있다. 그건 나중에 블로그에서 더 자세히 설명하고자한다.
Streaming Replication 설정 및 Failover 스크립트 생성 및 테스트
Online Recovery 부분에 대해서는 나와있지 않다.
해당 블로그에 들어가면 모든 부분을 확인할 수 있다. 아래 블로그에서 postresql 이중화 #1~#6번까지 보는걸 추천한다.
나는 Streaming Replication랑 Failover는 위 사이트 참고해서 하고 Online Recovery 부분만 아래 사이트를 참고했는데 그냥 처음부터 아래 블로그를 참고하는걸 추천한다.
[PostgreSQL 이중화] #6. PostgreSQL Pgpool2+Watchdog 이중화 Failover와 Failback
■ PostgreSQL 이중화(Pgpool2+Watchdog) Failover와 Failback ▶ 지난 포스팅에 이어 Auto Failover 테스트와 Failback 작업을 진행해 보겠습니다. ▶ pgpool-II version 4.1.4 버전을 사용하였습니다.(Ubuntu 22.04 Repository에
berasix.tistory.com
공식문서 참고자료: https://www.pgpool.net/docs/4.1/en/html/example-cluster.html
Pgpool-II + Watchdog Setup Example
Specify failover.sh script to be executed after failover in failover_command parameter. If we use 3 PostgreSQL servers, we need to specify follow_master_command to run after failover on the primary node failover. In case of two PostgreSQL servers, follow_m
www.pgpool.net
'DB > Postgresql' 카테고리의 다른 글
| 🐷 PostgreSQL On-premise RDS인 Pigsty 오픈소스 아키텍처 정리 (0) | 2026.07.01 |
|---|---|
| 🐘 Postgresql DB 백업 및 복구하여 다른 서버로 마이그레이션 (0) | 2026.01.10 |