[PostgreSQL] Internal: WAL의 구조

https://blog.naver.com/sssang97/223233122052
PostgreSQL은 다른 데이터베이스들과 마찬가지로 WAL 구조 기반으로 데이터를 쌓고, 그걸 후처리해서 최적화 가능한 형태로 가공하는 형태를 취한다.
스토리지 효율성이나 성능 최적화를 위해 섬세한 튜닝을 해야 한다면, WAL의 구조를 이해하는 것이 꽤 중요하다.

WAL의 저장 구조

Linux 환경이라면, 보통 wal은 아래 경로에 있다.

sudo ls -lah /var/lib/postgres/data/pg_wal

WAL은 위처럼 작은 로그 파일로 구성된다. 각각의 파일을 세그먼트라고도 부른다.
각각의 세그먼트 파일의 최대 크기는 기본적으로 16MB 정도다.

사용자가 시도한 모든 쓰기 내역은 전부 여기에 일단 기록되고 본다.
commit이 되지 않더라도, rollback된 write도 전부 WAL에 쌓인다. 그래서 롤백한다고 해서 데이터베이스에 부하가 가지 않는 것은 아니다. 일관성을 위한 것일 뿐이다.

단일 세그먼트 파일의 최대는 16MB 정도고, 초과하면 계속해서 새 파일을 생성하는 식으로 처리를 한다.

그리고 이 WAL은 영역 구분이 없다.
어떤 데이터베이스, 스키마, 테이블에 write를 날리든, 이 단일 경로에 WAL 파일이 만들어지는 것이다. 테이블 단위로 나누는 것은 후처리 개념으로 이루어진다.

WAL와 레코드 포맷

WAL은 당연히 단순한 텍스트파일이 아니다. 적당한 형태의 바이너리로 저장되어있다.
이걸 까보려면 pg_waldump 도구를 써서 보면 된다.
파일을 하나 골라서 까보자.

sudo pg_waldump /var/lib/postgres/data/pg_wal/wal파일

그럼 이렇게 어지럽게 쌓인다.
이 행 하나하나가 별도의 쓰기 데이터인 것이다.

WAL과 CHECKPOINT

체크포인트는 WAL을 어디까지 메인 데이터베이스에 반영했는지를 관리하는 일종의 커서다.

이를 통해 WAL 기록 중에 정전 등 장애가 발생하더라도, 안정적인 처리를 가능케 한다.

예를 들면 이런 식이다.

1. 00001-00010 총 10개의 WAL 데이터 삽입

2. 00001-00005까지의 WAL을 처리해서 메인 테이블에 반영.

3. CHECKPOINT에 00005까지 처리했다고 기록

4. 00006-00010 WAL 처리중 장애 발생

5. 재시작

6. CHECKPOINT를 기반으로 재시작 - 00006-00010 WAL 처리...

이러한 구조 덕분에 언제 장애가 발생하든지 WAL 기반으로 데이터를 다시 복구하고, 가공해서 사용 가능한 데이터로 만들 수 있다.

만약 체크포인트 직전, 이미 테이블에 반영한 것을 다시 반영하게 되더라도 괜찮다. 어차피 레코드 번호(LSN)을 기반으로 멱등적인 수정을 하는 식이기 때문이다.

또한, 데이터베이스에 대한 수정은 성능을 위해서 디스크 쓰기를 매우 게으르게 한다. 메모리에서만 수정하고 디스크에는 반영되지 않는 것이 흔하다. 체크포인트는 이걸 다시 바로잡는 보완적 개념으로서도 기능한다. 체크포인트가 돌면 디스크-메모리 불일치를 강제로 교정하는 것이다.

현재 커서 (LSN)은 다음 쿼리를 통해 확인 가능하고

체크포인트에 대한 커서 정보는 pg_control이라는 글로벌 설정 파일에 존재한다.

당연히 그냥은 못읽고

도구를 써야 파싱해서 볼 수 있다.

체크포인트는 쓰기나 커밋마다 돌리거나 하진 않고, postgresql이 내부적으로 백그라운드 돌려서 처리하는 식이다. 기본적으로는 시간 간격으로 돌리는게 하나 있고, 크기 제한으로 돌리는게 하나 있다.

기본 옵션은 이거다. 5분마다 체크포인트를 트리거하고, 복구 지점을 재설정하는 것이다.

쓰기 규모가 크다면 이 옵션을 조절하는 것도 성능에 유의미한 영향을 준다.
너무 자주 돌아도 좋지 않고, 너무 한번에 몰아서 처리해도 좋지 않다.
시간당 쌓이는 데이터 평균을 알아내서 max_wal_size를 설정하고, 안정적이고 예상 가능한 시점에 checkpoint가 돌게끔 하는 것이 최선의 전략이다.

WAL과 파일 정리

당연히 WAL은 로그이므로, 충분히 활용했다면 삭제하거나 정리를 해야 한다. 무한히 쌓는다면 디스크가 남아나지 않을 것이다.

기본적으로 불필요한 WAL 파일의 정리는 CHECKPOINT 단계에서 이루어진다.
체크포인트를 지난 WAL 파일들을 "삭제"하거나, 재활용하기도 한다. 재활용은 기존의 파일을 이름만 바꿔서 재사용하는 것을 말한다.

여기에는 여러가지 옵션이 있다.

min_wal_size/max_wal_size는 checkpoint 이후에도 남겨둘 최소-최대 wal 크기다.
이렇게 남긴 파일은 나중에 write가 발생할때, 이름만 바꾸고 덮어써서 재사용한다.

아카이브오드가 off여야 자동으로 wal 파일을 정리해준다. 기본값은 off다.

또 WAL 정리를 방해할 수 있는 주범으로는 replication slot이 있다.

CDC 구현에 사용되는 시스템인데, 당연히 로그가 쌓여있어야 그걸 갖다가 동기화에 쓸 수 있기 때문이다.
근데 이게 제때 소모되지 않고 쌓여있으면, wal을 지우지 못하고 걸려버린다.
https://m.blog.naver.com/sssang97/223926531588

WAL과 WAL Buffer

write를 한다고 해서 wal 세그먼트 파일이 또 바로 만들어지는 것은 아니다.
wal 쓰기 전 단계에 WAL Buffer라고 하는 메모리 버퍼가 존재한다.

기본적으로는 4MB~16MB 정도로 설정되며, 트랜잭션 단위로 flush된다.

그래서 개별 write를 단일 트랜잭션으로 쏘는 경우에는 성능적인 이득이 별로 없고, 여러개의 write를 단일 트랜잭션으로 모아서 쏘는 경우에만 유의미한 성능 향상이 있다.

WAL Buffer도 메모리 수준 영역이라 장애 발생시에는 유실될 수 있다. 하지만 어차피 트랜잭션 단위로 flush하기 때문에 그 부작용은 크지 않은 편이다.

하지만 트랙잭션에 거대한 write 단위가 들어오는 경우가 흔하다면, wal_buffer를 좀 크게 조정하는 것이 의미있는 튜닝이 될 수 있다. 그런 경우에는 보통 전체 메모리의 3-5% 정도를 권장한다.

WAL과 디스크 분리

가능하다면, 진짜 데이터베이스가 저장되는 디스크와 WAL이 저장되는 디스크는 물리적으로 분리되는 것이 더 성능을 극대화할 수 있는 방법이다. 단일 디스크에는 I/O 한계가 있기 때문이다.

주의사항

WAL 쓰기 또한 하드웨어나 OS 수준 장애로 인해서 언제든 실패할 수 있다.
예를 들면, 실제로 OS가 디스크에 flush하지 않았음에도 flush했다고 알려줄 수 있다. 이런 경우에는 어쩔 도리가 없다. 게다가 이런 장애 상황에서 정전이 발생한다거나 하면 복구 불가능한 상태까지 갈 수도 있다.

참조
https://www.postgresql.org/docs/current/wal-internals.html
https://postgresql.kr/docs/10/continuous-archiving.html
https://www.postgresql.org/docs/current/wal-reliability.html
https://edbkorea.com/blog/postgresql-checkpoint-tuning/
https://postgresql.kr/docs/9.5/runtime-config-wal.html