Azure Database for PostgreSQL의 고가용성(안정성)

이 문서에서는 가용성 영역 및 지역 간 복구 및 비즈니스 연속성을 포함하는 Azure Database for PostgreSQL의 고가용성에 대해 설명합니다. Azure의 안정성에 대한 포괄적인 개요는 Azure 안정성을 참조하세요.

Azure Database for PostgreSQL은 동일한 가용성 영역(영역) 내 또는 가용성 영역(영역 중복)에서 물리적으로 구분된 주 복제본과 대기 복제본을 프로비전하여 고가용성을 지원합니다. 이 고가용성 모델은 오류가 발생하는 동안 커밋된 데이터가 손실되지 않도록 설계되었습니다. HA(고가용성) 설정에서는 데이터가 기본 서버와 대기 서버 모두에 동기식으로 커밋됩니다. 이 모델은 소프트웨어 아키텍처에서 데이터베이스가 단일 실패 지점이 되지 않도록 설계되었습니다. 가용성 영역 및 가용성 영역 지원에 대한 자세한 내용은가용성 영역 지원을 참조하세요.

가용성 영역 지원

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

Azure Database for PostgreSQL은 고가용성 구성을 위해 영역 중복 모델과 영역 모델을 모두 지원합니다. 두 고가용성 구성을 모두 사용하면 계획된 이벤트와 계획되지 않은 이벤트 중에 데이터 손실이 없는 자동 장애 조치(failover) 기능을 사용할 수 있습니다.

• 영역 중복. 영역 중복 고가용성은 자동 장애 조치(failover) 기능을 통해 대기 복제본을 다른 영역에 배포합니다. 영역 중복성은 가장 높은 수준의 가용성을 제공하지만 영역 간에 애플리케이션 중복성을 구성해야 합니다. 이러한 이유로 인해 가용성 영역 수준 장애로부터 보호하고 가용성 영역 전반의 대기 시간을 허용하려는 경우에 영역 중복을 선택합니다. 동기 복제로 인해 쓰기와 커밋에 약간의 대기 시간이 발생할 수 있지만 읽기 쿼리에는 영향을 미치지 않습니다. 이 영향은 워크로드, 선택한 SKU 유형 및 지역에 따라 다릅니다.

  주 서버와 대기 서버 모두에 대한 지역과 가용성 영역을 선택할 수 있습니다. 대기 복제본 서버는 주 서버와 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 사용하여 같은 지역에서 선택한 가용성 영역에서 프로비전됩니다. 데이터 파일 및 트랜잭션 로그 파일(WAL이라고도 함)은 각 가용성 영역 내의 LRS(로컬 중복 스토리지)에 저장되어 세 개의 데이터 복사본 을 자동으로 저장합니다. 영역 중복 구성은 주 서버와 대기 서버 간의 전체 스택을 물리적으로 격리합니다.

  

영역 중복 옵션은 가용성 영역을 지원하는 지역에서만 사용할 수 있습니다.

다음에서는 영역 중복이 지원되지 않습니다.

• 버스트 가능 컴퓨팅 계층

• 단일 영역 가용성이 있는 지역

• 영역. 단일 가용성 영역 내에서 네트워크 대기 시간이 가장 짧은 최고 수준의 가용성을 달성하려면 영역 배포를 선택합니다. 지역 및 가용성 영역을 선택하여 주 데이터베이스 서버를 배포할 수 있습니다. 대기 복제본 서버는 주 서버와 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 통해 같은 가용성 영역에서 자동으로 프로비전되고 관리됩니다. 영역 구성은 노드 수준의 오류로부터 데이터베이스를 보호하고 계획된 가동 중지 시간 이벤트와 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데에도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버에 장애가 발생할 경우, 서버는 자동으로 대기 복제본으로 전환됩니다.

  

영역 배포 옵션은 유연한 서버를 배포할 수 있는 모든 Azure 지역에서 사용 가능합니다.

포털에서 영역 복원력 구성

대기 서버를 최대 복원력을 위해 다른 가용성 영역에 배치하는 영역 중복 HA 또는 대기 서버를 주 서버와 동일한 영역에 배포하여 대기 시간을 최소화하는 동일한 영역 HA의 두 가지 방법으로 HA(고가용성)를 구성할 수 있습니다.

구성을 간소화하고 영역 복원력을 보장하기 위해 포털은 두 개의 라디오 단추인 사용 및 사용 안 함으로 영역 복원력 옵션을 제공합니다. "Enabled"를 선택하면 다른 가용성 영역(영역 중복 HA 모드)에서 대기 서버를 생성하려고 시도합니다. 지역에서 영역 중복 HA를 지원하지 않는 경우 대체 확인란(다음 이미지에 강조 표시됨)을 선택하여 동일한 영역 HA를 대신 사용하도록 설정할 수 있습니다.

대체 확인란을 선택하면 시스템은 동일한 영역에 대기 서버를 만들고 나중에 유지 관리 기간 동안 자동 마이그레이션 워크플로를 트리거하여 용량을 사용할 수 있게 되면 다른 영역으로 이동합니다. 확인란을 선택하지 않고 영역 용량을 사용할 수 없는 경우 HA 사용이 실패합니다. 이 디자인은 영역 중복 HA를 기본값으로 적용하는 동시에 동일한 영역 HA에 대해 제어된 대체를 제공하여 워크로드가 수동 개입 없이 결국 전체 영역 복원력을 달성할 수 있도록 합니다.

고가용성 기능

• 대기 복제본은 vCore, 스토리지 및 네트워크 설정을 비롯한 동일한 VM 구성에 주 서버로 배포됩니다.

• 기존 데이터베이스 서버에 대한 가용성 영역 지원을 추가할 수 있습니다.

• 고가용성을 사용하지 않도록 설정하여 대기 복제본을 제거할 수 있습니다.

• 영역 중복 가용성에 주 및 대기 데이터베이스 서버의 가용성 영역을 선택할 수 있습니다.

• 중지, 시작, 다시 시작과 같은 작업은 주 데이터베이스 서버와 대기 데이터베이스 서버 모두에서 동시에 수행됩니다.

• 영역 중복 및 영역 모델에서 주 데이터베이스 서버는 주기적으로 자동 백업을 수행합니다. 동시에 대기 복제본은 백업 스토리지에 트랜잭션 로그를 지속적으로 보관합니다. 지역에서 가용성 영역을 지원하는 경우 백업 데이터는 ZRS(영역 중복 스토리지)에 저장됩니다. 가용성 영역을 지원하지 않는 지역에서는 백업 데이터가 LRS(로컬 중복 스토리지)에 저장됩니다.

• 클라이언트는 항상 주 데이터베이스 서버의 엔드 호스트 이름에 연결합니다.

• 서버 매개 변수에 대한 모든 변경 내용은 대기 복제본에도 적용됩니다.

• 서버를 다시 시작하여 정적 서버 매개 변수 변경 내용을 선택할 수 있습니다.

• 부 버전 업그레이드와 같은 정기적인 유지 관리 작업은 먼저 대기 시 발생합니다. 가동 중지 시간을 줄이기 위해 유지 관리 작업이 나머지 노드에 적용되는 동안 워크로드가 계속 작동할 수 있도록 대기 상태가 기본으로 승격됩니다.

고가용성 건강 모니터링

Azure Database for PostgreSQL의 HA(고가용성) 상태 모니터링은 HA 사용 인스턴스의 상태 및 준비 상태에 대한 지속적인 개요를 제공합니다. 이 모니터링 기능은 Azure의 RHC(Resource Health Check) 프레임워크를 적용하여 데이터베이스의 장애 조치(failover) 준비 상태 또는 전체 가용성에 영향을 줄 수 있는 문제를 감지하고 경고합니다. 연결 상태, 장애 조치 상태 및 데이터 복제 상태와 같은 주요 메트릭을 평가하여 HA 상태 모니터링을 통해 사전 문제 해결을 가능하게 하고 데이터베이스의 가동 시간 및 성능을 유지할 수 있습니다.

HA 상태 모니터링을 사용하여 다음을 할 수 있습니다.

• 성능 저하 또는 네트워크 차단과 같은 잠재적인 문제를 표시하는 상태 표시기를 사용하여 주 복제본과 대기 복제본의 상태를 실시간으로 파악합니다.
• HA 상태의 변경 내용에 대해 적시에 알림에 대한 경고를 설정하여 잠재적인 중단을 해결하기 위해 즉각적인 조치를 취할 수 있습니다.
• 데이터베이스 운영에 영향을 미치기 전에 문제를 식별하고 해결하여 장애 조치(failover) 준비를 최적화합니다.

HA 상태 구성 및 해석에 대한 자세한 가이드는 Azure Database for PostgreSQL에 대한 HA(고가용성) 상태 모니터링을 참조하세요.

고가용성 제한 사항

• 대기 서버에 대한 동기 복제, 특히 영역 중복 구성으로 인해 애플리케이션에서 높은 쓰기 및 커밋 대기 시간을 경험할 수 있습니다.

• 읽기 쿼리에는 대기 복제본을 사용할 수 없습니다.

• 주 서버의 워크로드 및 작업에 따라 대기 복제본을 승격하기 전에 복구해야 하므로 장애 조치(failover) 프로세스가 120초보다 오래 걸릴 수 있습니다.

• 대기 서버는 일반적으로 40MB/s로 WAL 파일을 복구합니다. 더 큰 버전의 경우 이 속도는 최대 200MB/초까지 증가할 수 있습니다. 워크로드가 이 한도를 초과하면 장애 조치(failover) 중에 또는 새 대기 서버를 설정한 후에 복구를 완료하는 데 시간이 오래 걸릴 수 있습니다.

• 주 데이터베이스 서버를 다시 시작하면 대기 복제본도 다시 시작됩니다.

• 추가 대기를 구성할 수 없습니다.

• 관리되는 유지 관리 기간 동안에는 고객이 시작한 관리 작업을 예약할 수 없습니다.

• 계획된 이벤트는 스케일 아웃 컴퓨팅 및 스케일 아웃 스토리지와 같이 대기 서버에서 먼저 발생하고, 이후 주 서버에서 발생합니다. 현재 서버는 이러한 계획된 작업을 장애 조치(failover)하지 않습니다.

• 논리적 디코딩 또는 논리적 복제가 HA 지원 유연한 서버에서 구성된 경우

  • PostgreSQL 16 이하에서는 기본적으로 장애 조치(failover) 후 대기 서버에서 논리 복제 슬롯이 유지되지 않습니다.
  • 논리 복제가 장애 조치 후에도 계속 작동하도록 보장하기 위해 pg_failover_slots 확장을 사용하도록 설정하고 hot_standby_feedback = on 지원 설정을 구성해야 합니다.
  • PostgreSQL 17부터 슬롯 동기화가 기본적으로 지원됩니다. 올바른 PostgreSQL 구성(, sync_replication_slots)을 사용하도록 설정하면 장애 조치(hot_standby_feedbackfailover) 후 논리 복제 슬롯이 자동으로 유지되며 확장이 필요하지 않습니다.
  • 설정 단계 및 필수 구성 요소는 PG_Failover_Slots 확장 설명서를 참조하세요.

• 프라이빗(가상 네트워크) 및 프라이빗 엔드포인트를 사용한 공용 액세스 간에 가용성 영역을 구성하는 것은 지원되지 않습니다. 가상 네트워크 내에서 가용성 영역(지역 내의 가용성 영역에 걸쳐) 또는 프라이빗 엔드포인트를 사용한 공용 액세스를 구성해야 합니다.

• 단일 지역 내에서만 가용성 영역을 구성할 수 있습니다. 지역 간에 가용성 영역을 구성할 수 없습니다.

서비스 수준 계약 (SLA)

• 영역 모델은 SLA에 따라 약 99%의 작동 시간을 제공합니다.

• 영역 중복 모델은 SLA에서 약 99%의 가동 시간을 제공합니다.

가용성 영역을 사용하도록 설정된 Azure Database for PostgreSQL 만들기

가용성 영역을 사용하여 고가용성을 위해 Azure Database for PostgreSQL을 만드는 방법을 알아보려면 빠른 시작: Azure Portal에서 Azure Database for PostgreSQL 만들기를 참조하세요.

가용성 영역 재배포 및 마이그레이션

영역 중복 및 영역 배포 모델 모두에서 유연한 서버에서 고가용성 구성을 사용하거나 사용하지 않도록 설정하는 방법을 알아보려면 유연한 서버에서 고가용성 관리를 참조하세요.

고가용성 구성 요소 및 워크플로

트랜잭션 완료

애플리케이션 트랜잭션에 의해 트리거된 쓰기 및 커밋이 주 서버의 WAL에 첫 번째 로그로 기록됩니다. 주 서버는 Postgres 스트리밍 프로토콜을 사용하여 이러한 로그를 대기 서버로 스트리밍합니다. 대기 서버 스토리지가 로그를 유지하면 주 서버는 쓰기 완료를 승인합니다. 애플리케이션은 이 승인 후에만 트랜잭션을 커밋합니다. 이 추가 왕복은 애플리케이션에 대기 시간을 추가합니다. 영향 비율은 애플리케이션에 따라 달라집니다. 이 승인 프로세스는 로그가 대기 서버에 적용될 때까지 대기하지 않습니다. 대기 서버는 승격될 때까지 복구 모드로 유지됩니다.

상태 확인

유연한 서버 상태 모니터링은 주 서버와 대기 서버의 상태를 주기적으로 확인합니다. 여러 ping 후 상태 모니터링에서 주 서버에 연결할 수 없음을 감지하면 서비스는 대기 서버에 대한 자동 장애 조치(failover)를 시작합니다. 상태 모니터링 알고리즘은 여러 데이터 요소를 사용하여 가양성 상황을 방지합니다.

장애 조치(failover) 모드

유연한 서버는 계획된 장애 조치 및 계획되지 않은 장애 조치(failover) 등 두 가지 장애 조치(failover) 모드를 지원합니다. 두 모드에서 복제가 중단되면 대기 서버는 기본으로 승격하기 전에 복구를 실행하고 읽기/쓰기를 위해 열립니다. 새 주 서버 엔드포인트로 업데이트된 자동 DNS 항목을 사용하여 애플리케이션은 동일한 엔드포인트를 사용하여 서버에 연결할 수 있습니다. 새 대기 서버가 백그라운드에서 설정되므로 애플리케이션에서 연결을 유지 관리할 수 있습니다.

고가용성 상태

시스템은 주 서버와 대기 서버의 상태를 지속적으로 모니터링합니다. 문제를 해결하기 위해 적절한 조치를 취해야 하며, 여기에는 대기 서버로의 장애 조치(failover)를 트리거하는 것도 포함됩니다. 다음 표에서는 가능한 고가용성 상태를 나열합니다.

정상 상태 작업

PostgreSQL 클라이언트 애플리케이션은 DB 서버 이름을 사용하여 주 서버에 연결합니다. 주 서버는 애플리케이션 읽기를 직접 제공합니다. 동시에 애플리케이션은 기본 서버와 대기 복제본 모두에서 로그 데이터가 유지된 후에만 커밋 확인을 받고 씁니다. 이러한 추가 왕복으로 인해 애플리케이션은 쓰기와 커밋의 대기 시간이 증가할 것으로 예상할 수 있습니다. 포털에서 고가용성의 상태를 모니터링할 수 있습니다.

1. 클라이언트는 유연한 서버에 연결하고 쓰기 작업을 수행합니다.
2. 변경 내용은 대기 사이트에 복제됩니다.
3. 주 서버는 승인을 받습니다.
4. 쓰기 및 커밋이 승인됩니다.

고가용성 서버의 특정 시점 복원

고가용성으로 구성된 유연한 서버의 경우 시스템은 로그 데이터를 대기 서버에 실시간으로 복제합니다. 실수로 테이블 삭제 또는 잘못된 데이터 업데이트와 같은 주 서버의 사용자 오류는 대기 복제본에 복제됩니다. 따라서 대기를 사용하여 이러한 논리적 오류를 복구할 수 없습니다. 이러한 오류를 복구하려면 백업에서 지정 시간 복원을 수행해야 합니다. 유연한 서버의 지정 시간 복원 기능을 사용하여 오류가 발생하기 전의 시간으로 복원할 수 있습니다. 새 데이터베이스 서버는 사용자가 제공한 고가용성으로 구성된 데이터베이스의 새 서버 이름을 사용하는 단일 영역 유연한 서버로 복원됩니다. 복원된 서버를 여러 사용 사례에 사용할 수 있습니다.

• 프로덕션에 복원된 서버를 사용하고 필요에 따라 동일한 영역 또는 동일한 지역의 다른 영역에 대기 복제본을 사용하여 고가용성을 사용하도록 설정합니다.

• 개체를 복원하려는 경우 복원된 데이터베이스 서버에서 개체를 내보내고 프로덕션 데이터베이스 서버로 가져옵니다.

• 테스트 및 개발 목적으로 데이터베이스 서버를 복제하거나 다른 목적으로 복원하려면 특정 시점 복원을 수행하면 됩니다.

유연한 서버의 특정 시점 복원을 수행하는 방법은 유연한 서버의 특정 시점 복원을 참조하세요.

장애 조치(failover) 지원

계획된 장애 조치

계획된 가동 중지 시간 이벤트에는 Azure 예약 정기 소프트웨어 업데이트 및 사소한 버전 업그레이드가 포함됩니다. 계획된 장애 조치를 사용하여 주 서버를 기본 가용성 영역으로 반환할 수도 있습니다. 고가용성을 구성할 때 애플리케이션이 주 서버에 계속 액세스하는 동안 이러한 작업은 먼저 대기 복제본에 적용됩니다. 프로세스가 대기 복제본을 업데이트하면 주 서버 연결을 드레이닝하고 대기 복제본을 동일한 데이터베이스 서버 이름을 가진 주 서버로 활성화하는 장애 조치(failover)를 트리거합니다. 클라이언트 애플리케이션은 동일한 데이터베이스 서버 이름으로 새 주 서버에 다시 연결하고 작업을 다시 시작할 수 있습니다. 이 프로세스는 이전 주 서버와 동일한 영역에 새 대기 서버를 설정합니다.

scale-compute 또는 scale-Storage와 같은 다른 사용자 시작 작업의 경우 프로세스는 먼저 대기에 변경 내용을 적용한 다음 기본 작업을 적용합니다. 현재 서비스는 스탠바이 서버로 페일오버되지 않습니다. 따라서 크기 조정 작업이 주 서버에서 실행되는 동안 애플리케이션은 짧은 가동 중지 시간이 발생합니다.

또한 이 기능을 사용하여 대기 서버로 장애 조치(failover)해 가동 중지 시간을 줄일 수 있습니다. 예를 들어 기본 서버는 계획되지 않은 장애 조치(failover) 후 애플리케이션과 다른 가용성 영역에 있을 수 있습니다. 주 서버를 이전 영역으로 다시 가져와서 애플리케이션과 공동 배치하려고 합니다.

이 기능을 실행할 때 프로세스는 먼저 대기 서버를 준비하여 최근 트랜잭션을 따라잡을 수 있도록 하여 애플리케이션이 읽기 및 쓰기를 계속 수행할 수 있도록 합니다. 이 프로세스는 대기 서버를 활성화하고 기본 서버와의 연결을 끊습니다. 프로세스가 백그라운드에서 새 대기 서버를 설정하는 동안 애플리케이션은 주 데이터베이스에 계속 쓸 수 있습니다. 다음 표에서는 계획된 장애 조치(failover)와 관련된 단계를 설명합니다.

애플리케이션 가동 중지 시간은 3단계에서 시작되며 5단계 후에 작업을 다시 시작할 수 있습니다. 나머지 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 발생합니다.

가능한 계획된 가동 중지 시간 이벤트 목록은 계획된 가동 중지 시간 이벤트를 참조하세요.

계획되지 않은 장애 조치

기본 하드웨어 오류, 네트워킹 문제 및 소프트웨어 버그와 같은 예기치 않은 중단으로 인해 계획되지 않은 가동 중지 시간이 발생할 수 있습니다. 고가용성으로 구성된 데이터베이스 서버가 예기치 않게 중단되면 프로세스는 대기 복제본을 활성화하고 클라이언트는 작업을 다시 시작할 수 있습니다. HA(고가용성)를 구성하지 않고 다시 시작 시도가 실패하면 프로세스가 자동으로 새 데이터베이스 서버를 프로비전합니다. 계획되지 않은 가동 중지 시간을 피할 수는 없지만 유연한 서버는 사람의 개입 없이 복구 작업을 자동으로 수행하여 가동 중지 시간을 완화하는 데 도움이 됩니다.

가능한 시나리오를 포함하여 계획되지 않은 장애 조치(failover) 및 가동 중지 시간에 대한 자세한 내용은 계획되지 않은 가동 중지 시간 완화를 참조하세요.

장애 조치(failover) 테스트(강제 장애 조치)

강제 장애 조치(failover)를 사용하면 프로덕션 워크로드를 실행하는 동안 계획되지 않은 중단 시나리오를 시뮬레이션하고 애플리케이션 가동 중지 시간을 관찰할 수 있습니다. 주 서버가 응답하지 않을 때 강제 장애 조치(failover)를 사용할 수도 있습니다.

강제 장애 조치(failover)는 주 서버를 중단시키고 대기 승격 작업이 수행되는 장애 조치(failover) 워크플로를 시작합니다. 대기가 마지막으로 커밋된 데이터까지 복구 프로세스를 완료하면 기본 서버로 승격됩니다. DNS 레코드가 업데이트되고 애플리케이션은 승격된 주 서버에 연결할 수 있습니다. 새로운 대기 서버가 백그라운드에서 설정되고 가동 시간에 영향을 미치지 않는 동안 애플리케이션은 계속해서 주 서버에 쓸 수 있습니다.

다음 표는 강제 전환 중의 단계를 설명합니다.

애플리케이션 가동 중지 시간은 1단계 후에 시작되며 6단계가 완료될 때까지 계속됩니다. 다른 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 실행됩니다.

강제 장애 조치(failover) 수행 시 고려 사항

• 전체 엔드 투 엔드 작업 시간은 애플리케이션에서 경험하는 실제 가동 중지 시간보다 길 수 있습니다.

  중요합니다

  항상 애플리케이션 관점에서 가동 중지 시간을 관찰합니다.

• 장애 조치(failover)를 연속해서 바로 수행하지 마세요. 새 대기 서버를 완전히 설정할 수 있도록 장애 조치(failover) 사이에 15-20분 이상 기다립니다.

• 작업량이 적은 기간 동안 강제 장애 조치(failover)를 수행하여 가동 중지 시간을 줄입니다.

장애 조치(failover) 후 PostgreSQL 통계에 대한 모범 사례

PostgreSQL 장애 조치(failover) 후 최적의 데이터베이스 성능을 유지하려면 pg_statistic 및 pg_stat_* 테이블의 고유한 역할을 이해해야 합니다. 이 테이블은 pg_statistic 쿼리 플래너에 중요한 최적화 프로그램 통계를 저장합니다. 이러한 통계에는 테이블 내의 데이터 배포가 포함되며 장애 조치(failover) 후에도 그대로 유지되므로 쿼리 계획 도구가 정확한 기록 데이터 배포 정보를 기반으로 쿼리 실행을 계속 효과적으로 최적화할 수 있습니다.

반면, pg_stat_* 스캔 수, 읽은 튜플 및 업데이트와 같은 활동 통계를 기록하는 테이블은 장애 조치 시 초기화됩니다. 이러한 테이블의 예로는 사용자 정의 테이블의 작업을 추적하는 pg_stat_user_tables가 있습니다. 이 재설정은 새로운 주 서버의 운영 상태를 정확하게 반영하지만, 자동 진공 프로세스 및 기타 운영 효율성에 정보를 제공할 수 있는 역사적 활동 메트릭이 손실된다는 의미도 포함합니다.

이를 고려하여 PostgreSQL 장애 조치(failover) 후에 ANALYZE을 실행합니다. 이 작업은 pg_stat_*와 같은 pg_stat_user_tables 테이블을 최신 작업 통계로 업데이트하여 자동 진공 프로세스를 돕고 데이터베이스 성능이 새 역할에서 최적으로 유지되도록 보장합니다. 이러한 자동 관리 단계는 필수 최적화 메트릭을 보존하고 작업 메트릭을 새로 고쳐 데이터베이스의 현재 상태에 맞추는 간의 간격을 메웁니다.

영역 축소 경험

영역: 영역 수준 오류에서 복구하려면 백업을 사용하여 특정 시점 복원을 수행할 수 있습니다. 최신 시간의 사용자 지정 복원 지점을 선택하여 최신 데이터를 복원할 수 있습니다. 새 유연한 서버가 영향을 받지 않는 또 다른 영역에 배포됩니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그의 양에 따라 달라집니다.

특정 시점 복원에 대한 자세한 내용은 Azure Database for PostgreSQL-유연한 서버의 백업 및 복원을 참조하세요.

영역 중복: 유연한 서버는 데이터가 손실되지 않으면서 60-120초 이내에 자동으로 대기 서버로 전환됩니다.

가용성 영역을 사용하지 않는 구성

권장되지는 않지만 고가용성을 사용하도록 설정하지 않고 유연한 서버를 구성할 수 있습니다. 고가용성 없이 구성된 유연한 서버의 경우 서비스는 세 개의 데이터 복사본, 영역 중복 백업(지원되는 지역에서) 및 기본 제공 서버 복원력을 사용하여 로컬 중복 스토리지를 제공하여 충돌된 서버를 자동으로 다시 시작하고 서버를 다른 실제 노드로 재배치합니다. 이 구성은 99.9%가동 시간 SLA 를 제공합니다. 계획되거나 계획되지 않은 장애 조치(failover) 이벤트 중에 서버가 중단되면 서비스는 다음 자동화된 절차를 사용하여 서버의 가용성을 유지 관리합니다.

1. 새 컴퓨팅 Linux VM이 프로비저닝됩니다.
2. 데이터 파일이 있는 스토리지가 새 가상 머신에 매핑됩니다.
3. 새 가상 머신에서 PostgreSQL 데이터베이스 엔진이 온라인 상태로 전환됩니다.

다음 그림에서는 VM과 스토리지 오류 간의 전환을 보여 줍니다.

지역 간 재해 복구 및 비즈니스 연속성

지역 전체 재해의 경우 Azure는 다른 지역을 사용하여 재해 복구를 통해 지역 또는 대규모 지리 재해로부터 보호를 제공할 수 있습니다. Azure 재해 복구 아키텍처에 대한 자세한 내용은 Azure 간 재해 복구 아키텍처를 참조하세요.

유연한 서버는 계획된 가동 중지 시간 및 계획되지 않은 가동 중지 시간 이벤트 중에 데이터를 보호하고 중요 업무용 데이터베이스의 가동 중지 시간을 완화하는 기능을 제공합니다. 강력한 복원력과 가용성을 제공하는 Azure 인프라 위에 빌드된 유연한 서버는 장애 보호를 제공하고 복구 시간 요구 사항을 해결하며 데이터 손실 노출을 줄이는 비즈니스 연속성 기능을 제공합니다. 애플리케이션을 설계할 때 RTO(복구 시간 목표) 및 데이터 손실 노출인 RPO(복구 지점 목표)의 가동 중지 시간 허용 시간을 고려합니다. 예를 들어, 중요 비즈니스용 데이터베이스는 테스트 데이터베이스보다 엄격한 가동 시간이 필요합니다.

다중 지역 지리의 재해 복구

지역 중복 백업 및 복원

지역 중복 백업 및 복원을 사용하면 재해가 발생할 경우 다른 지역에서 서버를 복원할 수 있습니다. 또한 1년 동안 백업 개체에 대해 최소 99.99999999999999%(16개의 9) 내구성을 제공합니다.

서버를 만들 때만 지역 중복 백업을 구성할 수 있습니다. 지역 중복 백업을 사용하여 서버를 구성하면 백업 데이터 및 트랜잭션 로그가 스토리지 복제를 통해 쌍을 이루는 지역에 비동기적으로 복사됩니다.

지역 중복 백업 및 복원에 대한 자세한 내용은 지역 중복 백업 및 복원을 참조하세요.

읽기 복제본

지역 간 읽기 복제본을 배포하여 지역 수준 오류로부터 데이터베이스를 보호할 수 있습니다. 읽기 복제본은 PostgreSQL의 물리적 복제 기술을 사용하여 비동기적으로 업데이트되며 주 복제본을 지연할 수 있습니다. 범용 및 메모리 최적화 컴퓨팅 계층은 읽기 복제본을 지원합니다.

읽기 복제본 기능 및 고려 사항에 대한 자세한 내용은 읽기 복제본을 참조하세요.

중단 검색, 알림 및 관리

지역 중복 백업을 사용하여 서버를 구성하는 경우 쌍을 이루는 지역에서 지역 복원을 수행할 수 있습니다. 새 서버가 프로비전되고, 이 지역에 복사된 마지막으로 사용 가능한 데이터로 복구됩니다.

지역 간 읽기 복제본을 사용할 수도 있습니다. 지역 오류가 발생하는 경우 읽기 복제본을 독립 실행형 읽기/쓰기 가능 서버로 승격하여 재해 복구 작업을 수행할 수 있습니다. RPO가 실패 시 복제 지연에 근접할 수 있는 경우 심각한 지역 오류를 제외하고 RPO는 최대 5분(데이터 손실 가능)이 될 것으로 예상됩니다.

지역 재해 후 계획되지 않은 가동 중지 시간 완화 및 복구에 대한 자세한 내용은 계획되지 않은 가동 중지 시간 완화를 참조하세요.

관련 콘텐츠

• Azure Database for PostgreSQL 설명서
• Azure의 안정성