Azure SQL Managed Instance를 사용하여 트랜잭션 복제

아티클
06/10/2024

트랜잭션 복제는 Azure SQL Managed Instance 또는 SQL Server 인스턴스의 테이블에서 원격 데이터베이스에 있는 테이블로 데이터를 복제할 수 있도록 하는 Azure SQL Managed Instance 및 SQL Server의 기능입니다. 이 기능을 사용하면 서로 다른 데이터베이스의 여러 테이블을 동기화할 수 있습니다.

개요

트랜잭션 복제를 사용하여 Azure SQL 관리되는 인스턴스에서 만든 변경 내용을 다음으로 푸시할 수 있습니다.

SQL Server 데이터베이스(온-프레미스 또는 Azure Virtual Machine)
Azure SQL Database의 데이터베이스
Azure SQL Managed Instance의 인스턴스 데이터베이스

참고 항목

Azure SQL Managed Instance의 모든 기능을 사용하려면 최신 버전의 SSMS(SQL Server Management Studio) 및 SSDT(SQL Server Data Tools)를 사용해야 합니다.

구성 요소

트랜잭션 복제의 주요 구성 요소는 다음 그림과 같이 게시자, 배포자 및 구독자입니다.

Azure SQL을 사용한 복제의 다이어그램

역할	Azure SQL Database	Azure SQL Managed Instance
게시자	예	예
배포자	예	예
끌어오기 구독자	예	예
밀어넣기 구독자	예	예

게시자는 배포자에게 업데이트를 전송하여 일부 테이블(문서)에 대해 변경된 내용을 게시합니다. 게시자는 Azure SQL 관리되는 인스턴스 또는 SQL Server 인스턴스일 수 있습니다.

배포자는 게시자에서 문서의 변경 내용을 수집하고 구독자에게 배포합니다. 배포자는 Azure SQL 관리되는 인스턴스 또는 SQL Server 인스턴스(게시자 버전보다 같거나 높은 모든 버전)일 수 있습니다.

구독자는 게시자에 대한 변경 내용을 받습니다. SQL Server 인스턴스와 Azure SQL 관리되는 인스턴스 모두 밀어넣기 및 끌어오기 구독자일 수 있지만 배포자가 Azure SQL 관리되는 인스턴스이며 구독자가 아닌 경우에는 끌어오기 구독이 지원되지 않습니다. Azure SQL Database의 데이터베이스는 밀어넣기 구독자만 될 수 있습니다.

Azure SQL Managed Instance는 다음 버전의 SQL Server에서 구독자가 되는 것을 지원할 수 있습니다.

SQL Server 2016 이상 버전
SQL Server 2014 RTM CU10(12.0.4427.24) 또는 SP1 CU3(12.0.2556.4)
SQL Server 2012 SP2 CU8(11.0.5634.1) 또는 SP3(11.0.6020.0) 또는 SP4(11.0.7001.0)

참고 항목

Azure에서 개체 게시를 지원하지 않는 다른 버전의 SQL Server에서는 데이터 다시 게시 방법을 사용하여 데이터를 최신 버전의 SQL Server로 이동할 수 있습니다.

이전 버전을 사용하여 복제를 구성하려고 하면 오류 MSSQL_REPL20084(프로세스가 구독자에 연결할 수 없습니다.) 및 MSSQL_REPL40532(로그인에서 요청한 서버 <이름>을 열 수 없습니다. 로그인이 실패했습니다.)가 발생할 수 있습니다.

복제의 유형

다음과 같은 여러 복제 유형이 있습니다.

복제	Azure SQL Database	Azure SQL Managed Instance
표준 트랜잭션	예(구독자로)	예
스냅샷	예(구독자로)	예
병합 복제	예	예
피어 투 피어	아니요	예
양방향	예	예
업데이트할 수 있는 구독	예	예

지원 가능성 매트릭스

Azure SQL Managed Instance에 대한 트랜잭션 복제 지원 가능성 매트릭스는 SQL Server 대한 것과 동일합니다.

게시자	배포자	구독자
SQL Server 2022	SQL Server 2022	SQL Server 2022 SQL Server 2019 SQL Server 2017
SQL Server 2019	SQL Server 2022 SQL Server 2019	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016
SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014
SQL Server 2016	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016	SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012
SQL Server 2014	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014	SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2012	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012	SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2008 R2 SQL Server 2008	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008	SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008

사용 시기

트랜잭션 복제는 다음과 같은 시나리오에서 유용합니다.

데이터베이스의 하나 이상의 테이블에서 변경한 내용을 게시하고 해당 변경 내용에 대해 구독한 SQL Server 인스턴스 또는 Azure SQL Database에 있는 하나 이상의 데이터베이스에 배포합니다.
여러 개의 분산된 데이터베이스를 동기화된 상태로 유지합니다.
변경 내용을 지속적으로 게시하여 SQL Server 인스턴스 또는 Azure SQL Managed Instance의 데이터베이스를 다른 데이터베이스로 마이그레이션합니다.

트랜잭션 복제와 데이터 동기화 비교

범주	데이터 동기화	트랜잭션 복제
장점	- 활성-활성 지원 - 온-프레미스 및 Azure SQL Database 간 양방향	- 낮은 대기 시간 - 트랜잭션 일관성 - 마이그레이션 후 기존 토폴로지 다시 사용
단점	- 트랜잭션 일관성 부족 - 성능에 더 많은 영향을 미침	- Azure SQL Database에서 게시할 수 없음 - 높은 유지 관리 비용

일반 구성

일반적으로 게시자와 배포자는 모두 클라우드 또는 온-프레미스에 있어야 합니다. 현재 지원되는 구성은 다음과 같습니다.

SQL Managed Instance에서 로컬 배포자로 게시자

게시자 및 배포자로서의 단일 인스턴스.

게시자 및 배포자는 단일 SQL 관리되는 인스턴스 내에서 구성되고, 다른 SQL 관리되는 인스턴스, SQL Database 또는 SQL Server 인스턴스로 변경 내용을 배포하고 있습니다.

SQL Managed Instance에서 원격 배포자로 게시자

이 구성에서는 하나의 SQL 관리되는 인스턴스가 또 다른 SQL 관리되는 인스턴스에 배치된 배포자에게 변경 내용을 게시합니다. 이 배포자는 여러 원본 SQL 관리되는 인스턴스를 제공하고 Azure SQL Database, Azure SQL Managed Instance 또는 SQL Server에 있는 하나 또는 여러 대상으로 변경 내용을 배포할 수 있습니다.

게시자 및 배포자에 대한 별도 인스턴스.

게시자 및 배포자는 두 개의 관리되는 인스턴스에서 구성됩니다. 이 구성을 사용하는 몇 가지 제약 조건이 있습니다.

두 관리되는 인스턴스가 동일한 vNet에 있습니다.
두 관리되는 인스턴스는 동일한 위치에 있습니다.

원격 구독자로 온-프레미스 게시자/배포자

구독자로 Azure SQL Database.

이 구성에서 Azure SQL Database 또는 Azure SQL Managed Instance의 데이터베이스는 구독자입니다. 이 구성은 온-프레미스에서 Azure로의 마이그레이션을 지원합니다. 구독자가 Azure SQL Database의 데이터베이스인 경우 밀어넣기 모드에 있어야 합니다.

요구 사항

복제 참가자 간 연결에 SQL 인증을 사용합니다.
복제에 사용되는 작업 디렉터리에 대해 Azure Storage 계정 공유를 사용합니다.
Azure 파일 공유에 액세스하려면 서브넷 보안 규칙에서 TCP 아웃바운드 포트 445를 엽니다.
SQL 관리되는 인스턴스가 게시자/배포자이고 구독자가 아닌 경우 TCP 아웃바운드 포트 1433을 엽니다. virtualnetwork에서 internet으로 포트 1433 대상 서비스 태그의 allow_linkedserver_outbound에 대한 SQL 관리되는 인스턴스 NSG 아웃바운드 보안 규칙을 변경해야 할 수도 있습니다.
클라우드 또는 온-프레미스 둘 다에 게시자와 배포자를 둘 다 저장합니다.
가상 네트워크가 서로 다른 경우 복제 참가자의 가상 네트워크 간에 VPN 피어링을 구성합니다.

참고

배포자가 Azure SQL Managed Instance 데이터베이스이고 구독자가 온-프레미스인 경우 아웃바운드 NSG(네트워크 보안 그룹) 포트 445가 차단되면 Azure Storage 파일에 연결할 때 오류 53이 발생할 수 있습니다. 이 문제를 해결하려면 vNet NSG를 업데이트합니다.

보안

로그인 `replAgentUser`

트랜잭션 복제를 위해 SQL Managed Instance에는 이름 replAgentUser이 있는 미리 생성된 로그인이 있습니다. 이 로그인은 sysadmin 서버 역할의 구성원이며 트랜잭션 복제 설정에 참여하는 SQL Managed Instance에 연결해야 하는 복제 에이전트에서 사용됩니다.

트랜잭션 복제를 사용하지 않는 경우 replAgentUser 로그인을 사용하지 않도록 설정할 수 있습니다. 트랜잭션 복제 사용을 시작하기로 결정한 경우 나중에 다시 사용하도록 설정할 수 있습니다.

제한 사항

트랜잭션 복제에는 Azure SQL Managed Instance와 관련된 몇 가지 제한 사항이 있습니다. 이 섹션에서는 이러한 제한 사항에 대해 자세히 알아봅니다.

Azure Storage 계정에서 스냅샷 파일이 삭제되지 않음

Azure SQL Managed Instance는 트랜잭션 복제에 사용되는 스냅샷 파일에 대해 사용자가 구성한 Azure Storage 계정을 사용합니다. 온-프레미스 환경의 SQL Server와 달리 Azure SQL Managed Instance는 Azure Storage 계정에서 스냅샷 파일을 삭제하지 않습니다. 파일이 더 이상 필요하지 않으면 파일을 삭제해야 합니다. 이 작업은 Azure Portal, Microsoft Azure Storage Explorer의 Azure Storage 인터페이스 또는 명령줄 클라이언트(Azure PowerShell 또는 CLI) 또는 Azure Storage 관리 REST API를 통해 수행할 수 있습니다.

다음은 파일을 삭제하는 방법과 빈 폴더를 삭제하는 방법의 예입니다.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

지속적으로 실행되는 배포 에이전트 수

지속적으로 실행되도록 구성된 배포 에이전트 수는 Azure SQL Managed Instance에서 30개로 제한됩니다. 더 많은 배포 에이전트를 만들려면 요청 시 또는 정의된 일정으로 실행해야 합니다. 일정은 10초마다(또는 그 이상) 매일 빈도 및 발생으로 정의할 수 있으므로 연속되지 않더라도 몇 초밖에 되지 않는 대기 시간을 도입하는 배포자를 사용할 수 있습니다. 많은 수의 배포자를 필요로 하는 경우 연속 구성이 아닌 예약된 배포자를 사용하는 것이 좋습니다.

장애 조치(failover) 그룹 사용

장애 조치(failover) 그룹에 있는 인스턴스에서 트랜잭션 복제 사용이 지원됩니다. 그러나 장애 조치(failover) 그룹에 SQL Managed Instance를 추가하기 전에 복제를 구성하면 장애 조치(failover) 그룹을 생성하기 시작하면 복제가 일시 중지되고 복제 모니터는 Replicated transactions are waiting for the next log backup or for mirroring partner to catch up 상태를 표시합니다. 장애 조치(failover) 그룹이 생성되면 복제가 다시 시작됩니다.

게시자 또는 배포자 SQL 관리되는 인스턴스가 장애 조치(failover) 그룹에 있는 경우 장애 조치(failover)가 발생한 후 SQL 관리되는 인스턴스 관리자가 모든 게시를 이전 주 데이터베이스에서 정리하고 새로운 주 데이터베이스에서 다시 구성해야 합니다. 이 시나리오에는 다음과 같은 작업이 필요합니다.

데이터베이스에서 실행 중인 모든 복제 작업을 중지합니다(있는 경우).
게시자 데이터베이스에서 다음 스크립트를 실행하여 게시자에서 구독 메타데이터를 삭제합니다. <name of publication> 및 <name of subscriber> 값을 바꿉니다.
```
EXEC sp_dropsubscription @publication = '<name of publication>',
    @article = 'all',
    @subscriber = '<name of subscriber>'
```
구독자에서 구독 메타데이터를 삭제합니다. 구독자 SQL 관리되는 인스턴스의 구독 데이터베이스에서 다음 스크립트를 실행합니다. <full DNS of publisher> 값을 바꿉니다. 예: example.ac2d23028af5.database.windows.net
```
EXEC sp_subscription_cleanup
   @publisher = N'<full DNS of publisher>',
   @publisher_db = N'<publisher database>',
   @publication = N'<name of publication>';
```
게시된 데이터베이스에서 다음 스크립트를 실행하여 게시자에서 모든 복제 개체를 강제로 삭제합니다.
```
EXEC sp_removedbreplication;
```
원래 주 SQL 관리되는 인스턴스에서 이전 배포자를 강제로 삭제합니다(배포자를 포함하는 데 사용된 이전 주로 장애 복구하는 경우). 이전 배포자 SQL 관리되는 인스턴스의 master 데이터베이스에서 다음 스크립트를 실행합니다.
```
EXEC sp_dropdistributor 1, 1;
```

구독자 SQL 관리되는 인스턴스가 장애 조치(failover) 그룹에 있는 경우, 구독자 SQL 관리되는 인스턴스의 장애 조치(failover) 그룹 수신기 엔드포인트에 연결하도록 게시를 구성해야 합니다. 장애 조치(failover) 시 SQL 관리되는 인스턴스 관리자의 후속 작업은 발생한 장애 조치(failover) 유형에 따라 달라집니다.

데이터 손실이 없는 장애 조치(failover)의 경우 장애 조치(failover) 후에도 복제가 계속 작동합니다.
데이터 손실이 있는 장애 조치(failover)의 경우 복제도 작동합니다. 손실된 변경 내용을 다시 복제합니다.
데이터 손실이 있는 장애 조치(failover)의 경우 데이터 손실이 배포 데이터베이스 보존 기간을 벗어나는 경우 SQL 관리되는 인스턴스 관리자가 구독 데이터베이스를 다시 시작해야 합니다.

일반적인 문제 해결

트랜잭션 로그 및 트랜잭션 복제

일반적인 상황에서는 데이터베이스 내의 데이터 변경 내용을 기록하는 데 트랜잭션 로그가 사용됩니다. 변경 내용은 트랜잭션 로그에 기록되며 이로 인해 로그 스토리지 사용량이 증가합니다. 트랜잭션 로그의 안전한 잘림을 허용하는 자동 프로세스도 있으며 이 프로세스는 로그에 사용되는 스토리지 공간을 줄입니다. 트랜잭션 복제에 대한 게시가 구성된 경우 로그 판독기 작업에서 로그의 변경 내용을 처리할 때까지 트랜잭션 로그 잘림이 방지됩니다. 경우에 따라 트랜잭션 로그 처리가 효과적으로 차단되고 해당 상태가 트랜잭션 로그용으로 예약된 전체 스토리지를 채울 수 있습니다. 트랜잭션 로그를 위한 여유 공간이 없고 트랜잭션 로그가 증가할 공간이 더 이상 없으면 전체 트랜잭션 로그가 있습니다. 이 상태에서 데이터베이스는 더 이상 쓰기 워크로드를 처리할 수 없으며 사실상 읽기 전용 데이터베이스가 됩니다.

비활성화된 로그 판독기 에이전트

경우에 따라 트랜잭션 복제 게시가 데이터베이스에 대해 구성되지만 로그 판독기 에이전트가 실행되도록 구성되지 않습니다. 이 경우 변경 내용이 트랜잭션 로그에 누적되고 처리되지 않습니다. 이로 인해 트랜잭션 로그가 지속적으로 증가하며 결국 트랜잭션 로그가 가득 차게 됩니다. 사용자는 로그 판독기 작업이 존재하고 활성 상태인지 확인해야 합니다. 필요하지 않은 경우 트랜잭션 복제를 사용하지 않도록 설정하는 것이 대안입니다.

로그 판독기 에이전트 쿼리 시간 제한

반복된 쿼리 시간 제한으로 인해 로그 판독기 작업이 효과적으로 진행되지 않는 경우가 있습니다. 쿼리 시간 제한을 해결하는 방법은 로그 판독기 에이전트 작업에 대한 쿼리 시간 제한 설정을 늘리는 것입니다.

SSMS를 사용하여 로그 판독기 작업에 대한 쿼리 시간 제한을 늘릴 수 있습니다. 개체 탐색기의 SQL Server 에이전트 아래에서 수정하려는 작업을 찾습니다. 먼저 중지한 다음, 해당 속성을 엽니다. step 2를 찾아서 편집합니다. 명령 값을 -QueryTimeout <timeout_in_seconds>와 함께 추가합니다. 쿼리 시간 제한 값의 경우 21600 이상을 시도합니다. 마지막으로 작업을 다시 시작합니다.

로그 스토리지 크기가 최대 한도인 2TB에 도달했습니다.

트랜잭션 로그 스토리지 크기가 최대 제한(2TB)에 도달하면 실제로 로그는 그 이상으로 증가할 수 없습니다. 이 경우 사용 가능한 유일한 완화 방법은 트랜잭션 로그가 잘릴 수 있도록 복제될 모든 트랜잭션을 처리된 것으로 표시하는 것입니다. 이는 로그에 남아 있는 트랜잭션이 복제되지 않으며 복제를 다시 초기화해야 함을 의미합니다.

참고 항목

완화를 수행한 후 복제를 다시 초기화해야 합니다. 이는 전체 데이터 집합을 다시 복제하는 것을 의미합니다. 이는 데이터 작업의 크기이며 복제되어야 하는 데이터의 양에 따라 장기 실행될 수 있습니다.

완화를 수행하려면 먼저 배포자에서 로그 판독기 에이전트를 중지해야 합니다. 그런 다음, 게시자 데이터베이스에서 reset 플래그가 1로 설정된 sp_repldone 저장 프로시저를 실행하여 트랜잭션 로그 잘림을 허용해야 합니다. 이 명령은 이 EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1과 같아야 합니다. 이 후에는 복제를 다시 초기화해야 합니다.

다음 단계

트랜잭션 복제를 구성하는 방법에 대한 자세한 내용은 다음 자습서를 참조하세요.

SQL Managed Instance 게시자와 구독자 간의 복제 구성
SQL Managed Instance 구독자, SQL Managed Instance 배포자 및 SQL Server 구독자 간 복제 구성
게시 만들기
서버 이름을 구독자(예: N'azuresqldbdns.database.windows.net)로, Azure SQL Database의 데이터베이스 이름을 대상 데이터베이스(예: Adventureworks)로 사용하여 밀어넣기 구독을 만듭니다.

다음을 통해 공유

Azure SQL Managed Instance를 사용하여 트랜잭션 복제