7.2 WAL archiving

Write-Ahead Log(WAL)은 PostgreSQL이 데이터 파일을 고치기 전에 변경 내용을 먼저 기록하는 로그다. WAL archiving은 이 WAL 파일을 primary에서 오브젝트 스토리지로 계속 실어 나르는 연속 작업이다. 공식 문서의 표현으로 “PostgreSQL의 WAL archive는 continuous backup의 심장"이다.

왜 필요한가. base backup(7.1)은 특정 순간의 스냅샷일 뿐이라, 그 이후의 변경은 담기지 않는다. WAL archive가 base backup 시점부터의 모든 변경을 순서대로 보관하기 때문에, 둘을 합치면 base backup 이후 임의의 시점까지 재생할 수 있다. 이것이 Point-in-Time Recovery(PITR, 7.3)의 토대다.

    flowchart TD
    PG["PostgreSQL primary"]
    PGW["pg_wal (로컬)"]
    ARCH["archive 프로세스"]
    OS["object store"]
    BASE["base backup"]
    PITR["PITR 복구"]

    PG --> PGW
    PGW --> ARCH
    ARCH -->|WAL 세그먼트 전송| OS
    BASE --> PITR
    OS -->|WAL 재생| PITR

플러그인 기반 아키텍처

1.30에서 WAL archiving은 플러그인 방식으로 옮겨 갔다. Cluster의 .spec.plugins에서 한 플러그인에 isWALArchiver: true를 주면 그 플러그인이 WAL 아카이빙을 맡는다. 중요한 제약이 하나 있다. 동시에 WAL 아카이빙을 담당하는 플러그인은 하나뿐이어야 한다.

7.1에서 본 Cluster 구성이 그대로 WAL archiving 설정이기도 하다. isWALArchiver: true가 그 스위치다.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store
  storage:
    size: 1Gi

현재 CNPG 커뮤니티가 공식 지원하는 유일한 WAL 아카이빙 플러그인은 Barman Cloud Plugin이다. 세부 설정은 플러그인 문서를 참고한다.

WAL 압축

WAL은 양이 많아 전송·보관 비용에 직접 영향을 준다. ObjectStore의 wal.compression으로 압축을 켜면 아카이브 크기와 전송량을 줄일 수 있다.

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: minio-store
spec:
  configuration:
    destinationPath: s3://backups/
    wal:
      compression: gzip

archive_timeout과 RPO

부하가 낮으면 WAL 세그먼트가 좀처럼 차지 않아 오랫동안 아카이브되지 않을 수 있다. 그러면 장애 시 마지막 아카이브 이후의 변경을 잃게 되어 Recovery Point Objective(RPO, 데이터 손실 허용 폭)가 커진다.

이를 막기 위해 CNPG는 archive_timeout 기본값을 5분으로 잡는다. 덕분에 트래픽이 적어도 최소 5분마다 WAL 파일이 닫히고 아카이브된다. 공식 문서는 이 조합으로 “재해 복구 시 RPO 5분 이하"를 달성할 수 있다고 설명한다.

RPO는 “얼마만큼의 데이터 손실을 감수할 수 있는가"이고, RTO(7.1)는 “복구에 얼마나 걸리는가"이다. archive_timeout을 줄이면 RPO는 좋아지지만 작은 WAL 파일이 잦게 생겨 오브젝트 스토리지 요청이 늘어난다. 워크로드에 맞춰 절충한다.

프로덕션에서는 항상 WAL archive를 구성하라는 것이 공식 권고다. 예외는 무한 RPO(데이터 손실을 감수)를 받아들이는 스테이징·개발 환경 정도다.

레거시 구성

플러그인 이전에는 .spec.backup.barmanObjectStore 필드로 네이티브 WAL 아카이빙을 설정했다. 1.30은 하위 호환을 위해 이 필드를 아직 인식하지만, 공식 문서는 “deprecated이며 이후 릴리스에서 제거될 예정"이라고 못 박는다. 신규 배포는 플러그인 방식을 쓴다.

정리

WAL archive는 base backup 이후의 변경을 이어 보관해 PITR를 가능하게 한다.
1.30에서는 플러그인 하나에 isWALArchiver: true를 줘서 활성화한다. WAL 아카이버는 동시에 하나만.
wal.compression으로 아카이브 크기·전송량을 줄인다.
archive_timeout 기본 5분이 저부하 상황에서도 RPO를 예측 가능하게 유지한다.
네이티브 barmanObjectStore 방식은 deprecated이므로 신규 구성은 플러그인으로.

다음 절(7.3)에서는 이 백업과 WAL archive로 새 클러스터를 세우는 recovery와 PITR를 본다.

7.1 Backup 7.3 Recovery와 PITR