Project6

Log Management

이번 프로젝트는 Analysis-Redo-Undo 3단계로 이루어진 복구 알고리즘을 구현하는 것이 목적이다.
이는 DB에 crash가 일어나도 중요한 덕목인 Atomicity와 Durability가 지켜줄 수 있도록하게 해준다.
Logging을 통해 복구 알고리즘을 구현한다. 로그란 redo/undo 단계를 위한 순서가 존재하는 DB의 기록물이다.
모든 변경사항이 발생한 이후에는 로그 버퍼에 로그가 만들어지고 로그의 타입으로는 commit, update, rollback, begin, compensate가 있다.
WAL(write ahead logging)을 위해 두가지 원칙이 지켜진다.
하나는 undo를 위해 해당 데이터 페이지가 디스크에 도달하기 전 로그버퍼에 존재하는 변경사항과 관련된 로그 레코드를 로그 파일로 강제로 내린다.
다른 하나는 redo를 위해 commit 전 버퍼에 올라와있는 로그 레코드가 온전히 전부 파일로 내려가기 전에는 commit이 완료되지 않는다.
crash 이후 recovery가 시작되면 파일에 저장된 로그들을 읽어와서 DB를 복구한다.

이 단계에서는 redo/undo pass로 들어가기 전에 loser/winner를 구분해내는 단계이다.
winner란 begin이 된 txn 중에서 commit또는 abort가 온전히 실행되어 undo pass에서 되돌릴 필요가 없는 txn을 말한다.
loser란 begin이 되었지만 commit이 되지 못하고 crash가 나버리거나 abort 과정 도중 crash가 나서 온전한 상태로 끝나지 못한 txn을 말한다.
분석 단계가 시작되면 로그파일에서 로그 레코드들을 차례로 읽어와서 판단을 내린다.
begin log인 경우: txn 리스트에 넣어둔다.
commit log인 경우: 해당 txn을 winner 리스트에 넣고 txn 리스트에서 제거한다.
update log인 경우: skip.
rollback log인 경우: 완전히 abort가 끝났다는 의미이므로 해당 txn을 winner 리스트에 넣고 txn 리스트에서 제거한다.
compensate log인 경우: skip.
모든 로그를 다 체크한 후 txn 리스트에서 남아있는 txn을 확인하고 loser 리스트로 넣는다.
리스트의 정보를 다음 단계로 넘겨준다.

로그파일을 열어서 처음 로그부터 차례로 redo를 실행한다.
모든 타입의 log를 redo할 필요는 없고 update와 compensate log에 대해서만 redo를 실행한다.
ARIES(Algroithms for recovery and isolation exploiting segmantics)방식을 사용하므로 loser포함 모든 txn의 log들을 전부 redo한다.
redo를 해야하는 로그의 LSN(log sequence number)이 해당 페이지의 lastLSN보다 큰 경우에만 redo한다.
그렇지 않은 경우에는 consider-redo, 즉 skip.

분석 단계에서 정해진 loser정보를 읽어와서 undo 단계를 진행한다.
로그 파일의 마지막 로그부터 처음 로그까지 역방향으로 진행한다.
update나 compensate 로그에 대해서만 undo를 진행한다.
update 로그를 만난 경우 그 로그를 타겟으로 하여 compensate log를 발급한다.
compensate 로그란 w(x)의 연산에 대해 w-1(x)연산을 수행하는 것이다.(inverse operation)
compensate 로그를 만난 경우 그 로그의 next_undo_LSN의 값을 읽고 해당하는 로그를 타겟으로 삼은 후 compensate 로그를 생성한다.
next_undo_LSN부터 다시 update 로그에 대해 compensate 로그를 계속해서 발행한다.
특정 tnx에 대한 모든 undo 작업이 끝난 경우는 rollback log를 발행한다.