SQL Managed Instance에서 사용자가 시작한 수동 장애 조치(failover)User-initiated manual failover on SQL Managed Instance

적용 대상: Azure SQL Managed Instance

이 문서에서는 SQL Managed Instance 일반 용도 (GP) 및 중요 비즈니스용 (BC) 서비스 계층에서 주 노드를 수동으로 장애 조치 하는 방법 및 BC 서비스 계층에서 보조 읽기 전용 복제본 노드를 수동으로 장애 조치 (failover) 하는 방법을 설명 합니다.This article explains how to manually failover a primary node on SQL Managed Instance General Purpose (GP) and Business Critical (BC) service tiers, and how to manually failover a secondary read-only replica node on the BC service tier only.

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

고가용성 은 데이터베이스 응용 프로그램에 대해 투명 하 게 작동 하는 SQL Managed Instance 플랫폼의 기본적인 부분입니다.High availability is a fundamental part of SQL Managed Instance platform that works transparently for your database applications. 노드 저하 또는 오류 감지 시 기본 노드에서 보조 노드로 장애 조치 (failover) 또는 정기적인 월간 소프트웨어 업데이트 중에 Azure에서 SQL Managed Instance를 사용 하는 모든 응용 프로그램에 대 한 예상 된 상황이 발생 합니다.Failovers from primary to secondary nodes in case of node degradation or fault detection, or during regular monthly software updates are an expected occurrence for all applications using SQL Managed Instance in Azure.

다음과 같은 이유로 SQL Managed Instance에서 수동 장애 조치 (failover) 를 실행 하는 것을 고려할 수 있습니다.You might consider executing a manual failover on SQL Managed Instance for some of the following reasons:

  • 프로덕션 환경에 배포 하기 전에 장애 조치 복원에 대 한 응용 프로그램 테스트Test application for failover resiliency before deploying to production
  • 자동 장애 조치 (failover) 시 오류 복원 력을 위한 종단 간 시스템 테스트Test end-to-end systems for fault resiliency on automatic failovers
  • 장애 조치 (failover)가 기존 데이터베이스 세션에 미치는 영향 테스트Test how failover impacts existing database sessions
  • 네트워크 대기 시간의 변경으로 인해 장애 조치 (failover)에서 종단 간 성능을 변경 하는지 확인 합니다.Verify if a failover changes end-to-end performance because of changes in the network latency
  • Query performance 저하의 경우 수동 장애 조치 (failover)를 통해 성능 문제를 완화할 수 있습니다.In some cases of query performance degradations, manual failover can help mitigate the performance issue.

참고

프로덕션 환경에 배포 하기 전에 응용 프로그램을 장애 조치 (failover) 하는 것을 확인 하면 프로덕션 환경에서 응용 프로그램 오류의 위험을 완화 하 고 고객의 응용 프로그램 가용성에 영향을 줍니다.Ensuring that your applications are failover resilient prior to deploying to production will help mitigate the risk of application faults in production and will contribute to application availability for your customers. SQL Managed Instance 비디오를 통해 장애 조치 (Failover) 복원에 대 한 앱 클라우드 준비를 테스트 하 여 클라우드 준비를 위한 응용 프로그램 테스트에 대해 자세히 알아보세요.Learn more about testing your applications for cloud readiness with Testing App Cloud Readiness for Failover Resiliency with SQL Managed Instance video recoding.

SQL Managed Instance에서 수동 장애 조치 (failover) 시작Initiate manual failover on SQL Managed Instance

Azure RBAC 권한 필요Azure RBAC permissions required

장애 조치 (failover)를 시작 하는 사용자에 게는 다음 Azure 역할 중 하나가 있어야 합니다.User initiating a failover will need to have one of the following Azure roles:

  • 구독 소유자 역할 또는Subscription Owner role, or
  • Managed Instance 참가자 역할 또는Managed Instance Contributor role, or
  • 다음 권한이 있는 사용자 지정 역할:Custom role with the following permission:
    • Microsoft.Sql/managedInstances/failover/action

PowerShell 사용Using PowerShell

Az. Sql의 최소 버전은 v 2.9.0여야 합니다.The minimum version of Az.Sql needs to be v2.9.0. 항상 최신 PowerShell 버전이 있는 Azure Portal에서 Azure Cloud Shell 를 사용 하는 것이 좋습니다.Consider using Azure Cloud Shell from the Azure portal that always has the latest PowerShell version available.

사전 요구 사항으로, 다음 PowerShell 스크립트를 사용 하 여 필요한 Azure 모듈을 설치 합니다.As a pre-requirement, use the following PowerShell script to install required Azure modules. 또한 장애 조치 (failover) 하려는 Managed Instance 있는 구독을 선택 합니다.In addition, select the subscription where Managed Instance you wish to failover is located.

$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 명령 AzSqlInstanceFailover 를 사용 하 여 BC 및 GP 서비스 계층 모두에 적용 되는 주 노드의 장애 조치 (failover)를 시작 합니다.Use PowerShell command Invoke-AzSqlInstanceFailover with the following example to initiate failover of the primary node, applicable to both BC and GP service tier.

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

다음 PS 명령을 사용 하 여 보조 노드를 장애 조치 (failover) 할 수 있습니다 (BC 서비스 계층에만 해당).Use the following PS command to failover read secondary node, applicable to BC service tier only.

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

CLI 사용Using CLI

최신 CLI 스크립트를 설치 했는지 확인 합니다.Ensure to have the latest CLI scripts installed.

다음 예제와 함께 az sql mi 장애 조치 CLI 명령을 사용 하 여 BC 및 GP 서비스 계층 모두에 적용 되는 기본 노드의 장애 조치 (failover)를 시작 합니다.Use az sql mi failover CLI command with the following example to initiate failover of the primary node, applicable to both BC and GP service tier.

az sql mi failover -g myresourcegroup -n myinstancename

다음 CLI 명령을 사용 하 여 보조 노드를 장애 조치 (failover) 할 수 있습니다 (BC 서비스 계층에만 해당).Use the following CLI command to failover read secondary node, applicable to BC service tier only.

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

Rest API 사용Using Rest API

연속 테스트 파이프라인 또는 자동화 된 성능 mitigators을 구현 하기 위해 SQL 관리 되는 인스턴스의 장애 조치 (failover)를 자동화 해야 하는 고급 사용자의 경우 API 호출을 통해 장애 조치 (failover)를 시작 하 여이 함수를 수행할 수 있습니다.For advanced users who would perhaps need to automate failovers of their SQL Managed Instances for purposes of implementing continuous testing pipeline, or automated performance mitigators, this function can be accomplished through initiating failover through an API call. 자세한 내용은 관리 되는 인스턴스-장애 조치 (Failover) REST API 를 참조 하세요.see Managed Instances - Failover REST API for details.

REST API 호출을 사용 하 여 장애 조치 (failover)를 시작 하려면 먼저 선택한 API 클라이언트를 사용 하 여 인증 토큰을 생성 합니다.To initiate failover using REST API call, first generate the Auth Token using API client of your choice. 생성 된 인증 토큰은 API 요청 헤더에서 권한 부여 속성으로 사용 되며 필수입니다.The generated authentication token is used as Authorization property in the header of API request and it is mandatory.

다음 코드는 호출할 API URI의 예입니다.The following code is an example of the API URI to call:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

API 호출에서 다음 속성을 전달 해야 합니다.The following properties need to be passed in the API call:

API 속성API property 매개 변수Parameter
subscriptionIdsubscriptionId 관리 되는 인스턴스가 배포 되는 구독 ID입니다.Subscription ID to which managed instance is deployed
resourceGroupNameresourceGroupName 관리 되는 인스턴스를 포함 하는 리소스 그룹Resource group that contains managed instance
managedInstanceNamemanagedInstanceName 관리 되는 인스턴스의 이름Name of managed instance
replicaTypereplicaType 필드 (주 또는 ReadableSecondary).(Optional) (Primary or ReadableSecondary). 이러한 매개 변수는 장애 조치 (failover) 될 복제본의 유형 (주 또는 읽을 수 있는 보조)을 나타냅니다.These parameters represent the type of replica to be failed over: primary or readable secondary. 지정 하지 않으면 기본적으로 주 복제본에서 장애 조치 (failover)가 시작 됩니다.If not specified, failover will be initiated on the primary replica by default.
api-versionapi-version 정적 값 이며 현재 "2019-06-01-preview" 여야 합니다.Static value and currently needs to be “2019-06-01-preview"

API 응답은 다음 두 가지 중 하나가 됩니다.API response will be one of the following two:

  • 202 수락됨202 Accepted
  • 400 요청 오류 중 하나입니다.One of the 400 request errors.

응답 헤더의 API 응답을 검토 하 여 작업 상태를 추적할 수 있습니다.Operation status can be tracked through reviewing API responses in response headers. 자세한 내용은 비동기 Azure 작업의 상태를 참조 하세요.For more information, see Status of asynchronous Azure operations.

장애 조치 (failover) 모니터링Monitor the failover

BC 인스턴스에 대해 사용자가 시작한 장애 조치 (failover)의 진행률을 모니터링 하려면 SQL Managed Instance에서 즐겨 사용 하는 클라이언트 (예: SSMS)에서 다음 T-sql 쿼리를 실행 합니다.To monitor the progress of user initiated failover for your BC instance, execute the following T-SQL query in your favorite client (such is SSMS) on SQL Managed Instance. 이 도구는 인스턴스에 사용할 수 있는 시스템 뷰 sys.dm_hadr_fabric_replica_states 및 보고서 복제본을 읽습니다.It will read the system view sys.dm_hadr_fabric_replica_states and report replicas available on the instance. 수동 장애 조치 (failover)를 시작한 후 동일한 쿼리를 새로 고칩니다.Refresh the same query after initiating the manual failover.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

장애 조치 (failover)를 시작 하기 전에 출력은 AlwaysOn 가용성 그룹에서 주 1 개 및 3 개의 보조 복제본이 포함 된 BC 서비스 계층의 현재 주 복제본을 표시 합니다.Before initiating the failover, your output will indicate the current primary replica on BC service tier containing one primary and three secondaries in the AlwaysOn Availability Group. 장애 조치 (failover)를 실행 하면이 쿼리를 다시 실행 하 여 주 노드의 변경을 나타내야 합니다.Upon execution of a failover, running this query again would need to indicate a change of the primary node.

이제는 BC에 대해 표시 된 것과 동일한 GP 서비스 계층을 사용 하 여 출력을 볼 수 없습니다.You will not be able to see the same output with GP service tier as the one above shown for BC. 이는 GP 서비스 계층이 단일 노드만 기반으로 하기 때문입니다.This is because GP service tier is based on a single node only. GP 서비스 계층 인스턴스의 노드에서 SQL 프로세스가 시작 된 시간을 보여 주는 대체 T-sql 쿼리를 사용할 수 있습니다.You can use alternative T-SQL query showing the time SQL process started on the node for GP service tier instance:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

장애 조치 (failover) 중에 일반적으로 1 분 이내에 지속 되는 클라이언트 연결의 단기 손실은 서비스 계층에 관계 없이 장애 조치 (failover) 실행을 나타냅니다.The short loss of connectivity from your client during the failover, typically lasting under a minute, will be the indication of the failover execution regardless of the service tier.

참고

높은 강도 워크 로드의 경우에는 장애 조치 (failover) 프로세스를 완료 하는 데 몇 분 정도 걸릴 수 있습니다.Completion of the failover process (not the actual short unavailability) might take several minutes at a time in case of high-intensity workloads. 이는 장애 조치 (failover)를 수행 하기 전에 인스턴스 엔진이 주 서버의 모든 현재 트랜잭션을 처리 하 고 보조 노드에서 처리 하기 때문입니다.This is because the instance engine is taking care of all current transactions on the primary and catch up on the secondary node, prior to being able to failover.

중요

사용자가 시작한 수동 장애 조치 (failover)의 기능 제한 사항은 다음과 같습니다.Functional limitations of user-initiated manual failover are:

  • 15 분 마다 동일한 Managed Instance에서 하나의 장애 조치 (failover)가 시작 될 수 있습니다.There could be one (1) failover initiated on the same Managed Instance every 15 minutes.
  • BC 인스턴스의 경우 장애 조치 (failover) 요청이 허용 되려면 복제본의 쿼럼이 있어야 합니다.For BC instances there must exist quorum of replicas for the failover request to be accepted.
  • BC 인스턴스의 경우 장애 조치 (failover)를 시작할 읽을 수 있는 보조 복제본을 지정할 수 없습니다.For BC instances it is not possible to specify which readable secondary replica to initiate the failover on.
  • 자동화 된 백업 시스템에서 새 데이터베이스에 대 한 첫 번째 전체 백업이 완료 될 때까지 장애 조치 (Failover)가 허용 되지 않습니다.Failover will not be allowed until the first full backup for a new database is completed by automated backup systems.
  • 진행 중인 데이터베이스 복원이 있으면 장애 조치 (Failover)가 허용 되지 않습니다.Failover will not be allowed if there exists a database restore in progress.

다음 단계Next steps