PostgreSQL 장애 조치(Failover) 대 전환(Switchover) 시나리오 이해 및 실행

현대 데이터베이스 아키텍처에서 고가용성(HA)을 통한 지속적인 운영 보장은 매우 중요합니다. 강력한 오픈 소스 관계형 데이터베이스인 PostgreSQL은 스트리밍 복제를 통해 여러 노드 간의 데이터 일관성을 유지합니다. 그러나 기본 서버에 문제가 발생하거나 유지 관리가 필요할 때, 데이터베이스 관리자는 서비스를 복원하기 위해 정확한 절차를 실행해야 합니다. 이 문서는 두 가지 중요한 HA 작업인 장애 조치(Failover)와 전환(Switchover)을 명확하게 구별하고, 대기 복제본을 새로운 기본 서버로 안전하게 승격시키기 위한 단계와 고려 사항을 자세히 설명합니다.

이러한 이벤트 간의 차이점을 이해하는 것은 매우 중요합니다. 전환(Switchover)은 계획되고 제어된 전환인 반면, 장애 조치(Failover)는 예상치 못한 중단에 대한 비상 대응입니다. 두 시나리오 중 하나를 성공적으로 탐색하는 것은 적절한 구성, 강력한 모니터링, 그리고 복제를 관리하는 데 사용되는 도구에 대한 숙련도에 크게 좌우됩니다.

복제 기본 사항: HA의 기반

PostgreSQL 고가용성은 스트리밍 복제를 기반으로 구축되며, 여기서 하나의 서버는 기본(Primary)(또는 마스터) 역할을 하고 하나 이상의 서버는 대기(Standby)(또는 복제본) 역할을 합니다. 기본 서버는 쓰기 전 로우(WAL) 레코드를 대기 서버로 스트리밍하여 동기화 상태를 유지합니다.

이러한 역할을 효과적으로 관리하려면 기본 및 복제본 노드 모두에 특정 구성 설정이 필요합니다:

중요 구성 설정

이 설정들은 복제가 작동하는 방식과 노드가 서로를 식별하는 방식을 제어합니다:

wal_level: 기본 서버에서 replica 이상(논리적 디코딩을 사용하는 경우 이상적으로는 logical)으로 설정되어야 합니다.
max_wal_senders: 대기 서버로부터의 동시 연결 최대 수를 정의합니다. 모든 대기 서버를 수용하려면 기본값(보통 10)에서 늘려야 합니다.
hot_standby: 복제 중 읽기 전용 쿼리를 허용하려면 대기 서버의 postgresql.conf에서 on으로 설정해야 합니다.
synchronous_commit: 트랜잭션 승인을 제어합니다. 전환 중 데이터 손실을 방지하기 위해 종종 on(또는 약간의 지연 허용을 위해 remote_write)으로 설정됩니다.
primary_conninfo: 대기 서버에 설정되며, 현재 기본 서버에 연결하기 위한 연결 정보(호스트, 포트, 사용자, 암호)를 자세히 설명합니다.

모범 사례: 강력한 HA를 위해서는 PgBouncer와 같은 연결 풀링 계층이나 Patroni 또는 Repmgr와 같은 전용 HA 프록시를 사용하여 실제 서버 주소를 추상화함으로써 애플리케이션에 대한 장애 조치 및 전환을 원활하게 수행해야 합니다.

전환(Switchover): 계획된 전환

전환(Switchover)은 활성 기본 노드가 의도적으로 종료되고 지정된 대기 서버가 그 자리를 차지하도록 승격되는 제어되고 원활한 프로세스입니다. 이 절차는 일반적으로 계획된 유지 관리, 버전 업그레이드 또는 하드웨어 교체를 위해 사용됩니다.

제어된 전환 단계

전환의 목표는 인플라이트(in-flight) 중인 모든 트랜잭션이 승격되기 전에 복제되도록 기다려서 데이터 손실이 없도록 보장하는 것입니다.

현재 기본 서버에서 쓰기 중지: 첫 번째 단계는 현재 기본 서버에서 새로운 트랜잭션이 커밋되는 것을 방지하는 것입니다. 이는 종종 default_transaction_read_only = on을 설정하거나 클라이언트 연결을 일시적으로 차단하여 달성됩니다.
복제 따라잡기 대기: 지정된 대기 서버가 기본 서버로부터 나머지 WAL 레코드를 모두 수신하고 적용했는지 확인합니다. 기본 서버의 pg_stat_replication을 사용하거나 대기 서버의 복구 상태를 검사하여 복제 지연을 확인할 수 있습니다.
대기 서버 승격 시작: 선택한 대기 서버를 기본 역할로 승격하는 명령을 실행합니다. 특정 명령은 사용된 관리 도구에 따라 다릅니다(예: pg_ctl promote 또는 클러스터 관리자 명령).
이전 기본 서버 재구성: 대기 서버가 성공적으로 승격되면, 이전 기본 서버는 새로운 기본 서버를 따르도록 대기 서버로 재구성되어야 합니다. 여기에는 primary_conninfo 업데이트가 포함됩니다.
애플리케이션 리디렉션: 로드 밸런서 또는 연결 풀러를 업데이트하여 트래픽을 새 기본 서버로 지시합니다.

장애 조치(Failover): 비상 대응

장애 조치(Failover)는 현재 기본 서버가 예기치 않게 실패하여(예: 하드웨어 충돌, 네트워크 분할, 소프트웨어 오류) 신속하게 온라인 상태로 복구될 수 없을 때 트리거되는 즉각적이고 반응적인 절차입니다.

장애 조치는 마지막으로 커밋된 몇 개의 트랜잭션이 실패 전에 대기 서버로 스트리밍될 시간이 없었을 수 있으므로 본질적으로 데이터 손실 위험이 더 높습니다.

긴급 장애 조치 실행

장애 조치 절차는 속도와 복구를 위해 설계되었으며, 종종 자동화를 위해 전문화된 도구를 활용하여 승격을 자동화합니다.

이전 기본 서버의 상태 확인: 원래 기본 서버가 일시적인 네트워크 문제가 아니라 실제로 사용할 수 없는지 확인합니다(이는 위험한 '분할 뇌(split-brain)' 시나리오를 방지합니다).
최적의 대기 서버 선택: 복제 지연이 가장 적은(WAL 스트림에서 가장 앞서 있는) 대기 서버를 선택합니다.
대기 서버 승격: 승격 명령(pg_ctl promote)을 사용하여 선택한 대기 서버를 즉시 승격합니다.
데이터 손실 처리(필요한 경우): 클러스터가 비동기 복제를 사용하는 경우, 실패한 기본 서버에서 손실된 데이터는 애플리케이션의 허용 범위에 따라 수동으로 조정하거나 단순히 수용해야 할 수 있습니다.
이전 기본 서버 재구성: 원래 기본 서버가 복구되면 정리되어야 하며, 새 기본 서버로부터 기본 백업을 받아 재초기화한 후 새 기본 서버를 따르도록 구성해야 합니다.

안전한 승격을 위한 도구: Repmgr 대 Patroni

pg_ctl을 사용한 수동 승격이 가능하지만, 강력한 HA 환경은 장애 조치 및 전환에 필요한 복잡한 안무를 관리하고 구성 변경 및 클러스터 상태 관리를 자동으로 처리하기 위해 전용 도구에 의존합니다.

Repmgr (복제 관리자)

repmgr은 복제를 모니터링하고 수동 또는 자동 장애 조치를 용이하게 하는 강력하고 가벼운 도구입니다. 주요 명령은 다음과 같습니다.

전환: repmgr standby promote 후 repmgr switchover --sibling-nodes-wait(따라잡기 보장).
장애 조치: repmgr failover

Patroni

Patroni는 분산 합의 저장소(etcd, ZooKeeper 또는 Consul와 같은)를 활용하여 클러스터 상태를 관리하며, 장애 감지 시 새 기본 서버를 자동으로 선출합니다. Patroni는 API 호출이나 Kubernetes 연산자를 통해 전환 및 장애 조치 작업을 대부분 자동화하여 수동 개입을 대폭 줄입니다.

Patroni 사용 예시(개념적 승격 명령):

# Patroni의 REST API를 통한 전환 트리거
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

분할 뇌(Split-Brain) 경고: 자동화된 장애 조치 중 가장 큰 위험은 네트워크 분할로 인해 두 노드가 실수로 자신이 기본이라고 생각하는 '분할 뇌' 시나리오입니다. Patroni와 같은 도구는 쿼럼 메커니즘을 사용하여 이를 완화하는 반면, 수동 설정은 단 하나의 기본 서버만 존재하도록 보장하기 위해 엄격한 펜싱 메커니즘(예: 전원 제어)을 요구합니다.

차이점 요약

기능	전환(계획됨)	장애 조치(비상)
트리거	유지 관리, 업그레이드, 관리자 선택	기본 서버 실패(충돌, 중단)
데이터 손실 위험	거의 없음(적절한 타이밍일 경우)	중간에서 높음(복제 모드에 따라 다름)
예상 다운타임	짧고 제어된 다운타임	즉각적이고 반응적인 다운타임
준비	사전 조정 및 WAL 동기화 확인 필요	즉각적인 조치 및 대기 서버 상태에 대한 의존성 필요

PostgreSQL 장애 조치 및 전환을 실행하려면 클러스터 상태와 이를 관리하는 도구에 대한 깊은 이해가 필요합니다. 전환은 조정을 통해 데이터 손실 제로를 목표로 하는 반면, 장애 조치는 최신 트랜잭션을 희생하더라도 신속한 서비스 복원을 우선시합니다. 복제 매개변수의 적절한 설정과 강력한 클러스터 관리 도구의 활용은 안정적인 PostgreSQL 고가용성의 초석입니다.