10.2 선택 기준
HA 도구는 기능 목록보다 운영 환경의 조건을 먼저 살펴 선택하는 편이 낫습니다. 실행 환경이 VM인지 Kubernetes인지, 합의 저장소를 운영할 수 있는지 확인해야 합니다. 데이터 손실과 서비스 중단 중 무엇을 더 피해야 하는지도 중요합니다. 라우팅 방식도 고려해야 할 조건입니다. 이 장에서는 1.2의 비교를 이 노트의 실측과 한계 분석으로 보완합니다. 이를 바탕으로 pg_auto_failover가 적합한 조건과 적합하지 않은 조건을 정리합니다.
판단 흐름
이 흐름은 출발점일 뿐입니다. 아래에서 각 분기의 근거를 설명합니다.
pg_auto_failover가 맞는 조건
VM이나 베어메탈에 PostgreSQL 클러스터가 여러 개 있으면서 DCS를 별도로 운영할 여력이 없는 팀에 맞습니다. monitor 한 대로 여러 formation을 관리할 수 있습니다. 따라서 클러스터가 늘어나도 추가 인프라는 늘지 않습니다. monitor 자체가 PostgreSQL이므로 DBA는 익숙한 도구로 백업하고 조회할 수 있습니다.
데이터 보장을 명확히 설명해야 하는 환경에도 맞습니다. 기본 설정은 synchronous replication입니다. standby 상태에 따라 primary가 primary와 wait_primary를 오가는 규칙도 문서와 로그에 명확히 나타납니다. "지금 failover하면 데이터를 잃는가"라는 질문에 답할 실마리를 monitor 테이블에서 얻습니다. 다만 사라진 노드만 마지막 동기 커밋을 가진 경우까지 조회만으로 가려낼 수는 없습니다. main에 guard_data_loss가 추가된 배경이기도 합니다. 3노드와 number_sync_standbys = 1을 쓰면 standby 하나를 잃어도 두 벌을 유지합니다.
애플리케이션이 libpq 계열 드라이버를 사용하고 multi-host 연결 문자열을 받아들일 수 있다면 라우팅 계층 없이 시작해도 됩니다.
맞지 않는 조건
failover를 수 초 안에 끝내야 하는 서비스에는 맞지 않습니다. 기본값에서 쓰기 공백은 50초 안팎이었습니다. timeout을 줄이면 split brain 구간이 생겼습니다(7.6). 대기 구조가 옛 primary의 자기 강등 시간과 연결되어 있습니다. 따라서 단순히 값만 줄여서는 해결되지 않습니다.
HAProxy나 PgBouncer를 반드시 앞에 두어야 하는 경우도 있습니다. health check 스크립트를 직접 만들 여유가 없다면 Patroni의 REST API가 편리합니다. Kubernetes에서는 operator가 없는 pg_auto_failover보다 CloudNativePG가 운영 모델에 더 적합합니다.
릴리스 주기와 유지보수 체계도 고려해야 할 조건입니다. v2.2 이후 split brain과 FSM 고착 수정이 main에 쌓여 있지만 아직 릴리스되지 않았습니다. 커밋 대부분도 한 사람이 작성합니다. 보안 패치나 새 PostgreSQL major 지원이 정해진 기간 안에 나와야 하는 조직이라면 이 점을 위험 요소로 기록해야 합니다.
비교 사실
| 항목 | pg_auto_failover v2.2 | Patroni | CloudNativePG |
|---|---|---|---|
| 추가 인프라 | monitor 1대(여러 formation 공유) | 외부 DCS(보통 3대 이상), Kubernetes API, 또는 내장 Raft | Kubernetes |
| 기본 복제 | synchronous | asynchronous | asynchronous |
| 역할 조회 수단 | SQL(monitor), pg_autoctl show | REST API | Kubernetes API |
| 실측 쓰기 공백, primary kill (이 노트) | 2노드 51초, 3노드 54초 | 이 노트에서 측정 안 함 | 이 노트에서 측정 안 함 |
| 판정자 장애 시 | 기존 쓰기 유지, 결정 중단 | DCS quorum 상실 시 설정에 따라 primary 강등(failsafe mode 선택) | API 서버 의존 |
| 최신 릴리스 (2026-09 확인) | v2.2, 2025-04-03 | v4.1.5, 2026-08-12 | v1.30.1, 2026-09-23 |
Patroni와 CloudNativePG의 failover 시간은 이 노트에서 측정하지 않았습니다. 같은 조건에서 비교하려면 각 노트의 실습을 동일한 부하와 측정 스크립트로 다시 실행해야 합니다.
이미 Patroni를 사용하는 팀이 pg_auto_failover로 바꿀 이유는 많지 않습니다. 반대로 DCS 없이 여러 소규모 클러스터에 자동 failover를 처음 도입한다면 pg_auto_failover는 추가 설치 항목이 가장 적습니다. 도입 전에는 Part VII의 시나리오를 대상 환경에서 그대로 재현해 볼 것을 권합니다.
정리
pg_auto_failover는 DCS 없이 VM 환경에서 자동 failover와 명시적인 데이터 보장을 얻으려는 경우에 맞습니다. 빠른 failover, REST 기반 라우팅, Kubernetes 통합, 예측 가능한 릴리스 주기가 필요하다면 다른 도구가 낫습니다. 어느 쪽이든 실측으로 확인한 쓰기 공백과 보장 범위를 근거로 판단해야 합니다.