이 문서에서는 재해 복구 또는 마이그레이션을 위해 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)할 수 있습니다.
링크에 대한 계획된 장애조치를 수행하려면 주 복제본에서 다음 T-SQL 명령을 사용합니다.
ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER
링크에 대한 강제 장애 조치(failover)를 수행하려면 보조 복제본에서 다음 T-SQL 명령을 사용합니다.
ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS
SSMS에서 SQL Server 및 Managed Instance 간 장애 조치(failover) 마법사를 사용하여 데이터베이스를 주 복제본에서 보조 복제본으로 장애 조치(failover)합니다.
주 복제본이나 보조 복제본에서 계획된 장애조치를 수행할 수 있습니다. 강제 장애 조치(failover)를 수행하려면 보조 복제본에 연결합니다.
주의
장애 조치(failover)를 수행하기 전에 원본 데이터베이스에서 워크로드를 중지하여 복제된 데이터베이스가 데이터 손실 없이 완전히 파악하고 장애 조치(failover)할 수 있도록 합니다. 강제 장애 조치(failover)를 수행하는 경우 데이터가 손실될 수 있습니다.
SQL Server 2019 이전 버전에서 데이터베이스를 장애 조치(failover)하면 두 복제본(replica) 간의 링크가 끊기고 제거됩니다. 초기 주 복제본으로 장애 복구(failback)할 수 없습니다.
SQL Server 2022에서 링크를 유지하면서 데이터베이스 장애 조치(failover)는 현재 프리뷰 상태입니다.
데이터베이스를 장애 조치(failover)하려면 다음 단계를 수행합니다.
SSMS를 열고 복제본(replica)에 연결합니다.
개체 탐색기에서 복제된 데이터베이스를 마우스 오른쪽 단추로 클릭하고 커서를 Azure SQL Managed Instance 링크에 올리고 장애 조치(failover)를 선택하여 SQL Server 및 Managed Instance 간 장애 조치(failover) 마법사를 엽니다. 같은 데이터베이스에서 링크가 여러 개 있으면 개체 탐색기의 Always On 가용성 그룹에서 가용성 그룹을 확장하고 장애 조치(failover)하려는 링크의 분산 가용성 그룹을 마우스 오른쪽 단추로 클릭합니다. 장애 조치(failover)를 선택하여 해당 특정 링크에 대한 SQL Server 및 Managed Instance 간 장애 조치(failover) 마법사를 엽니다.
소개 페이지에서 다음을 선택합니다.
장애 조치(failover) 유형 선택 페이지에는 각 복제본(replica), 선택한 데이터베이스의 역할 및 지원되는 장애 조치(failover) 유형에 대한 세부 정보가 표시됩니다. 모든 복제본(replica)에서 장애 조치(failover)를 시작할 수 있습니다. 강제 장애 조치(failover)를 선택하는 경우 상자를 선택하여 데이터 손실 가능성을 이해하고 있음을 나타내야 합니다. 다음을 선택합니다.
참고 사항
Azure SQL Managed Instance로 마이그레이션하는 경우 계획된 장애 조치를 선택합니다.
Azure 및 원격 인스턴스에 로그인 페이지에서 다음을 수행합니다.
로그인을 선택하여 자격 증명을 제공하고 Azure 계정에 로그인합니다.
이전 페이지에서 선택한 장애 조치(failover) 유형에 따라 로그인 옵션이 다르게 작동합니다. 계획된 장애 조치의 경우 원격 인스턴스(SQL Server 또는 SQL Managed Instance)에 로그인해야 합니다. 강제 장애 조치(failover)의 경우 다음 두 가지 시나리오가 지원되므로 로그인은 선택 사항입니다.
실질적인 재해 복구: 주 인스턴스는 일반적으로 실제 재해 중에 사용할 수 없으므로 로그인은 불가능하며, 사용자는 즉시 보조 인스턴스로 장애 조치(failover)하여 새 주 인스턴스로 만들어야 합니다. 중단이 해결된 후 두 복제본(replica)이 이제 주 역할이므로(스플릿 브레인 시나리오) 링크가 일관되지 않은 상태입니다.
재해 복구 훈련: 잠재적인 데이터 손실이 발생할 수 있으므로 강제 장애 조치(failover)를 사용하여 재해 복구 훈련을 수행하는 방법은 권장되지 않습니다. 그러나 훈련 중에 주 인스턴스가 사용 가능하므로 로그인이 지원되고, 스플릿 브레인 시나리오를 방지하기 위해 두 복제본(replica)에 대한 역할을 반대로 적용하는 옵션이 제공됩니다.
장애 조치(Failover) 후 작업 페이지에서 SQL Server 2022 및 이전 버전 사이에서 그리고 주 인스턴스에 연결할 수 있었는지 여부에 따라 옵션이 달라집니다.
SQL Server 2022의 경우 장애 조치(failover)가 완료된 후 복제본(replica) 사이에서 복제를 중지할 수 있습니다. 그러면 링크와 분산 가용성 그룹을 삭제합니다. 링크를 유지하고 복제본(replica) 간에 데이터를 계속 복제하려면 확인란을 선택 취소한 상태로 둡니다. 링크를 삭제하는 경우 데이터베이스를 Azure에 복제하기 위한 목적으로만 만든 경우 또는 더 이상 필요하지 않은 경우 확인란을 선택하여 가용성 그룹을 삭제할 수도 있습니다. 시나리오에 맞는 확인란을 선택한 다음, 다음을 선택합니다.
SQL Server 2019 이하 버전의 경우 링크 제거 옵션은 기본값으로 선택되어 있으며, SQL Managed Instance로 장애 조치(failover)하면 복제가 중지되고 링크가 끊어지며 분산 가용성 그룹이 삭제되므로 이 옵션을 선택 취소할 수 없습니다. 링크 삭제를 이해함을 나타내는 확인란을 선택한 다음, 다음을 선택합니다.
(선택 사항) 이전 페이지에서 SQL Server 인스턴스에 로그인할 수 있었던 경우 정리 섹션의 확인란을 선택하면 강제 장애 조치(failover)한 후 SQL Server 인스턴스에서 가용성 그룹을 삭제하는 옵션도 제공됩니다.
요약 페이지에서 작업을 검토합니다. 필요한 경우 스크립트를 선택하여 나중에 같은 링크를 사용하여 데이터베이스를 쉽게 장애 조치(failover)할 수 있도록 스크립트를 생성합니다. 데이터베이스를 장애 조치(failover)할 준비가 되면 마침을 선택합니다.
모든 단계가 완료되면 결과 페이지에서 성공적으로 완료된 작업 옆에 확인 표시가 나타납니다. 이제 마법사를 닫을 수 있습니다.
SQL Server 2022의 링크를 유지하면 보조 복제본이 새 주 복제본이 되고 링크는 계속 활성 상태이며 보조 복제본으로 장애 복구(failback)할 수 있습니다.
SQL Server 2019 이전 버전에 있거나 SQL Server 2022의 링크를 삭제한 경우 장애 조치(failover)가 완료되면 링크가 삭제되고 더 이상 존재하지 않습니다. 각 복제본의 원본 데이터베이스와 대상 데이터베이스 모두 읽기/쓰기 워크로드를 실행할 수 있습니다. 두 데이터베이스는 완전히 독립적입니다.
중요
SQL Managed Instance로 장애 조치(failover)가 성공하면 마이그레이션 또는 장애 조치(failover) 프로세스를 완료하고 Azure에서 계속 실행되도록 애플리케이션 연결 문자열을 SQL Managed Instance FQDN으로 수동으로 다시 지정합니다.
장애 조치(failover)하려면 먼저 T-SQL(Transact-SQL)을 사용하여 복제 모드 SQL Server 인스턴스를 전환해야 합니다.
그런 다음, PowerShell을 사용하여 장애 조치(failover)하고 역할을 전환할 수 있습니다.
복제 모드 전환(SQL MI로 장애 조치(failover))
SQL Server 및 SQL Managed Instance 간의 복제는 기본적으로 비동기식입니다. SQL Server에서 Azure SQL Managed Instance로 장애 조치(failover)하는 경우 데이터베이스를 장애 조치하기 전에 T-SQL(Transact-SQL)을 사용하여 SQL Server의 동기 모드로 링크를 전환합니다.
참고 사항
SQL Managed Instance에서 SQL Server 2022로 장애 조치(failover)하는 경우 이 단계를 건너뜁니다.
멀리 떨어져 있는 네트워크 간에 동기 복제를 사용하면 주 복제본에서 트랜잭션 속도가 저하될 수 있습니다.
SQL Server에서 다음 T-SQL 스크립트를 실행하여 SQL Server 분산 가용성 그룹의 복제 모드를 비동기에서 동기로 변경합니다. 다음과 같이 바꿉니다.
<DAGName>을 분산 가용성 그룹의 이름(링크를 만드는 데 사용됨)으로 바꿉니다.
<AGName>을 SQL Server에 만든 가용성 그룹의 이름(링크를 만드는 데 사용됨)으로 바꿉니다.
<ManagedInstanceName>을 관리되는 인스턴스의 이름으로 바꿉니다.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>]
MODIFY
AVAILABILITY GROUP ON
'<AGName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
'<ManagedInstanceName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
링크의 복제 모드를 성공적으로 변경했는지 확인하려면 다음 동적 관리 보기를 사용합니다. 결과는 SYNCHRONOUS_COMMIT 상태를 나타냅니다.
-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
ag.name, ag.is_distributed, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
ars.operational_state_desc, ars.synchronization_health_desc
FROM
sys.availability_groups ag
join sys.availability_replicas ar
on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars
on ars.replica_id=ar.replica_id
WHERE
ag.is_distributed=1
SQL Server를 동기 커밋 모드로 전환했으므로 두 인스턴스 간의 복제는 동기입니다. 이 상태를 반대로 설정해야 하는 경우 동일한 단계를 수행하고 AVAILABILITY_MODE를 ASYNCHRONOUS_COMMIT으로 설정합니다.
SQL Server 및 SQL Managed Instance에서 LSN 값 확인
장애 조치(failover) 또는 마이그레이션을 완료하려면 보조 항목으로의 복제가 완료되었는지 확인합니다. 이렇게 하려면 SQL Server 및 SQL Managed Instance 모두의 로그 레코드에 있는 LSN(로그 시퀀스 번호)이 같아야 합니다.
처음에는 주 항목의 LSN이 보조 항목의 LSN보다 높을 수 있습니다. 네트워크 대기 시간으로 인해 복제가 주 항목보다 다소 지연될 수 있습니다. 워크로드가 주 항목에서 중지되었으므로 일정 시간 후에 LSN이 일치하고 변경이 중지됩니다.
SQL Server에서 다음 T-SQL 쿼리를 사용하여 마지막으로 기록된 트랜잭션 로그의 LSN을 읽습니다. 바꾸기:
<DatabaseName>을 데이터베이스 이름으로 바꾸고 마지막으로 강화된 LSN 번호를 찾습니다.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
ag.name AS [Replication group],
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
ag.is_distributed = 1 and db.name = '<DatabaseName>'
SQL Managed Instance에서 다음 T-SQL 쿼리를 사용하여 데이터베이스에 대해 마지막으로 강화된 LSN을 읽습니다. <DatabaseName>을 데이터베이스 이름으로 바꿉니다.
이 쿼리는 범용 SQL Managed Instance에서 작동합니다. 중요 비즈니스용 SQL Managed Instance의 경우 스크립트 끝에서 and drs.is_primary_replica = 1 주석 처리를 제거합니다. 중요 비즈니스용 서비스 계층에서 이 필터는 주 복제본 세부 정보만 읽도록 합니다.
-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
WHERE
db.name = '<DatabaseName>'
-- for Business Critical, add the following as well
-- AND drs.is_primary_replica = 1
또한 Get-AzSqlInstanceLink PowerShell 또는 az sql mi link show Azure CLI 명령을 사용하여 이전 T-SQL 쿼리와 같은 정보를 제공하도록 SQL Managed Instance에서 링크의 LastHardenedLsn 속성을 페치할 수 있습니다.
중요
워크로드가 주 복제본에서 중지되었는지 다시 한 번 확인합니다. SQL Server와 SQL Managed Instance 둘 다의 LSN이 일치하는지, 그리고 일정 시간 동안 일치하고 변경되지 않은 상태로 유지되는지 확인합니다. 두 인스턴스의 안정적인 LSN는 비상 로그가 보조 복제본으로 복제되었으며 워크로드가 효과적으로 중지되었음을 나타냅니다.
데이터베이스 장애 조치(failover)
PowerShell을 사용하여 링크를 계속 유지하면서 SQL Server 2022 및 SQL Managed Instance 사이에서 데이터베이스를 장애 조치(failover)하거나 모든 버전의 SQL Server에 대해 장애 조치(failover)를 수행하려면(데이터 손실 발생) SSMS에서 SQL Server 및 Managed Instance 간 장애 조치(failover) 마법사를 사용하여 환경에 맞는 스크립트를 생성합니다. 주 복제본이나 보조 복제본에서 계획된 장애조치를 수행할 수 있습니다. 강제 장애 조치(failover)를 수행하려면 보조 복제본에 연결합니다.
장애 조치(failover)를 수행하기 전에 원본 데이터베이스에서 워크로드를 중지하여 복제된 데이터베이스가 데이터 손실 없이 완전히 파악하고 장애 조치(failover)할 수 있도록 합니다. 강제 장애 조치(failover)를 수행하거나 LSN이 일치하기 전에 링크를 끊으면 데이터가 손실될 수 있습니다.
SQL Server 2019 이전 버전에서 데이터베이스를 장애 조치(failover)하면 두 복제본(replica) 간의 링크가 끊기고 제거됩니다. 초기 주 복제본으로 장애 복구(failback)할 수 없습니다.
SQL Server 2022에서 링크를 유지하면서 데이터베이스 장애 조치(failover)는 현재 프리뷰 상태입니다.
다음 샘플 스크립트에서는 링크를 끊고 복제본(replica) 간의 복제를 종료하므로 두 인스턴스 모두에서 데이터베이스를 읽고 쓸 수 있습니다. 바꾸기:
<ManagedInstanceName>을 관리되는 인스턴스의 이름으로 바꿉니다.
<DAGName>을 장애 조치(failover)하는 링크의 이름으로 바꿉니다(위에서 이전에 실행한 Get-AzSqlInstanceLink 명령의 Name 속성 출력).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====
# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"
# ==== Do not customize the following cmdlet ====
# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force
장애 조치(failover)가 성공하면 링크가 삭제되고 더 이상 존재하지 않습니다. SQL Server 데이터베이스 및 SQL Managed Instance 데이터베이스는 이제 완전히 독립되었으므로 모두 읽기/쓰기 워크로드를 실행할 수 있습니다.
중요
SQL Managed Instance로 장애 조치(failover)가 성공하면 마이그레이션 또는 장애 조치(failover) 프로세스를 완료하고 Azure에서 계속 실행되도록 애플리케이션 연결 문자열을 SQL Managed Instance FQDN으로 수동으로 다시 지정합니다.
링크를 삭제한 후 SQL Server에서 가용성 그룹을 유지할 수 있지만 SQL Server에서 링크 메타데이터를 제거하려면 분산 가용성 그룹을 삭제해야 합니다. 이 추가 단계의 경우 SSMS에서는 자동으로 이 작업을 수행하기 때문에 PowerShell을 사용하여 장애 조치(failover)하는 경우에만 필요합니다.
분산 가용성 그룹을 삭제하려면 다음 값을 바꾼 다음, 샘플 T-SQL 코드를 실행합니다.
<DAGName>을 SQL Server의 분산 가용성 그룹의 이름(링크를 만드는 데 사용됨)으로 바꿉니다.
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
장애 조치(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
Azure SQL Managed Instance