DB 데이터베이스 - 장애와 회복(그림자 페이징, 로그 기반 복구)

1. 장애와 회복

- 장애(failure) : 정해진 명세대로 시스템이 작동하지 않는 상태

- 회복(recovery) : 장애(failure)로 인해 손상된 데이터베이스를 손상되기 이전의 정상적인 상태(consistent state)로 복구시키는 작업

- 회복의 주요기법은 장애가 일어나기 전에 데이터베이스의 내용을 주기적으로 덤프해 보관하고, 덤프 이후의 데이터베이스에 대한 변동 사항은 로그에 기록해 두는 것

 

2. 장애의 유형

2-1) 트랜잭션 실패(transaction failure)
논리적 오류(logical errors) : 내부 오류 조건으로 인해 트랜잭션이 완료될 수 없는 상황
시스템 오류(system errors) : 에러(예: 교착 상태)로 인해 데이터베이스 시스템이 활성 트랜잭션을 종료해야 하는 경우
2-2) 시스템 장애(system failure/crash)
휘발성 저장소의 내용 손실: 전원 장애나 다른 하드웨어 또는 소프트웨어 오류로 인해 시스템이 다운
실패 정지 가정: 비휘발성 저장소의 내용은 시스템 장애에 의해 손상되지 않는다고 가정
2-3) 디스크 장애(disk failure)
디스크 헤드 붕괴나 디스크 제어기 고장으로 인해 저장 장치의 데이터베이스 일부 또는 전부가 손상된 상태
디스크 드라이브는 체크섬을 사용하여 장애를 감지

 

3. 데이터 베이스 복구 방법 (그림자 페이징, 로그 기반 복구)

3-1) 그림자 페이징(shadow-paging) 

그림자 페이징 방식에는 데이터베이스의 변경 사항을 적용하기 전에 현재 데이터베이스의 복사본을 만든다. 이 복사본을 "섀도우(그림자)"라고 하며, 시스템에 문제가 발생했을 때 이 그림자를 사용하여 데이터베이스를 복구한다. 원본 데이터는 수정되기 전 상태로 유지되며, 모든 수정 사항이 성공적으로 적용되면 이 섀도우가 새로운 "진짜" 데이터베이스로 교체된다.

 

작동 방식

1. 모든 업데이트는 데이터베이스의 그림자 복사본에서 수행된다.

2. 트랜잭션이 부분적으로 커밋되고 모든 업데이트된 페이지가 디스크에 플러시된 후, "DB_pointer"는 업데이트된 그림자 복사본을 가리킨다.

3. "DB_pointer"는 항상 데이터베이스의 현재 일관된 복사본을 가리킨다. 만약 트랜잭션이 실패할 경우, "DB_pointer"가 가리키는 이전의 복사본을 사용할 수 있으며 그림자 복사본은 삭제될 수 있다.

예를 들어, active 상태인 트랜잭션 T1 있다고 가정하자. 디스크에는 현재 데이터베이스를 가리키는 Db_pointer라는 포인터가 유지되고 있다. 데이터베이스를 업데이트하려는 트랜잭션 T1은 먼저 데이터베이스의 완전한 복사본을 생성한다. 모든 후속 작업은 새로운 복사본에서 수행되며, 원래의 복사본은 그대로 두게 된다.
트랜잭션이 중단되면, 시스템은 새로운 복사본을 삭제하고, 오래된 복사본은 영향을 받지 않고 그대로 유지된다.
트랜잭션 T1이 성공하면, OS는 새로운 데이터베이스 복사본의 모든 페이지가 디스크에 쓰여지도록 한다. 데이터베이스 시스템은 Db_pointer를 업데이트하여 새로운 데이터베이스 복사본을 가리키도록 한다. 이제 새로운 복사본이 데이터베이스의 현재 복사본이 되며, 이전 복사본은 삭제된다. 트랜잭션 T1은 업데이트된 Db-pointer가 디스크에 쓰여지면 커밋된 것으로 간주된다.

 

원자성(Atomicity) 유지 방법
트랜잭션 T1이 Db_pointer 업데이트 전에 실패하면, 오래된 데이터베이스 내용은 영향을 받지 않는다. 트랜잭션 T1의 중단은 새로운 복사본을 삭제함으로써 이루어질 수 있다. 따라서 모든 변경 사항이 반영되거나 하나도 반영되지 않는다.

지속성(Durability) 유지 방법 
시스템이 업데이트된 포인터가 디스크에 쓰여지기 전에 실패했다고 가정해보자. 시스템이 다시 시작되면, 데이터베이스 포인터(Db_pointer)를 읽으려고 시도하고, 데이터베이스의 원래 내용을 보게 된다. 트랜잭션 T1의 영향은 보이지 않는다. 트랜잭션 T1은 Db_pointer가 업데이트될 때만 성공한 것으로 가정된다. 시스템이 Db_pointer 업데이트 후에 실패하면 그 이전에 새로운 복사본의 모든 페이지가 디스크에 쓰여진 상태가 된다. 따라서 시스템이 다시 시작되면 새로운 데이터베이스 복사본을 읽는다.

 

그림자 페이징은 트랜잭션의 원자성과 지속성을 지원하는 매우 간단한 기술이다. 장단점은 아래와 같다.

장점

1. 동시 트랜잭션 처리 어려움 : 여러 동시 트랜잭션이 있을 경우, 너무 많은 shadow(복사본)를 관리해야 하기 떄문에 효율적 처리가 어렵다.

2. 대용량 데이터베이스에 매우 비효율적 : 그림자 페이징은 대규모 데이터베이스에 적합하지 않다. 데이터 클러스터링이 불가능하며, 데이터의 복사를 줄이는 섀도우 페이징의 변형이 있긴 하지만 여전히 큰 데이터 베이스에는 실용적이지 않다.

장점

텍스트 편집기에 유용 : 그림자 페이징은 간단한 어플리케이션에서 유용하게 사용된다. 과거 데이터베이스 시스템에서도 사용되었지만, 현재는 대부분의 데이터베이스 시스템에서 더 효율적인 기술을 사용한다.

 

 

3-2) 로그 기반 복구(log-based recovery)

이 방법은 시스템의 변경 사항을 데이터베이스에 적용하기 전에 안정적인 저장소(ex) 하드 드라이브)에 로그 형태로 먼저 기록한다. 이 로그에는 수정된 내용에 대한 정보가 포함되어 있으며, 시스템이 실패한 경우 이 로그를 사용하여 데이터베이스를 이전 상태로 복구할 수 있다.

 

단순 로깅 : DBMS에서 트랜잭션의 무결성과 복구 가능성을 보장하는 핵심적 기술

단순 로깅 작동 방식

1. 안정적인 저장소에 로그 유지 : 로그는 안정적인 저장 장치에 유지된다. 이 로그는 데이터베이스에 이루어진 모든 업데이트를 문서화하는 로그 레코드의 순차적 목록이다.

2. 트랜잭션 시작 : 트랜잭션(Ti)이 시작될 때 '<Ti start>' 로그 항목을 기록하여 로그에 트랜잭션 시작을 알린다.

3. 데이터베이스 쓰기전 로그 레코드 작성

트랜잭션 Ti가 데이터 항목 X에 쓰기 작업을 수행하기 전에 '<Ti, X, V1, V2>' 로그 레코드를 작성한다. 

V1 : 쓰기 작업 전 X의 값, V2 : 쓰기 작업 후 X의 값 

<Ti, X, V1, V2> : 트랜잭션 Ti가 X를 V1에서 V2로 변경했음을 보여주는 로그 레코드

4. 트랜잭션 커밋

모든 작업을 완료한 후, 트랜잭션 Ti는 데이터베이스에 트랜잭션의 모든 변경 사항을 커밋할 수 있다는 것을 나타내는 <Ti commit> 레코드를 로그에 작성한다.

 

단순 로깅 특징

1. 동시성 

여러 트랜잭션이 동시에 운영될 수 있다. 모든 트랜잭션은 동일한 디스크 버퍼와 로그를 사용하며, 이는 버퍼 블록이 여러 트랜잭션에 의해 업데이트되는 데이터 항목을 포함할 수 있음을 의미한다.

2. 동시성 제어 (feat : Strict-2PL)

동시성 제어를 위해 엄격한 2단계 잠금 규약을 따른다. 즉, 커밋되지 않은 트랜잭션의 영향이 다른 트랜잭션에 보이지 않도록 한다.

그렇지 않다면, 트랜잭션 T1이 데이터 항목 X를 업데이트한 후 트랜잭션 T2가 X를 업데이트하고 커밋하고, T1이 나중에 중단해야 하는 경우, T1의 변경 사항을 T2의 커밋된 변경 사항을 방해하지 않고 취소할 수 있는 방법이 시스템에 있어야 한다.

3. 로그 구조

다른 트랜잭션의 로그 레코드가 로그 내에서 섞일 수 있다. 따라서, 시스템 복구 절차 중에 각 로그 항목을 적절한 트랜잭션과 정확하게 연결하기 위해 로그를 세심하게 관리해야 한다. 

 

1. 단순 로깅 시스템 회복 절차의 문제점
로그 전체를 검색하는 것은 시간이 많이 소요된다.
이미 데이터베이스에 업데이트를 출력(output)한 트랜잭션을 불필요하게 다시 실행(redo)할 수 있다.
2. 회복 절차 간소화
회복 절차를 간소화하기 위해 주기적으로 체크 포인트를 수행

3. 체크포인트 과정
1. 주 메모리에 있는 모든 로그 레코드를 안정적인 저장소로 출력한다. (all log records) main emeory ==output  => stable storage(disk)
2. 수정된 모든 데이터 버퍼 블록을 디스크로 출력한다. (all modified data buffer blocks) buffer == output ==> stable storage(disk)
3. <checkpoint L> 로그 레코드를 안정적인 저장소에 작성한다. 여기서 L은 체크포인트 시점에서 활동 중인 트랜잭션들의 목록이다.

 

단순 로깅 크래시 발생시 복구 프로세스

1. 복구 준비
“undo-list”와 “redo-list”를 비어 있는 상태로 초기화합니다.
로그를 끝에서부터 거꾸로 스캔하면서 첫 번째 <checkpoint L> 레코드를 찾을 때까지 진행

거꾸로 스캔하는 동안 발견된 각 레코드에 대해서
- 레코드가 <Ti commit>인 경우, Ti를 “redo-list”에 추가
- 레코드가 <Ti start>인 경우, Ti가 “redo-list”에 없다면 Ti를 “undo-list”에 추가
L에 있는 모든 Ti에 대해, Ti가 redo-list에 없으면 Ti를 “undo-list”에 추가 (L : 체크 포인트 시점 활동 중인 트랜잭션 목록)
2. 리스트 구성
이 시점에서 “undo-list”는 완료되지 않은 트랜잭션들을 포함하고 있으며 이들은 취소되어야 합니다.
“redo-list”는 완료된 트랜잭션들을 포함하고 있으며 이들은 다시 실행되어야 합니다.
3. 로그 스캔 및 작업 실행
로그를 가장 최근 레코드부터 거꾸로 스캔하며, undo-list에 있는 모든 Ti의 <Ti start> 레코드를 만날 때까지 계속합니다.
이 스캔 동안, undo-list에 속한 트랜잭션의 각 로그 레코드에 대해 취소 작업(undo)을 수행합니다.
가장 최근의 <checkpoint L> 레코드를 찾습니다.
<checkpoint L> 레코드부터 로그 끝까지 로그를 순방향으로 스캔합니다.
이 스캔 동안, redo-list에 있는 트랜잭션의 각 로그 레코드에 대해 재실행 작업(redo)을 수행합니다.

 

단순 로깅 트랜잭션의 처리 예시 1

 

체크포인트로 인해 디스크에 이미 출력된 업데이트를 가진 트랜잭션(T1)은 회복 절차에서 무시

트랜잭션(T2와 T3)은 다시 실행(redo)
완료되지 않고 중단된 트랜잭션(T4)은 취소(undo)

 

단순 로깅 트랜잭션 처리 예시 2

로그 분석

<T0 start>
<T0, A, 0, 10>
<T0 commit> /* 체크포인트 이전에 커밋되었으므로 T0은 복구 후 언두 또는 리두 리스트에 포함될 필요가 없다. */
<T1 start>  /* UNDO goes up here */
<T1, B, 0, 10> /* T1 변수 B를 0에서 10으로 업데이트, T1은 체크포인트 시점까지 커밋되지 않았으므로 undo_list에 추가*/ 
<T2 start> 
<T2, C, 0, 10> /*T2 : 변수 C를 0에서 10으로 첫 업데이트함*/
<T2, C, 10, 20>  /* T2 : 변수 C를 10에서 20으로 두 번째 업데이트함 */

/* T2도 체크포인트 시점까지 커밋되지 않았으므로 undo_list에 포함 */

<checkpoint {T1, T2}> /* REDO from here to the end */

<T3 start>
<T3, A, 10, 20> /* T3 : 변수 A를 10에서 20으로 두 번째 업데이트함 */
<T3, D, 0, 10> /* T3 : 변수 D를 0에서 10으로 첫 번째 업데이트함 */
<T3 commit> /* T3는 체크포인트 이후에 커밋되었으므로 redo_list에 추가 */

 

undo_list = {T1, T2}

redo_list = {T3}

언두 과정
undo_list에 있는 트랜잭션들(T1과 T2)은 크래시 이전에 커밋되지 않았으므로 데이터베이스의 일관성을 유지하기 위해 취소되어야 한다. 
T1에 의해 B가 0에서 10으로 변경된 업데이트와 T2에 의해 C가 0에서 10, 그리고 10에서 20으로 변경된 업데이트가 역순으로 진행된다.
리두 과정
redo_list에 있는 트랜잭션(T3)은 성공적으로 커밋되었지만 크래시 전에 완전히 지속되지 않았을 수 있으므로 다시 실행해야 한다.
T3에 의해 변경된 A와 D에 대한 업데이트를 다시 적용하여 커밋된 변경 사항이 손실되지 않도록 한다.

결론
로그에 있는 체크포인트는 복구 시 로그를 스캔해야 하는 범위를 제한함으로써 복구 시간을 줄이는 데 도움이 된다. 언두 작업은 완료되지 않은 트랜잭션의 영향을 제거함으로써 데이터베이스를 일관된 상태로 되돌리는 데 필요하며, 리두 작업은 커밋된 트랜잭션의 영향을 재적용하여 커밋된 데이터가 손실되지 않도록 보장한다.

 

 

 

 

 

 

 

 

 

 

참고 자료 

https://www.geeksforgeeks.org/how-to-implement-atomicity-and-durability-in-transactions-in-dbms/

How to Implement Atomicity and Durability in Transactions in DBMS? - GeeksforGeeks