TL;DR

최근 OLAP 데이터베이스로 Clickhouse를 self-managed로 구축하여 운영을 하고 있다. 새로운 데이터베이스를 도입하고 데이터의 Sync를 맞춰주는 작업을 진행하면서 Confluent (Kafka) Connector를 도입하여 적용하고 있는데 여기서 WAL이라는 개념과 Replication slots 에대한 이해가 필요에 공부하면서 정리해본다.

WAL ( Write Ahead Log )

번역하면 쓰기전 로그인데 말 그대로 데이터베이스 Disk 에 쓰여지기전에 쓰여지는 로그파일이다. 이러한 log 파일을 만들어서 얻을 수 있는 장점은 다음과 같다.

• 매 transaction 마다 disk의 영구저장소에 저장되는 과정이 일어나면 많은 부하가 발생하는데 이를 log에 기록하고 flushing 함으로써 부하를 줄일 수 있다.
• sequential 하게 쓰여진 log데이터를 기반으로 데이터베이스의 recovery가 가능하다.
• 비슷한 개념으로 wal 를 기반으로 replica database의 sync가 이루어지며 이기종 데이터베이스간의 replicate도 가능하다.

이렇듯 다양한 장점이 있는데 Kafka에서 사용되는 Database Connector도 이러한 WAL를 기반으로 persistent layer에서의 데이터 sync를 할 수 있게 된다.

이 때 wal의 level은 logical로 맞춰줘야 한다. minimal, replica, logical 3가지의 level이 있는데 minimal은 point in time recovery 라던가 backup을 사용할 수 없게 되어서 실제 사용은 어렵고 replica, logical을 사용할 수 있는데 logical은 replica에 비해 좀 더 많은 information을 갖고 있다고 보면 된다. ( logical decoding data )

PostgreSQL의 Primary DB 에는 wal sender process 가 존재하고 최신 버전 기준 기본 10개의 process가 형성된다. 그리고 각각의 standby 혹은 replica db 에 wal receiver process가 존재하고 wal sender process가 보내는 정보를 받아 sync작업이 이루어지게 되는 것이다.

Replication slots

일반적으로 wal segments 는 16MB의 용량을 가지고 refresh되게 된다. 따라서 모든 database의 변경사항들을 기록하고 보존할 수는 없고, 이에 따라서 잠시 중단됐던 replica db가 새로 기동될 때 필요한 WAL 가 없다면 recovery가 실패하게 된다.

이러한 문제를 방지할 수 있는 것이 replication slots 개념이다. 모든 복제본 데이터베이스가 wal segments를 읽어들여서 sync를 맞출 때 까지 남겨두게 된다.

aws aurora db를 이용하다보면 이 replication slots 가 남아있을 때 version upgrade를 못하게 되는데, 이 replication slots는 사용하고 나서 정리를 잘 해줘야한다. 따로 지워주지 않으면 사용하지 않고 있다고 해도 사라지지 않고 용량을 잡아먹기 때문에 문제가 될 수도 있는 점에 유의해야한다.

Reference

https://www.postgresql.org/docs/current/wal.html
https://www.postgresql.org/docs/15/warm-standby.html#STREAMING-REPLICATION-SLOTS