Azure Database for PostgreSQL - 유연한 서버의 고가용성(안정성)
적용 대상: 
Azure Database for PostgreSQL - 유연한 서버
이 문서에서는 Azure Database for PostgreSQL - 유연한 서버의 고가용성을 설명하며 여기에는 가용성 영역과 지역 간 복구 및 비즈니스 연속성이 포함됩니다. Azure의 안정성에 대한 포괄적인 개요는 Azure 안정성을 참조하세요.
Azure Database for PostgreSQL - 유연한 서버는 같은 가용성 영역(영역) 내에서 또는 가용성 영역(영역 중복) 간에서 물리적으로 구분된 주 복제본과 대기 복제본을 프로비전하여 고가용성 지원을 제공합니다. 이 고가용성 모델은 오류 발생 시 커밋된 데이터가 손실되지 않도록 설계되었습니다. 또한 모델은 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 설계되었습니다. 가용성 영역 및 가용성 영역 지원에 대한 자세한 내용은가용성 영역 지원을 참조하세요.
가용성 영역 지원
가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.
Azure의 가용성 영역에 대한 자세한 내용은 가용성 영역이란?을 참조하세요.
Azure Database for PostgreSQL - 유연한 서버는 고가용성 구성에 영역 중복 모델과 영역 모델을 모두 지원합니다. 두 고가용성 구성을 모두 사용하면 계획된 이벤트와 계획되지 않은 이벤트 중에 데이터 손실이 없는 자동 장애 조치(failover) 기능을 사용할 수 있습니다.
영역 중복 영역 중복 고가용성은 자동 장애 조치(failover) 기능을 통해 대기 복제본을 다른 영역에 배포합니다. 영역 중복은 최고 수준의 가용성을 제공하지만 영역 간에 애플리케이션 중복도를 구성해야 합니다. 이러한 이유로 인해 가용성 영역 수준 장애로부터 보호하고 가용성 영역 전반의 대기 시간을 허용하려는 경우에 영역 중복을 선택합니다.
주 서버와 대기 서버 모두에 대한 지역과 가용성 영역을 선택할 수 있습니다. 대기 복제본 서버는 주 서버와 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 사용하여 같은 지역에서 선택한 가용성 영역에서 프로비전됩니다. 데이터 파일과 트랜잭션 로그 파일(WAL(미리 쓰기 로그))은 각 가용성 영역 내의 데이터 복사본 3개를 자동으로 저장하는 LRS(로컬 중복 스토리지)에 저장됩니다. 영역 중복 구성은 주 서버와 대기 서버 간의 전체 스택을 물리적으로 격리합니다.
영역 단일 가용성 영역 내에서 네트워크 대기 시간이 가장 짧은 최고 수준의 가용성을 달성하려면 영역 배포를 선택합니다. 지역 및 가용성 영역을 선택하여 주 데이터베이스 서버를 배포할 수 있습니다. 대기 복제본 서버는 주 서버와 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 통해 같은 가용성 영역에서 자동으로 프로비전되고 관리됩니다. 영역 구성은 노드 수준의 오류로부터 데이터베이스를 보호하고 계획된 가동 중지 시간 이벤트와 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데에도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버에 대해 중단이 발생하는 경우 서버는 자동으로 대기 복제본으로 장애 조치(failover) 됩니다.
참고 항목
영역 및 영역 중복 배포 모델 모두 구조적으로 동일하게 작동합니다. 다음 섹션의 다양한 논의는 달리 명시되지 않는 한 두 모델 모두에 적용됩니다.
필수 조건
영역 중복:
영역 중복은 가용성 영역을 지원하는 지역에서 사용 가능합니다.
영역 중복도는 다음에 대해 지원되지 않습니다.
- Azure Database for PostgreSQL - 단일 서버 SKU
- 버스트 가능 컴퓨팅 계층
- 단일 영역 가용성이 있는 지역
영역:
- 영역 배포 옵션은 유연한 서버를 배포할 수 있는 모든 Azure 지역에서 사용 가능합니다.
고가용성 기능
대기 복제본은 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 파일을 복구합니다. 워크로드가 이 한도를 초과하면 장애 조치(failover) 중에 또는 새 대기 서버를 설정한 후에 복구를 완료하는 데 시간이 오래 걸릴 수 있습니다.
가용성 영역을 구성하면 쓰기 및 커밋에 약간의 대기 시간이 발생하지만 읽기 쿼리는 영향을 받지 않습니다. 성능에 미치는 영향은 워크로드에 따라 달라집니다. 일반적인 지침에 따르면 쓰기 및 커밋은 20~30% 정도의 영향을 받을 수 있습니다.
주 데이터베이스 서버를 다시 시작하면 대기 복제본도 다시 시작됩니다.
추가 대기 구성은 지원되지 않습니다.
관리되는 유지 관리 기간 중에는 고객이 시작한 관리 작업 구성을 예약할 수 없습니다.
확장 컴퓨팅 및 확장 스토리지와 같은 계획된 이벤트는 먼저 대기 서버에서 발생한 다음, 주 서버에서 발생합니다. 현재 서버는 이러한 계획된 작업을 장애 조치(failover)하지 않습니다.
가용성이 구성된 유연한 서버로 논리적 디코딩이나 논리적 복제를 구성한 경우 대기 서버로 장애 조치(failover) 시 논리적 복제 슬롯이 대기 서버로 복사되지 않습니다. 논리적 복제 슬롯을 유지 관리하고 장애 조치(failover) 후 데이터 일관성을 보장하려면 PG 장애 조치(failover) 슬롯 확장을 사용하는 것이 좋습니다. 이 확장을 사용하도록 설정하는 방법에 대한 자세한 내용은 문서를 참조하세요.
프라이빗 엔드포인트를 사용하여 프라이빗(VNET)과 공용 액세스 간에 가용성 영역을 구성할 수 없습니다. 프라이빗 엔드포인트를 사용하여 VNET(한 지역 내 가용성 영역에 걸쳐 있음) 또는 공용 액세스 내에서 가용성 영역을 구성해야 합니다.
가용성 영역은 단일 지역 내에서만 구성됩니다. 지역 간에 가용성 영역을 구성할 수 없습니다.
SLA
영역 모델은 작동 시간 SLA 99.95%를 제공합니다.
영역 중복도 모델은 작동 시간 SLA 99.99%를 제공합니다.
가용성 영역을 사용하도록 설정된 Azure Database for PostgreSQL - 유연한 서버 만들기
가용성 영역을 사용하여 고가용성 Azure Database for PostgreSQL - 유연한 서버를 만드는 방법은 빠른 시작: Azure Portal에서 Azure Database for PostgreSQL - 유연한 서버 만들기를 참조하세요.
가용성 영역 재배포 및 마이그레이션
영역 중복 및 동일 영역 배포 모델 모두에서 유연한 서버의 고가용성 구성을 사용하거나 사용하지 않도록 설정하는 방법은 유연한 서버에서 고가용성 관리를 참조하세요.
고가용성 구성 요소 및 워크플로
트랜잭션 완료
애플리케이션 트랜잭션이 트리거된 쓰기 및 커밋은 먼저 주 서버의 WAL에 로그됩니다. 그런 다음, Postgres 스트리밍 프로토콜을 사용하여 대기 서버로 스트림됩니다. 로그가 대기 서버 스토리지에 유지되면 주 서버에 쓰기 완료가 승인됩니다. 그런 다음에만 애플리케이션에서 해당 트랜잭션의 커밋을 확인합니다. 이 추가 왕복은 애플리케이션에 대기 시간을 더 추가합니다. 영향의 정도는 애플리케이션에 따라 달라집니다. 이 승인 프로세스는 로그가 대기 서버에 적용될 때까지 대기하지 않습니다. 대기 서버는 승격될 때까지 영구적으로 복구 모드에 있습니다.
상태 확인
유연한 서버 상태 모니터링은 주 상태와 대기 상태 모두 정기적으로 검사합니다. 여러 ping 후 상태 모니터링에서 주 서버가 연결할 수 없음을 감지하면 서비스는 대기 서버로 자동 장애 조치(failover)를 시작합니다. 이 상태 모니터링 알고리즘은 가양성 상황이 방지되도록 여러 데이터 요소를 기반으로 합니다.
장애 조치(failover) 모드
유연한 서버는 계획된 장애 조치 및 계획되지 않은 장애 조치(failover) 등 두 가지 장애 조치(failover) 모드를 지원합니다. 두 모드 모두에서 복제가 중단되면 대기 서버가 주 서버로 승격되기 전에 복구를 실행하고 읽기/쓰기를 위해 열립니다. 자동 DNS 항목이 새 주 서버 엔드포인트로 업데이트되면 애플리케이션은 같은 엔드포인트를 사용하여 서버에 연결할 수 있습니다. 새 대기 서버가 백그라운드에서 설정되므로 애플리케이션에서 연결을 유지 관리할 수 있습니다.
고가용성 상태
주 서버와 대기 서버의 상태가 지속적으로 모니터링되며 대기 서버로 장애 조치(failover) 트리거를 포함하여 문제가 해결되도록 적절한 작업이 수행됩니다. 다음 표에는 가능한 고가용성 상태가 나와 있습니다.
| 상태 | 설명 |
|---|---|
| 초기화 중 | 새로운 대기 서버를 만드는 과정에서 |
| 데이터 복제 중 | 대기 서버를 만든 후에 주 서버의 데이터를 받는 중입니다. |
| 정상 | 복제가 정상 상태이며 정상입니다. |
| 장애 조치(failover) 중 | 데이터베이스 서버가 대기 서버로 장애 조치(failover)하는 프로세스 중에 있습니다. |
| 대기 제거 중 | 대기 서버를 삭제하는 중입니다. |
| 사용 안 함 | 고가용성을 사용하도록 설정되지 않습니다. |
참고 항목
서버를 만드는 동안 또는 나중에 고가용성을 사용하도록 설정할 수도 있습니다. 만들기 이후 단계에서 고가용성을 사용하거나 사용하지 않도록 설정하는 경우 주 서버 작업이 적을 때 작업하는 것이 좋습니다.
정상 상태 작업
PostgreSQL 클라이언트 애플리케이션은 DB 서버 이름을 사용하여 주 서버에 연결됩니다. 애플리케이션 읽기는 주 서버에서 직접 제공됩니다. 동시에 로그 데이터가 주 서버와 대기 복제본 모두에서 유지된 후에만 애플리케이션에서 커밋과 쓰기를 확인합니다. 이러한 추가 왕복으로 인해 애플리케이션은 쓰기와 커밋의 대기 시간이 증가할 것으로 예상할 수 있습니다. 포털에서 고가용성의 상태를 모니터링할 수 있습니다.
- 클라이언트는 유연한 서버에 연결하고 쓰기 작업을 수행합니다.
- 변경 사항은 대기 사이트에 복제됩니다.
- 주 서버는 승인을 받습니다.
- 쓰기/커밋이 승인됩니다.
고가용성 서버의 특정 시점 복원
고가용성으로 구성된 유연한 서버에서는 데이터가 실시간으로 대기 서버에 복제됩니다. 실수로 테이블 삭제 또는 잘못된 데이터 업데이트와 같은 주 서버에서의 모든 사용자 오류는 대기 복제본에 복제됩니다. 따라서 이러한 논리적 오류를 복구하는 데 대기 복제본을 사용할 수 없습니다. 이러한 오류를 복구하려면 백업에서 특정 시점 복원을 수행해야 합니다. 유연한 서버의 특정 시점 복원 기능을 사용하면 오류가 발생하기 전의 시간으로 복원할 수 있습니다. 새 데이터베이스 서버는 사용자가 제공한 고가용성으로 구성된 데이터베이스의 새 서버 이름을 사용하는 단일 영역 유연한 서버로 복원됩니다. 몇 가지 사용 사례에 복원된 서버를 사용할 수 있습니다.
복원된 서버를 프로덕션에 사용하고 선택적으로 같은 영역이나 같은 지역의 다른 영역에서 대기 복제본을 사용하여 고가용성을 사용하도록 설정할 수 있습니다.
개체를 복원하려는 경우 복원된 데이터베이스 서버에서 개체를 내보내고 프로덕션 데이터베이스 서버로 가져옵니다.
테스트 및 개발 목적으로 데이터베이스 서버를 복제하거나 다른 목적으로 복원하려면 특정 시점 복원을 수행하면 됩니다.
유연한 서버의 특정 시점 복원을 수행하는 방법은 유연한 서버의 특정 시점 복원을 참조하세요.
장애 조치(failover) 지원
계획된 장애 조치
계획된 가동 중지 시간 이벤트에는 Azure 예약 정기 소프트웨어 업데이트 및 사소한 버전 업그레이드가 포함됩니다. 계획된 장애 조치를 사용하여 주 서버를 기본 가용성 영역으로 반환할 수도 있습니다. 고가용성으로 구성된 경우 이러한 작업은 애플리케이션이 주 서버에 계속 액세스하는 동안 먼저 대기 복제본에 적용됩니다. 대기 복제본이 업데이트되면 주 서버 연결이 비워지고 데이터베이스 서버 이름이 같은 주 서버가 되도록 대기 복제본을 활성화하는 장애 조치(failover)가 트리거됩니다. 클라이언트 애플리케이션은 같은 데이터베이스 서버 이름으로 새 주 서버에 다시 연결해야 합니다. 그러면 작업을 계속할 수 있습니다. 새 대기 서버가 이전 주 서버와 동일한 영역에 설정됩니다.
scale-compute 또는 scale-storage와 같은 다른 사용자 시작 작업의 경우 변경 내용이 대기 서버, 주 서버 순서로 적용됩니다. 현재 서비스가 대기 서버로 장애 조치(failover)되지 않으므로 주 서버에서 스케일링 작업이 수행되는 동안 애플리케이션에서 짧은 가동 중지 시간이 발생합니다.
또한 이 기능을 사용하여 대기 서버로 장애 조치(failover)해 가동 중지 시간을 줄일 수 있습니다. 예를 들어 계획되지 않은 장애 조치(failover) 후에는 주 서버가 애플리케이션과 다른 가용성 영역에 있을 수 있습니다. 주 서버를 이전 영역으로 다시 가져와서 애플리케이션과 공동 배치하려고 합니다.
이 기능을 실행하면 최근 트랜잭션을 사용할 수 있도록 대기 서버가 먼저 준비되므로 애플리케이션에서 읽기/쓰기를 계속 수행할 수 있습니다. 그런 다음, 대기 서버가 승격되고 주 서버에 대한 연결이 끊어집니다. 새 대기 서버가 백그라운드에서 설정되는 동안 애플리케이션은 주 서버에 계속 쓸 수 있습니다. 다음은 계획된 장애조치와 관련된 단계입니다.
| Step | 설명 | 가동 중지 시간 예상 여부 |
|---|---|---|
| 1 | 대기 서버가 주 서버와 일치될 때까지 대기합니다. | 아니요 |
| 2 | 내부 모니터링 시스템에서 장애 조치 워크플로를 시작합니다. | 아니요 |
| 3 | 대기 서버가 주 LSN(로그 시퀀스 번호)에 가까워지면 애플리케이션 쓰기가 차단됩니다. | 예 |
| 4 | 대기 서버가 독립 서버로 승격됩니다. | 예 |
| 5 | DNS 레코드가 새 대기 서버의 IP 주소로 업데이트됩니다. | 예 |
| 6 | 애플리케이션은 새로운 주 서버와 다시 연결하고 읽기/쓰기를 계속합니다. | 아니요 |
| 7 | 다른 영역에 새 대기 서버가 설정됩니다. | 아니요 |
| 8 | 대기 서버에서 설정 중에 누락된 Azure Blob의 로그를 복구합니다. | 아니요 |
| 9 | 주 서버와 대기 서버 간에 안정적인 상태가 설정됩니다. | 아니요 |
| 10 | 계획된 장애 조치 프로세스가 완료되었습니다. | 아니요 |
애플리케이션 가동 중지 시간은 #3단계에서 시작되고 #5단계 후 작업을 다시 시작할 수 있습니다. 나머지 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 발생합니다.
팁
유연한 서버를 사용하면 데이터베이스에 대한 작업이 적을 것으로 예상되는 날짜에서 60분 기간을 선택하여 Azure에서 시작한 유지 관리 작업을 선택적으로 예약할 수 있습니다. 패치 또는 사소한 버전 업그레이드와 같은 Azure 유지 관리 작업이 해당 기간 동안 발생합니다. 사용자 지정 기간을 선택하지 않으면 현지 시간으로 오후 11시에서 오전 7시 사이에 시스템에서 할당한 1시간이 서버에 선택됩니다. 가용성 영역으로 구성된 유연한 서버의 경우 이러한 Azure에서 시작한 유지 관리 작업은 대기 복제본에서도 수행됩니다.
가능한 계획된 가동 중지 시간 이벤트 목록은 계획된 가동 중지 시간 이벤트를 참조하세요.
계획되지 않은 장애 조치(Failover)
계획되지 않은 가동 중지 시간은 기본 하드웨어 결함, 네트워킹 문제 및 소프트웨어 버그와 같은 예상되지 않은 중단의 결과로 발생할 수 있습니다. 고가용성으로 구성된 데이터베이스 서버가 예기치 않게 중단되면 대기 복제본이 활성화되고 클라이언트에서 해당 작업을 다시 시작할 수 있습니다. HA(고가용성)로 구성되지 않은 경우 다시 시작 시도에 실패하면 새 데이터베이스 서버가 자동으로 프로비저닝됩니다. 예기치 않은 가동 중지 시간은 피할 수 없지만, 유연한 서버는 작업자의 개입 없이 복구 작업을 자동으로 수행하여 가동 중지 시간을 단축하도록 지원합니다.
가능한 시나리오를 포함하여 계획되지 않은 장애 조치(failover) 및 가동 중지 시간에 대한 자세한 내용은 계획되지 않은 가동 중지 시간 완화를 참조하세요.
장애 조치(failover) 테스트(강제 장애 조치(failover))
강제 장애 조치(failover)를 사용하면 프로덕션 워크로드를 실행하는 동안 계획되지 않은 중단 시나리오를 시뮬레이션하고 애플리케이션 가동 중지 시간을 관찰할 수 있습니다. 주 서버가 응답하지 않을 때 강제 장애 조치(failover)를 사용할 수도 있습니다.
강제 장애 조치(failover)는 주 서버를 중단시키고 대기 승격 작업이 수행되는 장애 조치(failover) 워크플로를 시작합니다. 대기 서버가 마지막으로 커밋된 데이터까지 복구 프로세스를 완료하면 주 서버로 승격됩니다. DNS 레코드가 업데이트되고 애플리케이션은 승격된 주 서버에 연결할 수 있습니다. 새로운 대기 서버가 백그라운드에서 설정되고 가동 시간에 영향을 미치지 않는 동안 애플리케이션은 계속해서 주 서버에 쓸 수 있습니다.
다음은 강제 장애 조치(failover) 중의 단계입니다.
| Step | 설명 | 가동 중지 시간 예상 여부 |
|---|---|---|
| 1 | 주 서버가 장애 조치(failover) 요청을 수신한 직후에 중지됩니다. | 예 |
| 2 | 주 서버가 다운되면 애플리케이션에서 가동 중지 시간이 발생합니다. | 예 |
| 3 | 내부 모니터링 시스템에서 오류를 감지하고 대기 서버로 장애 조치를 시작합니다. | 예 |
| 4 | 독립 서버로 완전히 승격되기 전에 대기 서버가 복구 모드로 들어갑니다. | 예 |
| 5 | 장애 조치 프로세스는 대기 복구가 완료될 때까지 대기합니다. | 예 |
| 6 | 서버가 시작되면 DNS 레코드가 같은 호스트 이름을 사용하지만 대기 서버의 IP 주소를 사용하여 업데이트됩니다. | 예 |
| 7 | 애플리케이션은 새 주 서버에 다시 연결하고 작업을 다시 시작할 수 있습니다. | 아니요 |
| 8 | 기본 영역에 대기 서버가 설정됩니다. | 아니요 |
| 9 | 대기 서버에서 설정 중에 누락된 Azure Blob의 로그를 복구합니다. | 아니요 |
| 10 | 주 서버와 대기 서버 간에 안정적인 상태가 설정됩니다. | 아니요 |
| 11 | 강제 장애 조치 프로세스가 완료되었습니다. | 아니요 |
애플리케이션 가동 중지 시간은 #1단계 후에 시작되며 #6단계가 완료될 때까지 유지됩니다. 나머지 단계는 애플리케이션 쓰기 및 커밋에 영향을 주지 않고 백그라운드에서 발생합니다.
Important
엔드투엔드 장애 조치(failover) 프로세스에는 (a) 1차 장애 후 대기 서버로의 장애 조치(failover) 및 (b) 안정적 상태의 새 대기 서버 설정이 포함됩니다. 대기 모드로의 장애 조치(failover)가 완료될 때까지 애플리케이션 가동 중지 시간이 발생하므로 전체 엔드투엔드 장애 조치(failover) 프로세스 대신 애플리케이션/클라이언트 관점에서 가동 중지 시간을 측정하세요.
강제 장애 조치(failover) 수행 시 고려 사항
전체 엔드투엔드 작업 시간이 애플리케이션에서 발생하는 실제 가동 중지 시간보다 길 수 있습니다.
Important
항상 애플리케이션 관점에서 가동 중지 시간을 관찰합니다.
장애 조치(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_user_tables업데이트 pg_stat_* 하여 자동 진공 프로세스를 지원하고 데이터베이스 성능이 새 역할에서 최적으로 유지되도록 합니다. 이 사전 대응 단계는 필수 최적화 프로그램 통계 유지와 데이터베이스의 현재 상태에 맞게 활동 메트릭 새로 고침 사이의 간격을 해소합니다.
영역 다운 환경
영역: 영역 수준 오류로부터 복구하려면 백업을 사용하여 특정 시점 복원을 수행하면 됩니다. 최신 시간의 사용자 지정 복원 지점을 선택하여 최신 데이터를 복원할 수 있습니다. 새 유연한 서버가 영향을 받지 않는 또 다른 영역에 배포됩니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그의 양에 따라 달라집니다.
특정 시점 복원에 대한 자세한 내용은 Azure Database for PostgreSQL-유연한 서버의 백업 및 복원을 참조하세요.
영역 중복: 유연한 서버는 데이터 손실 없이 60~120초 이내에 대기 서버로 자동 장애 조치(failover)됩니다.
가용성 영역을 사용하지 않는 구성
권장되지는 않지만 고가용성을 사용하도록 설정하지 않고 유연한 서버를 구성할 수 있습니다. 고가용성을 사용하지 않고 구성된 유연한 서버의 경우 서비스는 자동으로 손상된 서버가 다시 시작하고 서버가 다른 물리적 노드에 재배치되도록 데이터 복사본 3개, 영역 중복 백업(지원되는 지역에서) 및 기본 제공 서버 복원력이 있는 로컬 중복 스토리지를 제공합니다. 이 구성에서는 작동 시간 SLA 99.9%가 제공됩니다. 계획되거나 계획되지 않은 장애 조치(failover) 이벤트 중에 서버가 다운되면 서비스는 다음과 같은 자동화된 절차를 사용하여 서버 가용성을 유지 관리합니다.
- 새 컴퓨팅 Linux VM이 프로비저닝됩니다.
- 데이터 파일이 있는 스토리지가 새 가상 머신에 매핑됩니다.
- 새 가상 머신에서 PostgreSQL 데이터베이스 엔진이 온라인 상태로 전환됩니다.
다음 그림은 VM 및 스토리지 오류 간의 전환을 보여줍니다.
지역 간 재해 복구 및 비즈니스 연속성
지역 전체 재해가 발생하는 경우 Azure는 다른 지역을 활용하여 재해 복구를 통해 지역 또는 대규모 지역 재해로부터 보호할 수 있습니다. Azure 재해 복구 아키텍처에 대한 자세한 내용은 Azure 간 재해 복구 아키텍처를 참조하세요.
유연한 서버는 데이터를 보호하고 계획된 가동 중지 시간 이벤트 및 계획되지 않은 가동 중지 시간 이벤트 중에 중요 업무용 데이터베이스 가동 중지 시간을 완화하는 기능을 제공합니다. 강력한 복원력과 가용성을 제공하는 Azure 인프라 위에 빌드된 유연한 서버는 장애 보호를 제공하고 복구 시간 요구 사항을 해결하며 데이터 손실 노출을 줄이는 비즈니스 연속성 기능을 제공합니다. 애플리케이션을 설계할 때 가동 중지 시간 허용치(RTO(복구 시간 목표)) 및 데이터 손실 노출(RPO(복구 지점 목표))을 고려해야 합니다. 예를 들어, 중요 비즈니스용 데이터베이스는 테스트 데이터베이스보다 엄격한 가동 시간이 필요합니다.
다중 지역 지리의 재해 복구
지역 중복 백업 및 복원
지역 중복 백업과 복원을 사용하면 재해 발생 시 다른 지역에서 서버를 복원할 수 있습니다. 또한 1년 동안 백업 개체에 대해 최소 99.99999999999999%(16개의 9) 내구성을 제공합니다.
지역 중복 백업은 서버 만들기 시에만 구성할 수 있습니다. 서버가 지역 중복 백업으로 구성된 경우 스토리지 복제를 통해 백업 데이터와 트랜잭션 로그가 쌍으로 된 지역에 비동기적으로 복사됩니다.
지역 중복 백업 및 복원에 대한 자세한 내용은 지역 중복 백업 및 복원을 참조하세요.
읽기 복제본
지역 간 읽기 복제본을 배포하여 지역 수준 장애로부터 데이터베이스를 보호할 수 있습니다. 읽기 복제본은 PostgreSQL의 물리적 복제 기술을 통해 비동기적으로 업데이트되며 주 복제본이 지연될 수 있습니다. 읽기 복제본은 범용 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다.
읽기 복제본 기능 및 고려 사항에 대한 자세한 내용은 읽기 복제본을 참조하세요.
중단 검색, 알림 및 관리
서버가 지역 중복 백업으로 구성된 경우 쌍을 이루는 지역에서 지역 복원을 수행할 수 있습니다. 새 서버가 프로비전되고, 이 지역에 복사된 마지막으로 사용 가능한 데이터로 복구됩니다.
지역 간 읽기 복제본을 사용할 수도 있습니다. 지역 장애가 발생한 경우 읽기 복제본을 독립 실행형 읽기-쓰기 가능 서버로 승격하여 재해 복구 작업을 수행할 수 있습니다. RPO는 RPO가 실패 시점의 복제 지연에 근접할 수 있는 심각한 지역 장애의 경우를 제외하고 최대 5분(데이터 손실 가능)으로 예상됩니다.
지역 재해 후 계획되지 않은 가동 중지 시간 완화 및 복구에 대한 자세한 내용은 계획되지 않은 가동 중지 시간 완화를 참조하세요.