다음을 통해 공유

Azure SQL Database의 안정성

이 문서에서는 가용성 영역 및 다중 지역 배포를 통한 지역 내 복원력을 다루는 Azure SQL Database의 안정성 지원에 대해 설명합니다.

안정성은 사용자와 Microsoft 간의 공동 책임입니다. 이 가이드를 사용하여 특정 비즈니스 목표 및 가동 시간 목표를 충족하는 안정성 옵션을 결정할 수 있습니다.

프로덕션 배포 권장 사항

Azure SQL Database의 대부분의 프로덕션 배포에서는 다음 최소 구성을 고려하는 것이 좋습니다.

안정성 아키텍처 개요

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

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

  • 짧은 가동 중지 시간을 초래하는 관리 작업은 고객이 시작했습니다.
  • 서비스 유지 관리 작업.
  • 다음과 같은 문제 및 데이터 센터 중단:
    • 서비스에 전원을 공급하는 컴퓨터가 실행되는 랙.
    • SQL Database 엔진을 실행하는 VM을 호스트하는 물리적 컴퓨터입니다.
  • SQL Database 엔진의 기타 문제
  • 기타 계획되지 않은 지역적 중단 가능성.

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

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

일시적인 오류

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

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

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

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

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

가용성 영역 지원

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

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

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

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

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

요구 사항

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

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

범용 서비스 계층의 경우:

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

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

지원되는 지역

프리미엄, 범용 및 중요 비즈니스용 서비스 계층의 경우 가용성 영역을 지원하는 모든 Azure 지역에서 영역 중복성을 사용할 수 있습니다.

하이퍼스케일 서비스 계층의 경우 가용성 영역을 지원하는 모든 Azure 지역에서 영역 중복성을 사용할 수 있습니다. 그러나 하이퍼스케일 프리미엄 시리즈 및 프리미엄 시리즈 메모리 최적화 하드웨어에 대한 영역 중복 지원은 일부 Azure 지역에서 사용할 수 있습니다.

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

고려 사항

  • 지연 시간: 영역 중복 데이터베이스에는 서로 다른 데이터 센터에 복제본이 있기 때문에 네트워크 지연이 증가하면 트랜잭션 커밋 시간이 증가하여 일부 OLTP 워크로드의 성능에 영향을 미칠 수 있습니다. 대부분의 애플리케이션은 이러한 추가 대기 시간에 중요하지 않습니다.

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

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

비용

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

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

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

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

가용성 영역 지원 구성

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

  • 새 리소스: 데이터베이스를 만들 때 영역 중복으로 구성할 수 있습니다. 단일 Azure Database를 만들고 영역 중복성을 사용하여 구성하는 방법을 알아보려면 빠른 시작: 단일 데이터베이스 만들기 - Azure SQL Database를 참조하세요.

  • 기존 리소스: 기존 데이터베이스를 영역 중복으로 다시 구성할 수 있습니다. 영역 중복성을 사용하여 기존 데이터베이스를 다시 구성하는 방법을 알아보려면 영역 중복 사용 - Azure SQL Database를 참조하세요.

    영역 중복 사용을 포함한 모든 Azure SQL Database 크기 조정 작업은 온라인으로 수행되며, 가동 중지 시간은 최소화되거나 필요하지 않습니다. 자세한 내용은 가동 중지 시간을 최소화하면서 동적으로 데이터베이스 리소스 크기를 조정하는 것을 참조하세요.

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

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

  • 새 리소스: 하이퍼스케일 데이터베이스 및 탄력적 풀의 경우 데이터베이스를 만들 때 영역 중복성을 구성해야 합니다. 자세한 내용은 영역 중복 하이퍼스케일 데이터베이스 만들기를 참조하세요.

  • 영역 중복을 마이그레이션하거나 사용하지 않도록 설정합니다. 기존 하이퍼스케일 데이터베이스 또는 탄력적 풀에서 영역 중복을 사용하거나 사용하지 않도록 설정하려면 다시 배포해야 합니다. 이 프로세스는 고가용성을 위해 보조 복제본을 추가하고 다른 가용성 영역에 배치합니다.

    영역 중복을 사용하여 기존 하이퍼스케일 데이터베이스를 다시 배포하는 방법을 알아보려면 영역 중복 하이퍼스케일 데이터베이스 다시 배포 - Azure SQL Database를 참조하세요.

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

일반 작업

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

범용 서비스 계층의 경우:

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

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

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

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

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

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

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

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

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

영역 축소 경험

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

  • 검색 및 응답: Azure SQL Database는 가용성 영역에서 오류를 감지하고 대응하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작하기 위해 어떤 작업도 수행할 필요가 없습니다.

  • 활성 요청: 가용성 영역이 오프라인 상태가 되면 잘못된 가용성 영역에서 처리되는 모든 요청이 종료되고 다시 시도해야 합니다. 이러한 형식의 문제에 대한 애플리케이션을 복원력 있게 만들려면 임시 오류 처리 지침을 참조하세요.

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

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

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

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

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

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

  • 예상 가동 중지 시간: 가용성 영역 장애 조치(failover) 중에 약간의 가동 중지 시간이 발생할 수 있습니다. 일반적으로 가동 중지 시간은 30초 미만이며, 애플리케이션이 임시 오류 처리 지침을 따르는 경우 이 정도면 충분합니다.

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

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

영역 복구

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

영역 오류 테스트

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

다중 지역 지원

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

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

  • 장애 조치(failover) 그룹은 데이터베이스 그룹에 대한 장애 조치(failover) 기능을 제공함으로써 활성 지역 복제를 기반으로 빌드됩니다.

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

지역 지원

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

팁 (조언)

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

요구 사항

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

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

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

고려 사항

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

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

  • 활성 지역 복제를 검토하여 이 기능이 어떻게 작동하는지 자세히 이해합니다.

비용

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

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

다중 지역 지원 구성

일반 작업

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

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

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

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

지역 중단 환경

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

  • 검색 및 응답: 데이터베이스 또는 지역의 중단을 감지하고 장애 조치(failover)를 트리거하는 작업을 모두 담당합니다.

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

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

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

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

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

지역 복구

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

지역 오류 테스트

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

백업

데이터 손실을 포함한 다양한 위험으로부터 보호하기 위해 데이터베이스를 백업합니다. 실수로 데이터가 손실되거나 손상되거나 다른 문제가 발생한 경우 백업을 복원하여 복원할 수 있습니다. 백업은 영역 중복, 활성 지역 복제 또는 장애 조치(failover) 그룹과는 별개이며 용도가 다릅니다. 자세한 내용은 중복성, 복제 및 백업이란?

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

백업 스토리지

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

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

서비스 유지 관리 중 안정성

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

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

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

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

서비스 수준 약정

Azure SQL Database에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성과 활성 지역 복제에 대한 예상 복구 지점 및 복구 시간을 설명합니다. 또한 이러한 기대를 달성하기 위해 충족해야 하는 조건에 대해서도 설명합니다. 이러한 조건을 이해하려면 온라인 서비스에 대한 SLA(서비스 수준 계약)를 검토하는 것이 중요합니다.

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

관련 콘텐츠