백업 및 복구

로그 선행 기입 기법 (write-ahead logging, WAL)

시스템에서 모든 수정은 적용 이전에 로그에 기록된다.

• 데이터베이스의 데이터 파일을 로그 레코드로 사용하여 동기화
• 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것 보다 성능이 좋다.
• 데이터베이스 버퍼를 이용해 데이터 파일 변경을 효율적으로 진해애함.

 

 

데이터베이스 버퍼 

체크포인트가 갱신되면, Dirty 블록이 데이터 파일에 이동되는 것. 이해를 돕기 위해 그림

로그 - 버퍼 - 데이터

 

갱신 대상의 데이터를 포함한 블록이 버퍼 풀에 있는지 확인.

없을 경우 데이터 파일로 부터 해방 블록을 읽어 들임.

버퍼 풀 내에 해당 블록을 갱신함. ( Dirty 발생 ) / Dirty의 내용이 데이터 파일에 적용되는 거임.

갱신 내용이 Commit과 함께 로그에 기록.

갱신 되었지만 데이터 파일에 쓰이지 않은 블록은 Dirty 블록이 된다.

갱신된 데이터 블록은 나중에 데이터 파일에 적용됨 (체크포인트)

체크포인트 이전 로그파일은 필요 없음.

 

 

 

 

Crash 복구에 필요한 항목

Crash = 정전과 같은 사고

1. WAL (로그)

2. 데이터베이스 버퍼

3. 데이터베이스 파일

 

 

Crash 발생 시 복구 과정

1. WAL : 마지막으로 Commit 된 트랜잭션의 갱신 정보를 가짐

2. 데이터베이스 버퍼 : Crash로 내용이 전부 소실

3. 데이터베이스 파일 : 최후 체크 포인트 까지의 갱신 정보를 가짐

데이터베이스가 로그를 판단함. 적용 안된 부분을 로그를 보고 복구한다 -> 롤 포워드 단계

데이터베이스 파일을 Crash 전 최신 Commit 상태로 수정.

 

 

백업의 종류

핫 백업과 콜드 백업

1. 핫 백업 : 데이터베이스 정지하지 않고 가동한 상태로 백업 (많이 씀)

2. 콜드 백업 : 데이터베이스를 끄고 파일을 백업함. OS 기능을 이용

 

논리 백업과 물리 백업

1. 논리 백업 : SQL 기반 텍스트 형식으로 백업 데이터 기록

    이식성이 좋음 / 용량이 큼 / 백업과 복원 속도 느림

2. 물리 백업 : 데이터베이스 파일 자체를 백업 / 데이터 영역을 그래도 바이너리 형식 기록

   최소 크기로 데이터를 얻음 / 백업 및 복원 속도 빠름 / 호환성 나쁨 / 일부 데이터 수정 불가

 

풀 백업과 부분 백업

1. 풀 백업 : 데이터베이스 전체 데이터를 매일 백업 - 시간 오래 걸림, 과도한 용량

2. 부분 백업 : 풀 백업 이후 갱신된 데이터를 백업 ( 차등 / 증분 ) -  복원 절차가 복잡

 

 

데이터베이스 관리 시 주의점

1. 백업 파일들은 떨어진 곳에 따로 보관해야함

2. 장치를 서로 먼 지역에 배치시켜 장소 장애로부터 보호해야함

3. 장애 발생 시 빠른 복구가 가능하도록 운영 조건을 고려해야함