사용 사례
이 참조 아키텍처는 다음 시나리오를 지원합니다.
- 마지막 백업 이후 일부 다운타임과 데이터 손실을 톨러레이션(toleration)할 수 있는 데이터베이스가 있는 경우
- 서버 또는 VM 이미지 스냅샷이 아닌 데이터베이스 수준에서 사용자 오류, 손상 또는 물리적 장애로부터 AlloyDB Omni 데이터베이스를 보호하려는 경우
- 로컬 또는 원격으로 최대한 특정 시점까지 데이터베이스를 복구할 수 있어야 하는 경우
참조 아키텍처 작동 방식
표준 가용성 참조 아키텍처는 AlloyDB Omni 데이터베이스의 백업 및 복구를 다룹니다.
표준 가용성은 기본 구현이며 필요한 추가 하드웨어나 서비스를 최소화하지만 데이터베이스가 커질수록 복구 시간 목표(RTO)가 증가합니다. 백업할 데이터가 많을수록 데이터베이스를 복원하고 복구하는 데 시간이 오래 걸립니다. 데이터 손실은 백업 유형에 따라 다릅니다. 데이터 파일만 주기적으로 백업하는 경우 복원할 때 마지막 백업 이후의 데이터가 손실됩니다.
RPO 감소
PostgreSQL 연속 보관처리 기능을 사용하면 낮은 목표 복구 시간(RPO)을 달성하고 백업을 통해 PITR(point-in-time recovery)을 사용 설정할 수 있습니다. 이 프로세스에는 미리 쓰기 로깅(WAL) 파일 보관처리와 원격 스토리지 위치로 미리 쓰기 로깅 데이터 스트리밍이 포함될 수도 있습니다.
미리 쓰기 로깅 파일이 가득 차거나 특정 간격으로만 보관처리되는 경우 전체 데이터베이스 손실 (현재 미리 쓰기 로깅 파일 포함)로 인해 복구가 마지막으로 보관처리된 미리 쓰기 로깅 파일로 제한됩니다. 즉, RPO에서 잠재적인 데이터 손실을 고려해야 합니다. 반대로 미리 쓰기 로깅 데이터를 지속적으로 전송하면 잠재적인 데이터 손실이 최소화됩니다.
연속 백업을 구성할 때 특정 시점으로 복구할 수 있습니다. PITR(point-in-time recovery)을 사용하면 실수로 인한 테이블 삭제나 잘못된 일괄 업데이트와 같은 오류가 발생하기 전의 상태로 데이터베이스를 복원할 수 있습니다. 하지만 임시 보조 데이터베이스를 사용하지 않는 한 이 복구 방법은 RPO와 RTO 모두에 영향을 미칩니다. 전체 데이터베이스를 제자리에서 복원하면 영향을 받지 않는 테이블의 후속 트랜잭션이 롤백되고 데이터베이스가 오프라인으로 전환되는 반면, 임시 보조 데이터베이스로 복원하면 복구된 데이터만 복사할 수 있습니다.
백업 전략
AlloyDB Omni는 정기적인 물리적 백업, PITR(point-in-time recovery), WAL 보관처리 및 스트리밍, 다른 위치에 백업 저장과 같은 데이터 보호 전략을 지원합니다. 또는 소규모 데이터베이스의 경우 단일 데이터베이스에 pg_dump를 사용하거나 전체 클러스터에 pg_dumpall를 사용하여 논리적 백업을 수행하고 pg_restore를 사용하여 복원할 수 있습니다.
백업 도구
컨테이너 및 Linux 배포의 경우 다음 PostgreSQL 도구를 사용하여 백업을 예약하고 관리할 수 있습니다.
- pgBackRest: 자세한 내용은 AlloyDB Omni용 pgBackRest 설정을 참조하세요.
- Barman: 자세한 내용은 AlloyDB Omni용 Barman 설정을 참조하세요.
배포 옵션에 따라 Cloud Storage 또는 클라우드 공급업체에서 제공하는 스토리지 옵션과 같은 로컬 또는 원격 스토리지에 백업을 저장하도록 AlloyDB Omni를 구성할 수 있습니다. 로컬 스토리지에서 더 빠르게 백업과 복구를 수행할 수 있지만 전체 호스트나 VM이 실패할 때 원격 스토리지가 일반적으로 오류를 더 강력하게 처리합니다. 자세한 내용은 잠재적인 백업 대상을 보여주는 그림 1을 참조하세요.
그림 1. 백업 옵션이 있는 AlloyDB Omni
로컬 또는 원격 스토리지 옵션으로 백업을 수행할 수 있습니다. 로컬 백업은 I/O 처리량만 사용하므로 빠르지만 원격 백업의 경우 일반적으로 지연 시간이 더 길고 네트워크 대역폭이 더 낮습니다. 하지만 원격 백업은 로컬 백업보다 호스트 및 영역 장애에 대한 보호 기능이 더 우수합니다.
로컬 백업을 로컬 또는 공유 스토리지로 분할할 수도 있습니다. 데이터베이스 호스트가 실패할 때 로컬 스토리지에는 재해 복구 옵션이 없지만 공유 스토리지를 사용하면 해당 스토리지를 다른 서버로 이전한 후 복구에 사용할 수 있습니다. 즉, 공유 스토리지는 더 빠른 RTO를 제공할 수 있습니다.
로컬, 공유, 원격 스토리지 배포의 경우 다음 유형의 백업을 예약하거나 주문형으로 수동으로 수행할 수 있습니다.
- 전체 백업: 데이터 복구에 필요한 모든 데이터베이스 파일을 전체 백업합니다.
- 차등 백업: 마지막 전체 백업 이후의 파일 변경사항만 백업합니다.
- 증분 백업: 종류에 관계없이 마지막 백업 이후의 파일 변경사항만 백업합니다.
point-in-time recovery
PostgreSQL WAL 파일의 연속 백업은 PITR(point-in-time recovery)을 지원합니다. 실패 이벤트 후 미리 쓰기 로깅 파일이 손상되지 않고 사용 가능하면 이러한 파일을 사용하여 특정 시점으로 복구하고 데이터 손실을 최소화할 수 있습니다.
원격 위치로 미리 쓰기 로깅 데이터 스트리밍
백업 도구 (예: Barman)에 따라 복구 시 데이터 손실을 최소화하기 위해 WAL 데이터를 원격 위치로 실시간 스트리밍하도록 구성할 수 있습니다. 실시간 스트리밍에도 불구하고 스트리밍이 원격 위치에 쓰는 작업은 기본적으로 비동기식이므로 커밋된 트랜잭션이 손실될 가능성이 약간 있습니다. 하지만 WAL 데이터를 저장하고 상태 응답을 소스 데이터베이스로 다시 보내는 동기 모드를 사용하도록 WAL 스트리밍을 구성할 수 있습니다. 이 방법은 트랜잭션이 계속되기 전에 이 쓰기가 완료될 때까지 기다려야 하는 경우 트랜잭션 속도를 늦출 수 있습니다.
백업 일정
대부분의 환경에서 백업은 일반적으로 주 단위로 예약됩니다. 다음은 일반적인 주간 백업 일정입니다.
- 일요일: 전체 백업
- 월요일, 화요일: 증분 백업
- 수요일: 차등 백업
- 목요일, 금요일: 증분 백업
- 토요일: 차등 백업
이 일반적인 일정을 사용하면 1주일의 롤링 복구 기간에 전체 백업 최대 3개와 필요한 증분 또는 차등 백업을 저장할 수 있는 공간이 필요합니다. 이 방식은 일요일에 전체 백업 중에 발생하는 장애 복구를 지원하며 데이터베이스 복구가 백업이 시작되기 전 이전 일요일까지 확장되어야 합니다.
RPO가 높아질 수 있는 RTO를 최소화하기 위해 추가 데이터베이스가 연속 복구 모드로 작동할 수 있습니다. 이 모드에는 백업을 재생하고 새 미리 쓰기 로깅 파일을 보관처리하고 재생하여 보조 환경을 지속적으로 업데이트하는 작업이 포함됩니다. 잠재적인 데이터 손실을 반영하는 실제 RPO는 트랜잭션 빈도, 미리 쓰기 로깅 파일 크기, 미리 쓰기 로깅 스트리밍 사용에 따라 달라집니다.
백업 복원
저장된 백업에서 AlloyDB Omni 데이터베이스를 복원하거나 보관 기간 내의 특정 시점으로 복구할 수 있습니다. 배포 환경 및 복구 요구사항에 따라 데이터를 제자리에서 복원하거나 백업을 새 데이터베이스 인스턴스 또는 클러스터로 복원할 수 있습니다.
컨테이너 및 Linux 배포의 경우 AlloyDB Omni 데이터베이스 복원에는 일반적으로 데이터베이스 서비스 또는 컨테이너를 중지하고 데이터를 기존 데이터 디렉터리에 복원하거나 데이터를 새 위치에 복원하고 복원된 데이터를 사용하여 새 데이터베이스 인스턴스를 시작하는 작업이 포함됩니다. 자세한 내용은 pgBackRest를 사용하여 AlloyDB Omni 클러스터 복원 또는 Barman을 사용하여 AlloyDB Omni 클러스터 복원을 참조하세요.
구현
가용성 참조 아키텍처를 선택할 때는 다음 이점, 제한사항, 대안을 고려하세요.
이점
- 사용과 관리가 간단하며 RTO 및 RPO가 관대한 중요하지 않은 데이터베이스에 적합합니다.
- 추가 하드웨어가 거의 필요하지 않습니다.
- 재해 복구 계획에 필요한 기본적인 백업을 제공합니다.
- 복구 기간 내 특정 시점으로 복구할 수 있습니다.
제한사항
- 보관 요구사항에 따라 데이터베이스 자체보다 더 많은 저장공간이 필요할 수 있습니다.
- 복구 속도가 느릴 수 있으며 RTO가 높아질 수 있습니다.
- 데이터베이스 장애 후 현재 미리 쓰기 로깅 데이터 가용성에 따라 일부 데이터가 손실될 수 있으며 이는 RPO에 부정적인 영향을 미칠 수 있습니다.
대안
가용성 및 재해 복구 옵션을 개선하려면 향상된 가용성 또는 프리미엄 가용성 참조 아키텍처를 사용하는 것이 좋습니다.