본문으로 건너뛰기

1.1 pg_auto_failover란

PostgreSQL은 streaming replication과 pg_promote()를 제공합니다. 하지만 언제 어떤 노드를 승격할지는 정하지 않습니다. 이 결정을 대신하는 도구가 HA 매니저입니다. pg_auto_failover의 README는 이 도구를 "PostgreSQL 클러스터의 자동 failover를 감시하고 관리하는 extension과 서비스"라고 소개합니다. 설계 목표는 단순함(simplicity)과 정확성(correctness)입니다.

세 가지 구성 요소​

pg_auto_failover는 다음 세 부분으로 이루어져 있습니다.

구성 요소실체설치 위치
pgautofailover extensionmonitor 상태 머신을 구현한 PostgreSQL extensionmonitor 노드의 PostgreSQL
monitor 서비스extension이 설치된 PostgreSQL 인스턴스와 이를 감싼 pg_autoctl 프로세스monitor 노드
keeper로컬 PostgreSQL을 관리하는 pg_autoctl run 프로세스모든 데이터 노드

extension은 monitor에만 필요합니다. 데이터 노드에는 pg_autoctl 명령만 있으면 됩니다. 그래서 Debian 계열에서는 패키지를 나누어 제공합니다. 데이터 노드용은 pg-auto-failover-cli이고, monitor용 extension은 postgresql-17-auto-failover입니다.

monitor가 하는 일​

monitor는 witness이자 orchestrator입니다. 노드마다 "현재 상태(reported state)"와 "목표 상태(assigned state, goal state)"를 기록합니다. 두 상태가 다르면 keeper가 그 차이를 해소하도록 합니다. 노드 추가, failover, maintenance, 복제 설정 변경 등 클러스터 전체에 영향을 주는 결정은 모두 monitor가 내립니다.

monitor 자신은 복제 경로에 관여하지 않습니다. primary와 standby 사이의 streaming replication은 PostgreSQL 고유 기능이며, monitor 없이도 작동합니다. 따라서 monitor만 멈추면 새로운 결정을 내릴 수 없을 뿐입니다. 이미 진행 중인 쓰기와 복제는 계속됩니다. 다만 primary가 monitor와 standby에 모두 연결할 수 없으면 keeper가 PostgreSQL을 멈춥니다. split brain을 막기 위한 조치입니다(2.5). 7.3에서는 monitor를 멈춘 채 40초 동안 INSERT를 실행했습니다. 실패는 0건이었습니다.

keeper가 하는 일​

keeper는 로컬 PostgreSQL을 자식 프로세스로 실행합니다. 1.4 버전부터 이 방식을 사용합니다. systemd가 PostgreSQL을 직접 실행하지 않고 pg_autoctl run 하나만 관리하는 구조입니다. keeper는 1초마다 monitor의 pgautofailover.node_active() 함수를 호출합니다. 이 함수로 자신의 상태와 WAL 위치를 보고하고 새 목표 상태를 받습니다. 목표 상태가 바뀌면 pg_ctl, pg_basebackup, pg_rewind, SQL을 조합해 해당 상태로 전이합니다.

# 데이터 노드에서 keeper 상태 확인
pg_autoctl status
pg_autoctl show state
노트

PostgreSQL을 별도의 systemd 서비스로 실행하면 안 됩니다. 재부팅 중에 failover가 일어났다면 이전 primary는 standby로 돌아와야 합니다. 이 판단은 keeper가 monitor에서 목표 상태를 받은 뒤에야 가능합니다. 공식 설치 문서도 pg_autoctl이 PostgreSQL을 시작해야 한다고 명시합니다.

설계 목표: Business Continuity​

pg_auto_failover 문서는 2노드 구성을 "Business Continuity에 최적화되었다"고 설명합니다. 노드 하나를 잃더라도 서비스를 계속하는 것을 데이터 이중화보다 우선한다는 뜻입니다. 2노드에서 standby가 사라지면 monitor는 primary의 동기 복제를 끕니다. 이후에도 쓰기는 계속 받습니다. 그 대가로 primary까지 잃으면 그동안 쓴 데이터가 사라질 수 있습니다. 이 트레이드오프는 2.4와 5.4에서 자세히 다룹니다.

3개 이상의 PostgreSQL 노드를 사용하면 number_sync_standbys를 1 이상으로 설정해 항상 두 벌 이상의 데이터를 유지하는 구성도 가능합니다.

라이선스와 관리 주체​

Citus Data가 만든 프로젝트입니다. Microsoft가 Citus Data를 인수한 뒤에도 한동안 citusdata/pg_auto_failover 저장소를 사용했습니다. 지금은 hapostgres organization으로 옮겨졌습니다. 버전별 연혁은 1.3에 정리했습니다.

정리​

pg_auto_failover는 별도의 합의 저장소를 두지 않습니다. 대신 PostgreSQL 인스턴스 하나를 monitor로 사용해 상태 머신을 실행합니다. 설치할 구성 요소가 적고, 동작은 show events 로그로 추적하기 쉽습니다. 반면 monitor는 control plane의 단일 장애점입니다. 이 구조가 장애 상황에서 어떤 시간과 보장으로 이어지는지가 이 노트 전체의 주제입니다.