데이터베이스 장애에서 일관성을 복원하는 회복 기법

데이터베이스 장애 뒤 일관성과 무결성을 복원하는 Redo·Undo, 로그 갱신, 체크포인트, ARIES, 그림자 페이징의 작동 방식과 선택 기준을 정리한다.

2026-08-14 · 최초 발행 2025-08-10

장애가 트랜잭션 한가운데 끼어들었을 때

계좌이체 중 시스템이 멈추면 출금만 반영되고 입금은 남지 않는 상태가 생길 수 있다. 데이터베이스 회복은 이런 시스템 충돌, 정전, 하드웨어 오류, 소프트웨어 버그 뒤에 데이터베이스를 일관된 상태로 돌려놓는 과정이다.

핵심은 데이터 일관성(Consistency)과 무결성(Integrity)이다. 회복 과정은 트랜잭션의 원자성(Atomicity)을 지켜, 전체 작업이 완료됐거나 애초에 실행되지 않은 상태가 되도록 만든다. 시스템 장애뿐 아니라 트랜잭션 실패와 미디어 오류로부터 데이터를 보호하는 역할도 맡는다.

로그가 가르는 Redo와 Undo의 경계

Redo는 로그를 읽어 이미 커밋된 트랜잭션의 변경을 다시 실행하는 작업이다. 장애 직전에 커밋이 끝난 결과가 데이터베이스에 빠짐없이 반영되도록 보장한다. 로그 레코드를 분석하고, 커밋된 트랜잭션을 찾은 다음, 해당 작업을 재실행하는 순서로 진행된다.

반대로 Undo는 장애 시점까지 완료되지 않은 트랜잭션을 되돌린다. 커밋되지 않은 트랜잭션을 식별하고 변경사항을 역순으로 취소해 시작 상태로 복원한다. 이 둘을 어떻게 조합하는지가 회복 기법의 차이를 만든다.

갱신 시점에 따라 달라지는 로그 회복

즉시 갱신은 변경 전후를 모두 남긴다

즉시 갱신(Immediate Update)은 트랜잭션이 수행되는 동안 변경사항을 데이터베이스에 바로 반영한다. 로그에는 변경 전 이미지(Before Image)와 변경 후 이미지(After Image)를 함께 기록한다.

장애가 나면 커밋된 트랜잭션은 Redo로 다시 반영하고, 끝나지 않은 트랜잭션은 Before Image를 이용해 Undo한다. 일부 트랜잭션만 처리해 회복 시간을 단축할 수 있고 실시간 데이터 갱신으로 최신 상태를 유지한다는 장점이 있다. 대신 로그 오버헤드가 커지며, 실행 중 장애가 발생했을 때 복구 과정이 복잡해진다.

데이터베이스로그트랜잭션데이터베이스로그트랜잭션장애 발생 시변경 전 이미지(BI) 기록변경 즉시 반영변경 후 이미지(AI) 기록미완료 트랜잭션 Undo (BI 사용)커밋된 트랜잭션 Redo (AI 사용)

지연 갱신은 커밋까지 버퍼에 둔다

지연 갱신(Deferred Update)은 트랜잭션의 중간 결과를 버퍼에 유지하다가 커밋 시점에 데이터베이스에 반영한다. 로그에는 주로 변경 후 이미지를 기록한다.

데이터베이스에 미완료 변경이 남지 않으므로 장애 뒤에는 커밋된 트랜잭션만 Redo하면 되고 Undo는 필요하지 않다. 회복 절차와 로그 크기는 줄어들지만, 실제 데이터베이스 변경은 커밋까지 지연되며 대용량 버퍼가 필요하다.

데이터베이스로그버퍼트랜잭션데이터베이스로그버퍼트랜잭션커밋 결정장애 발생 시변경사항 버퍼에 임시 저장변경 로그 기록변경사항 DB에 반영커밋 로그 기록커밋된 트랜잭션만 Redo

체크포인트가 로그 탐색 범위를 줄이는 방식

체크포인트(Checkpoint)는 로그 기반 회복에서 중간 동기화 지점을 남기는 기법이다. 장애가 발생하면 전체 로그가 아니라 마지막 체크포인트 이후의 로그를 검사하게 해 회복 시간을 줄인다.

체크포인트를 만들 때는 시작 로그를 남기고, 수정된 버퍼 데이터를 디스크에 강제 기록한다. 이어 활성 트랜잭션 목록과 완료 로그를 기록한다. 회복 시간과 로그 공간 효율성은 좋아지며 오래된 로그도 삭제할 수 있다. 다만 체크포인트 수행 중 일시적인 성능 저하가 생기고, 간격 설정에는 트레이드오프가 따른다.

장애 발생분석 단계: 마지막 체크포인트위치 확인Redo 단계: 체크포인트부터EOF까지 로그 재실행Undo 단계: 커밋되지 않은트랜잭션 취소

ARIES는 Undo 작업까지 로그에 남긴다

ARIES(Algorithm for Recovery and Isolation Exploiting Semantics)는 IBM에서 개발한 고급 회복 알고리즘으로 현대 DBMS에서 널리 사용된다. 이 기법은 변경사항을 데이터베이스에 반영하기 전에 로그에 먼저 기록하는 Write-Ahead Logging(WAL), 장애 전 이력을 Redo에서 그대로 재현하는 방식, Undo 변경까지 로그에 남기는 원칙을 결합한다.

회복은 분석, Redo, Undo 단계로 이어진다. 분석 단계에서는 로그를 스캔해 활성 트랜잭션과 더티 페이지를 식별한다. Redo 단계는 로그 처음부터 끝까지 필요한 변경을 재실행하고, Undo 단계는 커밋되지 않은 트랜잭션을 역방향으로 취소하면서 로그도 기록한다.

Undo 중 다시 장애가 생겨도 처음부터 Undo를 반복할 필요가 없다는 점이 ARIES의 특징이다. Undo 과정 자체가 로그에 남기 때문에 재시작 지점을 이어갈 수 있다.

데이터베이스로그데이터베이스로그장애 발생분석 단계Redo 단계Undo 단계마지막 체크포인트 확인활성 트랜잭션 목록 생성LSN 기준으로 필요한 변경사항 재실행미완료 트랜잭션 역순으로 취소Undo 작업도 로그에 기록 (CLR)

그림자 페이징은 페이지 테이블을 교체한다

그림자 페이징(Shadow Paging)은 로그를 쓰지 않는 대안적 회복 방식이다. 현재 페이지 테이블(Current Page Table)과 그림자 페이지 테이블(Shadow Page Table)을 함께 유지한다.

트랜잭션이 시작되면 현재 테이블의 복사본을 그림자로 저장하고, 변경은 현재 테이블에만 적용한다. 커밋되면 현재 테이블을 새 그림자로 설정하며, 실패하면 그림자 테이블로 복원한다. 로그를 유지하지 않아도 되고 그림자 테이블로 교체하는 회복 절차가 단순하다. 반면 중복 페이지 때문에 공간 효율성이 떨어지고, 동시성 제어와 부분 롤백은 어렵다.

성공실패트랜잭션 시작현재 페이지 테이블 복사하여그림자 생성현재 테이블에만 변경 적용트랜잭션 완료?현재 테이블을 그림자로 설정그림자 테이블로 복원

회복 방식은 운영 조건과 함께 고른다

선택 기준은 회복 시간만이 아니다. 일반적으로 즉시 갱신은 회복 시간이 길고 지연 갱신은 회복이 빠르다. 중요 데이터에는 더 견고한 회복 메커니즘이 필요하며, 로그 기반 방식은 추가 I/O 부하를 동반한다.

그림자 페이징은 저장 공간을 더 요구한다. 높은 동시성이 필요한 환경에서는 로그 기반 방식이 유리하다. 성능 요구사항, 데이터 중요도, 시스템 부하, 저장 공간, 동시성 요구사항을 함께 봐야 한다.

제품과 서비스에서의 회복 구성

Oracle은 Redo 로그와 Archive 로그를 사용한 회복 메커니즘을 제공한다. 온라인 Redo 로그는 순환식으로 사용되고 아카이브 로그는 장기 보관되며, 시점 복구(Point-in-Time Recovery)를 통해 특정 시점으로 복원할 수 있다.

Amazon RDS는 자동 백업과 트랜잭션 로그를 결합한 회복 기법을 사용한다. 지정 시간 복구(Point-in-Time Recovery)를 지원하고, 다중 가용 영역(Multi-AZ) 배포로 즉각적인 장애 복구를 제공한다.

MongoDB는 복제셋(Replica Set)과 옵션 저널링 기능을 제공한다. 저널은 WAL 원칙을 따르며 40ms 간격으로 디스크에 기록한다. 장애가 발생하면 가장 최근 체크포인트부터 저널을 재생해 복구한다.

데이터베이스DB 회복ARIES체크포인트트랜잭션