6.2 후보 선정

leader race에서 “최적 후보"는 누가 정해 주는 것이 아니다. 각 노드가 같은 규칙으로 자신을 검사해, 스스로 자격이 있다고 판단한 노드만 leader key 취득을 시도한다. 공식 문서는 이 과정을 개요 수준으로만 서술하므로, 이 절의 검사 순서는 Patroni 소스 코드(ha.py의 _is_healthiest_node, fetch_node_status)로 검증한 내용이다.

자격 검사 순서

한 노드가 자신을 후보로 판정하기까지 통과해야 하는 관문은 다음과 같다.

    flowchart TD
    A["leader race 참가"] --> B{"nofailover: true?"}
    B -->|예| X["후보 탈락"]
    B -->|아니오| C{"PostgreSQL starting?"}
    C -->|예| X
    C -->|아니오| D{"timeline 뒤처짐?"}
    D -->|예| X
    D -->|아니오| E{"lag 1MiB 초과?"}
    E -->|예| X
    E -->|아니오| F{"더 앞선 멤버 존재?"}
    F -->|예| X
    F -->|아니오| G{"동률에서 priority 열세?"}
    G -->|예| X
    G -->|아니오| H["leader key 취득 시도"]
  

timeline 검사는 check_timeline을 켠 경우에만, 동률 비교는 failover_priority를 설정한 경우에만 의미가 있다.

WAL position은 어떻게 계산하나

비교에 쓰는 replica의 WAL position은 receive LSN과 replay LSN 중 큰 값이다.

# ha.py (fetch_node_status)
lsn = int(in_recovery and max(wal.get('received_location', 0),
                              wal.get('replayed_location', 0)))

받아만 두고 아직 replay하지 않은 WAL도 그 노드의 진도로 인정한다는 뜻이다. replay가 느린 노드라도 WAL을 디스크에 확보해 두었다면 promote 후 마저 적용하면 되므로, 데이터 보존 관점에서는 receive 기준이 타당하다.

nofailover와 failover_priority

두 tag는 같은 축의 다른 표현이다.

# patroni.yml (리포트용 replica 예시)
tags:
  nofailover: true

# patroni.yml (동률일 때 우선하고 싶은 노드 예시)
tags:
  failover_priority: 2

정리

후보 선정은 nofailover, 기동 상태, timeline, lag 한도라는 절대 조건을 먼저 거르고, 남은 노드끼리 WAL position을 비교해 가장 앞선 쪽이 이기는 구조다. failover_priority는 완전 동률일 때만 개입하는 마지막 타이브레이커이며, 이 순서를 알아야 “priority를 줬는데 왜 다른 노드가 승격됐나” 같은 상황을 설명할 수 있다.