1.2 PostgreSQL HA 도구 지형
PostgreSQL 자동 failover 도구는 결국 두 가지 질문에 답해야 합니다. 모든 노드가 현재 primary를 동일하게 인식하려면 무엇을 기준으로 삼아야 할까요. 옛 primary가 쓰기를 계속 받지 못하게 하려면 어떻게 해야 할까요. 도구마다 답이 다릅니다. 이 차이가 장애 시 소요 시간과 보장하는 데이터 범위를 결정합니다.
합의의 근거가 어디 있는가
Patroni는 etcd 같은 DCS의 leader key를 가진 노드를 primary로 판단합니다. key의 TTL이 만료되면 다른 노드가 key를 얻어 승격합니다. 합의는 DCS의 Raft나 ZAB가 담당합니다. 따라서 DCS를 3대 이상으로 구성해야 합니다.
CloudNativePG는 Kubernetes API 서버를 합의 저장소로 사용합니다. operator가 Cluster 리소스의 status를 갱신합니다. 각 pod 안의 instance manager는 이 status를 따릅니다.
pg_auto_failover는 합의 저장소 대신 monitor라는 PostgreSQL 인스턴스 하나를 판정자로 둡니다. monitor가 "node2를 승격하라"고 결정하면 그것이 곧 합의가 됩니다. 구성은 가장 단순합니다. 다만 monitor는 복제본이 없는 단일 인스턴스입니다.
repmgr는 각 노드의 repmgrd 데몬이 서로의 상태를 확인합니다. 필요하면 witness 노드를 두어 투표 수를 맞춥니다.
도구별 특징
| 항목 | pg_auto_failover | Patroni | CloudNativePG | repmgr |
|---|---|---|---|---|
| 판정 근거 | monitor(PostgreSQL + extension) | DCS leader key | Kubernetes API | repmgrd 간 확인, witness |
| 추가 인프라 | monitor 1대 | DCS 클러스터 3대 이상 | Kubernetes | 선택적 witness |
| 기본 복제 | synchronous | asynchronous (synchronous_mode 선택) | asynchronous (동기 설정 선택) | asynchronous |
| 상태 조회 | SQL, pg_autoctl show | REST API, patronictl | kubectl, plugin | repmgr cluster show |
| 라우팅 지원 | libpq multi-host URI 출력 | REST health check로 HAProxy 연동 | Service 리소스 | 사용자 구성 |
| 최신 릴리스 (2026-09 확인) | v2.2, 2025-04-03 | v4.1.5, 2026-08-12 | v1.30.1, 2026-09-23 | v5.5.0, 2024-11-22 |
Stolon 저장소는 보관(archived) 상태가 아닙니다. 하지만 마지막 릴리스는 v0.17.0(2021-09-03)이고 마지막 push는 2024-07입니다. 새로 도입할 후보로 보기는 어렵습니다.
pg_auto_failover가 다른 점
첫째, 기본값이 synchronous replication입니다. Patroni와 CloudNativePG는 비동기 복제가 기본입니다. 동기 복제를 사용하려면 별도로 설정해야 합니다. pg_auto_failover는 standby가 정상이면 항상 synchronous_standby_names를 채워 둡니다. standby가 사라지면 monitor가 이 값을 비워 쓰기를 재개합니다. 대신 그동안에는 자동 failover를 수행하지 않습니다. 이 동작은 2.4에서 다룹니다.
둘째, 상태 머신이 명확합니다. 노드 상태는 primary, wait_primary, draining, stop_replication 같은 이름으로 monitor 테이블에 남습니다. 각 전이의 사유는 pgautofailover.event에 기록됩니다. 장애 후 발생한 일을 SQL 한 번으로 재구성할 수 있습니다.
셋째, HTTP health endpoint가 없습니다. Patroni는 GET /primary 같은 REST 응답을 제공해 HAProxy가 primary를 찾도록 합니다. pg_auto_failover는 libpq의 multi-host 연결 문자열과 target_session_attrs를 권장합니다. PgBouncer나 HAProxy를 앞에 두려면 별도 구성이 필요합니다(8.2).
넷째, Kubernetes operator가 없습니다. 영구 볼륨을 연결한 pod에서 monitor와 노드를 운영하는 사례는 문서에 나옵니다. 하지만 CloudNativePG처럼 리소스를 선언하면 자동으로 상태를 맞추는 구조는 아닙니다.
정리
pg_auto_failover는 추가 인프라를 가장 적게 요구합니다. 대신 판정 기능이 한 곳에 집중됩니다. 동기 복제 기본값과 명확한 상태 머신 덕분에 데이터 보장을 설명하기 쉽습니다. REST API와 operator가 없으므로 라우팅과 자동화를 직접 구성해야 합니다. 선택 기준은 10.2에서 다시 정리합니다.