Managed Instance 링크 모범 사례 - Azure SQL Managed Instance

적용 대상:Azure SQL Managed Instance

이 문서에서는 Managed Instance 링크를 사용하여 Azure SQL Managed Instance 및 어디서나 호스트되는 SQL Server 인스턴스 간에 데이터를 복제하는 모범 사례를 간략하게 설명합니다. 링크는 연결된 복제본 간에 거의 실시간 데이터 복제를 제공합니다.

정기적으로 로그 백업 수행

SQL Server가 초기 주 데이터베이스인 경우, 초기 시드가 완료된 후 Azure SQL Managed Instance에서 데이터베이스가 더 이상 복구 중... 상태가 아니면 SQL Server에서 첫 번째 로그 백업을 수행합니다. 그런 다음 SQL Server 트랜잭션 로그 백업을 정기적으로 수행하여 SQL Server 주 역할에 있는 동안 트랜잭션 로그 파일 크기를 정상 상태로 유지합니다.

링크 기능은 Always On 가용성 그룹을 기반으로 하는 분산 가용성 그룹 기술을 사용하여 데이터를 복제합니다. 분산 가용성 그룹 데이터 복제는 트랜잭션 로그 레코드 복제를 기반으로 합니다. 주 SQL Server 인스턴스는 보조 복제본의 데이터베이스에 복제될 때까지 데이터베이스의 트랜잭션 로그 레코드를 잘라낼 수 없습니다. 네트워크 연결 문제로 인해 트랜잭션 로그 레코드 복제가 느리거나 차단되는 경우 기본 인스턴스에서 로그 파일이 계속 증가합니다. 워크로드의 강도와 네트워크 속도는 증가 속도를 결정합니다. 네트워크 연결 중단이 장기화되고 주 인스턴스의 워크로드가 많은 경우 로그 파일은 사용 가능한 모든 스토리지 공간을 사용할 수 있습니다.

일반 트랜잭션 로그 백업을 수행하면 트랜잭션 로그가 잘리고 로그 파일 증가로 인해 주 SQL Server 인스턴스의 공간이 부족할 위험이 최소화됩니다. 로그 백업이 이미 자동으로 수행되므로 SQL Managed Instance 기본인 경우 추가 작업이 필요하지 않습니다. SQL Server 주 데이터베이스에서 로그 백업을 정기적으로 실행하면 계획되지 않은 로그 증가 이벤트에 대해 데이터베이스의 복원력을 높일 수 있습니다. SQL Server 에이전트 작업을 사용하여 매일 로그 백업 작업을 예약하는 것이 좋습니다.

Transact-SQL(T-SQL) 스크립트를 사용하여 이 섹션에 제공된 샘플과 같은 로그 파일을 백업할 수 있습니다. 샘플 스크립트의 자리 표시자를 데이터베이스 이름, 백업 파일의 이름과 경로 및 설명으로 바꿉니다.

트랜잭션 로그를 백업하려면 SQL Server 다음 샘플 Transact-SQL(T-SQL) 스크립트를 사용합니다.

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

다음 Transact-SQL(T-SQL) 명령을 사용하여 SQL Server 데이터베이스에서 사용하는 간격이 지정되는 로그를 확인합니다.

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

쿼리 출력은 샘플 데이터베이스 tpcc에 대한 다음 예제와 같습니다.

이 예제에서 데이터베이스는 사용 가능한 로그의 76%를 사용했으며 절대 로그 파일 크기는 약 27GB(27,971MB)입니다. 작업 임계값은 워크로드에 따라 달라집니다. 이전 예제에서 트랜잭션 로그 크기 및 로그 사용 비율은 일반적으로 트랜잭션 로그 백업을 수행하여 로그 파일을 잘라내고 공간을 확보해야 하며 더 자주 로그 백업을 수행해야 했음을 나타냅니다. 또한 트랜잭션 로그 자르기가 열려 있는 트랜잭션에 의해 차단되고 있음을 나타낼 수도 있습니다. SQL Server 트랜잭션 로그 문제 해결에 대한 자세한 내용은 전체 트랜잭션 로그 문제 해결(SQL Server 오류 9002) 참조하세요. Azure SQL Managed Instance 트랜잭션 로그 문제 해결에 대한 자세한 내용은 Azure SQL Managed Instance 참조하세요.

복제본 간의 성능 용량 일치

링크 기능을 사용할 때, SQL Server와 SQL Managed Instance 간의 성능 용량을 일치시키세요. 보조 복제본이 주 복제본의 복제를 따라가지 못하거나 장애 조치 후 성능 문제를 방지하는 데 이 매칭이 도움이 됩니다. 성능 용량에는 CPU 코어(또는 Azure vCore), 메모리 및 I/O 처리량이 포함됩니다.

보조 복제본에서 다시 실행 큐 크기를 확인하여 복제 성능을 모니터링할 수 있습니다. 다시 실행 큐 크기에는 보조 복제본에서 다시 실행되기를 기다리는 로그 레코드 수가 표시됩니다. 일관되게 높은 다시 실행 큐 크기는 보조 복제본이 주 복제본을 따라갈 수 없다는 것을 보여줍니다. 다음 방법으로 다시 실행 큐 크기를 확인할 수 있습니다.

• 주 복제본의 sys.dm_hadr_database_replica_states 동적 관리 뷰에서의 redo_queue_size 값입니다.
• 주 복제본의 `Get-AzSqlInstanceLink`에서 InstanceRedoLagReplicationSeconds의 값입니다.

다시 실행 큐 크기가 지속적으로 높은 경우 보조 복제본에서 리소스를 늘리는 것이 좋습니다.

복제 지연 모니터링

복제 지연을 모니터링하면 보조 복제본이 주 복제본과 동기화되는 속도를 확인할 수 있습니다. 큰 불일치는 보조 복제본이 주 복제본을 유지하는 데 문제가 있음을 나타냅니다. 이는 일반적으로 두 인스턴스 간의 링크에서 느린 네트워크 처리량, 두 복제본 간의 리소스 할당 불일치 또는 주 복제본의 과도한 높은 워크로드로 인해 발생합니다.

복제 지연을 모니터링하는 것은 계획된 장애 조치(failover)를 수행할 때 특히 중요하며, 장애 조치(failover)를 실행하기 전에 보조 복제본을 주 복제본과 완전히 동기화해야 합니다. 복제 지연 시간이 높으면 장애 조치(failover)를 완료하는 데 시간이 더 오래 걸릴 수 있으며 경우에 따라 실패할 수도 있습니다.

SQL Server 및 SQL Managed Instance 다음 T-SQL 쿼리를 사용하여 복제본 간의 복제 지연을 모니터링합니다.

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

인증서 회전

SQL Server 데이터베이스 미러링 엔드포인트를 보호하는 데 사용되는 인증서를 수동으로 회전해야 할 수 있습니다. 서비스는 SQL Managed Instance 데이터베이스 미러링 엔드포인트를 보호하는 데 사용되는 인증서를 관리하고 자동으로 회전하므로 수동으로 회전할 필요가 없습니다.

SQL Server

SQL Server 데이터베이스 미러링 엔드포인트를 보호하는 데 사용하는 인증서가 만료됩니다. 인증서가 만료되면 링크가 저하 될 수 있습니다. 이 문제를 방지하려면 만료되기 전에 인증서를 회전 합니다.

다음 Transact-SQL(T-SQL) 명령을 사용하여 현재 인증서의 만료 날짜를 확인합니다.

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

인증서가 만료되거나 이미 만료된 경우 새 인증서를 만든 다음 기존 엔드포인트를 변경하여 현재 인증서를 대체합니다.

새 인증서를 사용하도록 엔드포인트를 구성한 후 만료된 인증서를 삭제 할 수 있습니다.

SQL 관리형 인스턴스

SQL Managed Instance 데이터베이스 미러링 엔드포인트 인증서는 주기적으로 자동으로 회전됩니다. SQL Managed Instance 데이터베이스 미러링 엔드포인트 인증서의 만료 날짜를 모니터링할 필요가 없습니다. SQL Server에서 인증서 체인을 성공적으로 유효성 검사할 수 있는 한.

SQL Server 인증서 체인의 유효성을 검사합니다.

인증서 체인에 문제가 발생하면 링크의 성능이 저하됩니다. 이 문제를 방지하려면 SQL Server 인증서 체인의 유효성을 다시 검사합니다.

다음 시나리오에서는 SQL Server 인증서 체인에 문제가 발생할 수 있습니다.

• SQL Managed Instance 예약된 인증서 회전입니다.
• 데이터베이스 미러링 엔드포인트를 보호하는 데 사용되는 인증서를 삭제하거나 변경하는 등 SQL Server 인증서를 의도하지 않거나 실수로 변경합니다.

먼저 certificate_id 값을 바꾼 다음 SQL Server 다음 쿼리를 실행하여 가져온 MI 엔드포인트 인증서의 <ManagedInstanceFQDN> 확인합니다.

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

다음으로, 이전 쿼리의 결과에서 <certificate_id> 값을 바꾼 다음 SQL Server 다음 쿼리를 실행하여 인증서의 유효성을 검사합니다.

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

응답은 Commands completed successfully. Completion time: ... MI 엔드포인트 인증서의 유효성을 성공적으로 검사했음을 나타냅니다.

오류가 발생할 경우, 가장 신뢰할 수 있는 완화 방법은 먼저 삭제 SQL Managed Instance에서 인증서 공개 키 가져 오기 및 Azure가 신뢰하는 루트 인증 기관 키를 SQL Server로 가져오기 섹션에서 만든 모든 인증서를 제거한 후, 다시 가져와서 SQL Server에 가져오는 것입니다.

시작 추적 플래그 추가

SQL Server 시작 매개 변수로 추가될 때 링크를 통해 데이터 복제 성능을 최적화할 수 있는 두 개의 추적 플래그(-T1800 및 -T9567)가 있습니다. 자세한 내용은 시작 추적 플래그 사용을 참조하세요.

주의해서 동기 커밋 사용

링크의 기본 커밋 모드는 비동기입니다. 커밋 모드를 동기로 변경할 수 있지만 권장되지 않으며 잠재적인 데이터 손실에 대해 보호할 필요는 없습니다.

복제는 계획된 연결 장애 조치 중 장애 조치가 완료될 때까지 일시적으로 synchronous commit 모드로 전환됩니다. 장애 조치(failover) 후 커밋 모드는 장애 조치(failover) 전에 동기 커밋 모드로 명시적으로 설정된 경우에도 비동기 모드로 다시 전환됩니다.

링크에 동기 커밋 모드를 사용하면 특히 복제본 간에 네트워크 대기 시간이 긴 경우 주 복제본의 성능에 영향을 미칠 수 있습니다. 동기 커밋 모드에서 주 복제본의 트랜잭션은 트랜잭션이 주 복제본에서 커밋되기 전에 보조 복제본에서 트랜잭션 로그 레코드가 강화되는지 확인할 때까지 기다려야 합니다. 이 대기 시간은 네트워크 대기 시간이 늘어나면 트랜잭션 응답 시간이 증가하고 주 복제본의 처리량이 감소할 수 있습니다.

관련 콘텐츠

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

• Managed Instance 링크에 대한 환경 준비
• SSMS를 사용하여 SQL Server와 SQL Managed Instance 간의 연결을 구성합니다
• 스크립트를 사용하여 SQL Server SQL Managed Instance 간 연결 구성
• 링크 장애 조치(failover)
• 링크를 사용하여 마이그레이션
• 링크 관련 문제 해결

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

• Managed Instance 링크 개요
• Managed Instance 링크를 사용한 재해 복구
• 링크 유지 관리 모범 사례

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

• SQL Managed Instance를 사용하여 트랜잭션 복제
• LRS(로그 재생 서비스)