10장. Replication — 한 대가 죽어도 서비스는 계속된다

9장의 WAL은 복구용 일기장이자, 복제의 방송 원본이기도 합니다. WAL 스트리밍이 스탠바이로 흐르는 길, 동기/비동기의 트레이드오프, 그리고 페일오버의 순간까지.

10.1 두 종류의 복제 — Physical vs Logical

PostgreSQL의 복제는 크게 두 갈래입니다. Physical 복제는 WAL 바이트를 그대로 스트리밍해 "클러스터 전체의 완전한 쌍둥이"를 만들고, Logical 복제는 WAL을 해석(디코드)해 "행 단위 변경"만 골라 보냅니다.

선택 기준은 간단합니다: "전체를 똑같이, 장애 시 즉시 전환" → Physical, "특정 테이블만, 다른 버전/스키마로" → Logical. 이 장은 HA의 근간인 Physical 스트리밍을 중심으로 봅니다.

10.2 WAL 스트리밍 — 커밋이 스탠바이에 닿기까지

Primary에서 커밋된 WAL은 walsender 프로세스가 네트워크로 흘려보내고, 스탠바이의 walreceiver가 받아 저장하고, startup 프로세스가 리플레이합니다. 각 단계마다 지연(lag)이 측정됩니다.

-- Primary에서: 스탠바이별 지연을 단계별로 분해
SELECT application_name, state, sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_bytes,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

10.3 구축 레시피 — 3줄 요약

스트리밍 복제 구축은 v12+ 기준으로 매우 단순해졌습니다. Primary에 복제 권한을 열고, pg_basebackup 한 방으로 스탠바이를 만듭니다.

# [Primary] postgresql.conf
wal_level = replica              # v10+ 기본값
max_wal_senders = 10             # 스탠바이 수 + pg_basebackup 여유
max_slot_wal_keep_size = 64GB    # v13+. 슬롯 폭주 방어 (필수급 권장)

# [Primary] pg_hba.conf — 복제 접속 허용
host  replication  replicator  10.0.0.0/16  scram-sha-256

# [Standby] 데이터 디렉터리를 통째로 복제 + 자동 설정
pg_basebackup -h primary.example -U replicator \
    -D $PGDATA -X stream -R -C -S standby1_slot -P
# -R: standby.signal + primary_conninfo 자동 생성
# -C -S: replication slot 생성 후 연결

10.4 동기 vs 비동기 — 커밋은 누구를 기다리는가

기본 스트리밍은 비동기입니다. Primary는 자기 WAL만 flush하면 커밋을 응답하고, 스탠바이 전송은 뒤따라갑니다. 빠르지만, Primary가 그 직후 죽으면 마지막 몇 개의 커밋이 스탠바이에 없을 수 있습니다. synchronous_standby_names를 설정하면 동기가 되어 스탠바이의 확인까지 기다립니다.

# postgresql.conf — 쿼럼 기반 동기 복제
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'  # 3대 중 아무 2대가 ACK하면 커밋

-- 정말 중요한 트랜잭션만 스탠바이 리플레이까지 기다리기
SET LOCAL synchronous_commit = remote_apply;   -- "쓴 직후 스탠바이에서 읽어도 최신" 보장

10.5 페일오버 — 스탠바이가 왕좌에 오르는 순간

계획된 전환은 Switchover, 장애에 의한 전환은 Failover라고 부릅니다. 핵심 절차는 같습니다: 스탠바이를 승격(promote)시키고, 트래픽을 돌리고, 구 Primary가 복귀할 땐 pg_rewind로 새 타임라인에 맞춥니다.

10.6 Hot Standby의 딜레마 — 읽기 쿼리 vs 리플레이

스탠바이에서 읽기 쿼리를 받다 보면 충돌이 생깁니다. Primary에서 VACUUM으로 지워진 행을, 스탠바이의 장기 쿼리가 아직 보고 있다면? WAL 리플레이를 기다리게 하거나, 쿼리를 취소하거나 — 둘 중 하나입니다.

정답은 워크로드에 따라 다릅니다: 분석 쿼리용 스탠바이는 feedback on + 긴 delay, 실시간 HA용 스탠바이는 그 반대로 설정합니다.

✍️ 이해도 체크