다음을 통해 공유

스크립트를 사용하여 링크 구성 - Azure SQL Managed Instance

  • 아티클

적용 대상: Azure SQL Managed Instance

이 문서에서는 Transact-SQL과 PowerShell 또는 Azure CLI 스크립트를 사용하여 SQL Server와 Azure SQL Managed Instance 간에 링크를 구성하는 방법을 설명합니다. 이 링크를 사용하면 초기 주 복제본(replica)의 데이터베이스가 거의 실시간으로 보조 복제본으로 복제됩니다.

링크를 만든 다음, 마이그레이션이나 재해 복구를 위해 보조 복제본으로 장애 조치(failover)할 수 있습니다.

참고 항목

개요

링크 기능을 사용하면 초기 주 복제본의 데이터베이스를 보조 복제본으로 복제할 수 있습니다. SQL Server 2022의 경우 초기 주 복제본은 SQL Server 또는 Azure SQL Managed Instance일 수 있습니다. SQL Server 2019 이전 버전의 경우 초기 주 복제본은 SQL Server여야 합니다. 링크가 구성되면 초기 주 복제본의 데이터베이스가 보조 복제본으로 복제됩니다.

주 복제본과 보조 복제본 간의 하이브리드 환경에서 연속 데이터 복제를 위해 링크를 그대로 두거나 Azure로 마이그레이션하기 위해 또는 재해 복구를 위해 데이터베이스를 보조 복제본으로 장애 조치(failover)할 수 있습니다. SQL Server 2019 이전 버전의 경우 Azure SQL Managed Instance로 장애 조치(failover)하면 링크가 끊어지고 장애 복구(failback)는 지원되지 않습니다. SQL Server 2022에는 링크를 유지하고 두 복제본(replica) 간에 장애 복구(failback)할 수 있는 옵션이 있습니다. 이 기능은 현재 미리 보기 상태입니다.

보조 Managed Instance를 재해 복구에만 사용하려면 하이브리드 장애 조치(failover) 혜택을 활성화하여 라이선스 비용을 절약할 수 있습니다.

이 문서의 지침을 수행하여 SQL Server 및 Azure SQL Managed Instance 간에 링크를 수동으로 설정합니다. 링크가 생성되면 원본 데이터베이스는 대상 보조 복제본에서 읽기 전용 복사본을 가져옵니다.

팁

  • 올바른 환경 매개 변수로 T-SQL 스크립트 사용을 간소화하려면 SSMS(SQL Server Management Studio)의 Managed Instance 링크 마법사를 사용하여 링크를 만드는 스크립트를 생성하는 것이 좋습니다. 새 Managed Instance 링크 창의 요약 페이지에서 마침 대신 스크립트를 선택합니다.

필수 조건

참고 항목

링크의 일부 기능은 일반 공급되지만 일부는 현재 미리 보기로 제공됩니다. 자세한 내용은 버전 지원 가능성을 검토하세요.

데이터베이스를 복제하려면 다음 필수 구성 요소가 필요합니다.

다음을 고려하십시오.

  • 링크 기능은 링크당 하나의 데이터베이스를 지원합니다. 인스턴스에서 다중 데이터베이스를 복제하려면 각 개별 데이터베이스에 대한 링크를 만듭니다. 예를 들어 10개의 데이터베이스를 SQL Managed Instance에 복제하려면 10개의 개별 링크를 만듭니다.
  • SQL Server와 SQL Managed Instance 간의 데이터 정렬은 동일해야 합니다. 데이터 정렬이 일치하지 않는 경우 서버 이름 대/소문자 구분이 일치하지 않을 수 있으며 SQL Server에서 SQL Managed Instance로의 성공적인 연결을 방해할 수 있습니다.
  • 초기 SQL Server 주 복제본의 오류 1475는 COPY ONLY 옵션 없이 전체 백업을 만들어 새 백업 체인을 시작해야 함을 나타냅니다.
  • SQL Managed Instance에서 SQL Server 2022로의 링크 또는 장애 조치(failover)를 설정하려면 SQL Server 2022 업데이트 정책을 사용하여 Managed Instance를 구성해야 합니다. SQL Managed Instance에서 SQL Server 2022로의 데이터 복제 및 장애 조치(failover)는 항상 최신 업데이트 정책으로 구성된 인스턴스에서 지원되지 않습니다.
  • SQL Server 2022에서 항상 최신 업데이트 정책을 사용하여 구성된 SQL Managed Instance로의 링크를 설정할 수 있지만 SQL Managed Instance로 장애 조치(failover)를 한 후에는 더 이상 데이터를 복제하거나 SQL Server 2022로 장애 복구할 수 없습니다.

사용 권한

SQL Server의 경우 sysadmin 권한이 있어야 합니다.

Azure SQL Managed Instance의 경우 SQL Managed Instance 기여자 구성원이거나 다음 사용자 지정 역할 권한이 있어야 합니다.

Microsoft.Sql/ 리소스 필요한 권한
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /작업
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

용어 및 명명 규칙

이 사용자 가이드에서 스크립트를 실행할 때 SQL Server 및 SQL Managed Instance 이름을 FQDN(정규화된 도메인 이름)으로 혼동하지 않아야 합니다. 다음 표에서는 다양한 이름이 정확히 나타내는 항목과 해당 값을 가져오는 방법을 설명합니다.

용어 Description 확인 방법
초기 주 복제본 1 초기에 데이터베이스를 보조 복제본으로 복제하는 링크를 만드는 SQL Server 또는 SQL Managed Instance입니다.
주 복제본 현재 주 데이터베이스를 호스트하는 SQL Server 또는 SQL Managed Instance입니다.
보조 복제본 현재 주 복제본에서 거의 실시간으로 복제된 데이터를 수신하는 SQL Server 또는 SQL Managed Instance입니다.
SQL Server 이름 짧은 단일 단어 SQL Server 이름 예: sqlserver1. T-SQL에서 SELECT @@SERVERNAME을 실행합니다.
SQL Server FQDN SQL Server의 FQDN(정규화된 도메인 이름) 예: sqlserver1.domain.com. Azure VM(가상 머신)을 사용하는 경우 네트워크(DNS) 구성 온-프레미스 또는 서버 이름을 참조하세요.
SQL Managed Instance 이름 짧은 단일 단어 SQL Managed Instance 이름 예: managedinstance1. Azure Portal에서 관리되는 인스턴스의 이름을 참조하세요.
SQL Managed Instance FQDN SQL Managed Instance의 FQDN(정규화된 도메인 이름) 예: managedinstance1.6d710bcf372b.database.windows.net. Azure Portal의 SQL Managed Instance 개요 페이지에서 호스트 이름을 참조하세요.
확인 가능한 도메인 이름 IP 주소로 확인할 수 있는 DNS 이름입니다. 예를 들어 nslookup sqlserver1.domain.com 실행은 10.0.0.1과 같은 IP 주소를 반환해야 합니다. 명령 프롬프트에서 nslookup 명령을 실행합니다.
SQL Server IP SQL Server의 IP 주소 SQL Server에 IP가 여러 개인 경우 Azure에서 액세스할 수 있는 IP 주소를 선택합니다. SQL Server를 실행하는 호스트 OS의 명령 프롬프트에서ipconfig 명령을 실행합니다.

1 Azure SQL Managed Instance를 초기 주 복제본으로 구성하는 기능은 현재 미리 보기 상태이며 SQL Server 2022 CU10부터 지원됩니다.

데이터베이스 복구 및 백업 설정

SQL Server가 초기 주 복제본인 경우 링크를 통해 복제할 데이터베이스는 전체 복구 모드에 있어야 하며 데이터베이스에는 백업이 최소 하나 이상 있어야 합니다. Azure SQL Managed Instance는 자동으로 백업을 수행하므로 SQL Managed Instance가 초기 주 복제본이면 이 단계를 건너뜁니다. 주

복제하려는 모든 데이터베이스에 대해 SQL Server에서 다음 코드를 실행합니다. <DatabaseName>을 실제 데이터베이스 이름으로 바꿉니다.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

자세한 내용은 전체 데이터베이스 백업 만들기를 참조하세요.

참고 항목

링크는 사용자 데이터베이스의 복제만 지원합니다. 시스템 데이터베이스의 복제는 지원되지 않습니다. master 또는 msdb 데이터베이스에 저장된 인스턴스 수준 개체를 복제하려면 해당 개체를 스크립팅하고 대상 인스턴스에서 T-SQL 스크립트를 실행하는 것이 좋습니다.

인스턴스 간 신뢰 설정

먼저 두 인스턴스 간에 신뢰를 설정하고 네트워크에서 통신하고 데이터를 암호화하는 데 사용된 끝점을 보호해야 합니다. 분산 가용성 그룹은 자체 전용 엔드포인트가 아닌 기존 가용성 그룹 데이터베이스 미러링 엔드포인트를 사용합니다. 따라서 가용성 그룹 데이터베이스 미러링 끝점을 통해 두 인스턴스 간에 보안과 신뢰를 구성해야 합니다.

참고 항목

링크는 Always On 가용성 그룹 기술을 기반으로 합니다. 데이터베이스 미러링 끝점은 가용성 그룹에서 다른 인스턴스로부터 연결을 받는 데만 사용하는 특별한 용도의 끝점입니다. 데이터베이스 미러링 끝점 용어를 레거시 SQL Server 데이터베이스 미러링 기능과 오인해서는 안 됩니다.

인증서 기반 신뢰는 SQL Server 및 SQL Managed Instance의 데이터베이스 미러링 끝점을 보호하기 위해 지원되는 유일한 방법입니다. Windows 인증을 사용하는 기존 가용성 그룹이 있는 경우 보조 인증 옵션으로 기존 미러링 엔드포인트에 인증서 기반 신뢰를 추가해야 합니다. 이 문서의 뒷부분에 나오는 대로 ALTER ENDPOINT 문을 사용하여 이 작업을 수행할 수 있습니다.

Important

인증서는 만료 날짜 및 시간으로 생성됩니다. 만료되기 전에 갱신 및 회전해야 합니다.

다음에서는 SQL Server 및 SQL Managed Instance 모두의 데이터베이스 미러링 끝점을 보호하는 프로세스를 간략하게 설명합니다.

  1. SQL Server에서 인증서를 생성하고 해당 공개 키를 가져옵니다.
  2. SQL Managed Instance 인증서의 공개 키를 가져옵니다.
  3. SQL Server 및 SQL Managed Instance 간에 공개 키를 교환합니다.
  4. Azure에서 신뢰할 수 있는 루트 인증 기관 키를 SQL Server로 가져오기

다음 섹션에서는 관련 단계를 자세히 설명합니다.

SQL Server에서 인증서를 만들고 해당 공개 키를 SQL Managed Instance로 가져옵니다.

먼저 master 데이터베이스에 데이터베이스 마스터 키를 만듭니다(아직 없는 경우). 다음 스크립트의 <strong_password> 자리에 비밀번호를 삽입하고 안전한 장소에 기밀로 보관합니다. SQL Server에서 다음 T-SQL 스크립트를 실행합니다.

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

그런 다음, SQL Server에서 인증서를 생성합니다. 다음 스크립트에서 다음을 바꿉니다.

  • @cert_expiry_date를 원하는 인증서 만료 날짜(이후 날짜)로 바꿉니다.

이 날짜를 기록하고 만료일 전에 SQL Server 인증서를 순환(업데이트)하도록 미리 알림을 설정하여 링크의 연속 작동을 보장합니다.

Important

이 스크립트에서 자동 생성된 인증서 이름을 사용하는 것이 좋습니다. SQL Server에서 고유한 인증서 이름을 사용자 지정할 수 있지만 이름에는 \ 문자가 포함되어서는 안 됩니다.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

그런 다음, SQL Server에서 다음 T-SQL 쿼리를 사용하여 인증서가 생성되었는지 확인합니다.

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

쿼리 결과에서 인증서가 마스터 키로 암호화되었음을 확인할 수 있습니다.

이제 SQL Server에서 생성된 인증서의 공개 키를 가져올 수 있습니다.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

다음 단계에 필요하므로 인증서를 가져올 때 출력에서 SQLServerCertName 및 SQLServerPublicKey 값을 저장합니다.

먼저 Azure에 로그인하고 관리되는 인스턴스가 호스트되는 구독을 선택했는지 확인합니다. 계정에 Azure 구독이 둘 이상인 경우 적절한 구독을 선택하는 것이 특히 중요합니다.

<SubscriptionID> 를 Azure 구독 ID로 바꿉니다.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

그런 다음, New-AzSqlInstanceServerTrustCertificate PowerShell 또는 az sql mi partner-cert create Azure CLI 명령을 사용하여 다음 PowerShell 샘플과 같이 인증 인증서의 공개 키를 SQL Server에서 Azure로 업로드합니다.

필요한 사용자 정보를 입력하고 복사하여 붙여넣은 다음 스크립트를 실행합니다. 다음을

  • <SQLServerPublicKey>를 이전 단계에서 기록된 이진 형식의 SQL Server 인증서 공개 부분으로 바꿉니다. 0x로 시작하는 긴 문자열 값입니다.
  • <SQLServerCertName>을 이전 단계에서 기록한 SQL Server 인증서 이름으로 바꿉니다.
  • <ManagedInstanceName>을 관리되는 인스턴스의 짧은 이름으로 바꿉니다.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

이 작업 결과는 Azure에 업로드된 SQL Server 인증서의 요약입니다.

Managed Instance에 업로드된 모든 SQL Server 인증서를 확인하려면 Azure Cloud Shell에서 Get-AzSqlInstanceServerTrustCertificate PowerShell 또는 az sql mi partner-cert list Azure CLI 명령을 사용합니다. SQL Managed Instance에 업로드된 SQL Server 인증서를 제거하려면 Azure Cloud Shell에서 Remove-AzSqlInstanceServerTrustCertificate PowerShell 또는 az sql mi partner-cert delete Azure CLI 명령을 사용합니다.

SQL Managed Instance에서 인증서 공개 키를 받아서 SQL Server로 가져오기

링크 끝점을 보호하는 인증서는 Azure SQL Managed Instance에서 자동으로 생성됩니다. 다음 PowerShell 샘플과 같이 Get-AzSqlInstanceEndpointCertificate PowerShell 또는 az sql mi endpoint-cert show Azure CLI 명령을 사용하여 SQL Managed Instance에서 인증서 공개 키를 가져오고 SQL Server로 가져옵니다.

주의

Azure CLI를 사용하는 경우 후속 단계에서 사용할 때 PublicKey 출력의 맨 앞에 수동으로 0x를 추가해야 합니다. 예를 들어 PublicKey는 "0x3082033E30..."처럼 표시됩니다.

다음 스크립트를 실행합니다. 다음을

  • <SubscriptionID>를 Azure 구독 ID로 바꿉니다.
  • <ManagedInstanceName>을 관리되는 인스턴스의 짧은 이름으로 바꿉니다.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

다음 단계에서 필요하므로 0x로 시작하는 전체 PublicKey 출력을 복사합니다.

또는 PublicKey를 복사해서 붙여넣을 때 문제가 발생하는 경우 관리되는 인스턴스에서 T-SQL 명령인 EXEC sp_get_endpoint_certificate 4를 실행하여 링크 엔드포인트에 대한 공개 키를 가져올 수도 있습니다.

다음으로 관리되는 인스턴스 보안 인증서의 획득한 공개 키를 SQL Server에 가져옵니다. SQL Server에서 다음 코드를 실행합니다. 다음을

  • <ManagedInstanceFQDN>을 관리되는 인스턴스의 정규화된 도메인 이름으로 바꿉니다.
  • <PublicKey>를 이전 단계에서 얻은 PublicKey 값으로 바꿉니다(Azure Cloud Shell에서 0x로 시작). 따옴표를 사용할 필요가 없습니다.

중요

인증서 이름은 SQL Managed Instance FQDN이어야 하며 수정되어서는 안 됩니다. 사용자 지정 이름을 사용하는 경우 링크가 작동되지 않습니다.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Azure에서 신뢰할 수 있는 루트 인증 기관 키를 SQL Server로 가져오기

Azure에서 database.windows.net 도메인에 대해 발급한 인증서를 신뢰하려면 Microsoft 및 DigiCert CA(인증 기관)의 퍼블릭 루트 인증서 키를 SQL Server용으로 가져와야 합니다.

주의

PublicKey가 0x로 시작하는지 확인합니다. 아직 없으면 PublicKey 시작 부분에 수동으로 추가해야 할 수 있습니다.

먼저 SQL Server에서 Microsoft PKI 루트 인증 기관 인증서를 가져옵니다.

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exists.'
GO

그런 다음, SQL Server에서 DigiCert PKI 루트 기관 인증서를 가져옵니다.

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exists.'
GO

마지막으로 다음 DMV(동적 관리 뷰)를 사용하여 만든 모든 인증서를 확인합니다.

-- Run on SQL Server
SELECT * FROM sys.certificates

데이터베이스 미러링 끝점 보호

SQL Server에 기존 가용성 그룹이나 데이터베이스 미러링 끝점이 없는 경우 다음 단계는 SQL Server에서 데이터베이스 미러링 끝점을 만들고 이전에 생성한 SQL Server 인증서로 보호하는 것입니다. 기존 가용성 그룹이나 미러링 끝점이 있으면 기존 끝점 변경 섹션으로 건너뜁니다.

SQL Server에서 데이터베이스 미러 끝점 만들기 및 보호

기존 데이터베이스 미러링 엔드포인트가 생성되지 않았는지 확인하려면 다음 스크립트를 사용합니다.

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

위의 쿼리에 기존 데이터베이스 미러링 엔드포인트가 표시되지 않는 경우 SQL Server에서 다음 스크립트를 실행하여 이전에 발급한 SQL Server 인증서의 이름을 가져옵니다.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

다음 단계에서 필요하니 출력의 SQLServerCertName을 저장합니다.

다음 스크립트를 사용하여 포트 5022에 새 데이터베이스 미러링 끝점을 만들고 SQL Server 인증서로 끝점을 보호합니다. 다음을

  • <SQL_SERVER_CERTIFICATE>을 이전 단계에서 얻은 SQLServerCertName 이름으로 바꿉니다.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

SQL Server에서 다음 스크립트를 실행하여 미러링 엔드포인트가 만들어졌는지 확인합니다.

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

성공적으로 생성된 엔드포인트 state_desc 열은 STARTED 상태여야 합니다.

인증서 인증을 사용하여 새 미러링 엔드포인트를 만들었으며 AES 암호화를 사용하도록 설정했습니다.

기존 엔드포인트 변경

참고

새 미러링 엔드포인트를 방금 만든 경우 이 단계를 건너뜁니다. 기존 데이터베이스 미러링 엔드포인트와 함께 기존 가용성 그룹을 사용하는 경우에만 이 단계를 사용합니다.

링크에 기존 가용성 그룹을 사용하거나 기존 데이터베이스 미러링 엔드포인트가 있는 경우 먼저 링크에 대해 다음 필수 조건을 충족하는지 확인합니다.

  • 형식은 DATABASE_MIRRORING이어야 합니다.
  • 연결 인증은 CERTIFICATE여야 합니다.
  • 암호화를 사용하도록 설정해야 합니다.
  • 암호화 알고리즘은 AES여야 합니다.

SQL Server에서 다음 쿼리를 실행하여 기존 데이터베이스 미러링 엔드포인트에 대한 세부 정보를 봅니다.

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

출력에 기존 DATABASE_MIRRORING 엔드포인트 connection_auth_desc가 CERTIFICATE가 아니거나 encryption_algorthm_desc가 AES가 아닌 것으로 표시되는 경우 요구 사항에 맞게 엔드포인트를 변경해야 합니다.

SQL Server에서는 가용성 그룹과 분산 가용성 그룹 모두에 동일한 데이터베이스 미러링 엔드포인트가 사용됩니다. connection_auth_desc 엔드포인트가 NTLM(Windows 인증) 또는 KERBEROS이고 기존 가용성 그룹에 대한 Windows 인증이 필요한 경우 인증 옵션을 NEGOTIATE CERTIFICATE로 전환하여 여러 인증 방법을 사용하도록 엔드포인트를 변경할 수 있습니다. 이 변경 내용으로 인해 기존 가용성 그룹에서 Windows 인증을 사용하는 동시에 SQL Managed Instance에 대한 인증서 인증을 사용할 수 있습니다.

마찬가지로 암호화에 AES가 포함되지 않고 RC4 암호화가 필요한 경우 두 알고리즘을 모두 사용하도록 엔드포인트를 변경할 수 있습니다. 엔드포인트를 변경하는 데 사용할 수 있는 옵션에 대한 자세한 내용은 sys.database_mirroring_endpoints에 대한 설명서 페이지를 참조하세요.

다음 스크립트는 SQL Server에서 기존 데이터베이스 미러링 엔드포인트를 변경하는 방법의 예입니다. 다음을

  • <YourExistingEndpointName>을 기존 엔드포인트 이름으로 바꿉니다.
  • <SQLServerCertName>을 발급된 SQL Server 인증서의 이름(위의 이전 단계 중 한 단계에서 얻음)으로 바꿉니다.

특정 구성에 따라 스크립트를 추가로 사용자 지정해야 할 수 있습니다. SELECT * FROM sys.certificates를 사용하여 SQL Server에서 만든 인증서의 이름을 가져올 수도 있습니다.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

ALTER 엔드포인트 쿼리를 실행하고 이중 인증 모드를 Windows 및 인증서로 설정한 후 SQL Server에서 이 쿼리를 다시 사용하여 데이터베이스 미러링 엔드포인트 세부 정보를 표시합니다.

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

SQL Managed Instance 링크에 대한 데이터베이스 미러링 엔드포인트를 성공적으로 수정했습니다.

SQL Server에서 가용성 그룹 만들기

기존 가용성 그룹이 없는 경우 다음 단계는 초기 주 복제본 여부에 관계없이 SQL Server에서 가용성 그룹을 만드는 것입니다. SQL Managed Instance가 SQL Server 2022 CU10부터 지원되는 초기 주 복제본인 경우 가용성 그룹을 만드는 명령은 다릅니다.

같은 데이터베이스에 링크 여러 개를 설정할 수 있지만 링크는 링크당 데이터베이스 하나의 복제본(replica)만 지원합니다. 같은 데이터베이스에 링크 여러 개를 만들려면 모든 링크에 같은 가용성 그룹을 사용한 다음, SQL Server 및 SQL Managed Instance 간의 데이터베이스 링크마다 새 분산 가용성 그룹을 만듭니다.

SQL Server가 초기 주 복제본이면 다음 링크 매개 변수를 사용하여 가용성 그룹을 만듭니다.

  • 초기 주 서버 이름
  • 데이터베이스 이름
  • MANUAL의 장애 조치(failover) 모드
  • AUTOMATIC의 시드 모드

먼저 다음 T-SQL 문을 실행하여 SQL Server 이름을 확인합니다.

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

그런 후, 다음 스크립트를 사용하여 SQL Server에서 가용성 그룹을 만듭니다. 다음을

  • <AGName>을 가용성 그룹의 이름으로 바꿉니다. Managed Instance 링크에는 가용성 그룹당 하나의 데이터베이스가 필요합니다. 여러 데이터베이스의 경우 여러 개의 가용성 그룹을 만들어야 합니다. 이름이 해당 데이터베이스를 반영할 수 있도록 각 가용성 그룹의 이름을 지정하는 것이 좋습니다(예: AG_<db_name>).
  • <DatabaseName>을 복제할 데이터베이스의 이름으로 바꿉니다.
  • <SQLServerName>을 이전 단계에서 가져온 SQL Server 인스턴스의 이름으로 바꿉니다.
  • <SQLServerIP>를 SQL Server IP 주소로 바꿉니다. 확인 가능한 SQL Server 호스트 컴퓨터 이름을 대안으로 사용할 수 있지만 이름이 SQL Managed Instance 가상 네트워크에서 확인할 수 있는지 확인해야 합니다.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

중요

SQL Server 2016의 경우 위의 T-SQL 문에서 WITH (CLUSTER_TYPE = NONE)을 삭제합니다. 모든 이후 SQL Server 버전에 대해 있는 그대로 둡니다.

다음으로, SQL Server에서 분산 가용성 그룹을 만듭니다. 링크를 여러 개 만들려는 경우 같은 데이터베이스에 링크를 여러 개 설정하는 경우에도 링크마다 분산 가용성 그룹을 만들어야 합니다.

다음 값을 바꾼 다음, T-SQL 스크립트를 실행하여 분산 가용성 그룹을 만듭니다.

  • <DAGName>을 분산 가용성 그룹의 이름으로 바꿉니다. 링크마다 분산 가용성 그룹을 만들어 같은 데이터베이스에 링크를 여러 개 구성할 수 있으므로 그에 따라 각 분산 가용성 그룹 이름을 지정하는 것이 좋습니다(예: DAG1_<db_name>, DAG2_<db_name>).
  • <AGName>을 이전 단계에서 만든 그룹의 이름으로 바꿉니다.
  • <SQLServerIP>를 이전 단계에서 SQL Server의 IP 주소로 바꿉니다. 확인 가능한 SQL Server 호스트 컴퓨터 이름을 대안으로 사용할 수 있지만 SQL Managed Instance 가상 네트워크에서 이름을 확인할 수 있는지 확인합니다(Managed Instance의 서브넷에 사용자 지정 Azure DNS를 구성해야 함).
  • <ManagedInstanceName>을 관리되는 인스턴스의 짧은 이름으로 바꿉니다.
  • <ManagedInstanceFQDN>을 관리되는 인스턴스 이름의 정규화된 도메인 이름으로 바꿉니다.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

가용성 그룹 확인

다음 스크립트를 사용하여 SQL Server 인스턴스의 모든 가용성 그룹 및 분산 가용성 그룹을 나열합니다. 이 시점에서 가용성 그룹의 상태는 connected여야 하며 분산 가용성 그룹의 상태는 disconnected여야 합니다. 분산 가용성 그룹 상태는 SQL Managed Instance와 조인된 경우에만 connected로 이동합니다.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

또는 SSMS 개체 탐색기를 사용하여 가용성 그룹 및 분산 가용성 그룹을 찾을 수 있습니다. Always On 고가용성 폴더를 확장한 다음, 가용성 그룹 폴더를 확장합니다.

마지막으로, 링크를 만들 수 있습니다. 명령은 초기 주 복제본인 인스턴스에 따라 다릅니다. 이 섹션의 PowerShell 예제와 같이 New-AzSqlInstanceLink PowerShell 또는 az sql mi link create Azure CLI 명령을 사용하여 링크를 만듭니다. SQL Managed Instance 주 복제본에서 링크를 만드는 것은 현재 Azure CLI에서 지원되지 않습니다.

Managed Instance에서 모든 링크를 확인해야 하는 경우 Azure Cloud Shell에서 Get-AzSqlInstanceLink PowerShell 또는 az sql mi link show Azure CLI 명령을 사용합니다.

프로세스를 간소화하려면 Azure Portal에 로그인하고 Azure Cloud Shell에서 다음 스크립트를 실행합니다. 다음을

  • <ManagedInstanceName>을 관리되는 인스턴스의 짧은 이름으로 바꿉니다.
  • <AGName>을 SQL Server에 만든 가용성 그룹의 이름으로 바꿉니다.
  • <DAGName>을 SQL Server에서 만든 분산 가용성 그룹 이름으로 바꿉니다.
  • <DatabaseName>을 SQL Server에서 가용성 그룹에 복제된 데이터베이스로 바꿉니다.
  • <SQLServerIP>를 SQL Server IP 주소로 바꿉니다. 제공된 IP 주소는 관리되는 인스턴스에서 액세스할 수 있어야 합니다.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

이 작업 결과는 링크 만들기 요청을 성공적으로 실행한 타임스탬프입니다.

SQL Managed Instance 및 SQL Server 간의 연결을 확인하려면 SQL Server에서 다음 쿼리를 실행합니다. 연결하는 데 시간이 거릴 수 있습니다. DMV가 성공적인 연결을 표시하기 시작하는 데 최대 1분이 걸릴 수 있습니다. SQL Managed Instance 복제본에 대한 연결이 CONNECTED로 나타날 때까지 DMV를 계속 새로 고칩니다.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

연결이 설정되면 초기 시드 배정 단계가 이동하고 데이터베이스의 전체 백업을 복원하므로 처음에는 SSMS의 개체 탐색기에 보조 복제본에서 복제된 데이터베이스가 복원 중 상태로 표시됩니다. 데이터베이스가 복원된 후에는 두 데이터베이스를 동기화된 상태로 만들기 위해 복제를 따라야 합니다. 초기 시드 배정이 완료되면 데이터베이스가 더 이상 복원 중 상태가 아닙니다. 작은 데이터베이스를 시드하는 것은 SSMS에서 초기 복원 상태를 볼 수 없을 정도로 빠를 수 있습니다.

중요

  • SQL Server와 SQL Managed Instance 간에 네트워크 연결이 없으면 링크가 작동하지 않습니다. 네트워크 연결 문제를 해결하려면 네트워크 연결 테스트 단계를 수행합니다.
  • SQL Server에서 로그 파일을 정기적으로 백업합니다. 사용된 로그 공간이 100%에 도달하면 공간 사용이 줄어들 때까지 SQL Managed Instance로의 복제가 중지됩니다. 매일의 작업을 설정하여 로그 백업을 자동화하는 것이 좋습니다. 자세한 내용은 SQL Server에서 로그 파일 백업을 참조하세요.

문제 해결

이 섹션에서는 링크 구성 및 사용과 관련된 issue를 해결하기 위한 지침을 제공합니다.

Errors

링크를 만들거나 데이터베이스를 장애 조치(failover)할 때 오류 메시지가 표시되면 쿼리 출력 창에서 오류 메시지를 검토하여 자세한 내용을 확인합니다.

링크를 사용할 때 오류가 발생하면 실패한 단계에서 쿼리 실행이 중지됩니다. 오류 조건이 해결된 후 명령을 다시 실행하여 작업을 진행합니다.

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

강제 장애 조치(failover)를 사용하면 주 복제본과 보조 복제본 간에 일관되지 않은 상태가 발생하여 두 복제본(replica)의 분할 브레인 시나리오가 같은 역할에 있을 수 있습니다. 사용자가 수동으로 복제본(replica) 하나를 주 복제본으로 지정하고 다른 복제본(replica)을 보조 복제본으로 지정하여 상황을 해결할 때까지 데이터 복제는 이 상태에서 실패합니다.

관련 콘텐츠

링크 기능에 대한 자세한 내용은 다음 리소스를 참조하세요.