Consistency / Journaling

Journaling

일종의 WAL (Write-Ahead logging)

데이터를 쓰기 전에 그 의도를 다른 곳에다 적어두는 방법

** 그 '다른 곳'은 Ext3이면 블록 중 하나를 저널 블록으로 사용 / 다른 파일 시스템은 파티션을 저널 공간으로 쓰기도 함

 

저널링 FS

- 리눅스 Ext3/4, IBM JFS, SGI XFS, NTFS 등

Ext3 특징

- Ext2 파일 시스템에 저널링을 더함

- 세가지 타입: 데이터 저널 / 오더드 저널 / 라이트 백

 

Data Journaling

I[v2] | B[v2] | Db

총 세가지 라이트가 있을 때 트랜잭션으로 세 과정을 묶음

 

Txb | I[v2] | B[v2] | Db | TxE

트랜잭션 비긴 / 트랜잭션 엔드가 추가되어 5개의 과정이 됨

트랜잭션이 잘 끝나면 오리지널 데이터를 업데이트할 준비가 된 것 => 체크포인팅

 

Recovery

체크포인팅 중간에 에러난 경우 -> redo .. 저널은 멀쩡하니 다시 하면 됨

저널링 중 에러 -> undo .. 원래 데이터가 유지됨

 

이슈 1 : 저널링 성능

저널링 자체의 오버헤드 : 결국 써야하는게 5개로 늘었는데 어떻게 오버헤드를 줄일 것이냐

 

- approach1: 순서관계 없이 한번에 실행

몇몇 리퀘스트가 로스될 수 있음

트랜잭션 비긴, 엔드 둘 다 있어도 중간에 없는 게 있을 수 있음

 

- approach2: fsync를 통해 순서 관계를 보장

느림

 

- approach3: commit 개념 도입

트랜잭션 엔드 시작 전에 fsync => 트랜잭션 엔드가 있으면 앞의 작업들은 끝난 거임

Txb | I[v2] | B[v2] | Db |   [commit]   |TxE

문제 생겼을 때 트랜잭션 엔드가 있으면 리두, 없으면 언두

 

- approach4: 체크섬

속도 향상

 

이슈 2 : 쓰기 볼륨이 너무 크다

결국 저널링을 하면 데이터를 두번 쓰는데, 유저 데이터까지 두 번 쓸 필요가 없다

=> 메타데이터 저널링

 

Metadata Journaling

Txb | I[v2] | B[v2] | TxE

메타데이터만 저널링함

중요한 건 저널링과 유저 데이터 라이트의 순서 관계

단순 데이터만 쓰여있는 건 일관성을 해치지 않음, 메타데이터만 써지면 문제가 됨

=> 유저데이터를 먼저 씀 (Ordered)

1) 데이터 쓰기 2) 메타데이터 저널링 3) 저널 커밋 4) 체크포인트 5) 프리

 

유저데이터를 먼저 쓰지 않는 방식이 writeback (non-ordrered)

물론 이러면 문제생길 수 있는데, 결국 순서를 맞추면 성능 저하이고

문제가 발생하는 일이 많이 드물어서 그냥 유저데이터를 먼저 안쓰는 방식이 존재함