Azure Database for PostgreSQL - 유연한 서버의 고가용성 개념
적용 대상:
Azure Database for PostgreSQL - 유연한 서버
Azure Database for PostgreSQL - 유연한 서버는 자동 장애 조치(failover) 기능이 있는 고가용성 구성을 제공합니다. 고가용성 솔루션은 커밋된 데이터가 오류로 인해 손실되지 않도록 하고 데이터베이스가 아키텍처에서 단일 실패 지점이 되지 않도록 설계되었습니다. 고가용성이 구성되면 유연한 서버가 자동으로 대기를 프로비저닝하고 관리합니다. WAL(미리 쓰기 로그)은 PostgreSQL 스트리밍 복제를 사용하여 동기 모드로 복제본에 스트리밍됩니다. 다음 두 가지의 고가용성 아키텍처 모델이 있습니다.
- 영역 중복 HA: 이 옵션은 한 지역 내에 있는 여러 가용성 영역에서 인프라의 완전한 격리 및 중복도를 제공합니다. 가장 높은 수준의 가용성을 제공하지만 가용성 영역에서 애플리케이션 중복성을 구성해야 합니다. 가용성 영역 오류로부터 보호하려는 경우 영역 중복 HA를 사용하는 것이 좋습니다. 그러나 교차 AZ 동기 쓰기에 대한 추가 대기 시간을 고려해야 합니다. 이 대기 시간은 짧은 기간 트랜잭션이 있는 애플리케이션에 대해 더 두드러집니다. 영역 중복 HA는 지역이 여러 가용성 영역을 지원하는 Azure 지역의 하위 집합에서 사용할 수 있습니다. 이 구성에서는 작동 시간 99.99%의 SLA가 제공됩니다.
- 동일한 영역 HA: 이 옵션은 기본 및 대기 서버가 동일한 가용성 영역에 있기 때문에 네트워크 대기 시간이 짧은 인프라 중복성을 제공합니다. 영역 간에 애플리케이션 중복도를 구성하지 않아도 고가용성을 제공합니다. 단일 가용성 영역 내에서 가장 높은 수준의 가용성을 달성하려는 경우 동일한 영역 HA가 선호됩니다. 이 옵션은 대기 시간 영향을 줄이지만 애플리케이션을 영역 오류에 취약하게 만듭니다. 동일 영역 HA는 유연한 서버를 배포할 수 있는 모든 Azure 지역에서 사용할 수 있습니다. 이 구성에서는 작동 시간 99.95%의 SLA가 제공됩니다.
고가용성 구성을 사용하면 계획된/계획되지 않은 이벤트 중에 데이터 손실이 없는 자동 장애 조치(failover) 기능(예: RPO=0)을 사용할 수 있습니다. 예를 들어 계획되지 않은 이벤트는 기본 하드웨어 및 소프트웨어 오류, 네트워크 오류 및 가용성 영역 오류와 같은 오류를 참조하는 동안에도 사용자가 시작한 크기 조정 컴퓨팅 작업은 계획된 장애 조치(failover)입니다.
참고
이러한 HA 배포 모델은 모두 구조적으로 동일하게 작동합니다. 다음 섹션의 다양한 논의는 달리 명시되지 않는 한 두 모델 모두에 적용할 수 있습니다.
고가용성 아키텍처
앞에서 설명한 것처럼 Azure Database for PostgreSQL 유연한 서버는 영역 중복 HA 및 동일한 영역 HA라는 두 가지 고가용성 배포 모델을 지원합니다. 두 배포 모델 모두에서 애플리케이션이 트랜잭션을 커밋할 때 트랜잭션 로그(WAL이라고도 하는 쓰기 로그)는 데이터/로그 디스크에 기록되고 동기 모드로 대기 서버에 복제됩니다. 로그가 대기에 유지되면 트랜잭션이 커밋된 것으로 간주되고 승인이 애플리케이션으로 전송됩니다. 대기 서버는 항상 트랜잭션 로그를 적용하는 복구 모드입니다. 그러나 주 서버는 대기 상태가 이러한 로그 레코드를 적용할 때까지 기다리지 않습니다. 과도한 트랜잭션 워크로드에서 복제본 서버는 뒤쳐질 수 있지만 일반적으로 워크로드 처리량 변동으로 주 서버까지 따라잡을 수 있습니다.
영역 중복 고가용성
이 고가용성 배포를 사용하면 가용성 영역에서 유연한 서버를 고가용성으로 사용할 수 있습니다. 기본 복제본과 대기 서버의 지역, 가용성 영역을 선택할 수 있습니다. 대기 복제본 서버는 주 서버와 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 사용하여 동일한 지역의 선택된 가용성 영역에서 프로비전됩니다. 데이터 파일 및 트랜잭션 로그 파일(미리 쓰기 로그, WAL)은 각 가용성 영역 내의 LRS(로컬 중복 스토리지)에 저장되며 자동으로 3개 데이터 복사본을 저장합니다. 이렇게 하면 주 서버와 대기 서버 간에 전체 스택을 물리적으로 격리할 수 있습니다.
참고
모든 지역에서 영역 중복 고가용성을 배포할 가용성 영역을 지원하지는 않습니다. 이 Azure 지역 목록을 참조하세요.
자동 백업은 주 데이터베이스 서버에서 주기적으로 수행되고 트랜잭션 로그는 대기 복제본에서 백업 스토리지로 지속적으로 보관됩니다. 백업 데이터는 영역 중복 스토리지에 저장됩니다.
동일한 영역의 고가용성
이 고가용성 배포 모델을 사용하면 유연한 서버를 동일한 가용성 영역 내에서 고가용성으로 사용할 수 있습니다. 이는 가용성 영역을 지원하지 않는 지역을 포함하여 모든 지역에서 지원됩니다. 지역 및 가용성 영역을 선택하여 기본 데이터베이스 서버를 배포할 수 있습니다. 대기 서버는 주 서버와 비슷한 컴퓨팅, 스토리지 및 네트워크 구성을 사용하여 동일한 지역의 동일한 가용성 영역에서 자동으로 프로비전되고 관리됩니다. 데이터 파일 및 트랜잭션 로그 파일(WAL이라고도 하는 쓰기 로그)은 로컬 중복 스토리지에 저장되며, 기본 및 대기에 대해 각각 3개의 동기 데이터 복사본으로 자동으로 저장됩니다. 이렇게 하면 동일한 가용성 영역 내에서 주 서버와 대기 서버 간에 전체 스택을 물리적으로 격리할 수 있습니다.
자동 백업은 주 데이터베이스 서버에서 주기적으로 수행되고 트랜잭션 로그는 대기 복제본에서 백업 스토리지로 지속적으로 보관됩니다. 지역에서 가용성 영역을 지원하는 경우 백업 데이터가 ZRS(영역 중복 스토리지)에 저장됩니다. 가용성 영역을 지원하지 않는 지역에서 백업 데이터는 LRS(로컬 중복 스토리지)에 저장됩니다.
구성 요소 및 워크플로
트랜잭션 완료
애플리케이션 트랜잭션이 트리거한 쓰기 및 커밋은 먼저 주 서버의 WAL에 로그됩니다. 그런 다음, Postgres 스트리밍 프로토콜을 사용하여 대기 서버로 스트리밍됩니다. 로그가 대기 서버 스토리지에 지속되면 주 서버에 쓰기 완료가 승인됩니다. 그런 다음에만 애플리케이션에 쓰기가 확인됩니다. 이 추가 왕복은 애플리케이션에 대기 시간을 더 추가합니다. 영향의 정도는 애플리케이션에 따라 달라집니다. 이 승인 프로세스는 로그가 대기 서버에 적용될 때까지 대기하지 않습니다. 대기 서버는 승격될 때까지 영구적으로 복구 모드에 있습니다.
상태 확인
유연한 서버에는 주 및 대기 상태를 주기적으로 확인하는 상태 모니터링이 있습니다. 여러 ping 후에 주 서버에 연결할 수 없는 경우 자동 장애 조치(failover)를 시작할지 여부를 결정합니다. 이 알고리즘은 가양성 상황을 방지하기 위해 여러 데이터 요소를 기반으로 합니다.
장애 조치(failover) 모드
두 가지 장애 조치(failover) 모드가 있습니다.
주 연결이 드레이닝된 것으로 알려진 상태로 장애 조치(failover)가 트리거되는 계획된 장애 조치(failover)(예: 유지 관리 기간 중)를 사용하면 복제가 중단되기 전에 완전한 종료가 수행됩니다. 주 서버를 기본 AZ로 다시 가져오는 데 이를 사용할 수도 있습니다.
계획되지 않은 장애 조치(failover)(예: 주 서버 노드 크래시)를 사용하면 주 서버가 즉시 펜스되므로 진행 중인 모든 트랜잭션이 손실되고 애플리케이션에서 다시 시도합니다.
두 장애 조치(failover) 모드에서 복제가 중단되면 대기 서버가 복구를 실행한 후 주 서버로 승격되고 읽기/쓰기를 위해 열립니다. 자동 DNS 항목이 새 주 서버 엔드포인트로 업데이트되면 애플리케이션은 동일한 서버 엔드포인트를 사용하여 서버에 연결할 수 있습니다. 새 대기 서버가 백그라운드에서 설정되며 애플리케이션 연결을 차단하지 않습니다.
가동 중지 시간
모든 경우에 애플리케이션/클라이언트 쪽에서 가동 중지 시간을 관찰해야 합니다. 애플리케이션은 DNS가 업데이트되는 즉시 장애 조치(failover) 후 다시 연결할 수 있습니다. 쓰기를 펜싱하기 전에 기본 및 대기 간의 LSN 비교를 포함하여 몇 가지 측면을 더 처리합니다. 그러나 계획되지 않은 장애 조치(failover)를 사용하면 읽기/쓰기를 위해 열기 전에 복구해야 하는 로그의 양 때문에 대기 시간이 2분보다 길어질 수 있습니다.
HA 상태
주 서버와 대기 서버의 상태가 지속적으로 모니터링되며 대기 서버로 장애 조치를 트리거하는 등의 문제를 해결하기 위해 적절한 작업이 수행됩니다. 고가용성 상태는 다음과 같습니다.
| Status | 설명 |
|---|---|
| 초기화하는 중 | 새로운 대기 서버를 만드는 과정에서 |
| 데이터 복제 중 | 대기 서버를 만든 후에 주 서버의 데이터를 받는 중입니다. |
| 정상 | 복제가 정상 상태이며 정상입니다. |
| 장애 조치(Failover) | 데이터베이스 서버가 대기 서버로 장애 조치(failover)하는 프로세스 중에 있습니다. |
| 대기 제거 | 대기 서버를 삭제하는 중입니다. |
| 사용 안 함 | 영역 중복 고가용성이 사용하도록 설정되어 있지 않습니다. |
참고
서버를 만드는 동안 또는 나중에 고가용성을 사용하도록 설정할 수도 있습니다. 만들기 이후 단계에서 고가용성을 사용하거나 사용하지 않도록 설정하는 경우 주 서버 작업이 적을 때 작업을 수행하는 것이 좋습니다.
정상 상태 작업
PostgreSQL 클라이언트 애플리케이션은 DB 서버 이름을 사용하여 주 서버에 연결됩니다. 애플리케이션 읽기는 주 서버에서 직접 제공되는 반면 커밋 및 쓰기는 로그 데이터가 주 서버와 대기 복제본 모두에서 유지된 후에만 애플리케이션에 적용됩니다. 이러한 추가 왕복으로 인해 애플리케이션은 쓰기 및 커밋에 대한 대기 시간이 증가할 것으로 예상할 수 있습니다. 포털에서 고가용성의 상태를 모니터링할 수 있습니다.
- 클라이언트는 유연한 서버에 연결하고 쓰기 작업을 수행합니다.
- 변경 사항은 대기 사이트에 복제됩니다.
- 주 서버는 승인을 받습니다.
- 쓰기/커밋이 승인됩니다.
장애 조치(failover) 프로세스 - 계획된 가동 중지 시간
계획된 가동 중지 시간 이벤트에는 Azure 예약 정기 소프트웨어 업데이트 및 사소한 버전 업그레이드가 포함됩니다. 고가용성으로 구성된 경우 이러한 작업은 애플리케이션이 주 서버에 계속 액세스하는 동안 먼저 대기 복제본에 적용됩니다. 대기 복제본이 업데이트되면 주 서버 연결이 비워지고 동일한 데이터베이스 서버 이름의 주 서버가 되도록 대기 복제본을 활성화하는 장애 조치(failover)가 트리거됩니다. 클라이언트 애플리케이션은 동일한 데이터베이스 서버 이름으로 새 주 서버에 다시 연결해야 하며 작업을 재개할 수 있습니다. 새 대기 서버는 이전 주 서버와 동일한 영역에 설정됩니다.
scale-compute 또는 scale-storage와 같은 다른 사용자 시작 작업의 경우 변경 사항은 대기에 먼저 적용되고 그 다음에 주 서버에 적용됩니다. 현재 서비스가 대기 상태로 장애 조치되지 않으므로 주 서버에서 스케일링 작업이 수행되는 동안 애플리케이션에서 짧은 가동 중지 시간이 발생합니다.
관리되는 유지 관리 기간으로 계획된 가동 중지 시간 감소
유연한 서버를 사용하면 데이터베이스에 대한 작업이 적을 것으로 예상되는 날짜에 60분의 기간을 선택하여 Azure에서 시작한 유지 관리 작업을 필요에 따라 예약할 수 있습니다. 패치 또는 부 버전 업그레이드와 같은 Azure 유지 관리 작업이 해당 유지 관리 기간에 수행됩니다. 사용자 지정 기간을 선택하지 않으면 현지 시간으로 오후 11시에서 오전 7시 사이에 시스템이 할당한 1시간이 서버에 대해 선택됩니다.
고가용성으로 구성된 유연한 서버에서는 이러한 유지 관리 작업이 대기 복제본에서 먼저 수행되고 서비스는 애플리케이션이 다시 연결할 수 있는 대기 복제본으로 장애 조치됩니다.
장애 조치(failover) 프로세스 - 계획되지 않은 가동 중지 시간
- 계획되지 않은 중단에는 데이터베이스의 가용성에 영향을 주는 소프트웨어 버그 또는 인프라 구성 요소 오류가 포함됩니다. 주 서버를 사용할 수 없게 되면 모니터링 시스템에서 이를 검색하고 장애 조치(failover) 프로세스를 시작합니다. 이 프로세스에는 가양성이 아닌지 확인하기 위해 몇 초의 대기 시간이 포함됩니다. 대기 복제본에 대한 복제가 중단되고 대기 복제본이 주 데이터베이스 서버로 활성화됩니다. 여기에는 남은 WAL 파일을 복구하기 위한 대기가 포함됩니다. 완전히 복구되면 동일한 엔드포인트에 대한 DNS가 대기 서버의 IP 주소로 업데이트됩니다. 그러면 클라이언트는 동일한 연결 문자열을 사용하여 데이터베이스 서버에 연결을 다시 시도하고 작업을 다시 시작할 수 있습니다.
참고
영역 중복 고가용성으로 구성된 유연한 서버는 0(데이터 손실 없음)의 RPO(복구 지점 목표)를 제공합니다. RTO(복구 시간 목표)는 일반적인 경우에 120초 미만으로 예상됩니다. 그러나 장애 조치 시 주 데이터베이스 서버의 작업에 따라 장애 조치가 더 오래 걸릴 수 있습니다.
장애 조치(failover) 후 새 대기 서버를 프로비전하는 동안(일반적으로 5-10분 소요) 애플리케이션은 계속 주 서버에 연결하고 읽기/쓰기 작업을 진행할 수 있습니다. 대기 서버가 설정되면 장애 조치 후 생성된 로그 복구를 시작합니다.
- 주 데이터베이스 서버가 중단되고 클라이언트의 데이터베이스 연결이 끊어집니다.
- 대기 서버가 활성화되어 새 주 서버가 됩니다. 클라이언트는 동일한 연결 문자열을 사용하여 새 주 서버에 연결합니다. 클라이언트 애플리케이션이 주 데이터베이스 서버와 동일한 영역에 있으면 대기 시간이 줄어들고 성능이 향상됩니다.
- 대기 서버는 기존 주 서버와 동일한 영역에 구축되며 스트리밍 복제가 시작됩니다.
- 정상 상태 복제가 설정되면 데이터가 두 사이트에 모두 유지된 후 클라이언트 애플리케이션이 커밋되고 쓰기가 승인됩니다.
주문형 장애 조치
유연한 서버는 대기 서버에 대해 주문형 장애 조치를 수행할 수 있는 두 가지 방법을 제공합니다. 이러한 방법은 애플리케이션에 대한 장애 조치(failover) 시간 및 가동 중지 시간 영향을 테스트하고 기본 가용성 영역으로 장애 조치(failover)하려는 경우에 유용합니다.
강제 장애 조치(failover)
이 기능을 사용하여 프로덕션 워크로드를 실행하는 동안 계획되지 않은 중단 시나리오를 시뮬레이션하고 애플리케이션 가동 중지 시간을 관찰할 수 있습니다. 또는 드문 경우지만 주 서버가 어떤 이유로든 응답하지 않는 경우 이 기능을 사용할 수 있습니다.
이 기능은 주 서버를 중단시키고 대기 승격 작업이 수행되는 장애 조치 워크플로를 시작합니다. 대기 서버가 마지막으로 커밋된 데이터까지 복구 프로세스를 완료하면 주 서버로 승격됩니다. DNS 레코드가 업데이트되고 애플리케이션은 승격된 주 서버에 연결할 수 있습니다. 새로운 대기 서버가 백그라운드에서 설정되고 가동 시간에 영향을 미치지 않는 동안 애플리케이션은 계속해서 기본 서버에 쓸 수 있습니다.
다음은 강제 장애 조치(failover) 중 단계입니다.
| Step | 설명 | 가동 중지 시간 예상 여부 |
|---|---|---|
| 1 | 주 서버가 장애 조치 요청이 수신된 직후에 중지됩니다. | 예 |
| 2 | 주 서버가 다운되면 애플리케이션에서 가동 중지 시간이 발생합니다. | 예 |
| 3 | 내부 모니터링 시스템에서 오류를 감지하고 대기 서버로 장애 조치를 시작합니다. | 예 |
| 4 | 독립 서버로 완전히 승격되기 전에 대기 서버가 복구 모드로 들어갑니다. | Yes |
| 5 | 장애 조치 프로세스는 대기 복구가 완료될 때까지 대기합니다. | 예 |
| 6 | 서버가 시작되면 DNS 레코드가 동일한 호스트 이름을 사용하지만 대기 서버의 IP 주소를 사용하여 업데이트됩니다. | 예 |
| 7 | 애플리케이션은 새 주 서버에 다시 연결하고 작업을 다시 시작할 수 있습니다. | 예 |
| 8 | 기본 영역에 대기 서버가 설정됩니다. | 예 |
| 9 | 대기 서버가 설정 중에 누락된 로그(Azure BLOB)를 복구하기 시작합니다. | 예 |
| 10 | 주 서버와 대기 서버 간에 안정적인 상태가 설정됩니다. | 예 |
| 11 | 강제 장애 조치 프로세스가 완료되었습니다. | No |
애플리케이션 가동 중지 시간은 #1단계 후에 시작되며 #6단계가 완료될 때까지 유지됩니다. 나머지 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 발생합니다.
중요
엔드투엔드 장애 조치(failover) 프로세스에는(a) 1차 장애 후 대기 서버로의 장애 조치(failover) 및(b) 안정적인 상태의 새 대기 서버 설정이 포함됩니다. 대기 모드로의 장애 조치(failover)가 완료될 때까지만 애플리케이션 가동 중지 시간이 발생하므로 전체 엔드투엔드 장애 조치(failover) 프로세스 대신 애플리케이션/클라이언트 관점에서 가동 중지 시간을 측정하세요 .
계획된 장애 조치
이 기능을 사용하면 대기 서버로 장애 조치하여 가동 중지 시간을 줄일 수 있습니다. 예를 들어 계획되지 않은 장애 조치 후 주 서버가 애플리케이션과 다른 가용성 영역에 있을 수 있으므로 주 서버를 이전 영역으로 다시 가져와서 애플리케이션과 공동 배치하려고 합니다.
이 기능을 실행하면 애플리케이션이 읽기/쓰기를 계속 수행할 수 있도록 하는 최근 트랜잭션을 사용할 수 있도록 대기 서버가 먼저 준비됩니다. 그런 다음 대기가 승격되고 기본에 대한 연결이 끊어집니다. 새 대기 서버가 백그라운드에서 설정되는 동안 애플리케이션은 주 서버에 계속 쓸 수 있습니다. 다음은 계획된 장애 조치와 관련된 단계입니다.
| Step | 설명 | 가동 중지 시간 예상 여부 |
|---|---|---|
| 1 | 대기 서버가 주 서버와 일치될 때까지 대기합니다. | 예 |
| 2 | 내부 모니터링 시스템에서 장애 조치 워크플로를 시작합니다. | 예 |
| 3 | 대기 서버가 주 LSN(로그 시퀀스 번호)에 가까워지면 애플리케이션 쓰기가 차단됩니다. | 예 |
| 4 | 대기 서버가 독립 서버로 승격됩니다. | Yes |
| 5 | DNS 레코드가 새 대기 서버의 IP 주소로 업데이트됩니다. | 예 |
| 6 | 애플리케이션은 새 주 서버와 다시 연결하고 읽기/쓰기를 다시 시작합니다. | 예 |
| 7 | 다른 영역에 새 대기 서버가 설정됩니다. | 예 |
| 8 | 대기 서버가 설정 중에 누락된 로그(Azure BLOB)를 복구하기 시작합니다. | 예 |
| 9 | 주 서버와 대기 서버 간에 안정적인 상태가 설정됩니다. | 예 |
| 10 | 계획된 장애 조치 프로세스가 완료되었습니다. | No |
애플리케이션 가동 중지 시간은 #3단계에서 시작되고 #5단계 후 작업을 다시 시작할 수 있습니다. 나머지 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 발생합니다.
주문형 장애 조치를 수행하는 동안 고려 사항
- 전체 엔드투엔드 작업 시간이 애플리케이션에서 발생하는 실제 가동 중지 시간보다 길 수 있습니다. 애플리케이션 관점에서 가동 중지 시간을 관찰하세요.
- 장애 조치를 연속해서 바로 수행하지는 마세요. 장애 조치 사이에 최소 15~20분 동안 기다리면 새 대기 서버를 완전히 설정할 수 있습니다.
- 가동 중지 시간이 감소된 계획된 장애 조치의 경우 작업이 적은 기간 동안 수행하는 것이 좋습니다.
고가용성 관리에 대해서는 이 가이드를 참조하세요.
HA 서버의 특정 시점 복원
고가용성으로 구성된 유연한 서버에서는 데이터가 실시간으로 대기 서버에 복제됩니다. 실수로 테이블을 삭제하거나 잘못된 데이터 업데이트와 같은 주 서버의 모든 사용자 오류는 대기 복제본에도 복제됩니다. 따라서 이러한 논리적 오류를 복구하기 위해 대기를 사용할 수 없습니다. 이러한 오류를 복구하려면 백업을 통해 특정 시점 복원을 수행해야 합니다. 유연한 서버의 특정 시점 복원 기능을 사용하여 오류가 발생하기 전의 시간으로 복원할 수 있습니다. 고가용성으로 구성된 데이터베이스의 경우 새 데이터베이스 서버는 사용자가 제공한 새 서버 이름을 사용하는 단일 영역 유연한 서버로 복원됩니다. 복원된 서버는 몇 가지 사용 사례에 사용할 수 있습니다.
- 프로덕션 사용을 위해 복원된 서버를 사용할 수 있으며 필요에 따라 영역 중복 고가용성을 사용하도록 설정할 수 있습니다.
- 개체를 복원하려는 경우 복원된 데이터베이스 서버에서 개체를 내보내고 프로덕션 데이터베이스 서버로 가져올 수 있습니다.
- 테스트 및 개발 목적으로 데이터베이스 서버를 복제하거나 다른 목적으로 복원하려는 경우 특정 시점 복원을 수행할 수 있습니다.
고가용성 - 특징
대기 복제본은 vCore, 스토리지, 네트워크 설정(VNET, 방화벽) 등을 포함하여 주 서버와 동일한 VM 구성으로 배포됩니다.
기존 데이터베이스 서버에 대해 고가용성을 추가할 수 있습니다.
고가용성을 사용하지 않도록 설정하여 대기 복제본을 제거할 수 있습니다.
영역 중복 HA의 경우 주 및 대기 데이터베이스 서버에 대한 가용성 영역을 선택할 수 있습니다.
중지, 시작, 다시 시작과 같은 작업은 주 데이터베이스 서버와 대기 데이터베이스 서버 모두에서 동시에 수행됩니다.
자동 백업은 주 데이터베이스 서버에서 수행되고 영역 중복 백업 스토리지에 저장됩니다.
클라이언트는 항상 주 데이터베이스 서버의 엔드 호스트 이름에 연결합니다.
서버 매개 변수에 대한 모든 변경 내용은 대기 복제본에도 적용됩니다.
서버를 다시 시작하여 정적 서버 매개 변수의 변경 내용을 선택할 수 있습니다.
사소한 버전 업그레이드와 같은 주기적인 유지 관리 작업은 대기 상태에서 먼저 발생하고 서비스가 장애 조치(failover)되어 가동 중지 시간을 줄입니다.
고가용성 - 제한 사항
버스트 가능한 컴퓨팅 계층에서는 고가용성이 지원되지 않습니다.
고가용성은 여러 영역을 사용할 수 있는 지역에서만 지원됩니다.
특히 영역 중복 HA를 사용하는 대기 서버에 대한 동기 복제로 인해 애플리케이션의 쓰기 및 커밋 대기 시간이 길어질 수 있습니다.
읽기 쿼리에는 대기 복제본을 사용할 수 없습니다.
주 서버의 워크로드 및 작업에 따라 승격되기 전에 대기 복제본에서 수행되어야 하는 복구 작업으로 인해 장애 조치 프로세스 시간이 120초보다 오래 걸릴 수 있습니다.
대기 서버는 일반적으로 40MB/s의 속도로 WAL 파일을 복구합니다. 워크로드가 이 제한을 초과하는 경우 장애 조치(failover) 중이나 새 대기를 설정한 후 복구를 완료하는 데 시간이 오래 걸릴 수 있습니다.
주 데이터베이스 서버를 다시 시작하면 대기 복제본도 다시 시작됩니다.
추가 대기 구성은 지원되지 않습니다.
관리되는 유지 관리 기간 중에는 고객이 시작한 관리 작업 구성을 예약할 수 없습니다.
확장 컴퓨팅 및 확장 스토리지와 같은 계획된 이벤트는 먼저 대기 서버에서 발생한 다음 주 서버에서 발생합니다. 현재 서버는 이러한 계획된 작업에 대해 장애 조치(failover)를 취하지 않습니다.
HA로 구성된 유연한 서버로 논리적 디코딩 또는 논리적 복제를 구성한 경우 대기 서버로 장애 조치(failover) 시 논리적 복제 슬롯이 대기 서버로 복사되지 않습니다.
HA가 아닌 서버에 대한 가용성
고가용성 없이 구성된 유연한 서버의 경우 서비스는 계획되거나 계획되지 않은 가동 중지 시간 이벤트에서 복구하는 데 도움이 되는 기본 제공 가용성, 스토리지 중복, 복원력을 제공합니다. 이 비 HA 구성에서는 작동 시간 99.9%의 SLA가 제공됩니다.
계획되거나 계획되지 않은 장애 조치(failover) 이벤트가 발생하는 동안 서버가 다운되면 서비스는 다음과 같은 자동화된 절차를 사용하여 서버의 고가용성을 유지합니다.
- 새 컴퓨팅 Linux VM이 프로비저닝됩니다.
- 데이터 파일이 있는 스토리지가 새 가상 머신에 매핑됩니다.
- 새 가상 머신에서 PostgreSQL 데이터베이스 엔진이 온라인 상태로 전환됩니다.
아래 그림은 VM 및 스토리지 오류에 대한 전환을 보여 줍니다.
계획된 가동 중지 시간
다음은 몇 가지 계획된 유지 관리 시나리오입니다.
| 시나리오 | 설명 |
|---|---|
| 컴퓨팅 스케일 업/다운 | 사용자가 컴퓨팅 스케일 업/다운 작업을 수행하면 스케일링된 컴퓨팅 구성을 사용하여 새 데이터베이스 서버가 프로비전됩니다. 기존 데이터베이스 서버에서는 활성 검사점을 완료할 수 있고, 클라이언트 연결이 드레이닝되며, 커밋되지 않은 트랜잭션은 취소된 후 종료됩니다. 그런 다음 이전 데이터베이스 서버에서 스토리지가 분리되고 새 데이터베이스 서버에 연결됩니다. 시작되고 실행되어 모든 연결을 허용합니다. |
| 스토리지 스케일 업 | 스토리지 스케일 업은 현재 오프라인 작업으로, 가동 중지 시간이 짧습니다. |
| 새 소프트웨어 배포(Azure) | 새 기능 출시 또는 버그 수정은 서비스의 계획된 유지 관리의 일부로 자동으로 이루어집니다. 자세한 내용은 설명서를 참조하고 포털도 확인합니다. |
| 부 버전 업그레이드 | Azure Database for PostgreSQL은 Azure에서 확인된 부 버전으로 데이터베이스 서버를 자동으로 패치합니다. 이러한 작업은 서비스의 계획된 유지 관리 중에 수행됩니다. 이러한 작업은 몇 초 이내의 짧은 가동 중지 시간 내에 발생하며, 새로운 부 버전으로 데이터베이스 서버가 자동으로 다시 시작됩니다. 자세한 내용은 설명서를 참조하고 포털도 확인합니다. |
계획되지 않은 가동 중지 시간
계획되지 않은 가동 중지 시간은 기본 하드웨어 결함, 네트워킹 문제 및 소프트웨어 버그와 같은 예상되지 않은 오류의 결과로 발생할 수 있습니다. 데이터베이스 서버가 예기치 않게 작동 중단되면 새 데이터베이스 서버가 몇 초 안에 자동으로 프로비전됩니다. 원격 스토리지는 새 데이터베이스 서버에 자동으로 연결됩니다. PostgreSQL 엔진은 WAL 및 데이터베이스 파일을 사용하여 복구 작업을 수행하고, 클라이언트가 연결할 수 있도록 데이터베이스 서버를 엽니다. 커밋되지 않은 트랜잭션은 손실되며 애플리케이션에서 다시 시도해야 합니다. 계획되지 않은 가동 중지 시간은 방지할 수 없지만, 유연한 서버는 작업자의 개입 없이 데이터베이스 서버 및 스토리지 레이어 모두에서 복구 작업을 자동으로 수행하여 가동 중지 시간을 완화합니다.
다음은 몇 가지 오류 시나리오와 유연한 서버가 자동으로 복구하는 방법입니다.
| 시나리오 | 자동 복구 |
|---|---|
| 데이터베이스 서버 오류 | 기본 하드웨어 결함으로 인해 데이터베이스 서버가 가동 중지되면 활성 연결이 삭제되고 모든 전송 중인 트랜잭션이 중단됩니다. 새 데이터베이스 서버가 자동으로 배포되고 원격 데이터 스토리지가 새 데이터베이스 서버에 연결됩니다. 데이터베이스 복구가 완료된 후 클라이언트는 동일한 엔드포인트를 사용하여 새 데이터베이스 서버에 연결할 수 있습니다. RTO(복구 시간 목표)는 데이터베이스 서버 시작 프로세스 중 수행해야 하는 큰 트랜잭션 및 복구 작업의 양과 같은 장애가 발생한 시점의 작업을 포함하여 여러 요소들에 따라 달라집니다. PostgreSQL 데이터베이스를 사용하는 애플리케이션은 삭제된 연결과 실패한 트랜잭션을 검색하고 다시 시도하도록 빌드되어야 합니다. |
| 스토리지 오류 | 디스크 오류 또는 물리적 블록 손상과 같은 스토리지 관련 문제는 애플리케이션에 영향을 주지 않습니다. 데이터가 3개 복사본에 저장되므로, 남은 스토리지에서 데이터 복사본이 제공됩니다. 블록 손상은 자동으로 수정됩니다. 데이터 복사본이 손실된 경우 새로운 데이터 복사본이 자동으로 생성됩니다. |
다음은 복구하려면 사용자 작업이 필요한 몇 가지 오류 시나리오입니다.
| 시나리오 | 복구 계획 |
|---|---|
| 가용성 영역 오류 | 해당 지역이 여러 가용성 영역을 지원하는 경우 백업은 자동으로 영역 중복 백업 스토리지에 저장됩니다. 영역 오류 발생 시 백업에서 다른 가용성 영역으로 복원할 수 있습니다. 이는 영역 수준 복원력을 제공합니다. 그러나 복원 및 복구 시간이 발생합니다. 일부 WAL 레코드가 백업 스토리지에 복사되지 않았을 수 있으므로 일부 데이터가 손실되었을 수 있습니다. 짧은 가동 중지 시간과 높은 작동 시간을 선호하는 경우 영역 중복 고가용성을 사용하여 서버를 구성하는 것이 좋습니다. |
| 논리적/사용자 오류 | 실수로 삭제된 테이블 또는 잘못 업데이트된 데이터와 같은 사용자 오류로부터 복구하려면 오류가 발생하기 바로 전의 시간으로 데이터를 복원 및 복구하는 PITR(지정 시간 복구)가 수행됩니다. 데이터베이스 서버에 있는 모든 데이터베이스 대신 데이터베이스의 일부 또는 특정 테이블만 복원하려면 새 인스턴스에서 데이터베이스 서버를 복원하고 pg_dump를 통해 테이블을 내보낸 후 pg_restore를 사용하여 테이블을 데이터베이스로 복원하면 됩니다. |
질문과 대답
HA 구성 질문
유연한 서버와 함께 제공되는 SLA는 어디에서 볼 수 있나요?
Azure Database for PostgreSQL SLA서버를 계획되지 않은 중단으로부터 보호하려면 HA가 필요한가요?
아니요. 유연한 서버는 자동으로 손상된 서버를 다시 시작하고 서버를 다른 실제 노드로 재배치하기 위해 세 개의 데이터 복사본, 영역 중복 백업(지원되는 지역에서), 기본 제공 서버 복원력이 있는 로컬 중복 스토리지를 제공합니다. 영역 중복 HA는 다른 영역에서 실행 중인 다른(대기) 서버로 자동 장애 조치(failover)를 수행하여 더 높은 작동 시간을 제공하므로 데이터 손실 없이 영역 복원력 있는 고가용성을 제공합니다.주 서버 및 대기 서버의 가용성 영역을 선택할 수 있나요?
동일한 영역 HA를 선택하는 경우 주 서버만 선택할 수 있습니다. 영역 중복 HA를 선택하는 경우 주 및 대기 AZ를 모두 선택할 수 있습니다.모든 지역에서 영역 중복 HA를 사용할 수 있나요?
영역 중복 HA는 지역 내 여러 AZ를 지원하는 지역에서 사용할 수 있습니다. 최신 지역 지원에 대해서는 이 설명서를 참조하세요. 계속해서 더 많은 지역을 추가하고 여러 AZ를 사용하도록 설정하고 있습니다. 동일한 영역 HA는 지원되는 모든 지역에서 사용할 수 있습니다.영역 중복 HA와 동일한 영역 HA를 동시에 배포할 수 있나요?
아니요. 이러한 옵션 중 하나만 배포할 수 있습니다.동일한 영역 HA를 영역 중복 HA로 직접 변환하고 그 반대로도 변환할 수 있나요?
아니요. 먼저 HA를 사용하지 않도록 설정하고, HA가 완료되기를 기다린 다음, 다른 HA 배포 모델을 선택해야 합니다.주 서버와 대기 서버 간의 복제 모드는 어떻게 되나요?
주 서버와 대기 서버 간에 복제의 동기 모드가 설정됩니다. 애플리케이션 쓰기 및 커밋은 WAL(미리 쓰기 로그) 데이터가 대기 사이트에서 유지된 후에만 승인됩니다. 이렇게 하면 장애 조치(failover) 시 데이터가 손실되지 않습니다.동기 모드는 대기 시간을 발생시킵니다. 애플리케이션 성능에는 어떠한 영향을 미치게 되나요?
HA에서 구성하면 쓰기 및 커밋 시 약간의 대기 시간이 발생합니다. 읽기 쿼리에는 영향을 주지 않습니다. 성능에 미치는 영향은 워크로드에 따라 달라집니다. 일반적인 지침에 따르면 쓰기 및 커밋은 20~30% 정도의 영향을 받을 수 있습니다.영역 중복 HA는 계획되거나 계획되지 않은 중단으로부터 보호를 제공하나요?
예. HA의 주요 목적은 작동 중단을 완화하기 위해 높은 가동 시간을 제공하는 것입니다. 계획되지 않은 가동 중단(데이터베이스, VM, 물리적 노드, 데이터 센터 또는 AZ 수준에서의 오류 포함) 발생 시 모니터링 시스템은 자동으로 서버를 대기로 장애 조치(failover)합니다. 마찬가지로, 계획된 중단(예약된 유지 관리 기간 동안 부 버전 업데이트 또는 인프라 패치 적용 포함)이 발생하는 동안에는 업데이트가 대기에 먼저 적용되며 이전 주가 업데이트 프로세스를 진행하는 동안에는 서비스가 장애 조치(failover)됩니다. 이렇게 하면 전체 가동 중지 시간이 줄어듭니다.언제든지 HA를 사용하거나 사용하지 않도록 설정할 수 있나요?
예. 서버가 중지됨, 다시 시작 중, 이미 장애 조치 처리 중과 같은 특정 상태에 있는 경우를 제외하고는 언제든지 영역 중복 HA를 사용하거나 사용하지 않도록 설정할 수 있습니다.
대기에 대한 AZ를 선택할 수 있나요?
아니요. 현재 대기에 대한 AZ를 선택할 수 없습니다. 나중에 이 기능을 추가할 계획입니다.개인(VNET)과 공용 액세스 간에 HA를 구성할 수 있나요?
아니요. VNET(한 지역 내 AZ에 걸쳐 있음) 또는 공용 액세스 내에서 HA를 구성할 수 있습니다.지역 간에 HA를 구성할 수 있나요?
아니요. HA는 한 지역 내 그러나 여러 가용성 영역에서 구성됩니다. 그러나 지역 복원력을 달성하기 위해 비동기 모드에서 지역 읽기 복제본을 사용하도록 설정할 수 있습니다.HA로 구성된 서버에서 논리적 복제를 사용할 수 있나요?
HA를 사용하여 논리적 복제를 구성할 수 있습니다. 그러나 장애 조치(failover) 후에는 논리 슬롯 세부 정보가 대기로 복사되지 않습니다. 따라서 현재 이 구성에 대해 제한적으로 지원됩니다. 논리 복제를 사용해야 하는 경우 장애 조치(failover) 후 다시 만들어야 합니다.
복제 및 장애 조치 관련 질문
유연한 서버는 AZ 오류와 같은 오류가 발생하는 경우 어떻게 고가용성을 제공하나요?
영역 중복 HA를 사용하여 서버를 사용하도록 설정하면 주 복제본과 동일한 컴퓨팅 및 스토리지 구성을 사용하는 실제 대기 복제본이 주 복제본과 다른 가용성 영역에 자동으로 배포됩니다. PostgreSQL 스트리밍 복제는 주 서버와 대기 서버 간에 설정됩니다.중단 시 일반적인 장애 조치(failover) 프로세스는 어떻게 되나요?
모니터링 시스템에서 오류를 검색하는 경우 대기가 모든 잔여 WAL 파일을 적용하고 읽기/쓰기를 위해 열기 전에 완전히 포착했는지 확인하는 작업을 수행하는 장애 조치(failover) 워크플로를 시작합니다. 그런 다음 클라이언트가 동일한 엔드포인트(호스트 이름)를 사용하여 서버에 다시 연결할 수 있기 전에 대기의 IP 주소를 사용하여 DNS를 업데이트합니다. 새 대기를 인스턴스화하여 구성을 항상 사용 가능 모드로 유지합니다.중단 시 일반적인 장애 조치(failover) 시간 및 예상되는 데이터 손실은 어떻게 되나요?
일반적인 경우 애플리케이션 관점에서 발생하는 장애 조치 시간 또는 가동 중지 시간은 60초에서 120초 사이입니다. 장기 실행 트랜잭션, 인덱스 만들기 또는 과도한 쓰기 작업 중에 중단이 발생한 경우에는 더 오래 걸릴 수 있습니다. 대기 복제본에서 복구 프로세스를 완료하려면 더 오래 걸릴 수 있기 때문입니다.복제는 동기 모드에서 발생하므로 데이터가 손실되지 않습니다.
장애 조치(failover) 시간에 대한 SLA를 제공하나요?
장애 조치(failover) 시간의 경우 일반적으로 작업에 소요되는 시간에 대한 지침을 제공합니다. 전체 가동 시간에 대해 공식 SLA가 제공됩니다.장애 조치(failover) 후 애플리케이션이 서버에 자동으로 연결되나요?
아니요. 동일한 엔드포인트(호스트 이름)에 다시 연결하려면 애플리케이션에 다시 시도 메커니즘이 있어야 합니다.장애 조치(failover)는 어떻게 테스트할 수 있나요?
강제 장애 조치 또는 계획된 장애 조치 기능을 사용하여 장애 조치를 테스트할 수 있습니다. 자세한 내용은 이 문서의 주문형 장애 조치 섹션을 참조하세요.복제 상태는 어떻게 확인하나요?
포털의 서버 개요 페이지에는 영역 중복 고가용성 상태와 서버 상태가 표시됩니다. 또한 서버 포털의 고가용성 블레이드에서 주 및 대기에 대한 상태 및 AZ를 확인할 수 있습니다.psql에서 다른 세부 정보 중 스트리밍 상태를 보여 주는
select * from pg_stat_replication;을 실행할 수 있습니다.대기 복제본에 대한 읽기 쿼리를 지원하나요?
아니요. 대기 복제본에 대한 읽기 쿼리는 지원되지 않습니다.PITR(지정 시간 복구)을 수행하는 경우 자동으로 HA에서 복원된 서버를 구성하나요?
아니요. PITR 서버는 독립 실행형 서버로 복원됩니다. HA를 사용하도록 설정하려면 복원이 완료된 후에 이 작업을 수행할 수 있습니다.