일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Blue-Green
- ci/cd
- 도커
- SQL 실행순서
- InnoDB 버퍼 풀
- 카카오 2차 코딩테스트
- db
- 기능별 구조
- 프리코스
- useMutation
- 회고
- 메서드명
- BalancedTree
- 백기선 스터디
- B+TREE
- Jenkins
- 우테코
- 블로그 병행
- DeleteAll
- 멀티쓰레드 프로그래밍
- jacoco
- 주간회고
- 어댑티브 해시 인덱스
- useQuery
- 클래스
- 월간회고
- mysql
- 계층별 구조
- N+1
- java
- Today
- Total
Haneul's Blog
[DB] WAL(Write-Ahead-Logging) 본문
트랜잭션에는 ACID라는 특성이 있습니다. 이 중 D는 지속성을 의미하는데, 여기서 지속성이라는것은 트랜잭션 동작을 완료하고 완료 통지를 사용자가 받은 시점에서는 그 동작이 영속화(사라지지 않고 지속됌)되어 결과를 잃어버리지 않는 것을 의미합니다.
그래서 DB서버나, OS의 비정상적인 종료가 일어난다해도 그 전에 완료한 동작은 견딜 수 있다는 것입니다.
그렇다면 어떻게 지속성을 실현시킬 수 있는지 직관적으로 생각해보면 아래와 같이 생각할 수 있습니다.
데이터를 보존하는 기억장치인 하드디스크에 데이터 동기화 쓰기를 통해서 지속성을 유지하는 것입니다.
하지만 데이터베이스의 쓰기는 기억장치의 임의 장소에 무작위로 엑세스해서 쓰기를 수행하기 때문에 동기화 쓰기는 느려서 성능적인 면에서 별로라 쓰지 않습니다.
그래서 DBMS는 지속성과 성능을 둘 다 잡기 위해 일반적으로 아래와 같은 구조를 사용합니다.
로그 선행 쓰기(WAL: Write-Ahead-Logging)
로그 선행 쓰기는 시스템에서 모든 수정은 적용을 하기 전에 먼저 로그에 기록되게 하는 것입니다.
트랜잭션이 발생 시에 일단 로그에 기록을 남기고, 데이터가 쌓이면 이를 DB의 디스크에 DATA BLOCK 형태로 쓰기를 진행합니다.
그렇다면 왜 제때 DATA BLOCK을 만들어서 디스크에 쓰지 않고 데이터가 쌓이면 쓰게 되는 것일지를 생각해봅시다.
바로 DB의 성능 문제 때문입니다. 디스크 IO는 비용이 큰 작업이기 때문에 자주 발생하면 DB 성능이 많이 떨어지게 되어서 로그 데이터를 보관해두고 데이터가 적정 사이즈가 된다면 이를 DATA BLOCK으로 만들어 디스크에 쓰기를 진행하게 되는 것입니다.
그렇다면 실제로 서버가 비정상적으로 종료(크래시)되었을 때 어떤 식으로 복구하게 되는 걸지도 생각해보면 좋을 것 같습니다.
크래시가 발생하면 마지막으로 DATA BLOCK을 만들어서 디스크에 썻던 것 까지 기록이 남아있기 때문에 이를 토대로 복구를 진행할 수 있게 됩니다.
'DB' 카테고리의 다른 글
[DB] SELECT 쿼리 문법 및 실행 순서 (0) | 2022.11.04 |
---|---|
[DB] InnoDB 어댑티브 해시 인덱스 (0) | 2022.11.02 |
[DB] InnoDB 버퍼 풀 (0) | 2022.11.01 |
[DB] MySQL 메모리 할당 및 사용 구조 (0) | 2022.10.28 |
[DB] MySQL의 실행 구조 (0) | 2022.10.14 |