복제와 고가용성의 경계

결론부터

복제는 다른 인스턴스가 변경을 따라가게 하고, 장애 전환은 그중 누가 새 쓰기 역할을 맡을지 결정한다.

같은 데이터를 가진 서버가 여러 대여도 앱이 어디로 쓸지, 장애가 난 서버를 어떻게 격리할지 정하지 않으면 서비스는 복구되지 않는다. PostgreSQL의 복제와 CNPG의 운영 자동화를 구분해 읽는다.

이 장에서 처음 나오는 말3개

primary · standby

쓰기를 처리하는 인스턴스와 그 변경을 따라가는 인스턴스. 여기서 replica는 주로 standby를 뜻한다.

복제 지연Replication lag

원본의 변경이 복제본에 도착하거나 적용되기까지의 차이.

replication slot

복제 소비자가 필요한 WAL을 서버가 너무 일찍 버리지 않도록 위치를 추적하는 장치.

물리 복제와 논리 복제

방식	전달하는 것	주된 사용처
물리 복제	WAL 기반의 저장 변경	같은 major 버전의 standby, 장애 대비와 읽기 분산
논리 복제	선택한 테이블의 행 변경	데이터 전달·일부 이행·버전 전환 전략

CNPG의 일반적인 primary·standby 구성은 물리 스트리밍 복제를 사용한다. 논리 복제는 테이블을 선택할 수 있지만 DDL·시퀀스 상태 등이 자동으로 모두 따라가는 것은 아니다. “SQL이 호환된다”와 “그대로 물리 복제할 수 있다”도 다르다. (물리 standby, 논리 복제의 제한)

커밋을 언제 성공으로 응답하나

비동기 복제에서는 primary가 로컬 커밋을 확정해도 standby에는 아직 변경이 없을 수 있다. 그 사이 primary를 잃고 standby를 승격하면 최근 변경을 잃을 수 있다.

동기 복제는 지정한 standby의 응답도 기다린다. 이때 synchronous_commit 설정에 따라 원격 기록 또는 적용을 기다리는 의미가 달라진다. 일반적인 on은 원격 WAL의 지속 저장을 기다리지만, 그 standby의 조회에 이미 반영됐다는 뜻까지는 아니다. remote_apply가 적용까지 기다리는 선택이다. (동기 복제, synchronous_commit)

읽기 replica에 바로 재조회하면 방금 쓴 행이 안 보일 수 있다. 저장 직후 확인이 필요한 요청은 primary로 읽는 등 앱의 일관성 요구와 경로를 함께 정한다. 여러 replica를 둘러 읽는다고 지연이 사라지지 않는다.

복제 상태를 어디서 보나

primary에서 실행하는 진단 SQL이다. 단일 로컬 DB에서는 복제 연결이 없으므로 0행이 정상이다.

SELECT application_name, state, sync_state,
       sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;

SELECT slot_name, slot_type, active, restart_lsn
FROM pg_replication_slots;

전송·기록·지속 저장·적용 위치를 나누어 읽는다. 시각 기반 lag 값이 NULL이거나 업데이트가 없다고 곧바로 장애로 판정하지 않는다. 부하가 없는 상태와 단절을 구분해야 한다. (통계 뷰)

WAL을 오래 붙잡는 상황

slot 소비자가 멈추거나 아카이브가 실패하면 필요한 WAL을 지우지 못해 디스크가 찰 수 있다. max_wal_size를 디스크 사용량의 절대 상한으로 생각하면 안 된다. slot 보존 제한을 두면 디스크를 보호하는 대신 뒤처진 replica나 소비자가 다시 초기화되어야 할 수 있다. (slot과 WAL 보존)

복제본은 백업이 아니다

실수로 작업을 삭제하면 그 DELETE도 정상 변경으로 복제된다. 복제본이 모두 건강해도 삭제 전으로 돌아갈 방법은 별도로 있어야 한다. 또한 동기 복제는 복제본까지 함께 잃는 재난이나 잘못된 SQL을 해결하지 않는다.

이해 확인: replica 두 대가 있으면 쓰기 처리량이 세 배일까? 일반 primary·standby 구조의 쓰기 역할은 여전히 하나다. 읽기 분산과 장애 대비의 효과를 구분한다.