[Aurora, PostgreSQL, MySQL] DB 크래쉬 복원 방식

Aurora와 Onpremise 의 PostgreSQL과 MySQL의 크래쉬 상황에서 복원 (롤포워드) 방식에 대해 알아보고자 합니다.

Onpremise에서는 사실 WAL, UndoLog, RedoLog 등을 사용하여 복원하는 것이 일반적이라서 크게 특이사항이 없었는데 

Aurora는 클러스터 볼륨, 컴퓨팅 영역 분리의 특징, 로그를 전달하는 방식의 데이터 저장 처리 등 다른 부분이 있기 때문에

이를 비교하고 이해하여 종합적인 이해도를 높이고자 하였습니다.

 

 

On-Premise MySQL (InnoDB)

Redo Log, Undo Log, Doublewrite Buffer 의 3가지 요소로 DB를 정상화 시킵니다.

먼저 서버는 체크 포인트의 마지막 지점을 파악하고 이 지점부터 RedoLog 파일과 DoubleWriter Buffer를 스캔하기 시작합니다.

이 과정에서 로그에 기록된 사항을 버퍼풀과 데이터 파일에 동기화합니다 (롤 포워드).

이후 UndoLog를 통해 COMMIT 되지 않은 데이터를 롤백하는 과정을 진행합니다.

이러한 처리 과정은 데이터를 쓰고 지우는 작업이 진행되기 때문에 Log 파일의 사이즈에 따라 시간이 증가합니다.

이 작업들은 병렬처리가 아닌 하나의 스레드를 통해 처리됩니다.

On-Premise PostgreSQL

기본적으로 MySQL과 넓은 개념은 비슷하다고 생각합니다. 다만 해당 과정에서 WAL 파일이 사용이 됩니다.

pg_control 파일을 읽어 체크포인트 레코드가 WAL의 어느 위치에 있는지 확인합니다. 

해당 위치부터 WAL 파일을 리플레잉하여 DB 다운 직전의 상태로 되돌립니다 (롤 포워드).

이후 커밋되지 않은 내용에 대하여 롤백을 진행합니다. 이 작업은 pg_xact 또는 pg_commit_ts 에 기록된 COMMIT 정보를 바탕으로 진행합니다.

mysql과 마찬가지로 하나의 프로세스로 처리가 진행되며 이 작업은 로그의 양에 따라 시간이 증가합니다.

---

Aurora

Aurora의 복구 방법을 이해하기 위해선 몇가지 LSN에 대하여 이해하여야합니다.

LSN : Log Sequence Number 프라이머리 노드에서 발행되는 값으로 단조롭게 증가하는 8바이트 숫자 입니다.

트랜잭션의 처리 숫자로도 볼 수 있습니다.

VCL : Volume Complete LSN 으로 6개의 스토리지 노드에서 4개 이상의 쿼럼을 만족한 LSN으로

해당 LSN은 COMMIT이 완료된 상태입니다.

CPL : Consistency Point LSN 으로 B-Tree와 같은 내부 데이터 구조의 파편화 없이 논리적으로 일관성을 갖춘 상태임을 보장하는 LSN 지점입니다. 해당 LSN을 기점으로 논리적 복구 지점의 목록을 가질 수 있습니다.

VDL : Volume Durable LSN 으로 VCL보다 작거나 같은 CPL 중에서 가장 큰 값입니다. 해당 값을 기준으로 DB 크래쉬 상태에서 복구 시작점을 정합니다.

•  

각 LSN의 위치에 따라 아래와 같이 해석할 수 있습니다.

1. LSN > VCL

  - 4개 미만의 노드에서만 응답을 받은 상태로 아직 COMMIT 되지 않은 데이터 입니다.

2. LSN < VDL

 - DB에 저장된 것을 확정지을 수 있는 LSN 입니다.

이 정보들을 바탕으로 DB 크래쉬가 발생한 상황에서 Aurora의 복원 방식을 이해할 수 있습니다.

1. 엔진은 VCL을 먼저 확정 잣습니다. 이후 VCL과 CPL 목록을 비교하여 VDL을 결정합니다.

2. 결정된 VDL을 기준으로 VDL 이후의 발생했을 수 있는 페이지 변경 상태를 무시하고 모든 데이터 페이지를 VDL의 시점의 상태로 준비합니다 (로그 포인트를 변경하는 과정).

3. VDL 부터 VDL까지의 로그를 스토리지에 반영하는 작업을 진행합니다 (REDO 과정과 유사)

4. COMMIT 되지 못한 VCL 이후의 LSN을 데이터 일관성을 맞추기 위해 제거하게 됩니다 (UNDO와 유사, Aurora는 이 Undo 과정을 DB가 온라인된 상태에서 백그라운드로 처리가 가능)

각각의 스토리지 노드는 서로 독립적인 노드이므로 이 작업은 병렬적으로 처리가 되어 더욱 빠르며 기존 Onpremise 장비들의 롤 포워드, 롤백등의 작업에 비해 매우 가볍게 처리되어 빠른 속도의 복원이 가능합니다.

다만 별도 작업(CCM 같은 기능 사용)을 하지 않을 경우 Promote되는 Read Replica는 재부팅하는 작업이 진행되기 때문에 메모리는 Onpremise에 비하여 더욱 Cold 상태라는 약간의 단점이 있습니다.