다음을 통해 공유

링크 장애 조치(failover) - Azure SQL Managed Instance

  • 아티클

적용 대상: Azure SQL Managed Instance

이 문서에서는 재해 복구 또는 마이그레이션을 위해 SSMS(SQL Server Management Studio)를 사용하여 SQL Server 및 Azure SQL Managed Instance 사이에서 연결된 데이터베이스를 장애 조치(failover)하는 방법을 설명합니다.

필수 조건

링크를 통해 데이터베이스를 보조 복제본으로 장애 조치(failover)하려면 다음 필수 조건이 필요합니다.

워크로드 중지

데이터베이스를 보조 복제본으로 장애 조치(failover)하려면 먼저 유지 관리 시간 동안 주 복제본에서 애플리케이션 워크로드를 중지합니다. 이렇게 하면 데이터베이스 복제를 통해 보조 복제본에서 캐치업할 수 있으므로 데이터 손실 없이 보조 복제본으로 장애 조치(failover)할 수 있습니다. 애플리케이션이 장애 조치(failover) 전에 주 복제본에 트랜잭션을 커밋하지 않는지 확인합니다.

데이터베이스 장애 조치(failover)

T-SQL(Transact-SQL), SQL Server Management Studio 또는 PowerShell을 사용하여 연결된 데이터베이스를 장애 조치(failover)할 수 있습니다.

SQL Server 2022 CU13(KB5036432)부터 Transact-SQL을 사용하여 링크를 장애 조치(failover)할 수 있습니다.

링크에 대한 계획된 장애조치를 수행하려면 주 복제본에서 다음 T-SQL 명령을 사용합니다.

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

링크에 대한 강제 장애 조치(failover)를 수행하려면 보조 복제본에서 다음 T-SQL 명령을 사용합니다.

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

장애 조치(failover) 후 데이터베이스 보기

SQL Server 2022에서 링크를 유지 관리하려는 경우 SQL Server Management Studio의 개체 탐색기에 있는 가용성 그룹 아래에 분산 가용성 그룹이 있는지 확인할 수 있습니다.

장애 조치(failover) 중에 링크를 삭제하면 개체 탐색기를 사용하여 분산 가용성 그룹이 더 이상 존재하지 않는지 확인할 수 있습니다. 가용성 그룹을 유지하려는 경우 데이터베이스는 여전히 동기화된 상태입니다.

장애 조치(failover) 후 정리

장애 조치(failover) 후 링크 제거를 선택하지 않은 한, SQL Server 2022를 사용한 장애 조치로 연결이 끊기지는 않습니다. 장애 조치(failover) 후에도 링크를 유지할 수 있으므로 가용성 그룹과 분산 가용성 그룹이 활성 상태인 채로 유지됩니다. 추가 조치가 필요하지 않습니다.

링크를 없애면 분산 가용성 그룹만 삭제되고, 가용성 그룹은 활성 상태로 남습니다. 가용성 그룹을 유지하거나 삭제할 수 있습니다.

가용성 그룹을 삭제하려는 경우 다음 값을 바꾼 다음, 샘플 T-SQL 코드를 실행합니다.

  • <AGName>을 SQL Server(링크를 만드는 데 사용됨)의 가용성 그룹 이름으로 바꿉니다.
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

강제 장애 조치(failover) 후의 일관되지 않은 상태

강제 장애 조치(failover) 이후, 스플릿 브레인 상황이 발생하여 복제본이 둘 다 기본 역할이라서 링크가 일관되지 않은 상태로 유지될 가능성이 있습니다. 이 문제는 재해 상황 중에 보조 복제본으로 장애 조치(failover)한 다음, 주 복제본이 온라인 상태로 복구되면 발생합니다.

우선, 스플릿 브레인 상황이 맞는지 확인합니다. 이 작업은 SSMS(SQL Server Management Studio) 또는 T-SQL(Transact-SQL)을 사용해 수행할 수 있습니다.

SSMS에서 SQL Server와 SQL Managed Instance 둘 다에 연결한 다음, 개체 탐색기에서 Always On 고가용성의 가용성 그룹 노드 아래에 있는 가용성 복제본을 확장합니다. 복제본 두 개가 (주)로 나열되어 있다면 스플릿 브레인 상황입니다.

아니면 SQL Server와 SQL Managed Instance 양쪽 모두에서 다음 T-SQL 스크립트를 실행해 복제본 역할을 확인할 수도 있습니다.

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

두 인스턴스 모두 링크 역할 열에 주 항목이 다른 경우, 스플릿 브레인 상황입니다.

스플릿 브레인 상황을 해결하려면 우선 원래 주 복제본이었던 복제본의 백업을 만들어야 합니다. 원래 주 복제본이 SQL Server였던 경우, 비상 로그 백업을 만듭니다. 원래 주 복제본이 SQL Managed Instance였던 경우, 복사 전용 전체 백업을 만듭니다. 백업이 완료되면 분산 가용성 그룹을 원래 주 복제본이었지만 이제 새 보조 복제본이 된 복제본의 보조 역할로 설정합니다.

예를 들어 실제로 재해가 발생한 경우, SQL Server 워크로드를 Azure SQL Managed Instance로 강제 장애 조치(failover)한 것으로 가정하고, SQL Managed Instance에서 계속 워크로드를 실행할 생각이라면 SQL Server의 비상 로그 백업을 만든 다음 분산 가용성 그룹을 SQL Server의 보조 역할로 설정하면 됩니다. 다음 예를 참조하세요.

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO

그런 다음, SQL Managed Instance에서 SQL Server로 계획된 수동 장애 조치(failover)를 실행합니다. 다음 예시에서와 같이 링크를 사용하세요.

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO

관련 콘텐츠

링크를 사용하려면 다음을 수행합니다.

링크에 대해 자세히 알아보려면 다음을 수행합니다.

다른 복제 및 마이그레이션 시나리오의 경우 다음을 고려합니다.