Azure SQL Database에 대한 장애 조치(failover) 그룹 구성

적용 대상:Azure SQL Database

이 문서에서는 Azure Portal, Azure PowerShell 및 Azure CLI를 사용하여 Azure SQL Database의 단일 및 풀링된 데이터베이스에 대해 장애 조치 그룹을 구성하는 방법을 설명합니다.

엔드 투 엔드 스크립트의 경우 Azure PowerShell 또는 Azure CLI를 사용하여 장애 조치 그룹에 단일 데이터베이스를 추가하는 방법을 검토합니다.

필수 조건

단일 데이터베이스에 대한 장애 조치(failover) 그룹을 만들려면 다음 사전 요구 사항을 고려합니다.

  • 보조 서버의 서버 로그인 및 방화벽 설정은 주 서버와 일치해야 합니다.

장애 조치 그룹 만들기

Azure Portal을 사용하여 장애 조치 그룹을 만들고 단일 데이터베이스를 이 그룹에 추가합니다.

  1. Azure Portal의 왼쪽 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 다음, 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기로 선택하고 왼쪽 탐색에 항목으로 추가합니다.

  2. 장애 조치 그룹에 추가하려는 데이터베이스를 선택합니다.

  3. 서버 이름에서 서버 이름을 선택하여 서버에 대한 설정을 엽니다.

    Open server for single db

  4. 설정 창에서 장애 조치(Failover) 그룹을 선택한 후 그룹 추가를 선택하여 새 장애 조치(failover) 그룹을 만듭니다.

    Add new failover group

  5. 장애 조치(failover) 그룹 페이지에서 필요한 값을 입력하거나 선택한 다음, 만들기를 선택합니다. 새 보조 서버를 만들거나 기존 보조 서버를 선택합니다. 장애 조치 그룹의 보조 서버는 주 서버와는 다른 지역에 있어야 합니다.

    • 그룹 내의 데이터베이스: 장애 조치 그룹에 추가하려는 데이터베이스를 선택합니다. 장애 조치(failover) 그룹에 데이터베이스를 추가하면 지역 복제 프로세스가 자동으로 시작됩니다.

    Add SQL Database to failover group

계획된 장애 조치 테스트

Azure Portal 또는 PowerShell을 사용하여 데이터 손실 없이 장애 조치 그룹의 장애 조치를 테스트합니다.

Azure Portal을 사용하여 장애 조치(failover) 그룹의 장애 조치를 테스트합니다.

  1. Azure Portal의 왼쪽 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 다음, 검색 상자에 "Azure SQL"을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기로 선택하고 왼쪽 탐색에 항목으로 추가합니다.

  2. 장애 조치 그룹에 추가하려는 데이터베이스를 선택합니다.

    Open server for single db

  3. 설정 창에서 장애 조치(failover) 그룹을 선택한 다음, 방금 만든 장애 조치 그룹을 선택합니다.

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  4. 주 서버와 보조 서버를 검토합니다.

  5. 작업창에서 장애 조치(failover)를 선택하여 데이터베이스가 포함된 장애 조치 그룹을 장애 조치합니다.

  6. TDS 세션의 연결이 해제됨을 알려주는 경고에서 를 선택합니다.

    Fail over your failover group containing your database

  7. 이제 어떤 서버가 주 서버이고 어떤 서버가 보조 서버인지 검토합니다. 장애 조치(failover)가 성공하면 두 서버의 역할이 바뀌어야 합니다.

  8. 장애 조치(failover) 를 다시 선택하여 서버를 원래 역할로 장애 조치(Failover) 합니다.

Important

보조 데이터베이스를 삭제해야 하는 경우 장애 조치 그룹에서 제거한 후 삭제합니다. 보조 데이터베이스를 장애 조치(failover) 그룹에서 제거하기 전에 삭제하면 예기치 않은 동작이 발생할 수 있습니다.

엔드 투 엔드 스크립트의 경우 Azure PowerShell 또는 Azure CLI를 사용하여 장애 조치 그룹에 탄력적 풀을 추가하는 방법을 검토합니다.

필수 조건

풀링된 데이터베이스에 대한 장애 조치(failover) 그룹을 만들려면 다음 사전 요구 사항을 고려합니다.

  • 보조 서버의 서버 로그인 및 방화벽 설정은 주 서버와 일치해야 합니다.

장애 조치 그룹 만들기

Azure Portal 또는 PowerShell을 사용하여 탄력적 풀에 대한 장애 조치 그룹을 만듭니다.

Azure Portal을 사용하여 장애 조치 그룹을 만들고 탄력적 풀을 이 그룹에 추가합니다.

  1. Azure Portal의 왼쪽 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 다음, 검색 상자에 "Azure SQL"을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기로 선택하고 왼쪽 탐색에 항목으로 추가합니다.

  2. 장애 조치 그룹에 추가하려는 탄력적 풀을 선택합니다.

  3. 개요 창의 서버 이름에서 서버 이름을 선택하여 서버에 대한 설정을 엽니다.

    Open server for elastic pool

  4. 설정 창에서 장애 조치(Failover) 그룹을 선택한 후 그룹 추가를 선택하여 새 장애 조치(failover) 그룹을 만듭니다.

    Add new failover group

  5. 장애 조치(failover) 그룹 페이지에서 필요한 값을 입력하거나 선택한 다음, 만들기를 선택합니다. 새 보조 서버를 만들거나 기존 보조 서버를 선택합니다.

  6. 그룹 내 데이터베이스를 선택하고 장애 조치 그룹에 추가할 탄력적 풀을 선택합니다. 탄력적 풀이 보조 서버에 아직 없는 경우 보조 서버에 탄력적 풀을 만들라는 경고가 나타납니다. 경고를 선택한 다음, 확인을 선택하여 보조 서버에서 탄력적 풀을 만듭니다.

    Add elastic pool to failover group

  7. 선택을 사용하여 탄력적 풀 설정을 장애 조치 그룹에 적용한 후 만들기를 선택하여 장애 조치 그룹을 만듭니다. 장애 조치(failover) 그룹에 탄력적 풀을 추가하면 지역 복제 프로세스가 자동으로 시작됩니다.

계획된 장애조치 테스트

Azure Portal 또는 PowerShell을 사용하여 탄력적 풀의 데이터 손실 없이 장애 조치를 테스트합니다.

장애 조치 그룹을 보조 서버로 장애 조치한 다음, Azure Portal을 사용하여 장애 복구합니다.

  1. Azure Portal의 왼쪽 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 다음, 검색 상자에 "Azure SQL"을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기로 선택하고 왼쪽 탐색에 항목으로 추가합니다.

  2. 장애 조치를 수행할 탄력적 풀을 선택합니다.

  3. 개요 창의 서버 이름에서 서버 이름을 선택하여 서버에 대한 설정을 엽니다.

    Screenshot of select server for elastic pool in the Azure portal.

  4. 설정 창에서 장애 조치 그룹을 선택한 다음, 앞서 만든 장애 조치 그룹을 선택합니다.

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  5. 주 서버와 보조 서버를 검토합니다.

  6. 작업창에서 장애 조치(failover) 를 선택하여 탄력적 풀이 포함된 장애 조치 그룹을 장애 조치합니다.

  7. TDS 세션의 연결이 해제됨을 알려주는 경고에서 를 선택합니다.

    Fail over your failover group containing your database

  8. 주 서버와 보조 서버를 검토합니다. 장애 조치(failover)에 성공하면 두 서버에 교환된 역할이 있어야 합니다.

  9. 장애 조치(failover) 를 다시 선택하여 장애 조치 그룹을 다시 원래 설정으로 장애 조치합니다.

Important

보조 데이터베이스를 삭제해야 하는 경우 장애 조치 그룹에서 제거한 후 삭제합니다. 보조 데이터베이스를 장애 조치(failover) 그룹에서 제거하기 전에 삭제하면 예기치 않은 동작이 발생할 수 있습니다.

프라이빗 링크를 사용하면 가상 네트워크 및 서브넷 내의 특정 개인 IP 주소에 논리 서버를 연결할 수 있습니다.

장애 조치 그룹에서 프라이빗 링크를 사용하려면 다음을 수행합니다.

  1. 주 서버와 보조 서버가 쌍을 이루는 지역에 있는지 확인합니다.
  2. 겹치지 않는 IP 주소 공간을 갖도록 주 서버와 보조 서버에 대한 프라이빗 엔드포인트를 호스팅하기 위해 각 지역에 가상 네트워크 및 서브넷을 만듭니다. 예를 들어 10.0.0.0/16의 주 가상 네트워크 주소 범위와 10.0.0.1/16의 보조 가상 네트워크 주소 범위가 겹칩니다. 가상 네트워크 주소 범위에 대한 자세한 내용은 designing Azure virtual networks(Azure Virtual Network 디자인) 블로그를 참조하세요.
  3. 주 서버에 대한 프라이빗 엔드포인트 및 Azure 프라이빗 DNS 영역을 만듭니다.
  4. 보조 서버에 대한 프라이빗 엔드포인트도 만듭니다. 하지만 이번에는 주 서버에 대해 만들어진 것과 동일한 프라이빗 DNS 영역을 다시 사용하도록 선택합니다.
  5. 프라이빗 링크를 설정한 다음에는 이 문서의 앞부분에서 간략하게 설명한 단계에 따라 장애 조치 그룹을 만들 수 있습니다.

수신기 엔드포인트 찾기

장애 조치 그룹을 구성한 후 애플리케이션에 대한 연결 문자열을 수신기 엔드포인트로 업데이트합니다. 이렇게 하면 애플리케이션이 주 데이터베이스 또는 탄력적 풀이 아닌 장애 조치 그룹 수신기에 연결된 상태로 유지됩니다. 이렇게 하면 데이터베이스 엔터티가 장애 조치될 때마다 연결 문자열을 수동으로 업데이트할 필요가 없으며, 트래픽은 현재 주가 되는 모든 엔터티로 라우팅됩니다.

수신기 엔드포인트는 fog-name.database.windows.net 형식이며, 장애 조치 그룹을 볼 때 Azure Portal에 표시됩니다.

Failover group connection string

장애 조치 그룹에서 데이터베이스 크기 조정

지역 보조 데이터베이스와의 연결을 끊지 않고도 주 데이터베이스를 다른 컴퓨팅 크기(동일한 서비스 계층 내)로 확장 또는 축소할 수 있습니다. 스케일 업할 때에는 지역 보조 데이터베이스부터 스케일 업한 다음, 주 데이터베이스를 스케일 업하는 것이 좋습니다. 스케일 다운할 때에는 역순으로 합니다. 주 데이터베이스부터 스케일 다운한 다음, 보조 데이터베이스를 스케일 다운합니다. 데이터베이스를 다른 서비스 계층으로 스케일링할 때에는 이 권장 사항이 강제 적용됩니다.

이 시퀀스는 더 낮은 SKU의 지역 보조 데이터베이스가 오버로드되어 업그레이드 또는 다운그레이드 프로세스 중에 다시 시딩해야 하는 문제를 방지하기 위해 특히 권장됩니다. 주에 대한 모든 읽기/쓰기 워크로드의 영향을 희생하여 주를 읽기 전용으로 설정해 문제를 방지할 수도 있습니다.

참고 항목

장애 조치(failover) 그룹 구성의 일부로 지역 보조 데이터베이스를 만든 경우 지역 보조 데이터베이스를 스케일 다운하는 것이 좋습니다. 이렇게 하면 지역 장애 조치(failover) 후 데이터 계층에 일반 워크로드를 처리할 수 있을 만큼 충분한 용량이 생깁니다. 중단으로 인해 이전 지역 주 데이터베이스를 사용할 수 없는 경우 계획하지 않은 장애 조치 후 지역 보조 데이터베이스의 크기를 조정할 수 없을 수 있습니다. 이것은 알려진 제한 사항입니다.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 sp_wait_for_database_copy_sync 시스템 프로시저를 호출하면 됩니다. sp_wait_for_database_copy_sync를 호출하면 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그로 전송되어 강화될 때까지 호출 스레드가 차단됩니다. 그러나 전송된 트랜잭션이 보조 데이터베이스에서 재생(다시 실행)될 때까지 기다리지는 않습니다. sp_wait_for_database_copy_sync의 범위는 특정 지역 복제 링크로 한정됩니다. 주 데이터베이스에 대한 연결 권한이 있는 모든 사용자는 이 프로시저를 호출할 수 있습니다.

참고

sp_wait_for_database_copy_sync는 특정 트랜잭션의 지역 장애 조치(failover) 후 데이터 손실을 방지하지만, 읽기 액세스에 대한 전체 동기화를 보장하지는 않습니다. sp_wait_for_database_copy_sync 프로시저를 호출하면 상당한 지연이 발생할 수 있으며, 호출 당시 주 데이터베이스에서 아직 전송되지 않은 트랜잭션 로그의 크기에 따라 지연 시간이 달라집니다.

보조 지역 변경

변경 시퀀스를 설명하기 위해 서버 A는 주 서버, 서버 B는 기존 보조 서버, 서버 C는 세 번째 지역의 새로운 보조 서버라고 가정합니다. 전환을 수행하려면 다음 단계를 수행합니다.

  1. 활성 지역 복제를 사용하여 서버 A에서 서버 C까지 각 데이터베이스의 추가 보조 데이터베이스를 만듭니다. 서버 A의 각 데이터베이스에는 서버 B와 서버 C에 하나씩 2개의 보조 데이터베이스가 있습니다. 따라서 전환 중에 주 데이터베이스를 보호된 상태로 유지합니다.
  2. 장애 조치 그룹을 삭제합니다. 이 시점에서 장애 조치 그룹 엔드포인트를 사용하는 로그인 시도는 실패합니다.
  3. 서버 A와 C 간에 동일한 이름으로 장애 조치(failover) 그룹을 다시 만듭니다.
  4. 서버 A의 모든 주 데이터베이스를 새 장애 조치 그룹에 추가합니다. 이 시점에는 로그인 시도가 더 이상 실패하지 않습니다.
  5. 서버 B를 삭제합니다. B의 모든 데이터베이스가 자동으로 삭제됩니다.

주 지역 변경

변경 시퀀스를 설명하기 위해 서버 A는 주 서버, 서버 B는 기존 보조 서버, 서버 C는 세 번째 지역의 새로운 주 서버라고 가정합니다. 전환을 수행하려면 다음 단계를 수행합니다.

  1. 계획된 지역 장애 조치를 수행하여 주 서버를 B로 전환합니다. 서버 A가 새 보조 서버가 됩니다. 장애 조치로 인해 가동 중지 시간이 몇 분 동안 발생할 수 있습니다. 실제 시간은 장애 조치 그룹의 크기에 따라 달라집니다.
  2. 활성 지역 복제를 사용하여 서버 B에서 서버 C까지 각 데이터베이스의 추가 보조 데이터베이스를 만듭니다. 서버 B의 각 데이터베이스에는 서버 A와 서버 C에 하나씩 2개의 보조 데이터베이스가 있습니다. 따라서 전환 중에 주 데이터베이스를 보호된 상태로 유지합니다.
  3. 장애 조치 그룹을 삭제합니다. 이 시점에서 장애 조치 그룹 엔드포인트를 사용하는 로그인 시도는 실패합니다.
  4. 서버 B와 C 간에 동일한 이름으로 장애 조치(failover) 그룹을 다시 만듭니다.
  5. B의 모든 주 데이터베이스를 새 장애 조치 그룹에 추가합니다. 이 시점에는 로그인 시도가 실패하지 않습니다.
  6. 장애 조치 그룹의 계획된 지역 장애 조치를 수행하여 B와 C를 전환합니다. 이제 서버 C가 주 서버가 되고 B가 보조 서버가 됩니다. 서버 A의 모든 보조 데이터베이스는 C의 주 데이터베이스에 자동으로 연결됩니다. 1단계에서와 같이 장애 조치로 인해 가동 중지 시간이 몇 분 동안 발생할 수 있습니다.
  7. 서버 A를 삭제합니다. A의 모든 데이터베이스가 자동으로 삭제됩니다.

Important

장애 조치 그룹을 삭제하면 수신기 엔드포인트의 DNS 레코드도 삭제됩니다. 이 시점에는 다른 사람이 같은 이름을 사용하는 장애 조치(failover) 그룹 또는 서버 DNS 별칭을 만들 가능성이 있습니다. 장애 조치(failover) 그룹 이름 및 DNS 별칭은 전역적으로 고유해야 하기 때문에 동일한 이름을 다시 사용할 수 없습니다. 이 위험을 최소화하려면 일반 장애 조치(failover) 그룹 이름을 사용하지 마세요.

장애 조치 그룹 및 네트워크 보안

일부 애플리케이션의 경우 보안 규칙에 따라 데이터 계층에 대한 네트워크 액세스가 VM, 웹 서비스 등과 같은 구성 요소나 특정 구성 요소로 제한되어야 합니다. 이 요구 사항 때문에 비즈니스 연속성 디자인과 장애 조치 그룹 사용에 관한 몇 가지 문제가 발생합니다. 이러한 제한된 액세스를 구현하는 경우 다음 옵션을 고려합니다.

장애 조치(failover) 그룹 및 가상 네트워크 서비스 엔드포인트 사용

Virtual Network 서비스 엔드포인트 및 규칙을 사용하여 데이터베이스에 대한 액세스를 제한하는 경우 각 가상 네트워크 서비스 엔드포인트를 하나의 Azure 지역에만 적용합니다. 엔드포인트를 사용하여 다른 지역이 서브넷에서 보낸 통신을 수락하도록 할 수는 없습니다. 따라서 동일한 지역에 배포된 클라이언트 애플리케이션만 주 데이터베이스에 연결할 수 있습니다. 지역 장애 조치는 SQL Database 클라이언트 세션이 다른 (보조) 지역의 서버로 다시 라우팅되는 결과를 가져오므로, 해당 지역 외부의 클라이언트에서 시작하는 세션은 실패할 수 있습니다. 이런 이유로 참여하는 서버가 Virtual Network 규칙에 포함된 경우 Microsoft에서 관리하는 장애 조치 정책을 사용할 수 없습니다. 수동 장애 조치 정책을 지원하려면 다음 단계를 수행합니다.

  1. 보조 지역에서 애플리케이션(웹 서비스, 가상 컴퓨터 등) 프런트 엔드 구성 요소의 중복 복사본을 프로비전합니다.
  2. 기본 및 보조 서버에 대한 가상 네트워크 규칙을 개별적으로 구성합니다.
  3. 트래픽 관리자 구성을 사용하여 프런트 엔드 장애 조치를 사용하도록 설정합니다.
  4. 중단을 감지하면 수동 지역 장애 조치를 시작합니다. 이 옵션은 프런트 엔드와 데이터 계층 간에 일관된 대기 시간을 필요로 하는 애플리케이션에 최적화되어 있으며 프런트 엔드, 데이터 계층 또는 모두가 중단의 영향을 받는 경우 복구를 지원합니다.

참고 항목

읽기 전용 수신기를 사용하여 읽기 전용 워크로드의 부하를 분산하는 경우 이 워크로드를 보조 데이터베이스에 연결할 수 있도록 보조 지역의 VM 또는 다른 리소스에서 실행했는지 확인합니다.

장애 조치 그룹 및 방화벽 규칙 사용

비즈니스 연속성 계획에 장애 조치 그룹을 사용하는 장애 조치가 필요한 경우 공용 IP 방화벽 규칙을 사용하여 SQL Database에 대한 액세스를 제한할 수 있습니다. 이 구성은 지역 장애 조치가 프런트 엔드 구성 요소의 연결을 차단하지 않으며, 애플리케이션이 프런트 엔드와 데이터 계층 간의 긴 대기 시간을 허용할 수 있다고 가정합니다.

장애 조치 그룹의 장애 조치를 지원하려면 다음 단계를 수행합니다.

  1. 공용 IP 만들기.
  2. 공용 부하 분산 장치를 만들고 여기에 공용 IP를 할당합니다.
  3. 프런트 엔드 구성 요소에 대한 가상 네트워크 및 가상 머신을 만듭니다.
  4. 네트워크 보안 그룹을 만들고 인바운드 연결을 구성합니다.
  5. Sql.<Region>서비스 태그를 사용하여 아웃바운드 연결이 지역의 Azure SQL Database에 대해 열려 있는지 확인합니다.
  6. SQL 데이터베이스 방화벽 규칙을 만들어서 1단계에서 만든 공용 IP 주소에서 인바운드 트래픽을 허용합니다.

아웃바운드 액세스를 구성하는 방법 및 방화벽 규칙에서 사용할 IP에 대한 자세한 내용은 부하 분산 장치 아웃바운드 연결을 참조하세요.

Important

지역 중단이 발생하는 동안 비즈니스 연속성을 보장하려면 프런트 엔드 구성 요소와 데이터베이스 모두에 대한 지리적 중복성을 확인해야 합니다.

사용 권한

장애 조치 그룹의 사용 권한은 Azure RBAC(Azure 역할 기반 액세스 제어)를 통해 관리합니다.

장애 조치(failover) 그룹을 만들고 관리하려면 Azure RBAC 쓰기 권한이 필요합니다. SQL Server Contributor 역할에는 장애 조치 그룹을 관리하는 데 필요한 모든 사용 권한이 있습니다.

다음 표에는 Azure SQL Database에 대한 특정 권한 범위가 나와 있습니다.

작업 사용 권한 범위
장애 조치 그룹 만들기 Azure RBAC 쓰기 권한 주 서버
보조 서버
장애 조치(failover) 그룹의 모든 데이터베이스
장애 조치(failover) 그룹 업데이트 Azure RBAC 쓰기 권한 장애 조치(failover) 그룹
현재 주 서버의 모든 데이터베이스
장애 조치(failover) 그룹의 장애 조치(failover) Azure RBAC 쓰기 권한 새 서버의 장애 조치(failover) 그룹

제한 사항

다음과 같은 제한 사항을 고려해야 합니다.

  • 동일한 Azure 지역의 두 서버 간에 장애 조치 그룹을 만들 수 없습니다.
  • 장애 조치 그룹은 그룹의 모든 데이터베이스를 다른 지역에 있는 하나의 보조 논리 서버로만 지역 복제할 수 있도록 지원합니다.
  • 장애 조치 그룹의 이름을 바꿀 수 없습니다. 그룹을 삭제하고 다른 이름으로 다시 만들어야 합니다.
  • 장애 조치 그룹의 데이터베이스에는 데이터베이스 이름 바꾸기를 지원하지 않습니다. 데이터베이스 이름을 변경하거나 장애 조치 그룹에서 데이터베이스를 제거하려면 장애 조치 그룹을 일시적으로 삭제해야 합니다.
  • 단일 또는 풀링된 데이터베이스에 대한 장애 조치(failover) 그룹을 제거해도 복제가 중지되지 않으며 복제된 데이터베이스도 삭제되지 않습니다. 단일 또는 풀링된 데이터베이스를 제거한 후 장애 조치 그룹에 다시 추가하려면 지역 복제를 수동으로 중지하고 보조 서버에서 데이터베이스를 삭제해야 합니다. 그러지 않으면 장애 조치 그룹에 데이터베이스를 추가하려고 할 때 The operation cannot be performed due to multiple errors와 유사한 오류가 발생할 수 있습니다.
  • 장애 조치 그룹 이름에는 명명 제한이 적용됩니다.

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

Azure PowerShell, Azure CLI 및 REST API를 사용하여 프로그래밍 방식으로 장애 조치(failover) 그룹을 관리할 수도 있습니다. 다음 표는 사용 가능한 명령의 집합을 보여줍니다. 장애 조치 그룹은 관리를 위해 Azure SQL Database REST APIAzure PowerShell cmdlet을 비롯한 Azure Resource Manager API 집합을 포함합니다. 이러한 API는 리소스 그룹을 사용해야 하며 Azure RBAC(Azure 역할 기반 액세스 제어)를 지원합니다. 액세스 역할을 구현하는 방법에 관한 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 참조하세요.

Cmdlet 설명
New-AzSqlDatabaseFailoverGroup 장애 조치 그룹을 만들고 주 및 보조 서버 모두에 등록합니다
Remove-AzSqlDatabaseFailoverGroup 서버에서 장애 조치 그룹 제거
Get-AzSqlDatabaseFailoverGroup 장애 조치 그룹의 구성 검색
Set-AzSqlDatabaseFailoverGroup 장애 조치 그룹의 구성 수정
Switch-AzSqlDatabaseFailoverGroup 장애 조치 그룹을 보조 서버로 장애 조치하도록 트리거
Add-AzSqlDatabaseToFailoverGroup 장애 조치 그룹에 하나 이상의 데이터베이스 추가

참고 항목

Az.SQL 3.11.0부터 Azure Powershell의 -PartnerSubscriptionId 매개 변수를 사용하여 구독 간에 장애 조치 그룹을 배포할 수 있습니다. 자세한 내용은 다음 예제를 검토하세요.

다음 단계

Azure SQL Database 고가용성 옵션에 대한 개요는 지역 복제장애 조치 그룹을 참조하세요.