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

적용 대상:Azure SQL Managed Instance

• Azure SQL Database
• Azure SQL Managed Instance

이 문서에서는 Azure Portal 및 Azure PowerShell을 사용하여 Azure SQL Managed Instance에 대한 장애 조치(failover) 그룹을 구성하는 방법을 설명합니다.

장애 조치(failover) 그룹 내에서 두 인스턴스를 생성하는 엔드투엔드 PowerShell 스크립트의 경우 장애 조치(failover) 그룹에 인스턴스 추가를 검토하세요.

필수 조건

다음 필수 구성 요소를 고려합니다.

• 보조 관리되는 인스턴스는 비어 있어야 합니다. 즉, 사용자 데이터베이스를 포함하지 않아야 합니다.
• SQL Managed Instance의 두 인스턴스는 같은 서비스 계층이어야 하고 스토리지 크기는 같아야 합니다. 필수는 아니지만 보조 인스턴스가 최대 작업 기간을 포함하여 주 인스턴스에서 복제되는 변경 내용을 지속적으로 처리할 수 있도록 두 인스턴스의 컴퓨팅 크기가 같도록 하는 것이 좋습니다.
• 주 인스턴스의 가상 네트워크에 대한 IP 주소 범위는 보조 관리형 인스턴스에 대한 가상 네트워크의 주소 범위나 주 또는 보조 가상 네트워크와 피어링되는 다른 가상 네트워크와 겹치지 않아야 합니다.
• 보조 관리형 인스턴스를 생성할 때 주 인스턴스의 DNS 영역 ID를 DnsZonePartner 매개 변수 값으로 지정해야 합니다. DnsZonePartner에 대한 값을 지정하지 않으면 각 가상 네트워크에서 첫 번째 인스턴스가 생성되고 동일한 서브넷의 다른 모든 인스턴스에 같은 ID가 할당될 때 영역 ID는 임의의 문자열로 생성됩니다. ID가 할당되면 DNS 영역을 수정할 수 없습니다.
• 서브넷 호스팅 인스턴스의 NSG(네트워크 보안 그룹) 규칙에는 포트 5022(TCP) 및 포트 범위 11000-11999(TCP)가 다른 관리되는 인스턴스를 호스팅하는 서브넷과의 연결을 위해 인바운드 및 아웃바운드를 열어야 합니다. 이는 주 인스턴스와 보조 인스턴스를 호스팅하는 서브넷 모두에 적용됩니다.
• 보조 관리되는 인스턴스의 데이터 정렬 및 표준 시간대는 기본 관리되는 인스턴스와 일치해야 합니다.
• 성능상의 이유로 관리되는 인스턴스를 쌍으로 연결된 지역에 배포해야 합니다. 지리적으로 쌍을 이루는 지역에 있는 관리형 인스턴스는 쌍을 이루지 않는 지역에 비해 지리적 복제 속도가 훨씬 더 빨라질 수 있습니다.

주소 공간 범위

주 인스턴스의 주소 공간을 검사하려면 주 인스턴스의 가상 네트워크 리소스로 이동하여 설정 아래에서 주소 공간을 선택합니다. 주소 범위 아래 범위를 확인합니다.

주 인스턴스의 영역 ID 지정

보조 인스턴스를 생성할 때 주 인스턴스의 영역 ID를 DnsZonePartner로 지정해야 합니다.

포털

Azure Portal에서 보조 인스턴스를 생성하는 경우 추가 설정 탭의 지역 복제에서 장애 조치(failover) 보조로 사용을 예로 선택한 다음, 드롭다운에서 주 인스턴스를 선택합니다.

PowerShell

Azure PowerShell을 사용하여 보조 인스턴스를 생성하는 경우 DnsZonePartner 매개 변수에 주 인스턴스의 영역 ID를 제공해야 합니다.

Get-AzSqlInstance 명령을 사용하여 주 인스턴스의 DNS 영역 ID를 매개 변수화한 다음, New-AzSqlInstance 명령의 DnsZonePartner 매개 변수에 전달할 수 있습니다.

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

인스턴스 간 연결 사용

중단 없는 지역 복제 트래픽 흐름의 주 인스턴스와 보조 인스턴스를 호스팅하는 가상 네트워크 서브넷 간의 연결을 설정해야 합니다. 다음을 포함하여 서로 다른 Azure 지역의 관리되는 인스턴스 간에 연결을 설정하는 여러 가지 방법이 있습니다.

• 전역 가상 네트워크 피어링
• Azure ExpressRoute
• VPN 게이트웨이

글로벌 가상 네트워크 피어링은 장애 조치(failover) 그룹의 두 인스턴스 간에 연결을 설정하는 가장 성능이 뛰어나고 강력한 방법으로 권장됩니다. 글로벌 가상 네트워크 피어링에서는 Microsoft 백본 인프라를 사용하여 피어링된 가상 네트워크 사이에 대기 시간이 짧고 대역폭이 높은 프라이빗 연결을 제공합니다. 피어링된 가상 네트워크 간의 통신에 공용 인터넷, 게이트웨이, 또는 추가 암호화가 필요하지 않습니다.

Important

추가 네트워킹 디바이스가 포함된 인스턴스를 연결하는 또 다른 방법이 있지만 연결 또는 복제 속도 문제 해결이 복잡해지고 네트워크 관리자의 적극적인 참여가 요구되며 해결 시간이 상당히 길어질 수 있습니다.

연결 메커니즘에 관계없이 지역 복제 트래픽이 흐르기 위해 충족해야 하는 요구 사항이 있습니다.

• 관리형 인스턴스 서브넷에 할당된 경로 테이블 및 네트워크 보안 그룹은 피어링된 두 가상 네트워크에서 공유되지 않습니다.
• 주 인스턴스를 호스트하는 서브넷의 NSG(네트워크 보안 그룹) 규칙에서는 다음을 허용합니다.
  • 보조 인스턴스를 호스트하는 서브넷에서 나오는 포트 5022 및 포트 범위 11000~11999의 인바운드 트래픽.
  • 보조 인스턴스를 호스트하는 서브넷으로 향하는 포트 5022 및 포트 범위 11000~11999의 아웃바운드 트래픽.
• 보조 인스턴스를 호스트하는 서브넷의 NSG(네트워크 보안 그룹) 규칙에서는 다음을 허용합니다.
  • 주 인스턴스를 호스트하는 서브넷에서 나오는 포트 5022 및 포트 범위 11000~11999의 인바운드 트래픽.
  • 주 인스턴스를 호스트하는 서브넷으로 향하는 포트 5022 및 포트 범위 11000~11999의 아웃바운드 트래픽.
• 주 인스턴스와 보조 인스턴스를 호스트하는 VNet의 IP 주소 범위는 겹치지 말아야 합니다.
• 주 인스턴스와 보조 인스턴스를 호스트하는 VNet과 로컬 가상 네트워크 피어링 또는 기타 수단을 통해 피어링되는 다른 VNet 간에 IP 주소 범위가 간접적으로 겹치지 않습니다.

또한 권장 글로벌 가상 네트워크 피어링보다 인스턴스 간의 연결을 제공하기 위해 다른 메커니즘을 사용하는 경우 다음을 확인해야 합니다.

• 방화벽 또는 NVA(네트워크 가상 어플라이언스)와 같이 사용되는 모든 네트워킹 디바이스는 위에서 설명한 포트에서 트래픽을 차단하지 않습니다.
• 라우팅이 제대로 구성되어 있고 비대칭 라우팅이 방지됩니다.
• 허브 및 스포크 네트워크 토폴로지 교차 지역에 장애 조치(failover) 그룹을 배포하는 경우 복제 트래픽은 허브 네트워크를 통해 지시되지 않고 두 관리형 인스턴스 서브넷 간에 직접 이동해야 합니다. 오히려 연결 및 복제 속도 문제를 방지하는 데 도움이 됩니다.

포털

1. Azure Portal에서 주 관리되는 인스턴스의 가상 네트워크 리소스로 이동합니다.
2. 설정에서 피어링을 선택한 다음 + 추가를 선택합니다.

1. 다음 설정에 대한 값을 입력하거나 선택합니다.

   설정	설명
   이 가상 네트워크
   피어링 링크 이름	피어링의 이름은 가상 네트워크 내에서 고유해야 합니다.
   원격 가상 네트워크로의 트래픽	기본 VirtualNetwork 흐름을 통해 두 가상 네트워크 간의 통신을 사용하도록 설정하려면 허용(기본값)을 선택합니다. 가상 네트워크 간의 통신을 사용하도록 설정하면 두 가상 네트워크 중 하나에 연결된 리소스가 동일한 가상 네트워크에 연결된 것처럼 동일한 대역폭 및 대기 시간으로 서로 통신할 수 있습니다. 두 가상 네트워크의 리소스 간 모든 통신은 Azure 프라이빗 네트워크를 통해 이루어집니다.
   원격 가상 네트워크에서 전달된 트래픽	이 자습서에서는 허용(기본값) 및 차단 옵션이 모두 작동합니다. 자세한 내용은 피어링 만들기를 참조하세요.
   가상 네트워크 게이트웨이 또는 Route Server	없음을 선택합니다. 사용 가능한 다른 옵션에 대한 자세한 내용은 피어링 만들기를 참조하세요.
   원격 가상 네트워크
   피어링 링크 이름	보조 인스턴스를 호스팅하는 가상 네트워크에서 사용할 동일한 피어링의 이름입니다.
   가상 네트워크 배포 모델	리소스 관리자를 선택합니다.
   리소스 ID를 알고 있음	확인란을 선택 취소된 상태로 둡니다.
   구독	피어링할 보조 인스턴스를 호스팅하는 가상 네트워크의 Azure 구독을 선택합니다.
   가상 네트워크	피어링하려는 보조 인스턴스를 호스팅하는 가상 네트워크를 선택합니다. 가상 네트워크가 나열되지만, 회색으로 표시된 경우 가상 네트워크의 주소 공간이 이 가상 네트워크의 주소 공간과 겹치기 때문일 수 있습니다. 가상 네트워크 주소 공간이 겹치면 피어링할 수 없습니다.
   원격 가상 네트워크로의 트래픽	허용(기본값) 선택
   원격 가상 네트워크에서 전달된 트래픽	이 자습서에서는 허용(기본값) 및 차단 옵션이 모두 작동합니다. 자세한 내용은 피어링 만들기를 참조하세요.
   가상 네트워크 게이트웨이 또는 Route Server	없음을 선택합니다. 사용 가능한 다른 옵션에 대한 자세한 내용은 피어링 만들기를 참조하세요.

2. 추가를 선택하여 선택한 가상 네트워크와의 피어링을 구성합니다. 몇 초 후 새로 고침 단추를 선택하면 피어링 상태가 업데이트 중에서 연결됨으로 변경됩니다.

   

PowerShell

주 및 보조 관리형 인스턴스를 호스트하는 가상 네트워크 간에 글로벌 가상 네트워크 피어링을 구성합니다.

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

이 코드 조각은 다음 명령을 사용합니다.

명령	주의
1. Get-AzVirtualNetwork	리소스 그룹의 가상 네트워크를 가져옵니다.
2. Add-AzVirtualNetworkPeering	가상 네트워크에 피어링을 추가합니다.
3. Get-AzVirtualNetworkPeering	가상 네트워크에 피어링을 가져옵니다.

장애 조치 그룹 만들기

Azure Portal 또는 PowerShell을 사용하여 관리형 인스턴스에 대한 장애 조치 그룹을 만듭니다.

포털

Azure Portal을 사용하여 SQL Managed Instance에 대한 장애 조치 그룹을 만듭니다.

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

2. 장애 조치 그룹에 추가하려는 주 관리형 인스턴스를 선택합니다.

3. 설정에서 인스턴스 장애 조치(Failover) 그룹으로 이동한 다음, 그룹 추가를 선택하여 인스턴스 장애 조치(Failover) 그룹 만들기 페이지를 엽니다.

   

4. 인스턴스 장애 조치(Failover) 그룹 페이지에서 장애 조치 그룹의 이름을 입력한 다음, 드롭다운에서 보조 관리형 인스턴스를 선택합니다. 만들기를 선택하여 장애 조치(failover) 그룹을 만듭니다.

   

5. 장애 조치(failover) 그룹 배포가 완료되면 장애 조치(failover) 그룹 페이지로 돌아갑니다.

PowerShell

PowerShell을 통해 New-AzSqlDatabaseInstanceFailoverGroup을 사용하여 관리형 인스턴스에 대한 장애 조치(failover) 그룹을 생성합니다.

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

테스트 장애 조치

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

포털

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

1. Azure Portal에서 보조 관리형 인스턴스로 이동하고 설정 아래에서 인스턴스 장애 조치(Failover) 그룹을 선택합니다.

2. 주 역할과 보조 역할의 관리되는 인스턴스를 확인합니다.

3. 장애 조치(failover) 를 선택한 다음, TDS 세션 연결이 끊어진다는 경고에서 예를 선택합니다.

   

4. 주 역할과 보조 역할의 관리되는 인스턴스를 확인합니다. 장애 조치(failover)에 성공하면 두 인스턴스의 역할이 전환되어야 합니다.

   

Important

역할이 전환되지 않은 경우 인스턴스와 관련 NSG 및 방화벽 규칙 간의 연결을 확인합니다. 역할이 전환된 후에만 다음 단계를 진행합니다.

1. 새 보조 관리형 인스턴스로 이동하고 장애 조치(failover) 를 다시 한 번 선택하여 기본 인스턴스를 기본 역할로 다시 장애 조치(failover)합니다.

PowerShell

보조 복제본으로 장애 조치(failover)한 다음, 장애 복구(failback)하여 계획된 장애조치를 테스트합니다.

각 서버의 역할 확인

Get-AzSqlDatabaseInstanceFailoverGroup 명령을 사용하여 각 서버의 역할을 확인합니다.

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

보조 서버로 장애 조치(failover)

Switch-AzSqlDatabaseFailoverGroup을 사용하여 보조 서버로 장애 조치합니다.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

장애 조치(failover) 그룹을 주 서버로 되돌리기

Switch-AzSqlDatabaseFailoverGroup 명령을 사용하여 주 서버로 장애 복구합니다.

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

각 서버의 역할 확인

Get-AzSqlDatabaseFailoverGroup 명령을 사용하여 각 서버의 역할을 확인합니다.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

보조 서버로 장애 조치(failover)

Switch-AzSqlDatabaseFailoverGroup을 사용하여 보조 서버로 장애 조치합니다.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

장애 조치(failover) 그룹을 주 서버로 되돌리기

Switch-AzSqlDatabaseFailoverGroup 명령을 사용하여 주 서버로 장애 복구합니다.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

수신기 엔드포인트 찾기

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

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

다른 구독의 인스턴스 간에 그룹 만들기

구독이 같은 Microsoft Entra 테넌트에 연결되어 있는 한, 다른 두 구독에서 SQL Managed Instance 간에 장애 조치(failover) 그룹을 생성할 수 있습니다.

• PowerShell API를 사용할 때 보조 SQL Managed Instance의 PartnerSubscriptionId 매개 변수를 지정하여 수행할 수 있습니다.
• REST API를 사용하는 경우 properties.managedInstancePairs 매개 변수에 포함된 각 인스턴스 ID는 고유한 구독 ID를 사용할 수 있습니다.
• Azure Portal은 다른 구독에서 장애 조치(failover) 그룹 생성을 지원하지 않습니다.

Important

Azure Portal은 다른 구독에서 장애 조치(failover) 그룹 만들기를 지원하지 않습니다. 여러 구독 및/또는 리소스 그룹에 걸친 장애 조치(failover) 그룹의 경우 주 SQL Managed Instance에서 Azure Portal을 통해 수동으로 장애 조치를 시작할 수 없습니다. 대신 지역 보조 인스턴스에서 시작합니다.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 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와 크기가 같고 DNS 영역이 같은 인스턴스 C를 만듭니다.
2. 인스턴스 A와 B 사이의 장애 조치(failover) 그룹을 삭제합니다. 이 시점에 장애 조치(failover) 그룹 수신기의 SQL 별칭이 삭제되고 게이트웨이가 장애 조치(failover) 그룹 이름을 인식하지 못하기 때문에 로그인 시도에 실패하기 시작합니다. 보조 데이터베이스는 주 데이터베이스에서 연결을 끊고 읽기/쓰기 데이터베이스가 됩니다.
3. 인스턴스 A와 C 간에 이름이 같은 장애 조치(failover) 그룹을 생성합니다. 장애 조치(failover) 그룹 구성 가이드의 지침을 따릅니다. 데이터 크기 작업이며, 인스턴스 A의 모든 데이터베이스가 시드되고 동기화되면 완료됩니다.
4. 불필요한 요금을 방지하기 위해 필요하지 않은 경우 인스턴스 B를 삭제합니다.

참고

2단계 이후 3단계가 완료될 때까지 인스턴스 A의 데이터베이스는 인스턴스 A의 치명적인 실패로부터 보호되지 않은 상태로 유지됩니다.

주 지역 변경

인스턴스 A는 주 인스턴스이고, 인스턴스 B는 기존 보조 인스턴스이며, 인스턴스 C는 세 번째 영역의 새 주 인스턴스라고 가정해 보겠습니다. 전환을 수행하려면 다음 단계를 수행합니다.

1. B와 크기가 같고 DNS 영역이 같은 인스턴스 C를 만듭니다.
2. 인스턴스 B에 연결하고 수동으로 장애 조치하여 주 인스턴스를 B로 전환합니다. 인스턴스 A는 자동으로 새 보조 인스턴스가 됩니다.
3. 인스턴스 A와 B 사이의 장애 조치(failover) 그룹을 삭제합니다. 이 시점에는 장애 조치(failover) 그룹 엔드포인트를 사용한 로그인 시도가 실패하기 시작합니다. A의 보조 데이터베이스는 주 데이터베이스와의 연결을 끊고 읽기/쓰기 데이터베이스가 됩니다.
4. 인스턴스 B와 C 간에 이름이 같은 장애 조치(failover) 그룹을 생성합니다. 장애 조치(failover) 그룹 가이드의 지침을 따릅니다. 데이터 크기 작업이며, 인스턴스 A의 모든 데이터베이스가 시드되고 동기화되면 완료됩니다. 이 시점에는 로그인 시도가 더 이상 실패하지 않습니다.
5. 수동으로 장애 조치(failover)하여 C 인스턴스를 주 역할로 전환합니다. 인스턴스 B는 자동으로 새 보조 인스턴스가 됩니다.
6. 불필요한 요금을 방지하기 위해 필요하지 않은 경우 인스턴스 A를 삭제합니다.

주의

3단계 이후 4단계가 완료될 때까지 인스턴스 A의 데이터베이스는 인스턴스 A의 치명적인 실패로부터 보호되지 않은 상태로 유지됩니다.

Important

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

시스템 데이터베이스의 개체에 종속된 시나리오 사용

시스템 데이터베이스는 장애 조치(failover) 그룹의 보조 인스턴스에 복제되지 않습니다. 시스템 데이터베이스의 개체에 따라 달라지는 시나리오를 지원하려면 보조 인스턴스에서 동일한 개체를 만들고 주 인스턴스와 동기화 상태를 유지해야 합니다.

예를 들어 보조 인스턴스에서 같은 로그인을 사용하려는 경우 같은 SID를 사용하여 해당 로그인을 만들어야 합니다.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

자세한 내용은 로그인 및 에이전트 작업의 복제를 참조하세요.

인스턴스 속성 및 보존 정책 인스턴스 동기화

장애 조치(failover) 그룹의 인스턴스는 별도의 Azure 리소스로 남아 있으며, 주 인스턴스 구성의 변경 내용은 보조 인스턴스에 자동으로 복제되지 않습니다. 모든 관련 변경을 주 인스턴스와 보조 인스턴스 모두에서 수행해야 합니다. 예를 들어 주 인스턴스에서 백업 스토리지 중복 또는 장기 백업 보존 정책을 변경하는 경우 보조 인스턴스에서도 변경해야 합니다.

인스턴스 크기 조정

주 인스턴스 및 보조 인스턴스를 동일한 서비스 계층 내의 다른 컴퓨팅 크기 또는 다른 서비스 계층으로 스케일 업하거나 스케일 다운할 수 있습니다. 동일한 서비스 계층 내에서 스케일 업할 때에는 지역 보조 위치부터 스케일 업한 다음, 주 위치를 스케일 업하는 것이 좋습니다. 동일한 서비스 계층 내에서 스케일 다운할 때에는 역순으로 합니다. 주 위치부터 스케일 다운한 다음, 보조 위치를 스케일 다운합니다. 인스턴스를 다른 서비스 계층으로 스케일링할 때에는 이 권장 사항이 강제 적용됩니다.

이 순서는 더 낮은 SKU의 지역 보조 데이터베이스가 오버로드되어 업그레이드 또는 다운그레이드 프로세스 중에 다시 시딩해야 하는 문제를 방지하기 위해 특히 권장됩니다.

사용 권한

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

주 및 보조 관리되는 인스턴스의 리소스 그룹으로 범위가 지정된 SQL Managed Instance 기여자 역할은 장애 조치(failover) 그룹에서 모든 관리 작업을 수행하기에 충분합니다.

다음 표에서는 장애 조치(failover) 그룹의 관리 작업에 필요한 최소 사용 권한 및 각각의 최소 필수 범위 수준에 대한 세부적인 보기를 제공합니다.

관리 작업	사용 권한	범위
장애 조치(failover) 그룹 만들기/업데이트	Microsoft.Sql/locations/instanceFailoverGroups/write	주 및 보조 관리되는 인스턴스의 리소스 그룹
장애 조치(failover) 그룹 만들기/업데이트	Microsoft.Sql/managedInstances/write	주 및 보조 관리되는 인스턴스
장애 조치(failover) 그룹의 장애 조치(failover)	Microsoft.Sql/locations/instanceFailoverGroups/failover/action	주 및 보조 관리되는 인스턴스의 리소스 그룹
장애 조치(failover) 그룹의 강제 장애 조치(failover)	Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action	주 및 보조 관리되는 인스턴스의 리소스 그룹
장애 조치(failover) 그룹 삭제	Microsoft.Sql/locations/instanceFailoverGroups/delete	주 및 보조 관리되는 인스턴스의 리소스 그룹

제한 사항

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

• 같은 Azure 지역에 있는 두 개의 인스턴스 간에 장애 조치(failover) 그룹을 만들 수 없습니다.
• 장애 조치 그룹의 이름을 바꿀 수 없습니다. 그룹을 삭제하고 다른 이름으로 다시 만들어야 합니다.
• 장애 조치(failover) 그룹에는 정확히 두 개의 관리되는 인스턴스가 포함됩니다. 장애 조치(failover) 그룹에 인스턴스를 추가하는 것은 지원되지 않습니다.
• 인스턴스는 언제든지 하나의 장애 조치(failover) 그룹에만 참여할 수 있습니다.
• 서로 다른 Azure 테넌트에서 속하는 두 인스턴스 간에 장애 조치 그룹을 만들 수 없습니다.
• 서로 다른 Azure 구독에 속하는 두 인스턴스 간의 장애 조치 그룹은 Azure Portal 또는 Azure CLI를 사용하여 만들 수 없습니다. 대신 Azure PowerShell 또는 REST API를 사용하여 이러한 장애 조치 그룹을 만듭니다. 구독 간 장애 조치 그룹이 생성되면 Azure Portal에 정기적으로 표시되며 장애 조치를 포함한 모든 후속 작업은 Azure Portal 또는 Azure CLI에서 초기화될 수 있습니다.
• 장애 조치(failover) 그룹의 인스턴스는 데이터베이스 이름 바꾸기가 지원되지 않습니다. 데이터베이스의 이름을 바꾸려면 장애 조치(failover) 그룹을 일시적으로 삭제해야 합니다.
• 시스템 데이터베이스는 장애 조치 그룹의 보조 인스턴스에 복제되지 않습니다. 따라서 서버 로그인 및 에이전트 작업과 같은 시스템 데이터베이스의 개체에 의존하는 시나리오에서는 보조 인스턴스에서 개체를 수동으로 만들고 주 인스턴스에서 변경한 후 수동으로 동기화를 유지해야 합니다. 유일한 예외는 장애 조치(failover) 그룹을 만드는 동안 보조 인스턴스에 자동으로 복제되는 SQL Managed Instance용 SMK(서비스 마스터 키)입니다. 그러나 주 인스턴스에서 SMK의 이후 변경 사항은 보조 인스턴스로 복제되지 않습니다. 자세히 알아보려면 시스템 데이터베이스의 개체에 따라 시나리오를 활성화하는 방법을 참조하세요.
• 인스턴스 중 하나라도 인스턴스 풀에 있으면 인스턴스 간에 장애 조치(Failover) 그룹을 만들 수 없습니다.

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

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

PowerShell

Cmdlet	설명
New-AzSqlDatabaseInstanceFailoverGroup	장애 조치 그룹을 만들고 주 인스턴스와 보조 인스턴스 모두에 등록합니다
Set-AzSqlDatabaseInstanceFailoverGroup	장애 조치 그룹의 구성 수정
Get-AzSqlDatabaseInstanceFailoverGroup	장애 조치 그룹의 구성 검색
Switch-AzSqlDatabaseInstanceFailoverGroup	장애 조치 그룹을 보조 인스턴스로 장애 조치하도록 트리거
Remove-AzSqlDatabaseInstanceFailoverGroup	장애 조치(failover) 그룹을 제거합니다.

Azure CLI

명령	설명
az sql instance-failover-group create	장애 조치 그룹을 만들고 주 및 보조 서버 모두에 등록합니다
az sql instance-failover-group delete	서버에서 장애 조치 그룹 제거
az sql instance-failover-group show	장애 조치 그룹 구성 검색
az sql instance-failover-group update	장애 조치(failover) 그룹의 구성을 수정하거나 하나 이상의 데이터베이스를 장애 조치(failover) 그룹에 추가
az sql instance-failover-group set-primary	장애 조치 그룹을 보조 서버로 장애 조치하도록 트리거

REST API

API	설명
장애 조치(failover) 그룹 만들기 또는 업데이트	장애 조치 그룹의 구성을 만들거나 업데이트
장애 조치(failover) 그룹 삭제	인스턴스에서 장애 조치 그룹 제거
장애 조치(failover)(계획됨)	전체 데이터 동기화를 사용하여 현재 주 인스턴스에서 이 인스턴스로의 장애 조치를 트리거합니다.
장애 조치(failover)로 인한 데이터 손실 허용	데이터를 동기화하지 않고 현재 주 인스턴스에서 보조 인스턴스로의 장애 조치를 트리거합니다. 이 작업으로 인해 데이터가 손실될 수 있습니다.
장애 조치 그룹 가져오기	장애 조치 그룹의 구성을 검색합니다.
장애 조치(failover) 그룹 나열 - 위치별 목록	위치에 있는 장애 조치(failover) 그룹을 나열합니다.

다음 단계

장애 조치(failover) 그룹을 구성하는 단계는 장애 조치(failover) 그룹에 관리형 인스턴스 추가 가이드를 참조하세요.

이 기능에 대한 개요는 장애 조치(failover) 그룹을 참조하세요. 라이선스 비용을 절감하는 방법을 알아보려면 대기 복제본 구성을 참조하세요.