[HUFS/데이터베이스] #17 회복

장애와 회복

장애란 시스템이 정해진 명세대로 작동하지 않는 상태이며,

장애의 원인으로는 ‘하드웨어 결함 / 소프트웨어의 논리오류 / 사람의 실수’ 등이 있다

 

트랜잭션 장애: 논리적 오류 입력 데이터의 불량

• 시스탬 장애: 하드웨어의 오동작
• 미디어 장애: 디스크 헤드 붕괴 또는 고장

 

회복(Recovery)이란 DB를 장애 발생 이전의 일관된 상태로 복원시키는 것으로,

일관된 상태(consistent state)란 오류가 없고 DB 내용에 모순이 없는 상태이다.

 

회복의 기본 원리는 데이터를 중복(redundancy)으로 기록하는 것이며,

다른 저장장치에 그대로 복제는 덤프(dump) 방식이나

데이터 파일의 변경된 부분만 별도의 파일에 기록하는 로그(log, journal) 방식을 사용할 수 있다

 

회복을 위한 조치는

가장 최근 복제본에 로그를 적용해 DB를 복원하는 REDO 방식과

로그 및 모든 변경들을 취소해 DB를 복원하는 UNDO 방식이 있다

 

이처럼 물리적으로 다른 위치에 DB의 복제본을 저장해두는 것이 이중데이터베이스 시스템이다

 

각 DB가 물리적으로 떨어져 있으며 서로 실시간 복제된다

DBMS의 회복관리자 모듈이 DB의 모든 장애를 탐지하고 복원시킬 수 있어야 한다

손상된 부분만 최소의 범위로 최단시간 내 트랜잭션 기반 회복을 진행한다

* 간단한 수준의 회복은 로그 기반으로 자동으로 이루어진다

저장장치와 트랜잭션

데이터베이스 저장장치의 타입은 속도, 용량, 장애시의 탄력성에 따라 다음과 같이 나뉜다

• 소멸 저장장치(volatile storage): 전원이 차단되면 상실되는 메인 메모리(DRAM)
• 비소멸 저장장치(nonvolatile storage): 디스크나 테이프, CD 등 전원이 차단되어도 지워지지 않음
• 안정 저장장치(stable storage): 데이터 손실을 막기 위해 여러 비소멸 저장장치로 백업된 저장장치

 

DBMS의 저장 구조: 온라인 데이터베이스와 로그를 활용한 DBMS의 회복이 각 버퍼를 통해 가능

데이터베이스 저장연산 (버퍼관리자가 I/O 관리)

트랜잭션이란 데이터베이스가 각 일관된 상태로 전이될 때의 연산자 시퀀스이다.

다음 조건 ACID를 모두 만족할 때, 트랜잭션이라고 할 수 있다

1. 원자성(atomicity): 다 실행되거나 다 실행되지 않아야 함(전부 or 전무)
2. 일관성(consistency): DB가 트랜잭션 전후로 일관된 상태 유지
3. 격리성(isolation): 트랜잭션 동작 도중 중간 결과와 독립적으로 작동
4. 영속성(durability): 트랜잭션이 성공적이면 그 결과는 영속적 (commit 반영)

트랜잭션(회복의 논리적 단위)의 원자성을 위한 두 가지 연산

Commit(완료): 트랜잭션의 성공적 실행 후 일관성을 유지하는 영구적 갱신, 영속성 보장

Rollback(복귀): 트랜잭션 실패 후 모순을 되돌리기 위해 수행한 모든 연산 UNDO

* 실패한 트랜잭션은 Rollback 후에 재시작하거나 일반적으로는 폐기한다

 

디스크 블록을 메인 메모리 버퍼로 가져오기 위한 Input/Output

• 원위치 갱신: 디스크 블록의 정보를 가져와 변경 후 다시 블록에 Overwrite, 주로 사용되는 방식
• 간접 갱신: 디스크 블록의 정보를 가져와 변경 후 새로운 블록에 Write

* 따라서 간접 갱신의 경우 DB 블록과 실제 블록의 물리적 번호가 일치하지 않아 mapping 필요

 

트랜잭션 상태

계좌 A에서 계좌 B로 100원 이체하는 프로그램(하나 이상의 트랜잭션 포함) 예시

로그(log, journal)는 온라인 로그(디스크)와 보관 로그(테이프)로 나뉘며, 트랜잭션의 실행과 변경 사항, commit과 rollback 등이 기록된다.

 

디스크(온라인)에 기록된 거대한 DB와 로그를 주기적으로 테이프(보존)에 백업해 회복에 활용

회복할 때, 해당 상태 이후 성공한 트랜잭션의 로그만 Redo를 통해 적용한다.

* 하나의 데이터 아이템이 그 사이 여러 번 갱신되었다면 마지막 데이터 값만 필요 (중간과정 X)

지연 갱신과 즉시 갱신

지연 갱신이란 commit 전까지 입력된 연산을 대기하다가 commit 후에 연산을 시행하는 것이다

입력된 연산은 REDO 연산에 대비해 로그 레코드로 기록되었다가 commit 후 DB에 갱신된다

즉, REDO 연산은 로그를 이용해 commit의 정보 손실 장애를 처리하는 것이다

* REDO 연산은 idempotent 성질을 가져 여러 번 실행해도 결과가 동일

 

commit이 완료된 트랜잭션만 시간 순으로 REDO

* 트랜잭션을 버퍼를 통해 병렬적으로 실행하는 지연 갱신은 버퍼 용량 문제로 실용성이 떨어진다

 

즉시 갱신이란 commit되지 않은 트랜잭션 블록도 output을 통해 디스크에 기록하는 방식이다

이 때, 디스크에 기록된 commit되지 않은 데이터에 대해서 Undo 연산이 필요하다

* DB는 일반적으로 즉시 갱신과 검사시점 회복 방식을 사용한다!

 

Undo 프로시저 연산도 idempotent 성질을 가지며 안정 저장소에 기록 후 output

commit되지 않은 것은 Undo 후에 commit된 것을 Redo

검사시점 회복과 그림자 페이징 기법

Redo와 Undo 트랜잭션 결정을 위해 로그 전체를 검사하는 시간이 너무 길 수 있는데,

검사시점(checkpoint) 회복을 통해 정기적으로 기록된 검사시점까지만 검사할 수 있다

* Undo연산을 수행하는 후진 회복 / Redo 연산을 수행하는 전진 회복

 

불필요한 Redo 생략 및 정기적 검사시점 이후만 다뤄 검사 및 회복 속도가 빨라진다

그림자 페이징(Shadow Paging) 기법은 두 테이블을 활용해 로그를 사용하지 않는 방식으로,

DB에 사용되지는 않지만 다양한 시스템에 응용된다

 

그림자 페이지 테이블 / 현 페이지 테이블 (트랜잭션 실행 중에는 현 페이지 테이블만 사용)

디스크 페이지의 변화를 다른 칸에 저장한 후 현 페이지 테이블이 가리키게 함

commit 되면 현 페이지 테이블을 그림자 페이지 테이블로 복사한 후 해당 테이블을 현 페이지 테이블로 사용! (장애가 발생하면 다시 두 위치를 변경만 하면 되니까 간단, Redo 연산 X)

 

장점: 로그를 사용하지 않기에 로그 레코드를 출력하는 오버헤드가 없다 (디스크 접근 횟수 감소),

Undo 연산이 매우 간단하고 Redo 연산이 필요 없다 (장애로부터 신속한 회복)

단점: 커밋 오버헤드 / 데이터 단편 / 쓰레기 수집 / 병행 트랜잭션 지원 불가

미디어 회복, WAL, 2PL

비소멸성 저장 장치의 내용이 손상되는 경우(디스크 붕괴)를 대비해 주기적 덤프 시행

1. 메인 메모리의 모든 로그 레코드를 안정 저장소에 출력
2. 변경된 버퍼 블록들을 모두 디스크에 출력
3. 데이터베이스의 내용을 안정 저장장치에 복사
4. 로그 레코드 <dump>를 안정 저장소에 출력시켜 덤프를 표시
5. 회복할 때는 가장 최근 덤프를 이용해 디스크에 DB 적재
6. 로그를 이용해 덤프 이후 완결된 트랜잭션들 재실행(Redo)

즉시 갱신하는 경우, 로그는 로그 우선 기록 규약(WAL: write-ahead log protocol)을 따른다

 

디스크 성능을 위한 로그 레코드 버퍼링 규칙 (로그를 버퍼에 기록)

DB가 버퍼를 관리하는 2가지 방안 (DBMS 직접관리 or 운영체제 가상 기억장치)

 하나의 글로벌 트랜잭션이 여러 개의 DB에 접근할 때, 2-레벨 회복 기법을 따른다

 

전역 회복 관리자(조정자)와 지역 회복 관리자(참여자) 사이의 규약