데이터베이스 회복 기법: 로그·체크포인트·ARIES 운영 원리

장애 유형이 회복 설계를 결정한다

트랜잭션 오류, DBMS나 OS 문제, 저장 매체 손상, 화재·홍수·지진 같은 물리적 재해는 모두 데이터베이스의 일관성을 깨뜨릴 수 있다. 데이터베이스 회복은 이런 장애 뒤에 데이터를 일관된 상태로 복원하기 위한 DBMS의 메커니즘이다.

장애는 보통 다음 범주로 나뉜다.

트랜잭션 장애: 오버플로우, 데드락처럼 트랜잭션 실행 중 발생하는 오류
시스템 장애: 전원 이상이나 소프트웨어 버그에 따른 DBMS 또는 OS 장애
미디어 장애: 디스크 크래시, 헤드 충돌 등 저장 매체의 물리적 손상
자연 재해: 화재, 홍수, 지진으로 인한 물리적 파괴

회복 방식은 장애 원인과 손상 범위에 따라 달라진다. 따라서 데이터베이스 설계와 운영에서는 어떤 상태를 남기고, 어떤 순서로 되돌릴지를 미리 정해 두어야 한다.

트랜잭션의 원자성과 지속성을 지키는 장치

트랜잭션은 데이터베이스 상태를 바꾸는 논리적 작업 단위다. 회복 기법은 ACID 속성 가운데 특히 원자성(Atomicity)과 지속성(Durability)을 보장하는 데 직접 관여한다.

원자성: 트랜잭션의 모든 연산은 완전히 수행되거나 전혀 수행되지 않아야 한다.
일관성: 트랜잭션 전후에 데이터베이스는 일관된 상태를 유지해야 한다.
독립성: 동시에 수행되는 트랜잭션은 서로 영향을 주지 않아야 한다.
지속성: 성공적으로 끝난 트랜잭션의 결과는 영구적으로 반영돼야 한다.

장애가 발생했을 때 완료된 작업은 보존하고, 완료되지 않은 작업은 되돌리는 과정이 회복의 핵심이다.

로그를 남겨 변경 이력을 복구에 사용한다

로그 기반 회복은 데이터베이스 변경 사항을 로그 파일에 기록한 뒤, 그 이력으로 회복하는 방식이다. 로그 레코드에는 일반적으로 트랜잭션 식별자, 데이터 항목 식별자, 이전 값, 새 값, 그리고 BEGIN·COMMIT·ABORT·UPDATE 같은 로그 유형이 들어간다.

즉시 갱신은 트랜잭션 수행 중 변경 내용을 곧바로 DB에 반영한다. 이때 로그 레코드를 먼저 기록한 뒤 데이터를 갱신하는 WAL(Write-Ahead Logging)을 따른다. 장애가 나면 아직 완료되지 않은 변경을 취소하기 위한 UNDO 작업이 필요하다.

지연 갱신은 트랜잭션이 끝날 때까지 변경 내용을 임시 영역에 저장하고, COMMIT 때만 DB에 반영한다. 이 방식에서는 장애 발생 시 UNDO가 필요하지 않고 REDO만 수행한다.

⤢✕

체크포인트로 로그 탐색 범위를 줄인다

장애가 발생할 때마다 전체 로그를 검사하면 회복 비용이 커진다. 체크포인트는 이 부담을 줄이기 위해 일정 시점의 상태를 로그와 디스크에 반영하는 방식이다.

체크포인트를 설정할 때는 로그에 CHECKPOINT 레코드를 기록하고, 실행 중인 트랜잭션 목록을 포함하며, 버퍼 내용을 디스크에 강제 기록(flush)한다. 회복 시에는 체크포인트 이전에 COMMIT된 트랜잭션은 별도 작업이 필요 없고, 이후 COMMIT된 트랜잭션은 REDO 대상이 된다. 끝나지 않은 트랜잭션은 UNDO해야 한다.

⤢✕

그림자 페이지 테이블로 이전 상태를 보존한다

그림자 페이징(Shadow Paging)은 로그를 쓰지 않고 회복하는 방식이다. 현재 페이지 테이블과 그림자 페이지 테이블, 두 버전을 함께 유지한다.

트랜잭션이 시작되면 현재 페이지 테이블을 그림자 페이지 테이블로 복사한다. 변경은 현재 페이지 테이블에만 반영한다. COMMIT하면 그림자 페이지 테이블을 삭제하고, ABORT하면 현재 페이지 테이블을 그림자 페이지 테이블로 대체한다.

이 방식은 그림자 페이지 테이블로 전환하면 되므로 회복이 빠르고 로그 기록이 필요 없다는 장점이 있다. 반면 저장 공간 효율성이 떨어질 수 있으며, 다중 트랜잭션 환경에서는 복잡해진다.

⤢✕

ARIES는 이력을 재실행한 뒤 미완료 작업을 되돌린다

ARIES(Algorithm for Recovery and Isolation Exploiting Semantics)는 IBM에서 개발한 고급 회복 기법이며, 현대 DBMS에서 널리 사용된다.

ARIES는 세 가지 원칙을 따른다.

WAL(Write-Ahead Logging): 데이터 페이지가 디스크에 기록되기 전에 로그 레코드가 먼저 기록돼야 한다.
반복 이력(Repeating History): 회복 과정에서 장애 이전의 모든 작업을 다시 실행한다.
로깅 언두(Logging Undo): 언두 작업도 로그에 기록한다.

회복은 분석(Analysis), REDO, UNDO 단계로 진행된다. 분석 단계에서는 로그를 스캔해 장애 시점의 활성 트랜잭션을 식별한다. REDO 단계에서는 필요한 작업을 재실행하고, UNDO 단계에서는 완료되지 않은 트랜잭션을 롤백한다.

LSN(Log Sequence Number)은 각 로그 레코드에 부여되는 고유 식별자다. 페이지에도 LSN을 유지해 해당 페이지의 최신 갱신 상태를 추적한다. ARIES는 높은 동시성과 효율적인 회복이 필요한 대규모 데이터베이스 시스템에 적합하다.

분산 트랜잭션은 두 단계 커밋으로 확정한다

분산 데이터베이스에서는 여러 참여자가 하나의 트랜잭션에 관여하므로 회복 과정도 복잡해진다. 2단계 커밋(Two-Phase Commit) 프로토콜은 분산 트랜잭션의 원자성을 보장하는 데 사용된다.

준비 단계(Prepare Phase)에서 코디네이터는 모든 참여자에게 PREPARE 메시지를 보낸다. 참여자는 트랜잭션 수행 가능 여부를 결정해 응답한다. 커밋 단계(Commit Phase)에서는 모든 참여자가 YES로 응답했을 때 COMMIT 메시지를 보내고, 하나라도 NO를 응답하면 ABORT 메시지를 보낸다. 참여자는 최종 결정에 따라 트랜잭션을 끝낸다.

⤢✕

Oracle이 제공하는 회복 메커니즘

Oracle DBMS는 회복에 필요한 구성 요소를 제공한다.

Redo 로그는 데이터베이스 변경 사항을 기록하는 로그 파일이다. 온라인 Redo 로그는 현재 활성화된 로그이고, 아카이브 Redo 로그는 보관용으로 저장된 이전 로그다.

Undo 세그먼트는 트랜잭션의 이전 상태 정보를 보관한다. 롤백에 사용되며 읽기 일관성을 제공하는 데도 활용된다.

체크포인트는 더티 버퍼를 주기적으로 디스크에 기록하며, DBWR(Database Writer) 프로세스가 수행한다.

복구 관리자(RMAN)는 백업과 복구를 관리하는 도구다. 증분 백업과 블록 레벨 복구 기능을 지원한다.

Flashback 기술은 특정 시점으로 데이터를 복원하는 데 사용된다.

Flashback Query: 과거 데이터 조회
Flashback Table: 테이블 단위 복원
Flashback Database: 전체 DB 복원

백업과 복구 계획을 함께 운영한다

회복 기법만으로 장애 대응 체계가 완성되지는 않는다. 데이터베이스 관리자는 백업, 로그, 대기 시스템, 복구 목표, 테스트를 함께 설계해야 한다.

백업은 전체 데이터베이스를 복사하는 전체 백업, 변경된 부분만 저장하는 증분 백업, 마지막 전체 백업 뒤 변경된 모든 내용을 저장하는 차등 백업으로 나눌 수 있다.

로그 관리에서는 로그 순환 정책을 세우고 아카이브 로그 보관 기간과 로그 볼륨을 관리한다. 재해 복구 측면에서는 실시간으로 동기화된 핫 스탠바이(Hot Standby), 주기적으로 동기화되는 웜 스탠바이(Warm Standby), 백업에서 복구해야 하는 콜드 스탠바이(Cold Standby)를 선택할 수 있다.

RTO는 서비스 중단 뒤 복구까지 허용 가능한 시간이고, RPO는 허용 가능한 데이터 손실 범위다. 복구 절차가 실제로 유효한지 확인하고 팀의 복구 능력을 유지하려면 정기적인 복구 테스트도 필요하다.