RDBMS의 디스크 활용법

데이터베이스를 사용하다 보면 자연스럽게 이런 궁금증이 생깁니다.
“INSERT나 UPDATE를 하면 데이터는 바로 디스크에 저장되는 걸까?” 하는 질문인데요.

 

실제로 대부분의 RDBMS는 이런 방식으로 동작하지 않습니다.
성능과 안정성을 동시에 확보하기 위해 데이터 변경은 먼저 메모리에서 처리하고, 변경 사실은 로그에 기록한 뒤 실제 디스크 반영은 이후 시점에 수행하는 구조를 사용합니다.

 

이번에 이러한 구조를 가진 RDBMS 의 디스크 활용법에 대해서 알아보겠습니다!

 

 

🚀 RDBMS는 데이터를 바로 디스크에 저장하지 않는다?

 

Oracle, MySQL(InnoDB), PostgreSQL 같은 주요 RDBMS들은
구현 방식이나 내부 명칭은 조금씩 다르지만
이러한 메모리 기반 처리 + 로그 기반 안정성 확보 구조를 공통적으로 가지고 있습니다.

 

이번 글에서는 그 중에서도 PostgreSQL을 기준으로
데이터 변경이 실제로 어떤 흐름을 통해 처리되는지
Shared Buffer, WAL, Checkpoint 관점에서 정리해보려고 합니다.

운영 환경에서 WAL 용량 증가나 Replication 지연 같은 이슈를 경험해보신 분들이라면
이 구조를 이해하는 것만으로도 문제를 바라보는 시각이 달라질 수 있습니다!

---

⚙️ 데이터 변경은 디스크가 아니라 메모리에서 먼저 발생!

PostgreSQL에서 INSERT나 UPDATE가 수행되면
데이터는 곧바로 디스크 파일에 기록되지 않습니다.

 

먼저 해당 데이터가 포함된 페이지(page)를 디스크에서 읽어
Shared Buffer라는 메모리 영역으로 가져오는데요.

그리고 실제 데이터 변경은 이 Shared Buffer 안에서 수행됩니다.

 

예를 들어 다음과 같은 UPDATE가 실행된다고 가정해보겠습니다.

UPDATE t1 SET value = 2 WHERE id = 10;

 

이때 내부적으로는 다음과 같은 흐름이 발생합니다.

• 해당 row가 포함된 데이터 페이지를 Shared Buffer로 적재합니다
• 메모리에서 row 값을 수정합니다
• 이 페이지는 dirty page 상태가 됩니다
• 동시에 변경 사실이 WAL 로그로 기록됩니다

즉 사용자 입장에서는 데이터가 즉시 반영된 것처럼 보이지만
실제로는 메모리에 반영된 상태일 수 있습니다.

---

🧠 WAL은 데이터를 저장하는 공간이 아닌 변경 기록

WAL은 종종 데이터를 먼저 저장하는 공간처럼 오해되기도 합니다.
하지만 WAL은 실제 데이터를 저장하는 저장소가 아니라
데이터 변경 사실을 기록하는 로그입니다.

 

WAL에는 다음과 같은 정보가 기록됩니다.

• 어떤 데이터 페이지가 변경되었는지
• 어떤 트랜잭션이 commit 되었는지
• 복구 시 필요한 redo 정보

PostgreSQL에서 트랜잭션이 성공적으로 완료되기 위한 조건은
데이터파일 write가 아니라 WAL 로그가 디스크에 안전하게 기록되는 것입니다.

이 구조 덕분에 PostgreSQL은
순차 쓰기(sequential write) 기반의 높은 처리 성능과
장애 발생 시 복구 가능성을 동시에 확보할 수 있습니다.

---

🔄 Checkpoint는 메모리 변경을 디스크에 동기화하는 작업

Shared Buffer에 반영된 변경 사항은
언젠가는 실제 테이블 파일(datafile)에 반영되어야 합니다.

이 작업을 수행하는 것이 바로 Checkpoint인데요.

Checkpoint는 다음 역할을 수행합니다.

• Dirty Page를 실제 데이터파일에 flush 합니다
• 장애 발생 시 WAL replay 범위를 줄여줍니다
• 오래된 WAL segment를 재사용할 수 있는 상태를 만듭니다

Checkpoint는 모든 DML마다 발생하는 것이 아니라
다음과 같은 조건에서 발생합니다.

• WAL 생성량이 max_wal_size를 초과했을 때
• 설정된 checkpoint_timeout 시간이 경과했을 때
• 수동 CHECKPOINT 실행 시
• 서버 종료 시

즉 데이터 변경과 디스크 반영은 시간차를 두고 이루어지는 구조입니다.

---

📡 Replication과 Replay는 WAL을 기반으로 동작

Streaming Replication 환경에서는
Primary 서버에서 생성된 WAL이 Standby 서버로 전달됩니다.

 

Standby 서버는 이 WAL을 기반으로 replay 작업을 수행하여
Primary와 동일한 상태를 유지하게 됩니다.

 

Replay는 다음 상황에서 특히 중요하게 동작합니다.

• DB Crash 후 Recovery
• Standby Replication
• 특정 시점 복구(PITR)

Primary 서버에서는 정상 운영 중 replay 작업을 직접 체감하기는 어렵지만
Standby 서버에서는 WAL replay가 지속적으로 수행되고 있습니다.

---

📦 Archive 관리는 자동으로 이루어지지 않는다

WAL Segment가 완료되면 archive_command를 통해
외부 저장소에 WAL이 보관될 수 있습니다.

 

이 Archive는 다음과 같은 목적을 가집니다.

• 시점 복구(PITR)
• 장애 분석
• Standby 재구성

중요한 점은 PostgreSQL은 Archive 파일을 자동으로 삭제하지 않는다는 것입니다.

Retention 정책이 없다면 Archive 스토리지는 결국 가득 차게 되고
Archive 실패는 WAL recycle 지연으로 이어질 수 있습니다.

 

결과적으로 pg_wal 디렉토리 용량 증가나
쓰기 트랜잭션 실패 같은 문제로 이어질 수 있기 때문에
Archive 관리는 운영자가 반드시 정책적으로 관리해야 합니다.

---

🧭 [정리] RDBMS 는 메모리 중심 Write-back 구조를 사용합니다

RDBMS 의 데이터 변경 흐름을 정리하면 다음과 같습니다.

• 실제 데이터 변경은 Shared Buffer에서 먼저 발생합니다
• WAL은 변경 사실을 기록하는 안정성 장치 역할을 합니다
• Checkpoint는 메모리 변경을 디스크에 동기화합니다
• Replay는 WAL 기반 상태 복구 메커니즘입니다
• Archive 관리는 운영자가 직접 정책을 가져가야 합니다

이 구조를 이해하면 WAL 증가, Replication 지연, Checkpoint I/O 증가 같은
운영 환경에서 자주 발생하는 이슈를 훨씬 빠르게 이해할 수 있습니다!

 

출처

- https://www.fun-coding.org/post/mysql_basic1.html#gsc.tab=0

- https://koras02.tistory.com/247