다음을 통해 공유

사용자가 시작한 수동 장애 조치(failover)를 사용하여 인스턴스 다시 시작 - Azure SQL Managed Instance

  • 아티클

적용 대상: Azure SQL Managed Instance

이 문서에서는 PowerShell, Azure CLI 또는 REST API를 사용하여 사용자가 시작한 수동 장애 조치(failover)를 보조 컴퓨팅 노드로 수행하여 Azure SQL Managed Instance를 다시 시작하는 방법을 설명합니다.

GP(범용) 및 BC(중요 비즈니스용) 서비스 계층에서 주 노드를 수동으로 장애 조치(failover)하고 BC 서비스 계층에서 보조 읽기 전용 복제본 노드를 수동으로 장애 조치(failover)할 수 있습니다.

참고 항목

이 문서의 장애 조치(failover)는 보조 노드에서 SQL Server 데이터베이스 엔진 프로세스를 시작하는 것을 참조하며 장애 조치(failover) 그룹의 지역 간 장애 조치(failover)와는 관련이 없습니다.

수동 장애 조치(failover)를 사용하는 경우

SQL Managed Instance 플랫폼의 기본 부분인 가용성은 SQL Server 데이터베이스 엔진 프로세스를 호스트하는 로컬 대기 컴퓨팅 노드를 제공하여 데이터베이스 애플리케이션에 대해 투명하게 작동합니다. 장애 조치(failover)는 SQL Server 데이터베이스 엔진 프로세스가 주 컴퓨팅 노드에서 오프라인으로 전환되고 보조 컴퓨팅 노드에서 온라인 상태가 될 때 발생합니다. 일반적으로 SQL Managed Instance 컴퓨팅 노드 간의 장애 조치(failover)는 오류가 감지되거나 노드가 저하되거나 정기적인 월간 소프트웨어 업데이트 중에 플랫폼에서 자동으로 관리됩니다.

전체 장애 조치(failover) 작업은 보조 노드에서 SQL Server 데이터베이스 엔진 프로세스를 온라인 상태로 전환하고, 데이터베이스 상태의 유효성을 검사한 다음, 마지막으로 클라이언트 연결을 새로운 주 노드로 리디렉션하는 것으로 구성됩니다. 클라이언트 연결은 장애 조치(failover) 작업의 마지막 단계에서 일반적으로 1분 미만의 짧은 시간 동안만 장애가 발생합니다.

다음과 같은 이유로 수동 장애 조치(failover)를 실행하여 다른 노드에서 엔진 프로세스를 다시 시작할 수 있습니다.

  • 로그인 실패 또는 성능 문제로 인한 속도 저하.
  • 애플리케이션을 프로덕션 환경에 배포하기 전에 장애 조치(failover) 복원력 테스트.
  • 엔드투엔드 시스템의 자동 장애 조치(failover) 시 오류 복원력 테스트.
  • 장애 조치(failover)가 기존 데이터베이스 세션에 미치는 영향 테스트.
  • 쿼리 성능 저하(인스턴스를 다시 시작하면 성능 문제를 완화하는 데 도움이 될 수 있습니다).

프로덕션 환경에 배포하기 전에 애플리케이션에 장애 조치(failover) 복원력이 있는지 확인하면 프로덕션 환경에서 애플리케이션 결함 위험을 완화하고 고객의 애플리케이션 가용성에 기여할 수 있습니다. 다음 동영상에서 애플리케이션의 클라우드 준비 상태를 테스트하는 방법에 대해 자세히 알아보세요.

다음 표에서는 서비스 계층 및 가용성 모델을 기반으로 장애 조치(failover) 작업 중 SQL Managed Instance의 예상 동작을 설명합니다.

서비스 계층 가용성 모델 예상 장애 조치(failover) 동작 잠재적인 장애 조치(failover) 동작(예외)
범용 로컬 중복도
(단일 가용성 영역)		 SQL 프로세스가 동일한 VM에서 다시 시작됩니다. SQL 프로세스가 다른 VM에서 다시 시작됩니다.
범용 영역 중복(미리 보기)
(여러 가용성 영역)		 SQL 프로세스가 동일한 VM에서 다시 시작됩니다. SQL 프로세스가 다른 VM에서 다시 시작됩니다.
중요 비즈니스용 로컬 중복도
(단일 가용성 영역)		 임의 보조 복제본이 주 복제본으로 승격됩니다. 해당 없음
중요 비즈니스용 영역 중복
(여러 가용성 영역)		 임의 보조 복제본이 동일하거나 다른 가용성 영역에서 주 복제본으로 승격됩니다. 해당 없음

사용 권한

장애 조치(failover)를 시작하는 사용자에게는 다음 Azure 역할 중 하나가 있어야 합니다.

  • 구독 소유자 역할 또는
  • SQL Managed Instance 기여자 역할
  • 다음 권한이 있는 사용자 지정 역할:
    • Microsoft.Sql/managedInstances/failover/action

수동 장애 조치(failover)를 사용하여 인스턴스 다시 시작

PowerShell, Azure CLI 또는 REST API를 사용하여 수동 장애 조치(failover)로 인스턴스를 다시 시작할 수 있습니다.

Az.Sql의 최소 버전은 v2.9.0이어야 합니다. 항상 사용 가능한 최신 PowerShell 버전이 있는 Azure Portal에서 Azure Cloud Shell을 사용하는 것이 좋습니다.

사전 요구 사항으로 다음 PowerShell 스크립트를 사용하여 필요한 Azure 모듈을 설치합니다. 또한 장애 조치(failover)하려는 SQL Managed Instance가 있는 구독을 선택합니다.

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

다음 예제와 함께 PowerShell 명령 Invoke-AzSqlInstanceFailover를 사용하여 BC 및 GP 서비스 계층 모두에 적용되는 주 노드의 장애 조치(failover)를 시작합니다.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

다음 PowerShell 명령을 사용하여 BC 서비스 계층에만 해당하는 읽기 보조 노드를 장애 조치(failover)할 수 있습니다.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

장애 조치(failover) 모니터링

사용자가 시작한 장애 조치(failover)의 진행률 모니터링은 중요 비즈니스용 및 범용 서비스 계층의 인스턴스에 따라 다릅니다.

사용자가 시작한 장애 조치(failover)의 진행률을 모니터링하려면 다음을 사용합니다.

  • sys.dm_os_sys_info를 사용하여 범용 서비스 계층에 대한 시스템 가동 시간을 확인합니다.
  • sys.dm_hadr_fabric_replica_states를 사용하여 중요 비즈니스용 서비스 계층에 사용 가능한 복제본을 확인합니다.

장애 조치(failover) 프로세스의 마지막 단계는 클라이언트 연결을 새로운 주 노드로 리디렉션하는 것입니다. 장애 조치(failover) 중에 일반적으로 1분 이내에 지속되는 클라이언트 연결의 단기 손실은 서비스 계층에 관계 없이 장애 조치(failover)가 성공했음을 나타냅니다.

범용 서비스 계층

다음 T-SQL 예시에서는 범용 서비스 계층에 대한 노드의 SQL 프로세스 가동 시간을 보여줍니다.

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

SQL 프로세스 시작 시간은 노드에서 SQL Server 데이터베이스 엔진 프로세스가 시작된 시간입니다. 장애 조치(failover)가 완료된 후 시간이 다시 시작됩니다. 범용 서비스 계층에서 인스턴스의 장애 조치(failover)를 시작하기 전과 후에 이 쿼리를 실행하여 장애 조치(failover) 작업의 진행률을 모니터링합니다.

중요 비즈니스용 서비스 계층

다음 T-SQL 예시는 현재 중요 비즈니스용 서비스 계층의 주 복제본인 노드를 나타냅니다.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

장애 조치(failover)가 완료된 후 주 복제본을 호스트하는 노드가 변경됩니다. 중요 비즈니스용 서비스 계층에서 인스턴스의 장애 조치(failover)를 시작하기 전과 후에 이 쿼리를 실행하여 장애 조치(failover) 작업의 진행률을 모니터링합니다.

참고 항목

전체 장애 조치(failover) 프로세스는 고강도 워크로드 중에 완료하는 데 몇 분 정도 걸릴 수 있는데, 인스턴스 엔진은 장애 조치(failover)를 시작하기 전에 보조 노드의 트랜잭션이 기본 노드의 트랜잭션을 따라잡도록 하기 때문입니다.

제한 사항

사용자가 시작한 수동 장애 조치(failover)의 다음과 같은 기능 제한 사항을 고려합니다.

  • 15분마다 같은 SQL Managed Instance에서 장애 조치(failover)가 한 번(1)만 시작될 수 있습니다.
  • 다음의 경우 장애 조치(failover)는 허용되지 않습니다.
    • 자동화된 백업 시스템에서 새 데이터베이스에 대한 첫 번째 전체 백업이 완료될 때까지.
    • 데이터베이스 복원이 진행 중인 경우.
  • 중요 비즈니스용 서비스 계층의 인스턴스:
    • 장애 조치(failover) 요청이 허용되려면 복제본의 Quorum이 있어야 합니다.
    • 장애 조치(failover)를 시작할 읽기 가능한 보조 복제본을 지정할 수 없습니다.

관련 콘텐츠