PostgreSQL: Streaming Replication

※ PostgreSQL: Streaming Replication.
 
안녕하세요. 듀스트림입니다.
 
오늘 포스팅은 PostgreSQL에서 고가용성을 보장하는 핵심 기술인 스트리밍 레플리케이션에 관한 내용입니다.

---

1. 스트리밍 레플리케이션 구조 및 핵심 프로세스

기본 구성 요소

구성 요소	설명	관련 소스 코드
WALSender	Primary 서버에서 WAL 로그를 Standby로 전송	walsender.c
WALReceiver	Standby 서버에서 WAL 로그를 수신	walreceiver.c
Startup	Standby 서버에서 WAL 로그를 적용	startup.c

 
레플리케이션 동작 흐름

1. Primary 서버에서 트랜잭션 실행 → WAL 기록
2. WALSender가 WAL 데이터를 standby로 전송 (streaming)
3. Standby의 WALReceiver가 수신 → 로컬 WAL 저장
4. Startup 프로세스가 WAL 적용 → DB 일관성 동기화

53.4. Streaming Replication Protocol

---

2. 주요 파라미터

Primary 서버 파라미터

파라미터	설명	기본값
wal_level	복제 또는 logical decoding을 위한 WAL 기록 수준 (minimal, replica, logical)	replica
max_wal_senders	동시에 동작 가능한 WALSender 프로세스 최대 수	10
wal_keep_size	standby가 따라잡을 수 있도록 유지할 WAL 파일의 최소 크기	0
max_replication_slots	replication slot 최대 수	10
synchronous_standby_names	동기 복제에 참여할 standby 이름 지정	빈 문자열
synchronous_commit	트랜잭션 커밋 시 WAL 확인 대상: remote_apply, remote_write, flush(on), local, off	on (flush)

 
Standby(Replica) 서버 파라미터

파라미터	설명	기본값
primary_conninfo	standby가 primary에 연결할 때 사용할 접속 정보	없음(필수)
primary_slot_name	standby가 사용할 replication slot 이름	없음(선택)
hot_standby	standby에서 읽기 전용 쿼리 허용 여부	on
hot_standby_feedback	primary에 feedback을 주어 vacuum 충돌 방지 여부	off

 

19.6. Replication

---

3. 동기식 vs 비동기식 복제

항목	동기식 복제 (synchronous_commit = on)	비동기식 복제 (synchronous_commit = local/off)
커밋 대기	Standby 확인 후 커밋	Primary에서 즉시 커밋
일관성 보장	강력	약함 (데이터 유실 위험)
성능	상대적으로 낮음	빠름

동기식으로 설정되어 있어도 synchronous_standby_names 파라미터에 값이 없으면 비동기식로 적용됩니다.

synchronous_commit 파라미터 설정에 따른 Commit 확정 시점

값	설명	Standby의 WAL 상태	커밋 확정 시점
remote_apply	apply까지 대기 (가장 강력한 일관성)	디스크 flush + apply 완료	replica에서 실제 apply 후 커밋 OK
on (flush)	flush까지 대기	WAL을 디스크에 flush	replica에서 flush 완료 후 커밋 OK
remote_write	write까지만 대기	write 완료만 확인 (flush는 안 됨)	OS 페이지 캐시에 write 완료 후 커밋 OK
local	replica 무시	Primary에서 WAL만 flush	replica 없이도 커밋 OK
off	가장 빠름 (Primary flush도 안함)	WAL을 메모리에만 기록	클라이언트에 즉시 커밋 OK

• remote_apply > on > remote_write > local > off 순으로 일관성은 높고 성능은 낮습니다.

PostgreSQL에서 write()는 WAL을 OS의 파일 시스템 캐시에 기록하는 작업이며,
이로 인해 pg_wal/ 디렉토리에 WAL 파일이 존재할 수 있지만, 이는 디스크에 영구 저장되었음을 의미하지는 않습니다.
실제 디스크에 flush하려면 fsync() 호출이 반드시 필요합니다.

WAL 기록 시 open() → write() → fsync() 순으로 동작이 일어납니다. (WAL 세그먼트 파일은 새로운 WAL 세그먼트를 다룰 때 open()으로 생성됨)

 

19.5. Write Ahead Log

---

+ lag 체크 쿼리 (Primary에서 수행)

-- replication lag 확인
SELECT client_addr, sent_lsn, replay_lsn, pg_wal_lsn_diff(sent_lsn, replay_lsn) AS byte_lag
FROM pg_stat_replication;

-- replication slot lag
SELECT slot_name, active, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes
FROM pg_replication_slots;

 
++ replication slot 사용 시 Standby 장애가 발생하면 Primary의 WAL 파일이 무제한으로 쌓입니다.
 
+++ replication slot은 Primary에서 관리합니다.

생성 함수: pg_create_physical_replication_slot()
제거 함수: pg_drop_replication_slot()

26.2. Log-Shipping Standby Servers

---

오늘은 여기까지~