WAL 커밋 포인트

사용자가 COMMIT을 입력해도, 로그가 디스크에 남기 전까지는 아직 부분 커밋입니다.

중요한 경계는 명령 수신이 아니라 Redo 로그 flush 성공입니다. 그 순간부터만 장애 후에도 변경 내용을 다시 재현할 수 있습니다.

공유 출발점

마지막 SQL은 끝났지만 변경은 아직 메모리에 있습니다

버퍼에 있는 변경 내용은 장애가 나면 사라질 수 있으므로, 아직 확정된 결과가 아닙니다.

더티 페이지 Redo 로그 버퍼

부분 커밋

이 구간이 과도기 상태입니다. 성공과 실패는 모두 여기서 갈립니다.

커밋 포인트

Redo 로그가 로그 파일에 flush된 순간에만 커밋이 성립합니다. 그 전에는 여전히 실패 후 ROLLBACK 경로가 열려 있습니다.

Redo flush 성공

이제 DBMS는 성공 응답을 보내도 됩니다. 장애가 나더라도 로그를 읽어 변경을 다시 적용할 수 있습니다.

내구성 로그가 디스크에 있으므로 재시작 후 Redo로 복구 가능합니다.

데이터 파일 데이터 페이지 기록은 나중이어도 됩니다. WAL이 먼저 안전망을 만들어 두었기 때문입니다.

로그 기록 중 장애

커밋 포인트에 도달하지 못했으므로 트랜잭션은 확정되지 않습니다. 남은 경로는 실패 처리와 변경 취소입니다.

의미 사용자가 COMMIT을 호출했더라도, 디스크에 남은 로그가 없으면 아직 성공으로 볼 수 없습니다.

결과 DBMS는 ROLLBACK으로 메모리 변경을 되돌려 일관성을 지킵니다.

핵심: WAL의 순서는 로그 먼저, 데이터는 나중입니다. 그래서 Redo 로그 flush 완료가 진짜 커밋 경계가 되고, 데이터 페이지 쓰기는 그 뒤여도 괜찮습니다.