WAL(Write-Ahead Logging)

 

 

---

공통 질문

1. WAL이란 무엇이며, 왜 필요한가?
2. WAL의 주요 동작 원리는?
3. WAL과 Undo Log, Redo Log의 차이점은?
4. WAL과 Checkpoint의 관계는?
5. WAL의 단점은?
6. WAL을 사용하지 않는다면 어떤 문제가 발생할 수 있는가?
7. WAL을 사용하는 대표적인 시스템은?
8. PostgreSQL의 WAL과 MySQL의 Redo Log 차이점은?
9. WAL에서 장애 발생 시 복구 과정은?
10. Kafka의 WAL과 DBMS의 WAL 차이점은?

WAL 로그를 효율적으로 관리하기 위한 방법은?
SSD를 사용할 때 WAL의 성능 최적화 방법은?
WAL과 Checkpoint 실행 주기를 조정하는 방법은?
WAL을 줄이는 방법이 있다면 어떻게 최적화할 수 있는가?

 

 

• WAL은 장애 발생 시 데이터를 복구하는 핵심 기술.
• PostgreSQL, MySQL InnoDB, Kafka, 파일 시스템 등에서 활용.
• Checkpoint와 함께 사용하여 디스크 공간과 성능을 최적화해야 함.
• Kafka의 WAL(Commit Log)과 DBMS의 WAL은 사용 목적이 다름.

 

---

1. WAL이란 무엇이며, 왜 필요한가?

데이터 변경 전에 변경 내용을 먼저 로그(WAL 파일)에 기록하는 방식

- 장애 발생 시 WAL을 사용하여 데이터 복구가 가능하며,

- 트랜잭션의 원자성(Atomicity)과 내구성(Durability)을 보장

 

✅ 데이터 일관성 보장

장애 발생 시 WAL 로그를 기반으로 복구 가능

 

 

✅ 트랜잭션 원자성 보장 (ACID 속성 중 A, D 충족)

트랜잭션이 중간에 실패하면 WAL을 통해 복구 가능

 

 

✅ 성능 최적화

데이터를 직접 변경하는 대신 로그에 먼저 기록하여 비동기적으로 저장

 

 

✅ 빠른 디스크 I/O

WAL은 순차 쓰기를 이용하여 디스크 I/O 성능을 최적화

 

 

 

---

2. WAL의 주요 동작 원리는?

1. WAL 로그 기록
   • 데이터를 변경하기 전에 WAL 로그에 변경 사항을 먼저 기록
   • 이 과정에서 fsync()를 통해 디스크에 안전하게 저장
2. DATABASE 데이터 변경
   • 로그가 기록된 후 실제 데이터 페이지를 변경(버퍼 캐시 사용 가능).
3. 트랜잭션 커밋
   • WAL 로그가 디스크에 저장된 후 트랜잭션이 커밋
   • 이때, 변경된 데이터가 실제 데이터베이스 파일로 반영될 수도 있음
4. check point
   • WAL을 정리하여 디스크 사용량을 줄이고 복구 시간을 단축하는 역할
   • Checkpoint를 생성하여 WAL을 정리
     • WAL 로그 내용을 실제 데이터에 반영
5. 장애 복구
   • 장애 발생 시 WAL 로그를 읽어
     • REDO: 변경 내용을 복구
     • UNDO(롤백): 적용되지 않은 변경을 롤백

 

---

3. WAL과 Undo Log, Redo Log의 차이점은?

 

 

---

4. WAL과 Checkpoint의 관계는?

• Checkpoint는 WAL 로그에 기록된 데이터 변경 사항을 실제 데이터 파일에 반영하는 과정
• Checkpoint 이후의 WAL 로그는 삭제 가능하여, 디스크 공간을 절약하고 성능을 최적화함
• Checkpoint가 너무 자주 발생하면 I/O 부하가 증가하고, 너무 드물면 복구 속도가 느려질 수 있음

 

---

5. WAL의 단점은?

 

• 디스크 공간 사용 증가 → WAL 로그가 많아질 경우 저장 공간을 차지
• 추가적인 I/O 부하 발생 → 데이터를 변경하기 전에 로그를 먼저 기록해야 함
• 쓰기 성능 저하 가능 → fsync()로 WAL을 디스크에 강제 기록하면 지연이 발생할 수 있음

해결 방법:

• WAL 크기 조절 (wal_keep_size 조정)
• SSD 사용으로 디스크 I/O 성능 최적화
• Batch Write(배치 쓰기) 적용

 

---

6. WAL을 사용하지 않는다면 어떤 문제가 발생할 수 있는가?

1. 장애 발생 시 데이터 손실
   • WAL이 없으면 트랜잭션 중 장애가 발생할 경우 변경 사항이 사라질 수 있음.
2. ACID 속성 보장 어려움
   • 특히 **Atomicity(원자성)**과 **Durability(내구성)**을 충족할 수 없음.
3. 데이터 불일치 문제
   • 특정 트랜잭션이 중간에 실패하면 데이터베이스 상태가 불완전해질 수 있음.
4. 복구 불가능
   • PostgreSQL, MySQL 등에서는 WAL을 기반으로 복구하는데, WAL이 없으면 장애 시 복구가 불가능함.

 

다만, 임시 데이터 처리(캐싱, 테스트 환경 등)에서는 WAL을 비활성화할 수 있음.

예: SQLite에서 WAL 비활성화

PRAGMA journal_mode = OFF;

 

 

 

---

7. WAL을 사용하는 대표적인 시스템은?

1️⃣ 데이터베이스(DBMS)

 

• ostgreSQL: pg_wal 디렉토리에 WAL 파일 저장.
• MySQL (InnoDB): ib_logfile0, ib_logfile1에 WAL 저장.
• SQLite: journal_mode=WAL을 통해 WAL 사용 가능.

2️⃣ 파일 시스템(FS)

 

• EXT4 (Linux): journaling 기능을 사용하여 WAL 개념 적용.
• NTFS (Windows): USN Journal을 사용하여 파일 변경 사항을 로그로 기록.

3️⃣ Kafka (메시지 브로커)

• Kafka의 Commit Log는 WAL 개념을 사용하여 메시지 무결성을 보장.
• 메시지를 Commit Log(WAL) 형태로 저장 후 Consumer에게 전달.

 

 

 

 

---

8. PostgreSQL의 WAL과 MySQL의 Redo Log 차이점은?

 

• PostgreSQL WAL은 전체 트랜잭션 로그를 저장하여 Redo/Undo 모두 가능.
• MySQL Redo Log는 Redo(재적용) 기능만 제공하며, Undo는 별도의 undo log에서 관리됨.

 

✅ WAL은 모든 변경 사항을 먼저 저장하지만, Redo/Undo Log는 특정 경우에만 사용된다.

 

 

---

9. WAL에서 장애 발생 시 복구 과정은?

 

• Redo (재적용):
  • WAL 로그를 분석하여 커밋된 트랜잭션을 다시 적용.
• Undo (롤백):
  • WAL에 커밋되지 않은 트랜잭션이 있다면 롤백.
• Checkpoint 이후의 데이터 확인:
  • Checkpoint 이전의 WAL 로그는 무시하고, 이후 변경 사항을 반영.

 

---

10. Kafka의 WAL과 DBMS의 WAL 차이점은?

 

 

• Kafka의 WAL (Commit Log)
  • 메시지를 로그 파일에 기록한 후 Consumer에게 제공.
  • 장애 발생 시 로그를 기반으로 메시지를 다시 처리 가능.
• DBMS의 WAL
  • 트랜잭션 데이터를 먼저 로그에 기록한 후 데이터베이스를 변경.
  • 장애 발생 시 WAL을 사용하여 데이터 복구.