-
[DB] Recovery 기본 개념 + Shadow데이터베이스 2021. 4. 25. 14:02728x90
Recovery
Failure 분류
- 트랜잭션 실패
- Logical error : 내부 조건의 문제
- System error : 데드락 같은 시스템의 문제
- 시스템 실패 : 전원 문제 등
- volatile storage(메인 메모리) 의 유실로 인한 문제 발생
Page -> Buffer-> Disk 순서로 write 되는데 버퍼는 메인 메모리에 저장되므로 시스템 문제로 유실되면 application 은 write 했다 생각하지만 실제 disk 에는 쓰이지 않는 문제 발생 (Durability 준수 X, Inconsistency 상태) - 디스크 실패
예
Recovery 알고리즘은 ACID 를 만족해야하며 보통 로그를 이용함
Storage structure
- Volatile storage : 메인 메모리
- Nonvolatile storage : 디스크
- Stable storage : 이론적으로만 존재하는 저장 영역
- 백업(copy)
- 원격 백업(Remote copy)
- RAID(Redundant Arrays of Independent Disk) 시스템
과거 : 용량이 큰 디스크는 비싸니 싸고 용량이 적은 디스크를 여러개 구비하는 기법
현재 : 디스크 안정성을 위해 여러 디스크를 두어 서로 싱크를 맞추며 복사하는 기법 - 레벨
- 0 : 중복 없음 -> 복사 안함
- 1 : 디스크 완전 복사
- block-interleaved parity
- block-interleaved distributed parity
- RAID 는 나중에 따로 정리하기
- 단점 : 데이터 전송/복사 중 에러가 발생할 수 있음
Disk IO 의 atomic 함은 OS 혼자서는 어려우므로 RAID 하드웨어의 도움이 필요함
데이터 읽기
DB는 여러 개의 페이지로 구성됨
Transaction 이 read 요청 시 System buffer 에 해당 페이지가 있는지 찾아보고, 없으면 버퍼로 로딩 후 해당 페이지를 트랜잭션에 제공
데이터 쓰기
트랜잭션이 write 요청 시 System buffer 에 해당 페이지가 있는지 찾아보고, 없으면 버퍼로 로딩 후 해당 페이지에 write.
이 후 적절한 시점에 disk write 함 (버퍼의 내용이 업데이트 될 때마다 write 되는 것은 아님)
Recovery approach
Shadow-paging
옛날 방식의 리커버리 방식으로, 특정 페이지에 수정이 일어난다면 페이지 자체를 복사해두고, 리커버리 요청이 오면 페이지를 완전히 바꿔치기하는 방식 => 현대의 디비는 크기가 너무 커서 불가능함
동시성 지원 또한 매우 어려움 -> 엄청 많은 shadow 가 생성되기 때문
데이터 클러스터링 불가 -> 연관된 데이터를 모아 저장
가벼운 텍스트 에디터에서 주로 사용
db_pointer 가 가장 최신의 copy 를 가리키는 포인터이며 db_pointer 가 가리키는 디비가 쿼리를 처리함
로깅 방식은 다음 글에..
'데이터베이스' 카테고리의 다른 글
[DB] 데이터베이스 버퍼 (0) 2021.04.25 [DB] Recovery 로깅 방식 (0) 2021.04.25 [DB] Isolation (0) 2021.04.25 [DB] 팬텀현상 (0) 2021.04.24 [DB] 데드락 (0) 2021.04.24