하지만 DB의 데이터는 Commit(확정)시 바로 하드디스크에 기록되지않고 Log에 먼저 기록하고 Sequential한 Log가 일정량 기록되면 DataBlock을 생성해 하드디스크에 기록한다.
왜 바로바로 기록하지않을까?
하드디스크 I/O는 많은 리소스를 소모하기때문에 Commit마다 수행하기엔 DB성능에 영향을 미치기때문이다.
Sequential한 Log는 무엇일까?
배열을 예로들면 이해가 좋을 것 같다. 메모리구조상 연속적인 형태가 조회측면에서 좋다.
같은 논리로 연속적인 로그는 랜덤한 방식보다 성능적으로 우수하다.
WAL로 데이터를 기록한다면 서버가 내려가더라도 Log기록이 있기때문에 데이터를 안전하게 보호할 수 있고(원자성) Log에 적히면 누가 조회하더라도 같은 결과를 받는다(일관성)
데이터베이스 버퍼
일단 지금까지의 DB기록 흐름을 보자.
Transcation Start -> Commit -> WAL(Sequential한 방식으로 로그기록)
이렇게 commit시 바로 데이터 파일(물리적저장소:하드디스크)에 저장하지않고 Log에 선행기록한다는 것까지 봤다.
물리적 저장소에 저장되기 전에 WAL과함께 동작하는 데이터베이스 버퍼가 존재한다.
갱신 쿼리를 날리고 해당 내용이 우선 버퍼에 있는지 확인한다(동일한 쿼리가 있는지 확인) 없다면 버퍼 풀에 갱신한다.
그 후에 갱신 내용이 커밋과 함께 로그에 기록이 된다.
하지만 아직 DB에는 기록이 안된 상황이다.
이렇게 DB에는 기록되지않고 버퍼풀에만 갱신된것을 더티페이지로 다룬다.
더티페이지는 적정한 타이밍에 데이터파일에 기록되고 이 시간을 체크포인트로 관리해 마지막 데이터파일에 기록한 시점을 기록한다.
크래시 복구
데이터베이스 서버에 장애가 발생했다.
장애가 발생하면 버퍼풀(더티페이지) 는 날아간다. 하지만 위에서 설명했듯이 로그에는 기록이 남아있고 체크포인트로 어디까지 DB에 기록이 되었는지 기억하기때문에 직전 체크포인트로 로그파일을 이용해 복구가 가능하다.
백업과 복구
크래시 복구를 다시 상기해보자.
직전 체크포인트 이후에 로그는 계속해서 쌓여가는 중에 어느 한 시점에서 크래시(장애)가 발생했다.
버퍼 풀에 있는 데이터는 소실되었고 로그기록만 남아있다.
이 상황에서 직전 체크포인트와 크래시된 시점까지의 로그기록을 이용해 복구하는것이 크래시 복구였다.
새로운 개념 PITR에 대해 알아보자.
백업이라는 것은 어느 시점까지의 기록을 남겨놓는 것이다.
그렇기때문에 백업 이후의 갱신은 백업을 하더라도 반영이 되지 않는다. 그래서 로그기록을 이용해 백업 이후의 갱신을 포함한 복원을 한다.
이것을 PITR이라 한다.
즉 백업만이 기준이 되는 시점이아니라 임의의 시점으로 복원을 가능하게해준다.
하지만 WAL를 생각해보면 직전체크포인트 이전의 로그는 다른 로그를 기록하기위해 비워버린다. 이렇게되면 임의의 시점으로의 복원이 어려워진다.
그래서 WAL용 로그 외에 다른 로그가 아카이브 지정모드로 제공된다.
백업
핫 백업 : 데이터베이스를 가동한 채로 백업데이터를 얻는다
콜드 백업 : 데이터베이스를 중단하고 백업데이터를 얻는다.
논리 백업 : SQL기반 텍스트 형식으로 백업 데이터를 얻는다. 바이너리 형식이 아니기때문에 백업과 복원의 속도가 느리지만 수정할 수 있다. 또한 다른 DBMS로의 이식성이 높다.
물리 백업 : 바이너리기반으로 백업데이터를 얻는다. 바이너리형식이기때문에 텍스트보다 용량이 적으며 백업과 복원속도가 빠르다. DBMS의존성이 있는 바이너리파일은 호환이 불가능하다.
풀백업 : 전체를 백업한다. 당연히 시간이 오래걸리고 용량도 많이 필요하다.
부분백업 : 처음엔 풀백업을하고 이후 갱신된 데이터만 백업한다. 시간이 짧고 용량도 적게필요하다. 하지만 복원절차가 복잡하다.
차등 부분 백업 : 첫 풀 백업후 갱신된 부분을 이어붙여 백업한다.
증분 부분 백업 : 위와 다르게 이어붙이지않고 따로따로 증분을 백업한다. 위 방식보다 용량은 적게들지만 따로따로 백업하는 만큼 복원절차도 순서대로해야한다.
롤 포워드 리커버리 : 앞서 WAL를 정리하며 이야기했지만 직전 체크포인트 + 체크포인트 이후 저장된 로그파일 을 이용해 임의의 시점으로의 복원이 가능하다했다. 이와 같은 맥락으로 풀 백업한 데이터 + 풀백업후 증분백업으로 데이터베이스에서 임의의시점으로 복원이 가능하다.
SightStudio
commented
1 year ago
DBMS 3가지 구조
WSL (Write Ahead Log) : DBMS의 데이터기록방식
DB의 데이터는 하드디스크에 직접 기록된다.
하지만 DB의 데이터는 Commit(확정)시 바로 하드디스크에 기록되지않고 Log에 먼저 기록하고 Sequential한 Log가 일정량 기록되면 DataBlock을 생성해 하드디스크에 기록한다.
왜 바로바로 기록하지않을까?
하드디스크 I/O는 많은 리소스를 소모하기때문에 Commit마다 수행하기엔 DB성능에 영향을 미치기때문이다.
Sequential한 Log는 무엇일까?
배열을 예로들면 이해가 좋을 것 같다. 메모리구조상 연속적인 형태가 조회측면에서 좋다.
같은 논리로 연속적인 로그는 랜덤한 방식보다 성능적으로 우수하다.
WAL로 데이터를 기록한다면 서버가 내려가더라도 Log기록이 있기때문에 데이터를 안전하게 보호할 수 있고(원자성) Log에 적히면 누가 조회하더라도 같은 결과를 받는다(일관성)
데이터베이스 버퍼
일단 지금까지의 DB기록 흐름을 보자.
Transcation Start -> Commit -> WAL(Sequential한 방식으로 로그기록)
이렇게 commit시 바로 데이터 파일(물리적저장소:하드디스크)에 저장하지않고 Log에 선행기록한다는 것까지 봤다.
물리적 저장소에 저장되기 전에 WAL과함께 동작하는 데이터베이스 버퍼가 존재한다.
갱신 쿼리를 날리고 해당 내용이 우선 버퍼에 있는지 확인한다(동일한 쿼리가 있는지 확인) 없다면 버퍼 풀에 갱신한다.
그 후에 갱신 내용이 커밋과 함께 로그에 기록이 된다.
하지만 아직 DB에는 기록이 안된 상황이다.
이렇게 DB에는 기록되지않고 버퍼풀에만 갱신된것을 더티페이지로 다룬다.
더티페이지는 적정한 타이밍에 데이터파일에 기록되고 이 시간을 체크포인트로 관리해 마지막 데이터파일에 기록한 시점을 기록한다.
크래시 복구
데이터베이스 서버에 장애가 발생했다.
장애가 발생하면 버퍼풀(더티페이지) 는 날아간다. 하지만 위에서 설명했듯이 로그에는 기록이 남아있고 체크포인트로 어디까지 DB에 기록이 되었는지 기억하기때문에 직전 체크포인트로 로그파일을 이용해 복구가 가능하다.
백업과 복구
크래시 복구를 다시 상기해보자.
직전 체크포인트 이후에 로그는 계속해서 쌓여가는 중에 어느 한 시점에서 크래시(장애)가 발생했다.
버퍼 풀에 있는 데이터는 소실되었고 로그기록만 남아있다.
이 상황에서 직전 체크포인트와 크래시된 시점까지의 로그기록을 이용해 복구하는것이 크래시 복구였다.
새로운 개념 PITR에 대해 알아보자.
백업이라는 것은 어느 시점까지의 기록을 남겨놓는 것이다.
그렇기때문에 백업 이후의 갱신은 백업을 하더라도 반영이 되지 않는다. 그래서 로그기록을 이용해 백업 이후의 갱신을 포함한 복원을 한다.
이것을 PITR이라 한다.
즉 백업만이 기준이 되는 시점이아니라 임의의 시점으로 복원을 가능하게해준다.
하지만 WAL를 생각해보면 직전체크포인트 이전의 로그는 다른 로그를 기록하기위해 비워버린다. 이렇게되면 임의의 시점으로의 복원이 어려워진다.
그래서 WAL용 로그 외에 다른 로그가 아카이브 지정모드로 제공된다.
백업
핫 백업 : 데이터베이스를 가동한 채로 백업데이터를 얻는다
콜드 백업 : 데이터베이스를 중단하고 백업데이터를 얻는다.
논리 백업 : SQL기반 텍스트 형식으로 백업 데이터를 얻는다. 바이너리 형식이 아니기때문에 백업과 복원의 속도가 느리지만 수정할 수 있다. 또한 다른 DBMS로의 이식성이 높다.
물리 백업 : 바이너리기반으로 백업데이터를 얻는다. 바이너리형식이기때문에 텍스트보다 용량이 적으며 백업과 복원속도가 빠르다. DBMS의존성이 있는 바이너리파일은 호환이 불가능하다.
풀백업 : 전체를 백업한다. 당연히 시간이 오래걸리고 용량도 많이 필요하다.
부분백업 : 처음엔 풀백업을하고 이후 갱신된 데이터만 백업한다. 시간이 짧고 용량도 적게필요하다. 하지만 복원절차가 복잡하다.
차등 부분 백업 : 첫 풀 백업후 갱신된 부분을 이어붙여 백업한다.
증분 부분 백업 : 위와 다르게 이어붙이지않고 따로따로 증분을 백업한다. 위 방식보다 용량은 적게들지만 따로따로 백업하는 만큼 복원절차도 순서대로해야한다.
롤 포워드 리커버리 : 앞서 WAL를 정리하며 이야기했지만 직전 체크포인트 + 체크포인트 이후 저장된 로그파일 을 이용해 임의의 시점으로의 복원이 가능하다했다. 이와 같은 맥락으로 풀 백업한 데이터 + 풀백업후 증분백업으로 데이터베이스에서 임의의시점으로 복원이 가능하다.