재시작 때 어디서부터 읽을까: 체크포인트와 복구
체크포인트는 데이터베이스가 크래시 뒤 복구할 때 필요한 상태와 시작 근거를 기록하는 절차다. 로그를 처음부터 끝까지 모두 분석해야 하는 부담을 줄이고, 어떤 변경과 페이지가 아직 처리 대상인지 판단하는 데 도움을 준다. 체크포인트 하나가 항상 전체 데이터베이스의 완성된 복사본을 뜻하는 것은 아니다.
체크포인트는 복구 기준을 제공하지만 필요한 로그와 후속 작업까지 대신하지 않는다.
로그가 길수록 복구의 출발점이 중요하다
오랫동안 운영된 DB에는 많은 로그가 쌓인다. 모든 커밋한 변경이 데이터 페이지에 이미 반영되었다면 그보다 오래된 기록을 다시 적용할 필요가 줄어든다. 그러나 수정된 페이지와 진행 중인 트랜잭션이 남아 있으면 로그 위치 하나만 기억하는 것으로 충분하지 않을 수 있다. 어떤 복구 알고리즘을 쓰는지에 따라 필요한 정보가 달라진다.
더티 페이지는 메모리에서 수정되어 디스크의 내용과 달라진 페이지다. 시스템은 체크포인트에서 관련 상태를 기록하고 필요한 쓰기를 진행한다. 진행 중인 트랜잭션과 아직 반영되지 않은 로그 범위를 알아야 안전하게 복구할 수 있다. 최신 체크포인트 뒤의 로그만 무조건 보면 된다는 단순 규칙은 시스템에 따라 틀릴 수 있다.
서비스를 계속하면서 기준을 남긴다
퍼지 체크포인트는 작업을 완전히 멈추고 모든 상태를 하나의 순간으로 고정하는 방식과 달리, 실행을 이어 가면서 복구에 필요한 정보를 기록하는 접근이다. 그 사이에도 새로운 변경이 생길 수 있으므로 체크포인트 정보와 로그를 함께 해석해야 한다. 동시 작업이 가능하다는 장점은 더 정밀한 상태 추적을 요구한다.
ARIES 계열의 설명에서는 분석, redo, undo의 단계가 등장한다. 분석은 크래시 당시의 트랜잭션과 페이지 상태를 복원하고, redo는 필요한 변경을 다시 반영하며, undo는 취소해야 할 작업을 되돌린다. 실제 DBMS는 버전 관리와 로그 형식에 따라 다른 복구 전략을 사용할 수 있으므로 이 세 단계를 모든 제품의 동일한 구현으로 외우면 안 된다.
페이지에 반영된 로그 위치를 알면 이미 처리한 변경을 불필요하게 다시 적용하는 일을 피할 수 있다. 일부 페이지는 체크포인트 전 변경까지 디스크에 저장되어 있고 다른 페이지는 더 오래된 상태일 수 있다. 복구는 전체 파일을 하나의 같은 시점이라고 가정하기보다 이런 차이를 관리한다.
자주 남기면 언제나 좋은가
체크포인트를 자주 수행하면 복구 작업량을 줄일 가능성이 있지만 디스크 쓰기와 I/O 부하가 늘 수 있다. 드물게 수행하면 평상시 비용이 줄어도 크래시 후 복구 시간이 길어질 수 있다. 갑자기 많은 페이지를 쓰면 응답 지연이 튈 수 있어 작업을 시간에 나누는 정책도 중요하다.
예를 들어 마지막 기준 이후 로그가 크게 쌓였고 아직 많은 더티 페이지가 남아 있으면 재시작에서 해야 할 일이 늘어난다. 복구 속도는 단순히 로그 파일 크기뿐 아니라 필요한 페이지 접근과 실제로 재적용할 변경, 저장장치 처리량에도 달려 있다. 로그 생성률과 체크포인트의 진행 상황을 함께 보는 이유다.
체크포인트를 만들었다고 오래된 로그를 즉시 모두 삭제할 수 있는 것도 아니다. 복제 노드가 아직 필요로 하거나 시점 복구를 위해 보관해야 할 수 있다. 기준 백업과 로그를 결합한 복구에는 다른 보존 조건이 적용된다. 체크포인트, 백업, 로그 아카이빙은 목적과 역할을 구분해야 한다.
운영 계획에서는 평상시 지연과 재시작에 허용할 시간을 함께 정한다. 장애 뒤 실제 복구를 시험하면 로그와 백업의 존재만 확인하는 것보다 실질적인 근거를 얻을 수 있다. 체크포인트를 이해한다는 것은 안전한 복구 출발점을 남기되, 그 이후와 이전에 걸친 필요한 작업이 어떤 조건으로 남는지 설명할 수 있다는 뜻이다.