ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [DB] 트랜잭션의 장애와 복구
    database/DB Concept 2021. 11. 25. 12:36

    트랜잭션의 장애와 복구


     

     

    트랜잭션 장애와 복구


    트랜잭션 동작 시 장애가 발생하면 어떻게 해야 할까. 보통 로그를 통한 복구를 진행하게 된다. 복구 방법으로 REDO 복구와 UNDO 복구가 있다. DBMS는 어떻게 복구를 해야할지 판단한 후 REDO와 UNDO를 통해 복구를 진행하게 된다.

     

     

     

    DBMS의 페이지 버퍼


    데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장하며 전체 데이터베이스의 일부분을 메인 메모리에 유지한다.

    DBMS는 데이터를 고정 길이의 페이지(page)로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력이 이루어진다.

    메인 메모리에 유지하는 페이지들을 관리하는 모듈을 보통 페이지 버퍼(page buffer) 관리자 또는 버퍼 관리자라고 부르는데, DBMS의 많은 주요 모듈 중에서 매우 중요한 모듈 중의 하나이다.

    DBMS는 각 제품마다 구조가 다르기는 하지만, 크게 질의 처리기(Query Processor) 저장 시스템(Storage System)으로 나눠볼 수 있다.

     

     

     

    UNDO의 필요성


    오퍼레이션 수행 중에 수정된 페이지들이 버퍼 관리자의 버퍼 교체 알고리즘에 따라서 디스크에 출력될 수 있다. 다음과 같은 2가지 정책이 있다.

    • STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책 ✔️
    • -STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책

     

    -STEAL 정책의 경우 트랜잭션 종료 전에 수정된 페이지들을 디스크에 쓰지 않는다면, 장애 발생 시 디스크 페이지에 반영되지 않아 로그 파일을 토대로 재실행 하여 해결 할 수 있다. 이 부분은 매력적이지만 이 정책은 매우 큰 크기의 메모리 버퍼가 필요하다는 문제점을 가지고 있다.

     

    그렇다보니 대부분의 DBMS는 STEAL 버퍼 관리 정책을 선택한다. 트랜잭션 시 변경 사항을 로그에 기록하며, 디스크 페이지에 변경사항을 적용하게 된다. 즉 장애 발생으로 트랜잭션이 중단 되면 아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있는 문제가 생긴다. 이를 해결 하기 위해 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션의 원자성(Atomicity)에 근거하여 변경한 페이지들은 원상 복구되어야 한다. STEAL 정책은 수정된 페이지가 어떠한 시점에도 디스크에 써질 수 있기 때문에 장애 발생시 트랜잭션의 원자성을 해치게 된다. 

     

    위에서 말한 복구가 UNDO(뜻:원상태로 되돌리다)라고 한다. UNDO복구는 UNDO로그를 역순으로 실행하여 원상태로 복구하게 된다.

     

     

    REDO의 필요성


    REDO 복구는 UNDO 복구의 반대 개념이다. 커밋한 트랜잭션의 수정은 어떤 경우에도 지속(durability)되어야 한다. 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 하는데, REDO 복구 역시 UNDO 복구와 마찬가지로 버퍼 관리 정책에 영향을 받는다. 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에도 쓸 것인가 여부로 두 가지 정책이 구분된다.

    • FORCE: 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
    • -FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책 ✔️

     

    여기서 주의 깊게 봐야 할 부분은 -FORCE 정책이 수정했던 페이지(데이터)를 디스크에 반영하지 않는다는 점이다. (어떤 일들을 했었다고 하는 로그는 기록하게 되다.)

    FORCE 정책을 따르면 트랜잭션이 커밋되면 수정되었던 페이지들이 이미 디스크 상의 데이터베이스에 반영되었으므로 REDO 복구가 필요 없게 된다. 반면에 -FORCE 정책을 따른다면 커밋한 트랜잭션의 내용이 디스크 상의 데이터베이스 상에 반영되어 있지 않을 수 있기 때문에 반드시 REDO 복구가 필요하게 된다.

     

    트랜잭션에 대한 로그가 모두 기록되었으나 트랜잭션이 완료 되는 순간 장애가 발생하는 경우 REDO복구를 통해 복구를 진행 할 수 있다.

     

     

    (그러면 디스크 반영은 언제 하는 거쥬? 아시는 분 댓글 좀 ㅎㅎ.. )

     

    로그


    UNDO 복구와 REDO 복구를 위해서 가장 널리 쓰이는 구조는 보편적으로 사용되는 기법은 로그(log)이다. DBMS에서 사용되는 3가지 로깅 방법이다.

     

    물리적인 상태 로깅(physical state logging)

    이 방법은 DBMS에서 가장 널리 쓰이는 기본적인 로깅 방법이다.

    갱신 이전 이미지와 이후 이미지를 모두 다 가지고 있으며, UNDO 복구 때에는 이전 이미지로 현재 이미지를 대체하며, REDO 복구 때에는 이후 이미지를 반영하는 방식으로 복구가 이루어진다. 물리적인 상태 로깅은 이전 이미지 혹은 이후 이미지로 단순히 대체하는 작업으로 이해하면 된다. 

     

    물리적인 전이 로깅(physical transition logging)

    이 방법은 페이지 혹은 레코드에 대해서 XOR 차이점을 기록하는 방식으로 이루어진다. 복구 시점에서 로그 레코드에 기록된 XOR 이미지와 레코드 이미지를 이용하여 UNDO 복구와 REDO 복구를 수행하게 된다.

     

    논리적인 전이 로깅(logical transition logging)

    이 방법은 오퍼레이션 로깅(operation logging)으로도 불리는데, 어떤 일을 했었는가를 기록하는 방식이다. 예를 들어, a = a + 1과 같은 연산을 로깅할 때 이전 값 0, 이후 값 1을 물리적으로 기록할 수도 있고, a = a + 1 이라는 연산 그 자체를 기록할 수 있다. 이러한 논리적인 로그에 대한 복구 작업은 REDO를 위하여 로그 레코드에 기록된 오퍼레이션을 재수행하거나, UNDO를 위하여 역 오퍼레이션을 수행하는 방식으로 이루어진다.

     

    Post


    References


    댓글