PlanetScale은 이전 백업을 복원해서 다음 백업을 만든다

Postgres 병렬 백업은 12시간마다 전체 데이터를 다시 복사하지 않고, 이전 백업을 임시 노드에 복원한 뒤 WAL을 재생해 현재 상태까지 따라잡아 새로운 백업을 만드는 방식 무거운 데이터 복원과 WAL 재생 대부분을 S3와 임시 백업 노드에서 처리하고, primary에서는 아직 아카이브되지 않은 최근 몇 분의 WAL만 가져와 프로덕션 부하를 최소화함 샤드마다 별도 임시 노드를 띄워 동시에 처리하므로 데이터베이스가 커져도 샤드 수만큼 백업을 병렬화할 수 있으며, 32TB 기준 22시간이 8샤드에서 2.8시간, 32샤드에서 42분으로 줄어듦 다음 백업을 만들 때마다 이전 백업을 실제로 복원하므로, 단순히 백업 파일을 저장하는 것과 달리 기존 백업이 복구 가능한지도 매 주기 검증됨 같은 백업 복원 → WAL 따라잡기 구조를 데이터베이스 리사이징과 장애 노드 교체에도 사용해, 백업을 재해 복구뿐 아니라 일상적인 데이터베이스 운영의 기반으로 활용함 샤딩 데이터베이스의 백업 구조 Neki 데이터베이스는 여러 개의 독립적인 Postgres primary가 하나의 샤딩 데이터베이스를 구성하며, 각 샤드에 일반적인 Postgres 백업 방식을 반복 적용함 정상 운영 상태에서는 12시간 전에 생성해 S3 같은 객체 스토리지에 저장해 둔 건강한 이전 백업을 출발점으로 사용함 Postgres 물리 백업은 파일시스템 백업과 archived Write-Ahead Log(WAL) 재생을 결합함 시각 T1에 디스크상의 Postgres 파일 전체 백업을 시작함 T2에 파일 복사가 끝날 때까지 디스크의 행이 변경될 수 있음 T1~T2 사이 WAL 변경을 재생해 복사 중 변경된 데이터를 보정함 완성된 결과를 S3 같은 별도 저장소에 저장함 프로덕션 대신 임시 백업 노드를 사용 이 작업을 primary나 트래픽을 처리하는 replica에서 직접 수행할 수도 있지만, 큰 데이터베이스에서는 상당한 IOPS와 연산 자원을 소비함 PlanetScale은 프로덕션 쿼리 영향을 줄이기 위해 샤드마다 새로운 EC2 인스턴스를 하나씩 띄워 백업 작업의 대부분을 처리함 AWS/GCP 같은 클라우드에서는 수십~수백 개의 인스턴스를 짧은 시간만 동적으로 생성할 수 있어 추가 비용을 감수하고 프로덕션 부하를 분리함 이전 백업을 매번 다시 복원 각 임시 백업 노드는 객체 스토리지에 저장된 가장 최근 백업을 직접 스트리밍해 복원함 매 주기마다 각 샤드 데이터를 객체...