SQL Server 복제: DBA를 위한 완벽 가이드 [2026]

SQL Server 복제는 한 데이터베이스에서 다른 데이터베이스로 데이터와 데이터베이스 객체를 복사하고 배포한 다음, 데이터베이스 간 동기화를 통해 일관성을 유지하는 기술 집합입니다. 이 기능을 통해 여러 서버와 위치에 데이터 복사본을 생성하고 유지 관리하여 데이터 가용성과 안정성을 보장할 수 있습니다.

1.2 복제의 목적 및 이점

SQL Server 데이터 복제는 여러 가지 중요한 비즈니스 요구 사항을 충족하고 데이터베이스 관리 및 데이터 배포에 상당한 이점을 제공합니다.

데이터 분산 방식 (위치별): 데이터 복제를 통해 지역 사무소 또는 전 세계 여러 지점 간에 데이터를 공유할 수 있으므로 필요한 데이터에 대한 로컬 액세스를 보장하여 운영 효율성을 향상시킬 수 있습니다. 이는 네트워크 지연 시간을 줄이고 지리적으로 분산된 사용자에게 더 나은 성능을 제공합니다.
고 가용성 및 재해 복구: 복제는 여러 서버에 중요 데이터의 복제본을 유지함으로써 하드웨어 오류 및 재해로부터 데이터를 보호하는 이중화 기능을 제공합니다. 기본 서버에 장애가 발생할 경우 복제본이 백업 역할을 하여 다운타임과 데이터 손실을 최소화할 수 있습니다.
부하 분산 및 확장성: 복제는 읽기 작업을 여러 서버에 분산시켜 특정 서버가 병목 현상을 일으키는 것을 방지합니다. 이러한 접근 방식은 시스템 성능을 향상시키고 데이터 및 사용자 수요 증가에 따라 인프라를 수평적으로 확장할 수 있도록 합니다.
실시간 보고 및 분석: 보고 및 분석 쿼리를 복제된 서버로 분산시키면 프로덕션 데이터베이스의 부하가 줄어듭니다. 사용자는 운영 시스템에 영향을 주지 않고 거의 실시간 데이터에 대해 복잡한 분석 쿼리를 실행할 수 있으므로 성능과 데이터 최신성을 모두 보장할 수 있습니다.
데이터 통합 및 통합: 데이터 복제는 다양한 소스의 데이터를 하나의 통합된 보기로 병합하는 것을 용이하게 합니다. 이는 특히 여러 지사를 보유한 조직이 본사에서 데이터를 통합하거나 분산된 운영 시스템에서 중앙 집중식 데이터 웨어하우스를 구축해야 할 때 유용합니다.

2. SQL Server 복제 아키텍처 및 구성 요소

SQL Server 복제 아키텍처는 데이터베이스 인프라 전체에 데이터를 분산하고 동기화하기 위해 함께 작동하는 여러 상호 연결된 구성 요소로 이루어져 있습니다. 이 섹션에서는 게시자, 배포자, 구독자, 게시, 기사, 구독 및 이러한 구성 요소 간의 데이터 흐름을 조정하는 에이전트를 포함한 핵심 구성 요소를 살펴봅니다.

제작사 : 출판사란 SQL Server 복제할 데이터가 포함된 하나 이상의 데이터베이스를 호스팅하는 인스턴스입니다. 이는 복제 토폴로지에서 권한 있는 소스 역할을 합니다.
유통 : 유통업체란 SQL Server 게시자와 구독자 간의 데이터 흐름을 관리하는 인스턴스입니다. 배포자 인스턴스는 복제 메타데이터와 트랜잭션을 저장하는 배포 데이터베이스를 호스팅합니다.
구독자: 구독자는 SQL Server 게시자로부터 복제된 데이터를 수신하고 저장하는 인스턴스입니다. 하나의 구독자 인스턴스는 여러 구독자 데이터베이스를 호스팅할 수 있으며, 각 데이터베이스는 서로 다른 게시자로부터 데이터를 수신합니다.
출판 : 출판물은 복제될 데이터와 구독자에게 배포될 방법을 정의합니다. 관련 논문들을 그룹화하고, 포함된 모든 객체에 적용되는 복제 방법론을 수립합니다.
기사 : 아티클은 복제의 기본 구성 요소로서, 구독자에게 배포될 개별 데이터베이스 객체를 나타냅니다.
구독 : 구독은 발행물과 구독자 간의 관계를 설정하며, 데이터가 대상 데이터베이스로 전달되는 방법과 시기를 정의합니다.
자치령 대표: 에이전트는 복제 구성 요소 간에 데이터를 이동하고 동기화하는 실제 작업을 수행하는 특수 프로세스입니다.

3. 종류 SQL Server 복제

SQL Server 여러 가지 복제 유형을 제공하며, 각 유형은 특정 데이터 배포 시나리오 및 비즈니스 요구 사항에 맞게 설계되었습니다. 환경에 적합한 접근 방식을 선택하려면 각 유형의 특성, 장점 및 한계를 이해하는 것이 중요합니다.

3.1 스냅샷 복제

스냅샷 복제는 게시할 데이터의 특정 시점 스냅샷을 생성한 다음, 해당 스냅샷의 정확한 전체 복사본을 구독자에게 배포합니다. 다음 스냅샷이 생성될 때까지 이후의 변경 사항은 모니터링하지 않습니다. 스냅샷 복제는 가장 간단한 형태의 복제 방식으로, 데이터 변경 빈도가 낮거나 데이터가 약간 오래된 상태로 유지되어도 괜찮은 시나리오에 적합합니다.

일반적인 사용 사례로는 주기적으로 업데이트되는 가격표나 환율과 같은 참조 데이터를 배포하거나, 데이터 웨어하우스의 초기 데이터 세트를 제공하거나, 개별 변경 사항을 추적하는 것보다 전체 데이터를 새로 고치는 것이 더 나은 시나리오 등이 있습니다. 예를 들어, 기업은 스냅샷 복제를 사용하여 업데이트된 제품 카탈로그를 매일 한 번씩 지사에 배포할 수 있습니다.

스냅샷 복제의 주요 장점은 단순성, 낮은 유지 관리 요구 사항, 기본 키 없이 데이터를 복제할 수 있다는 점입니다. 그러나 스냅샷 생성 시 테이블 잠금으로 인한 시스템 영향이 크고, 업데이트 간 지연 시간이 길며, 대규모 데이터 세트나 자주 변경되는 데이터에는 비효율적이라는 상당한 단점도 있습니다. 또한, 구독자 측에서 변경한 내용은 다음 스냅샷이 적용될 때 손실됩니다.

3.2 트랜잭션 복제

트랜잭션 복제는 개별 트랜잭션이 발생하는 즉시 복제하여 게시자의 변경 사항을 구독자에게 거의 실시간으로 전달합니다. 먼저 기준선을 설정하기 위한 초기 스냅샷을 생성한 다음, 트랜잭션 로그를 지속적으로 모니터링하여 게시된 아티클의 변경 사항을 감지하고 이를 구독자에게 점진적으로 전달합니다.

트랜잭션 복제는 높은 처리량과 낮은 지연 시간이 요구되는 서버 간 시나리오에 이상적입니다. 일반적인 사용 사례로는 읽기 작업을 구독자 서버로 분산하여 확장성과 가용성을 향상시키는 것, 거의 실시간 데이터를 사용하여 데이터 웨어하우징 및 보고를 지원하는 것, 여러 사이트의 데이터를 중앙 위치로 통합하는 것, 배치 처리를 전용 서버로 분산하는 것 등이 있습니다. 예를 들어, 전자상거래 플랫폼은 트랜잭션 복제를 사용하여 지역 데이터베이스 전반에 걸쳐 동기화된 재고 데이터를 유지할 수 있습니다.

트랜잭션 복제의 장점으로는 낮은 데이터 전송 지연 시간, 대용량 트랜잭션 처리량, 그리고 구독자 측에서 복제되지 않은 수정 작업을 수행할 수 있다는 점이 있습니다. 단점으로는 스냅샷 복제에 비해 복잡성이 높고, 복제 테이블에 기본 키가 필요하며, 구독자 측에서 기본 키 위반과 같은 충돌이 발생할 경우 복제가 중단될 가능성이 있다는 점이 있습니다.

3.3 병합 복제

병합 복제는 구독자가 오프라인 또는 간헐적인 연결 환경에서 작업한 후 연결이 가능해지면 변경 사항을 동기화해야 하는 환경을 위해 특별히 설계되었습니다. 이 복제 유형을 사용하면 게시자와 구독자 모두에서 데이터를 독립적으로 변경할 수 있으며, 트리거와 메타데이터 테이블을 사용하여 변경 사항을 추적하고 동기화 중에 수정 사항을 자동으로 병합할 수 있습니다.

병합 복제는 자율적인 변경이 발생하는 모바일 애플리케이션 및 분산 서버 환경을 위해 설계되었습니다. 사용 사례로는 모바일 사용자가 오프라인으로 작업하고 나중에 동기화하는 영업 자동화 시스템, 독립적으로 운영되고 주기적으로 데이터를 통합하는 POS 시스템, 여러 사이트에서 공유 데이터를 업데이트해야 하는 분산 애플리케이션 등이 있습니다. 예를 들어, 소매 체인점에서는 각 매장이 중앙 창고 시스템과 동기화하면서 지역 재고를 관리할 수 있도록 병합 복제를 사용할 수 있습니다.

병합 복제의 장점으로는 변경이 가능한 자율 구독자 지원, 간헐적인 네트워크 연결에 대한 내성, 유연한 충돌 해결 기능 등이 있습니다. 단점으로는 설정 및 유지 관리의 복잡성 증가, 메타데이터 및 트리거 추적으로 인한 성능 저하, 테이블에 고유 식별자 열 추가, 관리 및 해결이 필요한 충돌 발생 가능성 등이 있습니다.

3.4 피어 투 피어 복제

피어 투 피어 복제는 트랜잭션 복제를 기반으로 하며, 여러 서버 인스턴스(3개 이상의 노드)가 동등한 피어 역할을 수행할 수 있도록 합니다. 각 노드는 게시자와 구독자 역할을 동시에 수행할 수 있습니다. 이러한 토폴로지에서 모든 노드는 동일한 데이터 복사본을 유지하고 읽기 및 쓰기 작업을 모두 처리할 수 있으므로 진정한 분산형 멀티 마스터 환경을 제공합니다.

피어 투 피어 복제는 읽기 작업의 확장성과 고가용성이 요구되는 애플리케이션에 적합합니다. 사용 사례로는 데이터 일관성을 유지하면서 여러 노드에 카탈로그 쿼리를 분산하는 웹 애플리케이션, 노드를 개별적으로 오프라인으로 전환하여 다운타임 없이 유지 보수 또는 업그레이드가 필요한 시나리오, 그리고 여러 지역에 데이터 센터를 둔 글로벌 애플리케이션 등이 있습니다. 예를 들어, 전 세계 소프트웨어 지원 조직은 서로 다른 시간대에 있는 사무실 간에 피어 투 피어 복제를 사용하여 각 지점에서 최신 데이터에 로컬로 액세스할 수 있도록 할 수 있습니다.

피어 투 피어 복제의 장점으로는 스케일 아웃을 통한 읽기 성능 향상, 여러 활성 노드를 통한 높은 가용성, 거의 실시간에 가까운 데이터 일관성 등이 있습니다. 단점으로는 엔터프라이즈 에디션 필요성, 다중 노드 토폴로지 관리의 복잡성, 모든 노드에서 동일한 스키마 및 데이터 필요성, 쓰기 작업이 적절하게 파티셔닝되지 않을 경우 발생할 수 있는 충돌 가능성 등이 있습니다.

3.5 양방향 복제

양방향 복제는 두 서버 환경, 특히 두 서버 간에 변경 사항을 교환해야 하는 환경을 위해 특별히 설계된 트랜잭션 복제 토폴로지입니다. 각 서버는 상대 서버에서 데이터를 게시하고 동일한 데이터를 구독하여 간단한 양방향 동기화 흐름을 생성합니다. 피어 투 피어 복제도 두 노드를 지원할 수 있지만, 양방향 복제는 이러한 특정 시나리오에서 향상된 성능을 제공합니다.

양방향 복제는 고가용성을 위한 액티브-액티브 구성이나 각 사이트에서 로컬 쓰기 액세스가 필요한 지리적으로 분산된 애플리케이션과 같이 동기화된 데이터를 가진 두 개의 활성 서버가 필요한 시나리오에 적합합니다. 이러한 토폴로지를 구현하려면 데이터 업데이트를 분할하고 충돌을 방지하기 위해 애플리케이션을 신중하게 설계해야 합니다.

장점으로는 두 서버 환경에서 최적화된 성능, 피어 투 피어 복제에 비해 간소화된 구성, 거의 실시간에 가까운 동기화, 병합 복제보다 낮은 오버헤드 등이 있습니다. 단점으로는 정확히 두 대의 서버만 사용할 수 있다는 점, 내장된 충돌 해결 기능이 없어 애플리케이션 설계에 신중을 기해야 한다는 점, 그리고 충돌 방지를 위해 적절한 파티셔닝 전략이 필요하다는 점 등이 있습니다.

3.6 업데이트 가능한 구독

업데이트 가능한 구독은 트랜잭션 복제를 확장하여 구독자가 복제된 데이터를 수시로 변경하고, 변경 사항이 게시자와 다른 구독자에게 전파되도록 합니다. 빈번한 양방향 업데이트를 위해 설계된 병합 복제 또는 피어 투 피어 토폴로지와 달리, 업데이트 가능한 구독은 기본 데이터 흐름이 단방향(게시자에서 구독자로)이지만 구독자가 때때로 수정 또는 업데이트를 해야 하는 시나리오에 적합합니다.

업데이트 가능한 구독은 대부분의 업데이트가 게시자 측에서 이루어지지만 구독자 측에서도 가끔 업데이트가 필요한 시나리오에 적합합니다. 예를 들어, 주로 데이터를 읽지만 현지에서 수정이나 업데이트를 해야 하는 현장 사무소가 이에 해당합니다. 데이터 일관성을 유지하고 충돌을 최소화하려면 토폴로지를 신중하게 계획해야 합니다.

주요 장점으로는 트랜잭션 복제의 성능 특성을 유지하면서 구독자 측에서 제한적인 쓰기 작업을 허용할 수 있다는 점이 있습니다. 단점으로는 복잡성 증가, 해결이 필요한 충돌 가능성, 즉시 업데이트 모드에서 2단계 커밋 프로토콜로 인한 성능 오버헤드, 그리고 모든 복제 테이블에 기본 키가 있어야 한다는 요구 사항 등이 있습니다.

3.7 다양한 복제 유형 비교

복제 유형	업데이트 시간	출판사 수	방향	시나리오 사용
스냅 사진	시점	1	한 방향 (게시자 → 구독자)	참고 데이터(가격표, 환율)가 자주 변경되지 않음
거래상의	거의 실시간	1	한 방향 (게시자 → 구독자)	높은 처리량 시나리오(전자상거래 재고 관리, 데이터 웨어하우징, 보고)
병합	주기적 (연결 시)	1	양방향(게시자 ↔ 구독자)	모바일 애플리케이션, 오프라인 작업자(영업 자동화, 현장 서비스)
피어 - 투 - 피어	거의 실시간	여러 개 (3개 이상)	양방향(모든 노드)	글로벌 멀티 데이터센터 구축(전 세계 지사에서 로컬 읽기/쓰기 액세스 가능)
양방향	거의 실시간	2	양방향(두 서버 모두)	두 개의 데이터센터를 사용하는 액티브-액티브 구성(듀얼 사이트 고가용성)
업데이트 가능한 구독	거의 실시간	1	주로 단방향으로 진행됩니다 (간혹 역방향 업데이트가 있습니다).	주로 읽기 작업을 수행하지만 때때로 업데이트(지역 수정)를 하는 지점

4. 설정 SQL Server 복제

4.1 필수 조건 및 요구 사항

4.1.1 소프트웨어 요구사항

SQL Server 복제에는 호환성이 필요합니다. SQL Server 토폴로지의 모든 참여자 간에 버전이 일치해야 합니다. 배포자 버전은 게시자 버전과 같거나 높아야 하며, 구독자 버전은 게시자 버전과 두 버전 이내여야 합니다. 예를 들어, SQL Server 2016년 발행사는 복제할 수 있습니다. SQL Server 2012년, 2014년, 2016년, 2017년 또는 2019년 구독자.

4.1.2 권한 요구 사항

복제 구성을 위해서는 각 수준별로 특정 권한이 필요합니다. sysadmin 고정 서버 역할의 구성원은 모든 복제 구성 작업을 수행할 수 있습니다. 보다 세부적인 권한을 위해서는 게시자 및 구독자 데이터베이스에 대해 db_owner 데이터베이스 역할의 구성원이어야 합니다.

4.2 1단계: 배포 구성

배포 설정을 구성하는 것이 설정의 첫 번째 단계입니다. SQL Server 복제.

배포를 구성하려면 다음을 사용하세요. SQL Server Management Studio :

에 연결 SQL Server 인스턴스 SQL Server 매니지먼트 스튜디오.
개체 탐색기에서 마우스 오른쪽 버튼을 클릭합니다. 복제 폴더 및 선택 배포 구성.
배포 구성 마법사에서 다음을 클릭합니다. 다음 환영 페이지에서.
에 살수 장치 페이지에서 토폴로지 요구 사항에 따라 다음 옵션 중 하나를 선택하십시오.
- 지역 대리점: "ServerName이 자체 배포자 역할을 합니다"를 선택하십시오. SQL Server 게시자와 배포자가 동일한 인스턴스(현재 인스턴스)에서 실행되도록 하려면 "배포 데이터베이스 및 로그를 생성합니다" 옵션을 선택하십시오. 이 구성은 설정이 더 간단하며 소규모 환경이나 게시자와 배포자 간의 네트워크 지연으로 인해 문제가 발생할 수 있는 경우에 적합합니다.
- 원격 유통업체"다음 서버를 배포자로 사용"을 선택하고 클릭하십시오. 추가 배포 처리를 별도의 인스턴스로 오프로드하려면 원격 배포 서버를 지정하십시오. 이 구성은 복제량이 많을 때 워크로드를 여러 서버에 분산하여 성능을 향상시킵니다. 원격 배포 서버 이름과 게시자가 배포 서버에 연결하는 데 사용할 암호를 제공해야 합니다.
다음 스냅샷 폴더 위치를 지정하려면 로컬 경로 대신 UNC 경로(예: \\서버 이름\공유 폴더)를 사용하여 네트워크를 통한 접근성을 확보하십시오.
에 배포 데이터베이스 이 페이지에서 기본 배포 데이터베이스 이름(일반적으로 "distribution")을 수락하거나 사용자 지정 이름을 지정한 다음 데이터 및 로그 파일 위치를 구성합니다.
에 퍼블리셔 이 페이지에서 현재 서버가 게시자로 활성화되어 있는지 확인하십시오. 현재 서버를 배포자로 구성한 경우, 이 배포자를 사용할 추가 게시자를 추가할 수 있습니다.
마법사의 동작을 검토하고 클릭하세요. 마감재 배포를 구성합니다.

4.3 2단계: 출판물 생성

배포 설정을 완료한 후 다음 단계는 구독자에게 복제할 데이터 객체를 정의하는 게시를 생성하는 것입니다.

출판물을 만들려면 다음을 사용하세요 SQL Server Management Studio :

개체 탐색기에서 다음을 확장합니다. 복제 폴더에 있습니다.
마우스 오른쪽 단추로 클릭 지역 출판물 선택 새로운 출판물.
새 출판 마법사가 시작됩니다. 클릭하세요. 다음 환영 페이지에서.
게시할 데이터베이스를 선택하세요. 출판물 데이터베이스 이 페이지는 선택한 데이터베이스에 게시를 자동으로 활성화합니다.
에 출판 유형 해당 페이지에서 복제 유형을 선택하십시오. 스냅샷 게시, 거래 출판, P2P 출판및 출판물 병합.
에 기사 페이지, 확장 테이블 노드를 선택하고 기사로 포함할 테이블을 선택합니다.
선택적으로 확장 가능 저장 프로 시저, 조회수또는 추가 항목을 포함하기 위한 다른 객체 유형.
기사 속성 필터링 또는 기타 기사별 설정을 구성합니다.
에 테이블 행 필터링 페이지에 필요한 경우 행 필터를 추가하세요.
에 스냅샷 에이전트 이 페이지에서 스냅샷을 생성할 시점을 선택하세요. 즉시, 특정 시간 또는 예약된 시간에 생성할 수 있습니다.
에 에이전트 보안 페이지에서 스냅샷 에이전트에 대한 보안 컨텍스트를 지정합니다.
에 마법사의 행동 페이지, 선택 출판물을 생성하세요.
출판물 이름을 입력하고 클릭하세요. 마감재 .

4.4 3단계: 구독 생성

출판물을 생성한 후 다음 단계는 출판물을 구독자 데이터베이스에 연결하는 구독을 생성하는 것입니다.

구독은 푸시 구독(배포자가 관리) 또는 풀 구독(구독자가 관리)일 수 있습니다. 주요 차이점은 구독을 생성하는 위치와 선택하는 에이전트 위치에 있으며, 이는 구독의 동작 방식(푸시 또는 풀)을 결정합니다.

푸시 구독용 (유통업체에서 관리):

에 발행자 서버, 확장 복제 -> 지역 출판물.
출판물을 마우스 오른쪽 버튼으로 클릭하고 선택하세요. 새로운 구독.

풀 구독의 경우 (구독자가 관리함):

에 구독자 서버, 확장 복제, 마우스 오른쪽 버튼으로 클릭 로컬 구독, 선택 새로운 구독.
에 출판기획 & 편집 페이지 클릭 Find SQL Server 작성자 그리고 게시자 서버에 연결합니다.

두 구독 유형 모두에 공통적으로 적용되는 마법사 단계:

새 구독 마법사에서 클릭하세요. 다음 환영 페이지에서.
출판물을 선택하고 클릭하세요. 다음.
에 유통 대리점 위치 페이지에서 에이전트 위치를 선택하세요.
- 푸시 구독"배포업체에서 모든 에이전트 실행"을 선택하면 배포업체가 구독자에게 변경 사항을 푸시합니다.
- 구독 취소"각 에이전트를 해당 구독자에서 실행"을 선택하면 각 구독자가 배포자로부터 변경 사항을 가져옵니다.
에 가입자 페이지에서 기존 가입자 서버를 선택하거나 클릭하세요. 가입자 추가 새로운 항목을 추가하려면.
각 구독자에 대해 대상 데이터베이스를 선택하거나 새 데이터베이스를 생성하십시오. 참고 : 구독 데이터베이스는 게시자 데이터베이스와 달라야 합니다. 단, 동일한 데이터베이스를 사용하는 경우는 예외입니다. SQL Server 예.
에 유통 대리점 보안 페이지에서 각 구독의 속성 버튼을 클릭하여 보안 컨텍스트를 구성하십시오.
에 동기화 일정 페이지에서 연속 동기화 또는 예약 동기화를 선택하세요.
에 구독 초기화 페이지, 선택 바로 마법사 완료 중에 초기화하거나 첫 번째 동기화.
마법사 작업 검토 및 클릭 마감재 .

5. 모니터링 및 관리 SQL Server 복제

5.1 복제 모니터를 이용한 복제 모니터링

복제 모니터를 실행하려면 다음 단계를 따르세요.

In SQL Server Management Studio, 확장 복제 개체 탐색기에서.
마우스 오른쪽 단추로 클릭 복제 선택 복제 모니터 실행.
등록된 게시자가 없으면 클릭하세요. 게시자 추가 왼쪽 된 창에서.
왼쪽 메뉴에서 추가 SQL Server 작성자 그리고 게시자 서버에 연결합니다.
게시자는 왼쪽 창에 표시되며, 출판물 및 구독을 위한 확장 가능한 노드가 있습니다.

5.2 성능 모니터링

5.2.1 모니터 지연 시간

복제 지연 시간은 게시자에서 변경 사항이 발생한 시점과 구독자에 해당 변경 사항이 적용되는 시점 사이의 시간 차이입니다. 데이터 최신성이 비즈니스 요구 사항을 충족하는지 확인하려면 복제 지연 시간을 모니터링해야 합니다.

복제 모니터를 사용하여 모든 구독 탭에서 지연 시간 메트릭을 확인할 수 있습니다. 지연 시간 열에는 평균 지연 시간(초)이 표시됩니다. 트랜잭션 복제의 경우, 추적 토큰은 복제 파이프라인을 통해 추적되는 마커 트랜잭션을 삽입하여 정확한 지연 시간 측정값을 제공합니다.

트레이서 토큰을 사용하려면 다음 단계를 따르세요.

복제 모니터에서 트랜잭션 게시를 선택합니다.
클릭 트레이서 토큰 탭.
추적기 삽입 마커 트랜잭션을 삽입합니다.
토큰이 발행자에서 유통자, 그리고 구독자로 이동하는 과정을 모니터링하십시오.
각 구간별 소요 시간을 확인하여 병목 현상을 파악하십시오.

5.2.2 처리량 모니터링

처리량은 시간에 따른 복제 데이터 양을 측정하는 지표로, 일반적으로 초당 트랜잭션 수 또는 초당 명령 수로 표시됩니다. 복제 속도가 게시자 활동 속도를 따라잡을 수 있도록 처리량을 모니터링하십시오.

복제 모니터는 기본적인 동기화 상태를 제공하지만, 전달률 및 자세한 처리량 지표는 GUI에서 확인할 수 없습니다. 처리량을 모니터링하려면 배포 데이터베이스에 대한 T-SQL 쿼리를 사용하십시오.

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

상태 코드: 1 = 시작, 2 = 진행 중, 3 = 성공, 4 = 대기, 5 = 재시도, 6 = 실패. 복제 지연 상황을 파악하려면 게시자 트랜잭션 속도와 전달 속도를 비교하십시오. 성능 카운터는 다음과 같습니다. Windows 성능 모니터 각 복제 에이전트에 대한 추가 처리량 지표를 제공합니다.

5.2.3 병목 현상 파악

복제 병목 현상은 토폴로지의 여러 지점에서 발생할 수 있습니다. 게시자 측에서는 스냅샷 생성 시간이 지나치게 길거나 로그 판독기 에이전트 지연이 발생하는 경우 리소스 제약이 원인일 수 있습니다. 복제 작업 중에 게시자의 CPU, 메모리 및 디스크 I/O를 모니터링하십시오.

배포 담당자는 배포 데이터베이스에서 누적된 트랜잭션을 확인하십시오. 배포되지 않은 명령이 많다는 것은 배포 담당자가 배송 처리량을 따라가지 못하고 있음을 나타냅니다. 배포 서버 리소스를 모니터링하고 대용량 환경에서는 전용 원격 배포 담당자를 사용하는 것을 고려하십시오.

가입자 측에서 변경 사항 적용이 느려지는 원인은 리소스 부족, 인덱스 누락 또는 삽입 작업 속도를 저하시키는 제약 조건 때문일 수 있습니다. 배포 에이전트가 실행 중일 때 가입자 리소스 사용률과 쿼리 성능을 모니터링하십시오. 구성 요소 간 네트워크 대역폭 제한 또한 특히 대용량 데이터의 경우 병목 현상을 일으킬 수 있습니다.

5.3 복제 에이전트 관리

5.3.1 시작 및 중지 에이전트

복제 에이전트를 시작하거나 중지하려면 다음 단계를 따르십시오.

In SQL Server Management Studio, 확장 SQL Server 에이전트 -> 작업.
복제 에이전트 작업을 찾으십시오(일반적으로 작업 이름에는 게시 및 구독자 정보가 포함됩니다).
해당 작업을 마우스 오른쪽 버튼으로 클릭하고 선택하세요. 작업 시작 or 작업 중지.

5.3.2 에이전트 프로필 구성

에이전트 프로필에는 에이전트 동작을 제어하는 매개변수 세트가 포함되어 있습니다. SQL Server 일반적인 시나리오에 최적화된 기본 프로필을 제공하며, 특정 요구 사항에 맞춰 사용자 지정 프로필을 만들 수도 있습니다.

에이전트 프로필을 수정하려면 다음 단계를 따르세요.

개체 탐색기에서 확장 복제.
마우스 오른쪽 단추로 클릭 복제 선택 대리점 속성.
클릭 프로필 기본 설정 버튼을 클릭합니다.
드롭다운 메뉴에서 에이전트 유형(스냅샷, 로그 판독기, 배포 또는 병합)을 선택하십시오.
프로필을 선택하고 클릭하세요 등록 매개변수 값을 보려면.
새 프로필 기존 프로필을 기반으로 사용자 지정 프로필을 생성합니다.
필요에 따라 매개변수를 수정하고 클릭하세요. OK.

에이전트에 프로필을 적용하려면 구독 속성을 편집하고 에이전트 프로필 드롭다운에서 원하는 프로필을 선택하십시오.

5.3.3 에이전트 매개변수 및 설정

에이전트 매개변수는 성능과 동작을 세밀하게 조정합니다. 배포 에이전트의 주요 매개변수에는 CommitBatchSize(커밋당 적용되는 트랜잭션 수), CommitBatchThreshold(커밋 전 명령 수), SubscriptionStreams(더 빠른 전송을 위한 병렬 연결) 및 QueryTimeout(명령 시간 초과)이 포함됩니다.

로그 판독기 에이전트의 주요 매개변수에는 ReadBatchSize(스캔당 읽는 트랜잭션 수), ReadBatchThreshold(전달 전 명령 수) 및 PollingInterval(로그 스캔 간 지연 시간)이 있습니다. 이러한 매개변수는 트랜잭션 볼륨 및 지연 시간 요구 사항에 따라 조정하십시오.

5.4 백업 및 복원 시 고려 사항

복제에 관련된 데이터베이스를 백업할 때는 특별한 고려 사항이 필요합니다. 게시자 데이터베이스의 경우 정기적인 전체 백업과 트랜잭션 로그 백업이 필수적입니다. 트랜잭션 복제를 사용하는 데이터베이스를 백업할 때는 WITH REPLICATION 옵션을 사용하여 복제 지원을 위한 백업을 생성하십시오. 배포자 데이터베이스도 정기적으로 백업하여 복제 구성을 보호해야 합니다.

게시자 데이터베이스를 동일한 서버에 동일한 이름으로 복원할 때 복제 상태를 유지하려면 WITH KEEP_REPLICATION 옵션을 사용하십시오. 이 옵션을 사용하면 로그 판독기 에이전트에서 아직 처리되지 않은 트랜잭션이 복제 대상으로 표시된 상태로 유지되어 구독을 다시 초기화하지 않고도 복제가 자동으로 계속될 수 있습니다.

백업을 사용할 수 없거나, 손상되었거나, 데이터베이스 파일이 손상된 재해 복구 시나리오에서는 특수 복구 도구가 필요할 수 있습니다. DataNumen SQL Recovery 손상되었거나 접근할 수 없는 MDF 및 NDF 파일에서 데이터를 추출할 수 있으므로 표준 복원 절차가 실패할 경우 최후의 수단으로 사용할 수 있습니다.

자세한 내용은 SQL Server 백업 관련 문의는 저희 웹사이트를 참조하세요. 종합 가이드.

6. 자주 묻는 질문(FAQ)

질문: 스냅샷 복제와 트랜잭션 복제의 차이점은 무엇인가요?

A: 스냅샷 복제는 특정 시점의 데이터를 완전히 복사하여 구독자에게 적용하는 방식으로, 데이터 변경 빈도가 낮은 경우에 적합합니다. 트랜잭션 복제는 초기 스냅샷 생성 후, 개별 트랜잭션이 발생할 때마다 지속적으로 복제하여 빈번하게 변경되는 데이터에 대해 거의 실시간 동기화를 제공합니다.

질문: 서로 다른 기기 간에 복제가 가능한가요? SQL Server 버전?

A : 그렇습니다. SQL Server 복제는 제한된 범위 내에서 버전 호환성을 지원합니다. 배포자 버전은 게시자 버전과 같거나 높아야 하며, 구독자 버전은 게시자 버전과 두 버전 이내여야 합니다. 예를 들어, 게시자 버전이 다음과 같을 경우: SQL Server 2016년, 구독자는 다음과 같을 수 있습니다. SQL Server 2012년, 2014년, 2016년, 2017년 또는 2019년.

질문: 병합 복제에서 충돌은 어떻게 처리하나요?

A: 병합 복제는 내장된 충돌 감지 및 해결 메커니즘을 제공합니다. 아티클 수준에서 충돌 해결사를 구성할 수 있으며, 내장된 해결사 중에서 선택하거나 사용자 지정 충돌 해결사를 구현할 수 있습니다. 충돌은 일반적으로 우선순위 기반 또는 타임스탬프 기반 방식으로 해결되며, 수동 검토를 위해 충돌을 로그에 기록하는 옵션도 제공됩니다.

Q: 복제는 성능에 어떤 영향을 미칩니까?

A: 복제는 여러 가지 방식으로 성능에 영향을 미칩니다. 게시자는 변경 사항 추적 및 스냅샷 생성으로 인한 오버헤드가 발생하고, 배포자는 트랜잭션을 저장하고 전달하는 데 리소스를 사용하며, 데이터 전송 중에는 네트워크 대역폭이 소모됩니다. 이러한 영향은 복제 유형에 따라 달라지는데, 스냅샷 복제는 주기적으로 높은 성능 저하를 유발하는 반면, 트랜잭션 복제는 보다 일관적이지만 지속적인 부하를 유지합니다.

질문: 복제 토폴로지를 어떻게 보호할 수 있습니까?

A: 몇 가지 모범 사례를 구현하여 복제 토폴로지를 보호하십시오. Windows 인증 또는 강력한 보안 조치를 사용하십시오. SQL Server 인증, TLS를 사용한 연결 암호화, 적절한 보안 조치를 통해 스냅샷 폴더를 보호합니다. NTFS 권한을 설정하고, 액세스를 제어하기 위해 게시 액세스 목록(PAL)을 구성하고, 각 복제 에이전트에 대해 최소한의 필수 권한만 있는 별도의 서비스 계정을 사용하고, 복제 보안 설정을 정기적으로 감사합니다.

질문: Azure SQL Database로 복제할 수 있나요?

A: 네, 온프레미스 데이터베이스를 트랜잭션 복제를 사용하여 Azure SQL Database로 복제할 수 있습니다. SQL Server 또는 Azure SQL Managed Instance를 게시자 및 배포자로 사용할 수 있습니다. Azure SQL Database는 구독자로는 사용할 수 있지만 게시자 또는 배포자로는 사용할 수 없습니다. Azure SQL Database에서는 병합 복제 및 피어 투 피어 복제가 지원되지 않습니다.

질문: 복제 지연을 어떻게 모니터링하나요?

A: 복제 모니터를 사용하여 복제 지연을 모니터링하세요. SQL Server Management Studio는 각 구독에 대한 지연 시간 메트릭을 표시합니다. 또한 MSdistribution_history 및 MSrepl_commands와 같은 배포 데이터베이스 테이블을 쿼리하거나, 복제 에이전트별 성능 카운터를 사용하거나, 지연 시간 임계값을 기반으로 경고를 설정하여 동기화 지연을 사전에 감지하고 해결할 수 있습니다.

질문: 가입자가 오프라인 상태일 경우 어떻게 되나요?

A: 가입자가 오프라인 상태일 때 동작은 복제 유형에 따라 다릅니다. 트랜잭션 복제의 경우, 가입자가 다시 온라인 상태가 될 때까지 트랜잭션이 배포 데이터베이스에 누적된 후 동기화가 재개됩니다. 병합 복제의 경우, 양쪽에서 변경 사항이 추적되고 연결이 복원되면 병합됩니다. 보존 기간 설정은 데이터를 다시 초기화해야 하기 전까지 데이터를 보관하는 기간을 결정합니다.

질문: 기존 게시물에 새 글을 추가하려면 어떻게 해야 하나요?

A: 기존 출판물에 새 기사를 추가하려면 다음을 사용하세요. SQL Server Management Studio를 사용하여 게시 속성을 수정하고 추가 개체를 선택하거나 sp_addarticle 저장 프로시저를 사용할 수 있습니다. 아티클을 추가한 후에는 새 스냅샷을 생성하고 모든 구독을 다시 초기화하여 구독자가 새 아티클을 수신하도록 해야 합니다. 게시 설정에 따라 일부 변경 사항에 대해서는 구독을 다시 초기화해야 할 수 있습니다.

질문: 데이터베이스에서 복제를 제거하려면 어떻게 해야 하나요?

A: 데이터베이스에서 복제를 제거하려면 먼저 sp_dropsubscription을 사용하여 모든 구독을 삭제하고, sp_droppublication을 사용하여 게시를 삭제한 다음, sp_replicationdboption을 사용하여 데이터베이스에서 게시를 비활성화하십시오. 서버가 배포자 서버인 경우 sp_dropdistributor를 사용하여 배포를 비활성화하십시오. 복제 구성을 제거하기 전에 항상 데이터베이스를 백업하십시오.

Q: 차이점은 무엇입니까? SQL Server 복제 및 AlwaysOn 가용성 그룹?

A: 복제는 객체 수준에서 작동하는 데이터 분산 및 통합 솔루션입니다. 항상 사용 가능한 가용성 그룹 이 솔루션은 데이터베이스 수준에서 작동하는 고가용성 및 재해 복구 솔루션입니다.

7. 결론

SQL Server 복제는 여러 데이터베이스와 위치에 걸쳐 데이터를 분산하고 동기화하기 위한 강력한 프레임워크를 제공합니다. 이 기술은 다양한 복제 유형을 통해 여러 시나리오를 지원합니다.

적절한 복제 전략을 선택하는 것은 특정 요구 사항에 따라 달라집니다. 데이터 변경 빈도, 지연 시간 요구 사항, 가입자의 업데이트 필요성, 네트워크 특성 및 가입자 자율성 요구 사항을 고려해야 합니다. 스냅샷 복제는 지연 시간이 중요하지 않은, 변경 빈도가 낮은 참조 데이터에 가장 적합합니다. 트랜잭션 복제는 낮은 지연 시간과 주로 단방향 데이터 흐름이 요구되는 대용량 시나리오에 적합합니다.

가입자가 오프라인 기능과 양방향 동기화를 갖춘 자율적인 운영이 필요한 경우 병합 복제를 선택하십시오. 여러 활성 노드에 걸쳐 읽기 작업의 로드 밸런싱을 수행하고 거의 실시간 일관성을 유지하려면 피어 투 피어 복제를 구현하십시오. 다양한 요구 사항이 있는 복잡한 시나리오에서는 여러 복제 유형을 결합하는 하이브리드 방식을 고려하십시오.

참고자료

저자에 관하여

위안 셩 10년 이상의 경력을 가진 선임 데이터베이스 관리자(DBA)입니다. SQL Server 환경 및 기업 데이터베이스 관리 분야에서 그는 금융 서비스, 의료, 제조 분야에서 수백 건의 데이터베이스 복구 시나리오를 성공적으로 해결했습니다.

원은 다음을 전문으로 합니다. SQL Server 데이터베이스 복구, 고가용성 솔루션, 성능 최적화 분야의 전문가입니다. 그는 수 테라바이트 규모의 데이터베이스 관리, Always On Availability Groups 구현, 미션 크리티컬 비즈니스 시스템을 위한 자동 백업 및 복구 전략 개발 등 풍부한 실무 경험을 보유하고 있습니다.

Yuan은 기술적 전문성과 실용적인 접근 방식을 통해 데이터베이스 관리자와 IT 전문가가 복잡한 문제를 해결하는 데 도움이 되는 포괄적인 가이드를 만드는 데 중점을 둡니다. SQL Server 효율적으로 도전합니다. 그는 최신 정보를 유지합니다. SQL Server Microsoft의 새로운 릴리스와 진화하는 데이터베이스 기술을 활용하고, 정기적으로 복구 시나리오를 테스트하여 권장 사항이 실제 모범 사례를 반영하는지 확인합니다.

에 대한 질문이 SQL Server 복구가 필요하거나 추가적인 데이터베이스 문제 해결 지침이 필요하신가요? Yuan이 환영합니다. 피드백과 제안 이러한 기술적 자원을 개선하기 위해.