WAL과 장애 후 복구

결론부터

변경 로그를 먼저 안전하게 기록하면 데이터 페이지 기록이 끝나기 전에 장애가 나도 변경을 다시 적용할 수 있다.

매번 바뀐 데이터 페이지를 전부 디스크에 기록한 뒤 응답한다면 작은 변경도 많은 I/O를 기다릴 수 있다. PostgreSQL은 WAL을 먼저 기록하고 데이터 페이지는 나중에 기록할 수 있도록 순서를 지킨다.

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

WALWrite-Ahead Log

데이터 페이지보다 먼저 기록하는 변경 로그. 장애 복구와 물리 복제·시점 복구에 사용한다.

checkpoint

복구를 시작할 기준과 관련 데이터 기록을 정리하는 작업.

LSNLog Sequence Number

WAL 안의 위치를 나타내는 값. 복제가 어디까지 진행됐는지 비교할 때 쓴다.

커밋과 데이터 파일 기록은 같은 순간이 아니다

일반적인 logged 테이블에서 fsync=on, synchronous_commit=on이고 동기 standby가 없는 기본 구성을 생각한 그림이다. 데이터 파일을 디스크에 쓸 때 그 변경을 재현할 WAL이 먼저 지속 저장되어야 한다. 모든 커밋이 항상 그림처럼 데이터 파일보다 먼저 끝난다는 뜻은 아니다. (WAL 원리)

장애 후 시작할 때는 필요한 WAL을 재생해 데이터 상태를 복구한다. checkpoint는 이 재생의 출발점을 전진시키는 데 도움을 준다. checkpoint가 백업 파일을 만들거나 과거 시점으로 돌아갈 권리를 주는 것은 아니다. (WAL 설정과 checkpoint)

설정을 낮추면 무엇을 바꾸나

synchronous_commit=off는 WAL의 지속 저장을 기다리지 않고 성공을 응답할 수 있다. 장애 시 최근 성공으로 응답한 트랜잭션 일부를 잃을 수 있다. 단순한 속도 옵션으로 취급하지 않는다. fsync=off는 더 근본적인 저장 안전성을 약화시키므로 같은 의미로 설명하지 않는다. (WAL 지속성 설정)

로컬 DB에서 현재 조건을 읽는다.

SHOW fsync;
SHOW synchronous_commit;
SELECT pg_current_wal_lsn();

기본 이미지에서는 앞의 두 값이 on, 마지막은 0/… 형태의 위치다. LSN은 시각도, 업무 데이터의 행 번호도 아니다.

같은 로그가 다른 목적에 쓰인다

사용처	WAL의 역할	추가로 필요한 것
crash recovery	로컬 장애 후 상태 재구성	일관된 데이터 디렉터리와 필요한 로컬 WAL
물리 복제	다른 인스턴스가 변경을 따라감	초기 데이터 복사와 복제 연결
PITR	백업 시점 이후 변경을 원하는 지점까지 재생	베이스 백업과 끊기지 않은 WAL 아카이브

이해 확인: pg_wal 디렉터리만 복사하면 DB 전체 백업이 될까? 아니다. 변경을 적용할 바탕인 베이스 백업과 필요한 연속 구간이 있어야 한다. 복제와 백업에서 각각 이어 본다.