다음을 통해 공유

Azure SQL Database의 안정성

Azure SQL 데이터베이스는 사용자 개입 없이 업그레이드, 패치, 백업, 모니터링 등 대부분 데이터베이스 관리 기능을 처리하는 완전 관리형 플랫폼 서비스(PaaS) 데이터베이스 엔진입니다.

Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.

이 문서에서는 일시적인 오류, 가용성 영역 중단 및 지역 중단을 포함하여 다양한 잠재적인 중단 및 문제에 대해 Azure SQL Database를 복원력 있게 만드는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법, 서비스 유지 관리를 처리하는 방법 및 Azure SLA(SQL Database 서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.

프로덕션 배포 권장 사항

솔루션의 안정성 요구 사항을 지원하기 위해 Azure SQL Database를 배포하는 방법과 안정성이 아키텍처의 다른 측면에 미치는 영향에 대해 알아보려면 Azure Well-Architected Framework의 Azure SQL Database에 대한 아키텍처 모범 사례를 참조하세요.

안정성 아키텍처 개요

SQL Database는 적용 가능한 모든 패치를 포함하여 Windows 운영 체제의 안정적인 최신 SQL Server 데이터베이스 엔진에서 실행됩니다.

SQL Database는 기본적으로 기본 지역의 단일 데이터 센터에 세 개의 데이터 복사본을 저장하여 중복성을 달성합니다. 이 방법은 소규모 네트워크 오류 또는 전원 오류와 같은 지역화된 오류가 발생하는 경우 및 다음 이벤트 중에도 데이터를 보호합니다.

  • 짧은 가동 중지 시간을 초래하는 고객이 수행한 관리 작업

  • 서비스 유지 관리 작업

  • 데이터 센터에 다음 구성 요소가 있는 문제 및 데이터 센터 중단:

    • 서비스에 전원을 공급하는 컴퓨터가 실행되는 랙

    • SQL Database 엔진을 실행하는 VM(가상 머신)을 호스트하는 물리적 컴퓨터

  • SQL Database 엔진의 기타 문제

  • 기타 지역별 계획되지 않은 중단

SQL Database는 Azure Service Fabric을 사용하여 데이터베이스의 복제를 관리합니다.

중복성은 SQL Database의 다양한 서비스 계층에 대해 다양한 방식으로 구현됩니다. 자세한 내용은 중복성을 통한 가용성 - SQL Database를 참조하세요.

일시적인 오류에 대한 복원력

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

SQL Database는 패치, 백업, Windows 및 SQL Database 엔진 업그레이드와 같은 중요한 서비스 작업을 자동으로 처리합니다. 또한 기본 하드웨어, 소프트웨어 또는 네트워크 오류와 같은 계획되지 않은 이벤트를 자동으로 처리합니다. SQL Database는 중요한 오류로부터 신속하게 복구하도록 설계되어 데이터를 항상 사용할 수 있도록 합니다. 대부분의 사용자는 업그레이드가 지속적으로 수행된다는 사실을 알지 못합니다.

데이터베이스가 패치되거나 장애 조치되면 애플리케이션에서 재시도 논리를 사용하는 경우 가동 중지 시간이 중단되지 않습니다.

애플리케이션 오류 복원력 테스트의 지침에 따라 임시 오류에 대한 애플리케이션의 복원력을 테스트할 수 있습니다.

가용성 영역 오류에 대한 복원력

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

영역 중복 단일 데이터베이스 또는 탄력적 풀을 만들 수 있습니다. 영역 중복성을 사용하면 애플리케이션 논리를 변경하지 않고도 치명적인 데이터 센터 중단을 비롯한 대규모 오류 집합에 대해 데이터베이스가 복원력을 유지할 수 있습니다.

범용 서비스 계층의 경우 영역 중복성을 통해 상태 비저장 컴퓨팅 구성 요소와 SQL Database의 상태 저장 데이터 스토리지 구성 요소가 모두 가용성 영역 중단에 대한 복원력을 보장합니다.

프리미엄, 중요 비즈니스용 및 하이퍼스케일 서비스 계층의 경우 영역 중복은 SQL 데이터베이스의 복제본을 주 지역의 여러 Azure 가용성 영역에 배치합니다. SPOF(단일 실패 지점)를 제거하기 위해 제어 링도 여러 가용성 영역에서 중복됩니다.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

요구 사항

기본 및 표준 서비스 계층은 영역 중복을 지원하지 않습니다.

영역 중복성은 vCore 기반 구매 모델의 중요 비즈니스용, 범용 및 하이퍼스케일 서비스 계층의 데이터베이스와 DTU 기반 구매 모델의 프리미엄 서비스 계층에서만 사용할 수 있습니다.

범용 서비스 계층의 경우:

프리미엄 및 중요 비즈니스용 서비스 계층의 경우:

하이퍼스케일 서비스 계층의 경우:

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

고려 사항

  • 지연: 영역 중복 데이터베이스는 별도의 데이터 센터에 복제본이 있습니다. 네트워크 대기 시간이 추가되어 트랜잭션 커밋 시간이 늘어나고 OLTP(특정 온라인 트랜잭션 처리) 워크로드의 성능에 영향을 줄 수 있습니다. 대부분의 애플리케이션은 이러한 추가 대기 시간에 중요하지 않습니다.

  • master 데이터베이스: 영역 중복 구성이 있는 데이터베이스가 논리 서버에 만들어지면 서버 master 와 연결된 데이터베이스도 영역 중복으로 자동으로 만들어집니다. 데이터베이스가 영역 중복인지 확인하는 master 방법에 대한 자세한 내용은 데이터베이스 영역 중복 가용성을 참조하세요.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

비용

범용 서비스 계층의 경우 SQL Database에 대한 영역 중복을 사용하도록 설정하는 추가 요금이 있습니다. 자세한 내용은 가격 책정 - SQL Database를 참조하세요.

프리미엄 및 중요 비즈니스용 서비스 계층은 데이터베이스의 여러 복제본을 제공합니다. 영역 중복을 사용하도록 설정하면 복제본이 가용성 영역 간에 분산됩니다. 이 배포는 프리미엄 또는 중요 비즈니스용 서비스 계층에 있는 경우 SQL 데이터베이스에서 영역 중복을 사용하도록 설정하는 것과 관련된 추가 비용이 없다는 것을 의미합니다.

하이퍼스케일 서비스 계층 데이터베이스의 여러 복제본을 사용하도록 설정하는 경우 영역 중복을 사용하도록 설정할 수 있습니다. 영역 중복을 사용하도록 설정하면 복제본이 가용성 영역 간에 분산됩니다. 이 배포는 여러 복제본이 있다고 가정하고 하이퍼스케일 서비스 계층에 있을 때 SQL 데이터베이스에서 영역 중복을 사용하도록 설정하는 것과 관련된 추가 비용이 없다는 것을 의미합니다.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

가용성 영역 지원 구성

범용, 프리미엄 및 중요 비즈니스용 서비스 계층:

  • 새 리소스: 데이터베이스를 만들 때 영역 중복으로 구성할 수 있습니다. 자세한 내용은 빠른 시작: 단일 데이터베이스 만들기 - SQL Database를 참조하세요.

  • 기존 리소스: 기존 데이터베이스를 영역 중복으로 다시 구성할 수 있습니다. 자세한 내용은 영역 중복 사용 - SQL Database를 참조하세요.

    영역 중복을 사용하도록 설정하는 것을 포함하여 모든 SQL Database 크기 조정 작업은 온라인 작업이며 가동 중지 시간을 최소화해야 합니다. 자세한 내용은 가동 중지 시간을 최소화하면서 데이터베이스 리소스를 동적으로 확장을 참조하세요.

  • 영역 중복을 사용하지 않도록 설정합니다. 영역 중복을 사용하지 않도록 설정할 수 있습니다. 이 프로세스는 일반 서비스 계층 목표 업그레이드와 유사한 온라인 작업입니다. 프로세스가 끝나면 데이터베이스가 영역 중복 링에서 단일 영역 링으로 마이그레이션됩니다.

하이퍼스케일 서비스 계층의 경우:

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

모든 영역이 정상인 경우의 동작

이 섹션에서는 데이터베이스가 영역 중복성을 위해 구성되고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.

범용 서비스 계층의 경우:

  • 영역 간의 트래픽 라우팅: 요청은 SQL 데이터베이스 컴퓨팅 계층을 실행하는 노드로 라우팅됩니다. 영역 중복을 사용하도록 설정하면 이 노드가 가용성 영역에 있을 수 있습니다.

  • 영역 간 데이터 복제: 데이터 및 로그 파일은 ZRS를 사용하여 가용성 영역에서 동기적으로 복제됩니다. 모든 가용성 영역에서 데이터가 성공적으로 복제될 때까지 쓰기 작업이 완료된 것으로 간주되지 않습니다. 이 동기 복제는 영역 오류 발생 시 강력한 일관성과 데이터 손실이 없도록 합니다. 그러나 LRS(로컬 중복 스토리지)에 비해 쓰기 대기 시간이 약간 더 높을 수 있습니다.

프리미엄 및 중요 비즈니스용 서비스 계층의 경우:

  • 영역 간의 트래픽 라우팅: 복제본은 가용성 영역에 분산되며 해당 복제본 중 하나가 주 복제본으로 지정됩니다. 요청은 데이터베이스의 주 복제본으로 라우팅됩니다.

  • 영역 간 데이터 복제: 주 복제본은 각 트랜잭션을 커밋하기 전에 충분한 수의 보조 복제본에서 데이터가 유지되도록 보조 복제본에 변경 내용을 순차적으로 푸시합니다. 이 프로세스는 어떤 이유로든 주 복제본 또는 읽기 가능한 보조 복제본을 사용할 수 없게 되면 항상 완전히 동기화된 복제본을 장애 조치(failover)에 사용할 수 있도록 보장합니다. 영역 중복을 사용하도록 설정하면 해당 복제본은 다른 가용성 영역에 있습니다. 그러나 이 프로세스는 트래버스 영역의 네트워크 대기 시간으로 인해 쓰기 대기 시간이 약간 더 높아질 수 있습니다.

하이퍼스케일 서비스 계층의 경우:

  • 영역 간의 트래픽 라우팅: 데이터베이스 복제본은 가용성 영역에 분산되며 해당 복제본 중 하나가 주 복제본으로 지정됩니다. 요청은 데이터베이스의 주 복제본으로 라우팅됩니다.

  • 영역 간 데이터 복제: 주 데이터베이스 복제본은 가용성 영역에서 모든 변경 내용을 동기적으로 복제하는 영역 중복 로그 서비스를 통해 변경 내용을 푸시합니다. 페이지 서버는 각 가용성 영역에 있으며 데이터베이스의 상태를 저장합니다. 이 프로세스는 어떤 이유로든 주 복제본 또는 읽을 수 있는 보조 복제본을 사용할 수 없게 되면 항상 완전히 동기화된 복제본을 장애 조치(failover)에 사용할 수 있도록 보장합니다. 그러나 이 프로세스로 인해 LRS에 비해 쓰기 대기 시간이 약간 더 높아질 수 있습니다.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

영역 오류 중 동작

이 섹션에서는 데이터베이스가 영역 중복에 대해 구성되고 가용성 영역 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 검색 및 응답: SQL Database는 가용성 영역의 오류를 감지하고 대응하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작하기 위해 어떤 작업도 수행할 필요가 없습니다.
  • 통지: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
  • 활성 요청: 가용성 영역이 오프라인 상태가 되면 잘못된 가용성 영역에서 처리되는 모든 요청이 종료되고 다시 시도해야 합니다. 이러한 유형의 문제에 대해 애플리케이션을 복원력 있게 만드는 방법에 대한 자세한 내용은 일시적인 오류에 대한 복원력 지침을 참조하세요.

  • 트래픽 경로 변경: 범용 서비스 계층의 경우 SQL Database는 데이터베이스 엔진을 다른 가용성 영역에 있고 충분한 사용 가능한 용량을 가진 다른 상태 비스테이블 컴퓨팅 노드로 이동합니다. 장애 조치(failover)가 완료되면 새 연결이 새 주 컴퓨팅 노드로 자동으로 리디렉션됩니다.

    자세한 내용은 범용 서비스 계층을 참조하세요.

  • 트래픽 경로 변경: 프리미엄 및 중요 비즈니스용 서비스 계층의 경우 SQL Database는 다른 가용성 영역에서 복제본을 선택하여 주 복제본이 됩니다. 보조 복제본이 새 주 복제본이 되면 클러스터에 쿼럼을 유지하기에 충분한 수의 복제본이 있는지 확인하기 위해 다른 보조 복제본이 만들어집니다. 장애 조치(failover)가 완료되면 새 연결이 새 주 복제본(또는 연결 문자열에 따라 읽을 수 있는 보조 복제본)으로 자동으로 리디렉션됩니다.

    자세한 내용은 프리미엄 및 중요 비즈니스용 서비스 계층을 참조하세요.

  • 트래픽 경로 변경: 하이퍼스케일 서비스 계층의 경우 영역 중단으로 인해 주 복제본이 손실된 경우 SQL Database는 다른 영역의 고가용성 복제본 중 하나를 새 주 복제본으로 승격합니다.

    자세한 내용은 Hyperscale 서비스 계층을 참조하세요.

  • 예상 가동 중지 시간: 가용성 영역 장애 조치(failover) 중에 약간의 가동 중지 시간이 발생할 수 있습니다. 가동 중지 시간은 일반적으로 30초 미만이며, 일시적인 오류 지침에 대한 복원력을 따르는 경우 애플리케이션에서 허용해야 합니다.

  • 예상 데이터 손실: 가용성 영역 장애 조치(failover) 중에 예상되는 데이터 손실은 없습니다.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

영역 복구

가용성 영역이 복구되면 Azure Service Fabric은 복구된 가용성 영역에 데이터베이스 복제본을 자동으로 만들고, 다른 가용성 영역에서 만든 임시 복제본을 제거하고, 데이터베이스에 대한 일반 트래픽 라우팅을 다시 시작합니다. 중단을 방지하기 위해 주 복제본은 영역 복구 후 원래 영역을 자동으로 반환하지 않습니다.

영역 오류 테스트

SQL Database 플랫폼은 영역 중복 데이터베이스에 대한 트래픽 라우팅, 장애 조치(failover) 및 영역 복구 절차를 관리합니다. 이 기능은 완전히 관리되므로 가용성 영역 오류 프로세스를 시작하거나 유효성을 검사할 필요가 없습니다. 그러나 테스트 애플리케이션 오류 복원력에 설명된 프로세스에 따라 애플리케이션의 오류 및 장애 조치 처리의 유효성을 검사할 수 있습니다.

지역 전체 오류에 대한 복원력

이 섹션에서는 SQL Database의 다중 지역 지역 복제에 사용할 수 있는 두 가지 관련 있지만 별도의 기능에 대해 간략하게 설명합니다.

  • 활성 지역 복제 는 단일 데이터베이스를 동기화된 보조 데이터베이스에 복제합니다.

  • 장애 조치(failover) 그룹은 활성 지역 복제를 기반으로 하며 데이터베이스 그룹을 장애 조치(failover)할 수 있습니다.

활성 지리적 복제

활성 지역 복제 는 단일 주 데이터베이스에 대해 모든 지역에서 지속적으로 동기화된 읽기 가능한 보조 데이터베이스( 지역 보조 또는 지역 복제본이라고도 함)를 만듭니다. 활성 지역 복제는 동일한 지역에 보조 데이터베이스를 만들 수 있지만 이 구성은 지역 중단에 대한 보호를 제공하지 않습니다. 활성 지역 복제를 사용하여 지역 중복성을 달성하는 경우 다른 지역에서 주 데이터베이스에 대한 보조 데이터베이스를 찾습니다.

요구 사항

활성 지역 복제를 사용하는 경우 다음 요구 사항을 고려합니다.

  • 지역 지원:활성 지역 복제 는 모든 Azure 지역에서 사용하도록 설정할 수 있으며 Azure 지역 쌍을 사용할 필요가 없습니다.

    팁 (조언)

    SQL Database는 Azure가 쌍을 이루는 지역에 동시에 업데이트를 배포하지 않도록 하는 안전한 배포 방법을 따릅니다. 복구되지 않은 지역을 사용하도록 활성 지역 복제를 구성하는 경우 각 지역의 서버에 대해 서로 다른 유지 관리 기간을 설정합니다. 이 방법을 사용하면 두 지역 모두 유지 관리로 인한 연결 문제가 동시에 발생할 가능성을 줄일 수 있습니다.

  • 구성: 기본 및 지역 보조는 모두 동일한 서비스 계층을 가져야 하며 컴퓨팅 계층, 컴퓨팅 크기 및 백업 스토리지 중복성이 동일해야 합니다.

  • 방화벽: 주 복제본과 지역 보조 복제본 모두 동일한 IP 주소 방화벽 규칙을 가져야 합니다.

  • Azure 구독: 활성 지역 복제는 여러 Azure 구독의 데이터베이스에 대해 지원됩니다.

고려 사항

  • 활성 지역 복제는 단일 데이터베이스에 대한 장애 조치를 제공하기 위해 설계되었습니다. 여러 데이터베이스를 장애 조치(failover)해야 하는 경우 장애 조치(failover) 그룹을 대신 사용하는 것이 좋습니다.

  • 지역 복제는 비동기이므로 장애 조치(failover)가 발생할 때 데이터 손실이 발생할 수 있습니다. 장애 조치(failover) 중에 비동기 복제에서 데이터 손실을 제거해야 하는 경우, 마지막으로 커밋된 트랜잭션이 전송되고 보조 데이터베이스의 트랜잭션 로그에 기록될 때까지 호출 스레드를 차단하도록 애플리케이션을 구성합니다. 이 방법을 사용하려면 사용자 지정 개발이 필요하며 애플리케이션의 성능이 저하됩니다. 자세한 내용은 중요한 데이터의 손실 방지를 참조하세요.

  • 제한 사항 및 고려 사항에 대한 자세한 내용은 활성 지역 복제를 참조하세요.

비용

보조 데이터베이스는 별도의 데이터베이스로 청구됩니다.

읽기 또는 쓰기 워크로드에 보조 데이터베이스를 사용하지 않는 경우 비용을 줄이기 위해 대기 복제본으로 지정할 수 있는지 여부를 고려합니다.

다중 지역 지원 구성

모든 지역이 정상인 경우의 동작

이 섹션에서는 데이터베이스가 활성 지역 복제를 사용하도록 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 지역 간 트래픽 라우팅: 주 데이터베이스에 읽기-쓰기 요청을 보내도록 애플리케이션을 구성해야 합니다. 필요에 따라 읽기 전용 요청을 보조 데이터베이스로 보낼 수 있으므로 읽기 전용 워크로드가 주 데이터베이스에 미치는 영향을 줄일 수 있습니다.

  • 지역 간 데이터 복제: 주 데이터베이스와 보조 데이터베이스 간의 복제는 비동기적으로 발생합니다. 즉, 변경 내용이 주 데이터베이스에 적용되는 시점과 보조 데이터베이스에 복제되는 시점 사이에 지연이 있을 수 있습니다.

    장애 조치(failover)를 수행할 때 데이터 손실 가능성을 처리하는 방법을 결정합니다.

지역 오류 중 동작

이 섹션에서는 데이터베이스가 활성 지역 복제를 사용하도록 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 검색 및 응답: 데이터베이스 또는 지역의 중단을 감지하고 장애 조치(failover)를 트리거하는 작업을 모두 담당합니다.
  • 알림: Microsoft는 지역이 다운된 경우 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.

  • 활성 요청: 장애 조치(failover) 중 활성 요청은 종료되며 다시 시도해야 합니다.

  • 예상 데이터 손실: 주 데이터베이스를 사용할 수 있는 경우 선택적으로 데이터 손실 없이 장애 조치(failover)를 수행할 수 있습니다. 장애 조치 프로세스는 역할을 전환하기 전에 주 데이터베이스와 보조 데이터베이스 간에 데이터를 동기화합니다.

    주 데이터베이스를 사용할 수 없는 경우 강제 장애 조치(failover)를 수행해야 하므로 데이터가 손실될 수 있습니다. 복제 지연을 모니터링하여 데이터 손실의 양을 예측할 수 있습니다. 자세한 내용은 메트릭 및 경고를 사용하여 SQL Database 모니터링을 참조하세요.

  • 예상 가동 중지 시간: 일반적으로 장애 조치(failover) 중에는 최대 60초의 가동 중지 시간이 있습니다. 짧은 가동 중지 시간에서 복구할 수 있도록 애플리케이션이 일시적인 오류를 처리하는 지 확인합니다. 또한 새 주 데이터베이스에 연결하기 위해 애플리케이션을 얼마나 빨리 다시 구성하면 발생하는 가동 중지 시간에 영향을 줍니다.

  • 트래픽 경로 변경: 새 주 데이터베이스에 요청을 보내도록 애플리케이션을 다시 구성할 책임이 있습니다. 장애 조치가 투명하게 이루어져야 한다면, 장애 조치 그룹을 사용하는 것이 좋습니다.

지역 복구

주 지역이 복구된 후에는 다른 장애 조치(failover)를 수행하여 주 지역으로 수동으로 장애 복구를 수행할 수 있습니다.

지역 오류 테스트

언제든지 수동 장애 조치를 트리거하여 지역 중단을 시뮬레이션할 수 있습니다. 데이터 손실 없는 장애 조치(failover)나 강제 장애 조치를 트리거할 수 있습니다.

장애 조치 그룹

Failover 그룹은 활성 지역 복제를 기반으로 구축됩니다. 장애 조치(failover) 그룹을 사용하면 다음 작업을 수행할 수 있습니다.

  • Azure 지역의 모든 조합에 걸쳐 단일 논리 서버에서 데이터베이스 집합을 복제합니다.

  • 그룹으로 데이터베이스에서 장애 조치(failover)를 수행합니다.

  • 기본 노드에 자동으로 연결을 유도하는 연결 엔드포인트를 사용합니다.

요구 사항

  • 지역 지원: 장애 조치(failover) 그룹은 모든 Azure 지역에서 만들 수 있으며 Azure 지역 쌍을 사용할 필요가 없습니다.

    팁 (조언)

    복구되지 않은 지역을 사용하여 장애 조치(failover) 그룹을 구성하는 경우 각 지역의 서버에 대해 다른 유지 관리 기간을 설정하는 것이 좋습니다. 이 방법을 사용하면 두 지역 모두 유지 관리로 인한 연결 문제가 동시에 발생할 가능성을 줄일 수 있습니다.

  • 구성: 장애 조치(failover) 그룹의 보조 데이터베이스는 주 데이터베이스와 동일한 서비스 계층, 컴퓨팅 계층, 컴퓨팅 크기, IP 주소 방화벽 규칙 및 백업 스토리지 중복성을 가져야 합니다.

고려 사항

  • 영역 중복성: 하이퍼스케일 서비스 계층의 경우 주 데이터베이스에 영역 중복이 사용하도록 설정된 경우 보조 데이터베이스는 영역 중복을 자동으로 사용하도록 설정됩니다.
  • 영역 중복성: 보조 데이터베이스는 기본적으로 영역 중복을 사용하도록 설정하지 않지만 나중에 사용하도록 설정할 수 있습니다.

  • 가능한 데이터 손실: 지역 복제는 비동기이므로 장애 조치(failover)가 발생할 때 데이터가 손실될 수 있습니다. 장애 조치(failover) 중에 비동기 복제에서 데이터 손실을 제거해야 하는 경우 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그에서 전송되고 강화될 때까지 호출 스레드를 차단하도록 애플리케이션을 구성할 수 있습니다. 이 방법을 사용하려면 사용자 지정 개발이 필요하며 애플리케이션의 성능이 저하됩니다. 자세한 내용은 중요한 데이터의 손실 방지를 참조하세요.

  • 제한 사항 및 고려 사항에 대한 자세한 내용은 장애 조치 그룹을 확인하세요.

비용

보조 데이터베이스는 별도의 데이터베이스로 청구됩니다.

읽기 또는 쓰기 워크로드에 보조 데이터베이스를 사용하지 않는 경우 비용을 줄이기 위해 대기 복제본으로 지정할 수 있는지 여부를 고려합니다.

다중 지역 지원 구성

  • 장애 조치(failover) 그룹 사용: 논리 서버에서 장애 조치(failover) 그룹을 구성합니다. 논리 서버의 모든 데이터베이스를 장애 조치(failover) 그룹에 추가하거나 추가할 데이터베이스의 하위 집합을 선택할 수 있습니다.

    장애 조치(failover) 그룹을 만들 때 장애 조치(failover) 정책을 선택합니다. 이 정책은 중단을 검색하고 장애 조치(failover)를 수행하는 담당자를 지정합니다. 고객이 관리하는 장애 조치, 권장되며, 또는 Microsoft가 관리하는 장애 조치를 구성할 수 있습니다.

    중요합니다

    Microsoft에서 시작한 장애 조치(failover)는 상당한 지연 후에 발생할 가능성이 높으며 최상의 노력으로 수행됩니다. 데이터베이스 장애 조치(failover)는 다른 Azure 서비스의 장애 조치 시점과 다르게 발생할 수 있습니다. 자세한 내용은 SQL Database에 대한 장애 조치(failover) 그룹 구성을 참조하세요.

    장애 조치(failover) 그룹을 구성한 후 초기 시드 단계에 다소 시간이 걸릴 수 있습니다.

  • 장애 조치(failover) 그룹 사용 안 함: 장애 조치(failover) 그룹에서 개별 데이터베이스를 제거하거나, 전체 장애 조치(failover) 그룹을 제거하거나, 데이터베이스를 다른 장애 조치(failover) 그룹으로 이동할 수 있습니다.

모든 지역이 정상인 경우의 동작

이 섹션에서는 데이터베이스가 장애 조치(failover) 그룹 내에서 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 지역 간 트래픽 라우팅: 읽기-쓰기 및 읽기 전용 워크로드의 경우 장애 조치(failover) 그룹은 애플리케이션을 연결할 수 있는 두 개의 수신기 엔드포인트를 제공합니다. 장애 조치 그룹 수신기 엔드포인트를 사용하여 장애 조치 중 가동 중지 시간을 최소화합니다. 정상적인 작업 중에는 다음과 같은 라우팅 동작이 발생합니다.

    • 읽기-쓰기 수신기 엔드포인트는 모든 요청을 주 데이터베이스로 라우팅합니다.

    • 읽기 전용 수신기 엔드포인트는 모든 요청을 읽을 수 있는 보조 데이터베이스로 라우팅합니다.

  • 지역 간 데이터 복제: 주 데이터베이스와 보조 데이터베이스 간의 지역에서 복제는 비동기적으로 발생합니다. 이 대기 시간은 주 데이터베이스에 적용되는 변경 내용과 보조 데이터베이스에 복제되는 시점 사이에 지연이 있을 수 있음을 의미합니다.

    장애 조치(failover)를 수행할 때 데이터 손실 가능성을 처리하는 방법을 결정합니다.

지역 오류 중 동작

이 섹션에서는 데이터베이스가 장애 조치(failover) 그룹 내에서 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 검색 및 응답 은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

    • 고객이 시작한 장애 조치(failover): 데이터베이스 또는 지역의 중단을 감지하고 장애 조치(failover)를 트리거할 책임이 있습니다.

    • Microsoft에서 시작한 장애 조치(failover): Microsoft는 영향을 받는 지역의 모든 장애 조치(failover) 그룹에 대해 장애 조치(failover)를 트리거합니다. Microsoft는 예외적인 상황에서만 이러한 유형의 장애 조치(failover)를 수행할 것으로 예상합니다. 대부분의 솔루션에는 Microsoft 관리 장애 조치(failover)를 사용하지 마세요. 자세한 내용은 장애 조치 정책(failover) - Microsoft 관리를 참조하세요.

  • 알림: Microsoft는 지역이 다운된 경우 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.

  • 활성 요청: 장애 조치(failover) 중 활성 요청은 종료되며 다시 시도해야 합니다.

  • 예상 데이터 손실: 데이터 손실은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

    • 고객이 시작한 장애 조치(failover): 주 데이터베이스를 사용할 수 있는 경우 선택적으로 데이터 손실 없이 장애 조치(failover)를 수행할 수 있습니다. 장애 조치 프로세스는 역할을 전환하기 전에 주 데이터베이스와 보조 데이터베이스 간에 데이터를 동기화합니다.

      주 데이터베이스를 사용할 수 없는 경우 강제 장애 조치(failover)를 수행해야 하므로 데이터가 손실될 수 있습니다. 복제 지연을 모니터링하여 데이터 손실의 양을 예측할 수 있습니다. 자세한 내용은 메트릭 및 경고를 사용하여 SQL Database 모니터링을 참조하세요.

    • Microsoft에서 시작한 장애 조치(failover): Microsoft에서 관리하는 장애 조치(failover)는 예외적인 상황에서만 트리거됩니다. Microsoft에서 관리하는 페일오버는 강제 페일오버이므로 일부 데이터 손실이 예상됩니다. 발생할 수 있는 데이터 손실의 양을 제어할 수 없습니다.

  • 예상 가동 중지 시간: 가동 중지 시간은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

    • 고객이 시작한 장애 조치(failover): 일반적으로 장애 조치(failover) 중에는 최대 60초의 가동 중지 시간이 있습니다. 짧은 가동 중지 시간에서 복구할 수 있도록 애플리케이션이 일시적인 오류를 처리하는 지 확인합니다.

    • Microsoft에서 시작한 장애 조치(failover): Microsoft가 장애 조치(failover)를 시작하기 전에 기다려야 하는 기간을 결정하는 유예 기간을 지정할 수 있습니다. 최소 유예 기간은 1시간입니다. 그러나 Microsoft 응답 시간은 적어도 몇 시간이 될 수 있습니다.

  • 트래픽 경로 변경: 장애 조치(failover) 중에 SQL Database는 필요에 따라 트래픽을 새 주 및 보조 데이터베이스로 전송하도록 읽기-쓰기 및 읽기 전용 수신기 엔드포인트를 업데이트합니다.

    새 보조 데이터베이스(이전의 주 데이터베이스)를 사용할 수 없는 경우 읽기 전용 수신기 엔드포인트는 새 보조 데이터베이스를 사용할 수 있게 될 때까지 연결할 수 없습니다.

지역 복구

필요한 경우 주 지역으로 복구하는 것은 사용자의 책임입니다. 고객 관리 장애 조치(failover)를 수행하여 주 지역으로 수동으로 장애 복구를 수행할 수 있습니다.

Microsoft에서 원래 장애 조치(failover)를 시작했더라도, 사용자가 선택하는 경우 이전 지역으로 장애 복구(failback)할 책임이 여전히 귀하에게 있습니다.

지역 오류 테스트

언제든지 수동 장애 조치를 트리거하여 지역 중단을 시뮬레이션할 수 있습니다. 데이터 손실 없는 장애 조치(failover)나 강제 장애 조치를 트리거할 수 있습니다.

백업 및 복원

데이터 손실을 비롯한 다양한 위험으로부터 보호하기 위해 데이터베이스의 백업을 수행합니다. 실수로 인한 데이터 손실, 손상 또는 기타 문제를 복구하기 위해 백업을 복원할 수 있습니다. 백업은 영역 중복성, 활성 지역 복제 또는 장애 조치(failover) 그룹과 다르며 용도가 다릅니다. 자세한 내용은 중복성, 복제 및 백업을 참조하세요.

SQL Database는 데이터베이스의 자동 백업을 제공합니다. 백업에서 복원해야 하는 경우 데이터 손실 양에 영향을 줄 수 있는 백업 빈도에 대한 자세한 내용은 SQL Database의 자동화된 백업을 참조하세요.

백업 스토리지

자동화된 백업을 LRS 또는 ZRS에 저장하도록 선택할 수 있습니다. 쌍을 이루는 지역을 사용하는 경우 지역 중복 스토리지를 사용하여 자동화된 백업을 쌍을 이루는 지역에 복제하도록 선택할 수 있습니다. 이 기능을 사용하면 백업을 지정된 쌍 지역으로 지리적 복원할 수 있습니다. 자세한 내용은 SQL Database의 자동화된 백업을 참조하세요.

페어링되지 않은 지역을 사용하거나 쌍을 이루는 지역이 아닌 다른 지역에 백업을 복제해야 하는 경우 데이터베이스를 내보내고 내보낸 파일을 blob 개체 복제를 사용하여 다른 지역의 스토리지 계정으로 복제하는 스토리지 계정에 저장하는 것이 좋습니다. 자세한 내용은 데이터베이스 내보내기를 참조하세요.

서비스 유지 관리에 대한 복원력

SQL Database가 데이터베이스 및 탄력적 풀에 대한 유지 관리를 수행하는 경우 보조 복제본을 사용하도록 데이터베이스를 자동으로 장애 조치(failover)할 수 있습니다. 클라이언트 애플리케이션은 장애 조치(failover)가 발생할 때 짧은 연결 중단을 경험할 수 있습니다. 클라이언트 애플리케이션은 일시적인 오류에 대한 복원력을 높이기 위해 지침을 따라야 합니다.

SQL Database를 사용하면 서비스 업그레이드 및 기타 유지 관리 작업에 일반적으로 사용되는 유지 관리 기간을 지정할 수 있습니다. 유지 관리 기간을 구성하면 업무 시간 동안 자동 장애 조치(failover)와 같은 부작용을 최소화하는 데 도움이 됩니다. 계획된 유지 관리에 대한 사전 알림을 받을 수도 있습니다.

플랫폼은 SQL Database에 대한 연결을 처리하는 데 사용되는 게이트웨이를 자동으로 유지 관리합니다. 업그레이드 또는 유지 관리 작업으로 인해 클라이언트가 다시 시도할 수 있는 짧은 연결 중단이 발생할 수도 있습니다.

자세한 내용은 SQL Database의 유지 관리 기간을 참조하세요.

서비스 수준 약정

Azure 서비스의 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 해당 가용성 예상 결과치를 달성하기 위해 솔루션이 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.

SQL Database에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성과 활성 지역 복제에 대한 예상 복구 지점 및 복구 시간을 설명합니다.

영역 중복 데이터베이스 또는 탄력적 풀을 배포하고 지원되는 서비스 계층을 사용하는 경우 가동 시간 SLA가 더 높습니다.

관련 콘텐츠

  • Last updated on