장애 조치(failover) 그룹 개요 ＆ 모범 사례(Azure SQL 데이터베이스)

  • 아티클

적용 대상:Azure SQL Database

장애 조치(failover) 그룹 기능을 사용하면 논리 서버의 일부 또는 모든 데이터베이스를 다른 지역의 논리 서버로 복제 및 장애 조치할 수 있습니다. 이 문서에서는 Azure SQL 데이터베이스에서 사용하기 위한 모범 사례 및 권장 사항과 함께 장애 조치(failover) 그룹 기능에 대한 개요를 제공합니다.

시작하려면 장애 조치(failover) 그룹 구성을 검토합니다.

참고 항목

이 문서에서는 Azure SQL Database에 대한 장애 조치(failover) 그룹에 대해 설명합니다. Azure SQL Managed Instance의 경우 Azure SQL Managed Instance의 장애 조치(failover) 그룹을 참조하세요.

Azure SQL 데이터베이스 재해 복구에 대한 자세한 내용은 다음 비디오를 시청하세요.

개요

장애 조치(failover) 그룹 기능을 사용하면 데이터베이스를 다른 Azure 지역으로 복제 및 장애 조치(failover)를 관리할 수 있습니다. 논리 서버의 사용자 데이터베이스를 모두 또는 하위 집합으로 선택하여 다른 논리 서버에 복제본(replica) 수 있습니다. 대규모 지역 복제 데이터베이스의 배포 및 관리를 단순화하도록 디자인되었으며 활성 지역 복제 기능을 기반으로 하는 선언적 추상화입니다.

지역 장애 조치(failover) RPO 및 RTO에 대한 자세한 내용은 비즈니스 연속성 개요를 참조하세요.

엔드포인트 리디렉션

장애 조치(failover) 그룹은 지역 장애 조치(failover) 중에 변경되지 않는 읽기-쓰기 및 읽기 전용 수신기 엔드포인트를 제공합니다. 연결이 자동으로 현재 기본으로 라우팅되기 때문에 지리적 장애 조치(failover) 후에 애플리케이션에 대한 연결 문자열을 변경할 필요가 없습니다. 지역 장애 조치(failover)는 그룹의 모든 보조 데이터베이스를 주 역할로 전환합니다. 지역 장애 조치(failover)가 완료되면 엔드포인트를 새 지역으로 리디렉션하도록 DNS 레코드가 자동으로 업데이트됩니다.

읽기 전용 워크로드 오프로드

주 데이터베이스에 대한 트래픽을 줄이기 위해 장애 조치(failover) 그룹의 보조 데이터베이스를 사용하여 읽기 전용 워크로드를 오프로드할 수도 있습니다. 읽기 전용 수신기를 사용하여 읽기 전용 트래픽을 읽기 가능한 보조 데이터베이스로 보냅니다.

애플리케이션 복구

완전한 비즈니스 연속성을 달성하기 위해 지역 데이터베이스 중복성을 추가하는 것은 솔루션의 일부일 뿐입니다. 치명적인 오류 후 애플리케이션(서비스) 엔드투엔드 복구에는 서비스 및 모든 종속성 서비스를 구성하는 모든 구성 요소의 복구가 필요합니다. 이러한 구성 요소의 예에는 클라이언트 소프트웨어(예: 사용자 지정 JavaScript를 사용한 브라우저), 웹 프런트 엔드, 스토리지 및 DNS가 포함됩니다. 모든 구성 요소는 동일한 오류에 탄력적이며 애플리케이션의 RTO(복구 시간 목표) 내에서 사용할 수 있는 것이 중요합니다. 따라서 모든 종속성 서비스를 확인하고 제고하는 보장 사항 및 기능을 이해해야 합니다. 그런 다음 의존하는 서비스 장애 조치 중 서비스 기능을 확인하도록 적절한 단계를 수행해야 합니다.

장애 조치(failover) 정책

장애 조치(failover) 그룹은 다음과 같은 두 개의 장애 조치(failover) 정책을 지원합니다.

  • 고객 관리(권장) - 고객이 장애 조치(failover) 그룹의 하나 이상의 데이터베이스에 영향을 미치는 예기치 않은 중단을 발견하면 그룹의 장애 조치(failover)를 수행할 수 있습니다. PowerShell, Azure CLI 또는 Rest API와 같은 명령줄 도구를 사용하는 경우 고객 관리 장애 조치(failover) 정책 값은 manual입니다.
  • Microsoft 관리 - 주 지역에 영향을 주는 광범위한 중단이 발생하는 경우 Microsoft는 장애 조치(failover) 정책을 Microsoft 관리로 구성된 영향을 받은 모든 장애 조치(failover) 그룹의 장애 조치(failover)를 시작합니다. Microsoft 관리 장애 조치(failover)는 개별 장애 조치(failover) 그룹 또는 하위 지역의 장애 조치(failover) 그룹의 하위 집합에 대해서는 시작되지 않습니다. PowerShell, Azure CLI 또는 Rest API와 같은 명령줄 도구를 사용하는 경우, Microsoft 관리 장애 조치(failover) 정책 값은 automatic입니다.

각 장애 조치(failover) 정책에는 다음 테이블에서 요약한 대로 장애 조치(failover) 범위 및 데이터 손실에 대한 고유한 사용 사례 집합과 해당 기대 사항이 있습니다.

장애 조치(failover) 정책 장애 조치(failover) 범위 사용 사례 잠재적 데이터 손실
고객 관리형
(권장)		 장애 조치(failover) 그룹 장애 조치(failover) 그룹에서 하나 이상의 데이터베이스가 가동 중단의 영향을 받아 사용할 수 없게 됩니다. 장애 조치(failover)를 선택할 수 있습니다. 예
Microsoft 관리 지역의 모든 장애 조치(failover) 그룹 데이터 센터, 가용성 영역 또는 지역의 광범위한 가동 중단으로 인해 데이터베이스를 사용할 수 없게 되며 Microsoft Azure SQL 서비스 팀은 강제 장애 조치(failover)를 트리거하기로 결정합니다.
애플리케이션은 1시간 이상의 RTO(가동 중지 시간)를 허용하고 재해 복구 책임을 Microsoft에 위임하려는 경우에만 이 옵션을 사용합니다.		 예

고객 관리형

드물지만 기본 제공 가용성 또는 고가용성만으로 가동 중단을 완화하지 못하고, 데이터베이스를 사용하는 애플리케이션의 SLA(서비스 수준 약정)에서 허용하지 않는 시간 동안 장애 조치(failover) 그룹의 데이터베이스를 사용하지 못하는 경우가 있습니다. 일부 데이터베이스에만 영향을 미치는 지역화된 문제로 인해 데이터베이스를 사용할 수 없거나 데이터 센터, 가용성 영역 또는 지역 수준에 존재할 수 있습니다. 이러한 경우에서 비즈니스 연속성을 복원하기 위해 강제 장애 조치(failover)를 시작할 수 있습니다.

장애 조치(failover) 정책을 고객 관리형으로 설정하는 것이 좋습니다. 장애 조치(failover)를 시작하고 비즈니스 연속성을 복원할 시기를 제어할 수 있기 때문입니다. 장애 조치(failover) 그룹에 있는 하나 이상의 데이터베이스에 영향을 주는 예기치 않은 가동 중단이 발견되면 장애 조치(failover)를 시작할 수 있습니다.

Microsoft 관리

Microsoft 관리 장애 조치(failover) 정책을 통해 재해 복구 책임이 Azure SQL 서비스로 위임됩니다. Azure SQL 서비스가 강제 장애 조치(failover)를 시작하려면 다음 조건을 충족해야 합니다.

  • 자연 재해 이벤트, 구성 변경, 소프트웨어 버그 또는 하드웨어 구성 요소 장애 및 해당 지역의 많은 데이터베이스로 인한 데이터 센터, 가용성 영역 또는 지역 수준 가동 중단이 영향을 받습니다.
  • 유예 기간이 만료되었습니다. 가동 중단 규모와 완화 정도를 확인하려면 사람이 작업해야 하므로 유예 기간을 1시간 미만으로 설정할 수 없습니다.

이러한 조건이 충족되면 Azure SQL 서비스는 장애 조치(failover) 정책이 Microsoft 관리로 설정된 지역의 모든 장애 조치(failover) 그룹에 대해 강제 장애 조치(failover)를 시작합니다.

다음 경우에만 Microsoft 관리로 장애 조치(failover) 정책을 설정합니다.

  • 재해 복구 책임을 Azure SQL 서비스에 위임하려고 합니다.
  • 애플리케이션에서 데이터베이스를 1시간 이상 사용할 수 없는 상황을 허용합니다.
  • 강제 장애 조치(failover)의 실제 시간이 크게 달라질 수 있으므로 유예 기간이 만료된 후 일정 시간 동안 강제 장애 조치(failover)를 트리거할 수 있습니다.
  • 장애 조치(failover) 그룹에 있는 모든 데이터베이스는 영역 중복 구성 또는 가용성 상태와 관계없이 장애 조치(failover)가 허용됩니다. 영역 중복을 위해 구성된 데이터베이스는 영역 오류에 대한 복원력을 지원하고 가동 중단의 영향을 받지 않을 수 있지만, Microsoft 관리 장애 조치(failover) 정책을 통해 장애 조치(failover) 그룹에 속한 경우에도 장애 조치(failover)됩니다.
  • 애플리케이션에서 사용하는 다른 Azure 서비스 또는 구성 요소에 대한 애플리케이션의 종속성을 고려하지 않고 장애 조치(failover) 그룹의 데이터베이스를 강제 장애 조치(failover)할 수 있으며, 이로 인해 애플리케이션의 성능이 저하되거나 사용 불가능하게 될 수 있습니다.
  • 강제 장애 조치(failover)의 정확한 시간을 제어할 수 없고 보조 데이터베이스의 동기화 상태를 무시하므로 알 수 없는 양의 데이터 손실이 발생할 수 있습니다.
  • 장애 조치(failover) 그룹의 모든 주 및 보조 데이터베이스에서 서비스 계층, 컴퓨팅 계층(프로비전 또는 서버리스) 및 컴퓨팅 크기(DTU 또는 vCore)는 동일합니다. 장애 조치(failover) 그룹에 있는 모든 데이터베이스의 SLO(서비스 수준 목표)가 일치하지 않는 경우 장애 조치(failover) 정책은 결국 Azure SQL 서비스에 의해 Microsoft 관리에서 고객 관리로 업데이트됩니다.

Microsoft에서 장애 조치(failover)를 트리거하면 Azure SQL 장애 조치(failover) 그룹 장애 조치(failover) 작업 이름 항목이 Azure Monitor 활동 로그에 추가됩니다. 이 항목은 리소스 아래에 장애 조치(failover) 그룹 이름을 포함하고 이벤트 시작 위치에서는 Microsoft에서 장애 조치(failover)를 시작했음을 나타내기 위해 단일 하이픈(-)이 표시됩니다. 이 정보는 Azure Portal에서 새 주 서버 또는 인스턴스의 활동 로그 페이지에서도 찾을 수 있습니다.

용어 및 기능

  • FOG(장애 조치 그룹)

    장애 조치(failover) 그룹은 주 지역의 중단으로 인해 모든 또는 일부 주 데이터베이스를 사용할 수 없는 경우 다른 Azure 지역에 대한 단위로 장애 조치(failover)할 수 있는 Azure 내 단일 논리 서버에서 관리하는 명명된 데이터베이스 그룹입니다.

    Important

    장애 조치 그룹의 이름은 .database.windows.net 도메인에서 전역적으로 고유해야 합니다.

  • 서버

    논리 서버의 사용자 데이터베이스 중 일부 또는 모두를 장애 조치(failover) 그룹에 배치할 수 있습니다. 또한 서버는 단일 서버에서 여러 개의 장애 조치 그룹을 지원합니다.

  • 주

    장애 조치(failover) 그룹에서 주 데이터베이스를 호스팅하는 논리 서버입니다.

  • 보조

    장애 조치(failover) 그룹에서 보조 데이터베이스를 호스팅하는 논리 서버입니다. 보조는 주 데이터베이스와 동일한 Azure 지역에 있을 수 없습니다.

  • 장애 조치(failover)(데이터 손실 없음)

    장애 조치(failover)는 보조 역할이 주 역할로 전환되기 전에 주 데이터베이스와 보조 데이터베이스 간에 전체 데이터 동기화를 수행합니다. 이렇게 하면 데이터 손실이 발생하지 않습니다. 장애 조치(failover)는 주 위치에 액세스할 수 있는 경우에만 가능합니다. 장애 조치(failover)는 다음과 같은 시나리오에서 사용합니다.

    • 데이터 손실이 허용되지 않을 때 프로덕션에서 DR(재해 복구) 연습 수행
    • 워크로드를 다른 지역으로 재배치
    • 가동 중단이 완화된 후 워크로드를 주 지역으로 반환(장애 복구(failback))

  • 강제 장애 조치(failover)(데이터 손실 가능성)

    강제 장애 조치(failover)는 주 역할에서 최근 변경 내용이 전파될 때까지 기다리지 않고 즉시 보조 역할을 주 역할로 전환합니다. 이 작업으로 인해 데이터가 손실될 수 있습니다. 강제 장애 조치(failover)는 주 역할에 액세스할 수 없을 때 가동 중단 중에 복구 방법으로 사용됩니다. 중단이 완화되면 이전 주 데이터베이스는 자동으로 다시 연결되고 새로운 보조 데이터베이스가 됩니다. 장애 조치(failover)를 실행하여 장애 복구하고, 복제본을 원래 주 역할 및 보조 역할로 되돌릴 수 있습니다.

  • 데이터 손실이 있는 유예 기간

    데이터가 비동기 복제를 사용하여 보조 위치에 복제되므로 Microsoft 관리 장애 조치(failover) 정책을 사용하는 그룹의 강제 장애 조치(failover) 시 데이터가 손실될 수 있습니다. 애플리케이션의 데이터 손실 허용 오차를 반영하도록 장애 조치(failover) 정책을 사용자 지정할 수 있습니다. GracePeriodWithDataLossHours를 구성하면 데이터 손실을 초래할 수 있는 강제 장애 조치(failover)가 시작될 때까지 Azure SQL 서비스가 대기하는 시간을 제어할 수 있습니다.

  • 장애 조치(failover) 그룹에 단일 데이터베이스 추가

    동일한 논리 서버에 있는 여러 개의 단일 데이터베이스를 동일한 장애 조치 그룹에 포함할 수 있습니다. 장애 조치(failover) 그룹에 단일 데이터베이스를 추가하면 장애 조치 그룹을 만들 때 지정한 보조 서버에 동일한 버전과 컴퓨팅 크기를 사용하는 보조 데이터베이스가 자동으로 만들어집니다. 보조 서버에 보조 데이터베이스가 이미 있는 데이터베이스를 추가하는 경우 해당 지역 복제 링크가 그룹에 상속됩니다. 장애 조치(failover) 그룹에 속하지 않는 서버에 보조 데이터베이스가 이미 있는 데이터베이스를 추가하면 새 보조 데이터베이스가 보조 서버에 만들어집니다.

    Important

    • 기존 보조 데이터베이스가 아닌 경우 보조 논리 서버에 이름이 같은 데이터베이스가 없는지 확인합니다.
    • 메모리 내 OLTP 개체가 데이터베이스에 포함된 경우 메모리 내 OLTP 개체는 메모리에서 상주하므로 주 데이터베이스와 보조 지역 복제본(replica) 데이터베이스에서 서비스 계층이 일치해야 합니다. 지역 복제본(replica) 데이터베이스의 서비스 계층이 더 낮으면 메모리 부족 문제가 발생할 수 있습니다. 이 경우 지역 복제본(replica)에서 데이터베이스를 복구하지 못하여 보조 데이터베이스를 지역 보조 데이터베이스의 메모리 내 OLTP 개체와 함께 사용할 수 없습니다. 이로 인해 장애 조치(failover)도 실패할 수 있습니다. 이를 방지하려면 지역 보조 데이터베이스의 서비스 계층이 주 데이터베이스의 서비스 계층과 일치해야 합니다. 서비스 계층 업그레이드는 데이터 크기 작업일 수 있으며 완료하는 데 시간이 걸릴 수 있습니다.

  • 장애 조치(failover) 그룹에 탄력적 풀의 데이터베이스 추가

    탄력적 풀에 있는 전체 또는 여러 개의 데이터베이스를 동일한 장애 조치(failover) 그룹에 포함할 수 있습니다. 탄력적 풀에 주 데이터베이스가 있는 경우 동일한 이름을 가진 보조 데이터베이스가 탄력적 풀에 자동으로 만들어집니다(보조 풀). 장애 조치(failover) 그룹에서 만들 보조 데이터베이스를 호스트하기에 충분한 여유 용량과 정확히 동일한 이름을 가진 탄력적 풀이 보조 서버에 있는지 확인해야 합니다. 보조 풀에 보조 데이터베이스가 이미 있는 데이터베이스를 풀에 추가하는 경우 해당 지역 복제 링크가 그룹에 상속됩니다. 장애 조치(failover) 그룹에 속하지 않는 서버에 이미 보조 데이터베이스가 있는 데이터베이스를 추가하면 보조 풀에 새 보조 데이터베이스가 만들어집니다.

  • 장애 조치 그룹 읽기-쓰기 수신기

    현재 주 지역을 가리키는 DNS CNAME 레코드입니다. 장애 조치(failover) 그룹을 만들 때 자동으로 생성되며 장애 조치(failover) 후에 주 지역이 변경될 때 읽기-쓰기 워크로드가 주 데이터베이스에 투명하게 다시 연결할 수 있습니다. 서버에 장애 조치 그룹이 생성되면 리스너 URL의 DNS CNAME 레코드는 <fog-name>.database.windows.net으로 구성됩니다. 장애 조치 후 DNS 레코드가 자동으로 업데이트되어 수신기를 새 기본 레코드로 리디렉션합니다.

  • 장애 조치 그룹 읽기 전용 수신기

    현재 보조 지역을 가리키는 DNS CNAME 레코드입니다. 장애 조치(failover) 그룹을 만들 때 자동으로 생성되며 장애 조치(failover) 후에 보조 지역이 변경될 때 읽기 전용 SQL 워크로드가 보조 데이터베이스에 투명하게 연결할 수 있습니다. 서버에 장애 조치 그룹이 생성되면 리스너 URL의 DNS CNAME 레코드는 <fog-name>.secondary.database.windows.net으로 구성됩니다. 기본적으로 읽기 전용 수신기의 장애 조치(failover)는 보조 위치가 오프라인 상태일 때 주 위치의 성능에 영향을 주지 않도록 하기 위해 사용하지 않도록 설정됩니다. 그러나 보조 서버가 복구될 때까지 읽기 전용 세션이 연결할 수 없음을 의미합니다. 읽기 전용 세션의 가동 중지 시간을 허용할 수 없고 주 데이터베이스의 성능이 잠재적으로 저하되더라도 읽기 전용 및 읽기/쓰기 트래픽 둘 다에 주 데이터베이스를 사용할 수 있으면, AllowReadOnlyFailoverToPrimary 속성을 구성하여 읽기 전용 수신기에 장애 조치를 사용하도록 설정할 수 있습니다. 이 경우, 보조 데이터베이스를 사용할 수 없으면 읽기 전용 트래픽이 주 데이터베이스로 자동으로 리디렉션됩니다.

    참고 항목

    AllowReadOnlyFailoverToPrimary 속성은 Microsoft 관리 장애 조치(failover) 정책이 사용되고 강제 장애 조치(failover)가 트리거된 경우에만 적용됩니다. 이 경우 속성이 True로 설정되면 새로운 주 데이터베이스에서 읽기/쓰기 및 읽기 전용 세션을 모두 제공합니다.

  • 여러 장애 조치 그룹

    같은 서버 쌍에 대해 여러 장애 조치(failover) 그룹을 구성하여 지역 장애 조치(failover)의 범위를 제어할 수 있습니다. 각 그룹은 독립적으로 장애 조치됩니다. 데이터베이스당 테넌트 애플리케이션이 여러 지역에 배포되어 탄력적 풀을 사용하는 경우 이 기능을 사용하여 각 풀에서 주 데이터베이스와 보조 데이터베이스를 혼합할 수 있습니다. 이렇게 하면 중단의 영향을 일부 테넌트 데이터베이스로 제한할 수 있습니다.

장애 조치(failover) 그룹 아키텍처

Azure SQL Database의 장애 조치(failover) 그룹에는 일반적으로 동일한 애플리케이션에서 사용되는 하나 이상의 데이터베이스가 포함될 수 있습니다. 기본 서버에 장애 조치(failover) 그룹을 구성하여 다른 Azure 지역의 보조 서버에 연결해야 합니다. 장애 조치(failover) 그룹에는 기본 서버의 모든 데이터베이스 또는 일부 데이터베이스가 포함될 수 있습니다. 다음 다이어그램은 장애 조치(failover) 그룹에서 여러 데이터베이스를 사용하는 지역 중복 클라우드 애플리케이션의 일반적인 구성을 보여 줍니다.

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

비즈니스 연속성을 염두에 두고 서비스를 설계할 때는 이 문서에 설명된 일반 지침과 모범 사례를 따릅니다. 장애 조치(failover) 그룹을 구성할 때, 지역-보조가 새로운 주 지역이 될 때 보조 지역의 인증 및 네트워크 액세스가 지역 장애 조치(failover) 후에 올바르게 작동하도록 설정해야 합니다. 자세한 내용은 재해 복구 후의 SQL Database 보안을 참조하세요. 더 자세한 정보는 재해 복구를 위한 클라우드 솔루션 디자인을 참고하세요.

쌍을 이루는 지역 사용

주 서버와 보조 서버 간에 장애 조치(failover) 그룹을 만들 때 쌍을 이루는 지역의 장애 조치(failover) 그룹으로 쌍을 이루는 지역을 사용하면 페어링 지역에 비해 성능이 향상됩니다.

안전한 배포 방법에 따라 Azure SQL Database는 일반적으로 쌍을 이루는 지역을 동시에 업데이트하지 않습니다. 그러나 먼저 업그레이드할 지역을 예측할 수 없으므로 배포 순서가 보장되지 않습니다. 주 서버가 먼저 업그레이드되고 두 번째로 업그레이드되는 경우도 있습니다.

Azure 지역 페어링과 일치하지 않는 데이터베이스에 대해 지역 복제 또는 장애 조치(failover) 그룹을 구성한 경우, 기본 데이터베이스와 보조 데이터베이스에 대해 서로 다른 유지 관리 기간 일정을 사용하세요. 예를 들어 보조 데이터베이스에는 주중 유지 관리 기간을, 주 데이터베이스에는 주말 유지 관리 기간을 선택할 수 있습니다.

초기 시드

장애 조치(failover) 그룹에 데이터베이스 또는 탄력적 풀을 추가할 때 데이터 복제가 시작되기 전에 초기 시드 단계가 있습니다. 초기 시드 단계는 가장 길고 비용이 많이 드는 작업입니다. 초기 시드가 완료되면 데이터가 동기화되고 후속 데이터 변경 내용만 복제됩니다. 초기 시드를 완료하는 데 걸리는 시간은 데이터의 크기, 복제된 데이터베이스의 수, 주 데이터베이스의 부하, 주 지역과 보조 지역 간의 네트워크 링크 속도에 따라 다릅니다. 정상적인 상황에서 가능한 시드 속도는 SQL Database에 대해 시간당 최대 500GB입니다. 모든 데이터베이스에 대해 시드가 병렬로 수행됩니다.

여러 장애 조치(failover) 그룹을 사용하여 여러 데이터베이스 장애 조치(failover)

다른 하위 지역의 두 서버(기본 및 보조 서버) 간에 하나 이상의 장애 조치 그룹을 만들 수 있습니다. 주 지역의 가동 중단으로 인해 주 데이터베이스 전체 또는 일부를 사용할 수 없게 되는 경우를 대비하여 각 그룹에 한 단위로 복구되는 하나 또는 여러 개의 데이터베이스가 포함될 수 있습니다. 장애 조치(failover) 그룹을 만들면 주 데이터베이스와 서비스 목표가 같은 지역 보조 데이터베이스가 생성됩니다. 장애 조치(failover) 그룹에 기존의 지역 복제 관계를 추가하는 경우 보조 데이터베이스가 주 데이터베이스와 동일한 서비스 계층 및 컴퓨팅 크기로 구성되었는지 확인합니다.

읽기-쓰기 수신기 사용(주)

읽기-쓰기 워크로드의 경우 연결 문자열의 서버 이름으로 <fog-name>.database.windows.net을 사용합니다. 연결은 자동으로 주 인스턴스에 연결됩니다. 이 이름은 장애 조치(failover) 후에 변경되지 않습니다. 장애 조치(failover) 시에는 DNS 레코드가 업데이트되므로 클라이언트 DNS 캐시를 새로 고친 후에만 클라이언트 연결이 새 주 데이터베이스로 리디렉션됩니다. 주 수신기 및 보조 수신기 DNS 레코드의 TTL(Time To Live)은 30초입니다.

읽기 전용 수신기 사용(보조)

데이터 대기 시간을 허용하는 논리적으로 격리된 읽기 전용 워크로드가 있는 경우 지역 보조 데이터베이스에서 이러한 워크로드를 실행할 수 있습니다. 읽기 전용 세션의 경우 연결 문자열의 서버 이름으로 <fog-name>.secondary.database.windows.net을 사용합니다. 연결은 자동으로 지역 보조 데이터베이스에 연결됩니다. 또한 ApplicationIntent=ReadOnly를 사용하여 연결 문자열에 읽기 의도를 표시하는 것이 좋습니다.

프리미엄, 중요 비즈니스용, 하이퍼스케일 서비스 계층에서 SQL Database는 연결 문자열의 ApplicationIntent=ReadOnly 매개 변수를 사용하여 읽기 전용 쿼리 워크로드를 오프로드하도록 읽기 전용 복제본 사용을 지원합니다. 지역 보조 데이터베이스를 구성한 경우 이 기능을 사용하여 주 위치 또는 복제된 지역 위치에 있는 읽기 전용 복제본에 연결할 수 있습니다.

보조 위치의 읽기 전용 복제본에 연결하려면 ApplicationIntent=ReadOnly와 <fog-name>.secondary.database.windows.net을 사용합니다.

장애 조치(failover) 후 잠재적인 성능 저하

일반적인 Azure 애플리케이션은 여러 Azure 서비스를 사용하며 여러 구성 요소로 구성됩니다. 그룹의 장애 조치(failover)는 Azure SQL 데이터베이스의 상태에 따라 트리거됩니다. 주 지역의 다른 Azure 서비스는 중단의 영향을 받지 않을 수 있으며 해당 구성 요소는 해당 지역에서 계속 사용할 수 있습니다. 주 데이터베이스가 보조(DR) 지역으로 전환되면 종속 구성 요소 사이의 대기 시간이 증가할 수 있습니다. 늘어난 대기 시간이 애플리케이션 성능에 영향을 주지 않도록, DR 지역에 있는 모든 애플리케이션 구성 요소가 중복되도록 하고, 네트워크 보안 지침을 따르고, 데이터베이스와 함께 관련 애플리케이션 구성 요소의 지역 장애 조치(failover)를 오케스트레이션합니다.

강제 장애 조치(failover) 후 데이터 손실 가능성

주 지역에서 중단이 발생하는 경우 최근 트랜잭션이 지역 보조 데이터베이스에 복제되지 않았을 수 있으며 강제 장애 조치(failover)가 수행되면 데이터가 손실될 수 있습니다.

Important

DTU가 800개 이하이거나 vCore가 8개 이하이고 데이터베이스가 250개를 초과하는 Elastic Pool에서는 계획된 지역 장애 조치(failover)가 지연되고 성능이 저하되는 등의 문제가 발생할 수 있습니다. 이러한 문제는 지역 복제본(replica)이 지역적으로 광범위하게 분리되어 있거나 여러 보조 지역 복제본(replica)이 각 데이터베이스에 사용되는 경우 쓰기 집약적 워크로드에서 발생할 가능성이 높습니다. 이러한 문제의 증상으로 지역 복제 지연이 시간이 갈수록 커지고, 중단으로 인한 데이터 손실이 더 커질 수 있습니다. 이러한 지연은 sys.dm_geo_replication_link_status를 사용하여 모니터링할 수 있습니다. 이러한 문제가 발생하면 풀을 스케일 업하여 DTU 또는 vCore 수를 늘리거나 풀의 지역 복제 데이터베이스 수를 줄이는 조치를 취할 수 있습니다.

장애 복구

장애 조치(failover) 그룹이 Microsoft 관리 장애 조치(failover) 정책으로 구성된 경우 정의된 유예 기간에 따라 재해 시나리오 중에 지역 보조 서버로 강제 장애 조치(failover)가 시작됩니다. 이전 주 위치로의 장애 복구(failback)는 수동으로 시작해야 합니다.

권한 및 제한 사항

권한 및 제한 사항 목록은 장애 조치(failover) 그룹 구성 가이드를 검토합니다.

프로그래밍 방식으로 장애 조치(failover) 그룹 관리

Azure PowerShell, Azure CLI 및 REST API를 사용하여 프로그래밍 방식으로 장애 조치(failover) 그룹을 관리할 수도 있습니다. 자세한 내용은 장애 조치(failover) 그룹 구성에서 확인할 수 있습니다.

관련 콘텐츠