피어 투 피어 - 트랜잭션 복제

적용 대상: SQL Server

피어 투 피어 복제는 여러 서버 인스턴스(노드라고도 함)에 걸쳐 데이터 복사본을 유지 관리함으로써 확장성 및 고가용성 솔루션을 제공합니다. 트랜잭션 복제를 기반으로 구축된 피어 투 피어 복제는 거의 실시간으로 트랜잭션 일치 변경 내용을 전파합니다. 따라서 읽기 작업을 확장해야 하는 애플리케이션은 클라이언트의 읽기 작업을 여러 노드에 배포할 수 있습니다. 여러 노드의 데이터가 거의 실시간으로 유지 관리되므로 피어 투 피어 복제는 데이터 중복을 제공하며 이러한 중복은 데이터의 가용성을 높여 줍니다.

웹 애플리케이션을 고려하세요. 이렇게 하면 다음과 같은 방법으로 피어 투 피어 복제를 활용할 수 있습니다.

• 카탈로그 쿼리 및 기타 읽기는 여러 노드에 분산됩니다. 이렇게 하면 읽기가 증가함에 따라 성능이 일관성을 유지할 수 있습니다.

• 시스템의 노드 중 하나가 실패하면 애플리케이션 계층이 해당 노드에 대한 쓰기를 다른 노드로 리디렉션할 수 있습니다. 이렇게 하면 사용 가능성을 유지 관리할 수 있습니다.

• 노드를 유지 관리해야 하거나 전체 시스템을 업그레이드해야 하는 경우 애플리케이션의 가용성에 영향을 주지 않고 각 노드를 오프라인 상태로 만들었다가 다시 시스템에 추가할 수 있습니다.

피어 투 피어 복제를 사용하면 읽기 작업을 확장할 수 있지만 토폴로지에 대한 쓰기 성능은 단일 노드의 경우와 유사합니다. 이는 궁극적으로 모든 삽입, 업데이트 및 삭제가 모든 노드에 전파되기 때문입니다. 복제는 변경 내용이 지정된 노드에 적용된 시기를 인식하고 변경 내용이 노드를 두 번 이상 순환하지 못하도록 방지합니다. 다음과 같은 이유로 인해 각 행에 대한 쓰기 작업은 하나의 노드에서만 수행하는 것이 좋습니다.

• 행이 둘 이상의 노드에서 수정되면 행이 다른 노드로 전파될 때 충돌 또는 업데이트 손실이 발생할 수 있습니다.

• 변경 내용이 복제될 때 항상 약간의 대기 시간이 발생합니다. 최신 변경 내용을 즉시 표시해야 하는 애플리케이션의 경우 여러 노드에서 애플리케이션을 동적으로 부하 분산하는 것이 문제가 될 수 있습니다.

피어 투 피어 복제에는 피어 투 피어 토폴로지에서 충돌 검색을 사용하도록 설정하는 옵션이 포함되어 있습니다. 이 옵션을 사용하면 일관되지 않은 애플리케이션 동작 및 업데이트 손실 등 검색되지 않은 충돌로 인해 발생하는 문제를 방지할 수 있습니다. 이 옵션을 사용하도록 설정하면 기본적으로 충돌하는 변경 내용이 배포 에이전트 오류를 일으키는 심각한 오류로 처리됩니다. 충돌이 발생하면 충돌이 수동으로 해결되고 데이터가 토폴로지 전체에서 일관성을 가질 때까지 토폴로지가 일관성 없는 상태로 유지됩니다. 자세한 내용은 피어 투 피어 복제에서 피어 투 피어 - 충돌 검색을 참조하세요.

참고 항목

잠재적인 데이터 불일치를 방지하려면 충돌 검색이 설정된 경우에도 피어 투 피어 토폴로지에서 충돌을 방지해야 합니다. 특정 행에 대한 쓰기 작업이 하나의 노드에서만 수행되도록 하려면 데이터에 액세스하고 변경하는 애플리케이션은 삽입, 업데이트 및 삭제 작업을 분할해야 합니다. 이렇게 분할하면 행이 다른 노드에서 수정되기 전에 한 노드에서 시작된 지정된 행에 대한 수정이 토폴로지의 다른 모든 노드와 동기화됩니다. 애플리케이션에 정교한 충돌 감지 및 해결 기능이 필요한 경우 병합 복제를 사용합니다. 자세한 내용은 병합 복제 및 병합 복제 충돌 감지 및 해결을 참조하세요.

피어 투 피어 토폴로지

다음 시나리오에서는 피어 투 피어 복제에 대한 일반적인 사용을 보여 줍니다.

참여하는 데이터베이스가 두 개인 토폴로지

앞의 두 그림 모두 애플리케이션 서버를 통해 데이터베이스로 전달되는 사용자 트래픽과 함께 참여하는 두 개의 데이터베이스를 보여 줍니다. 이 구성은 웹 사이트에서 작업 그룹 애플리케이션에 이르는 다양한 애플리케이션에 사용할 수 있으며 다음과 같은 이점을 제공합니다.

• 읽기는 두 서버에 분산되므로 읽기 성능이 향상되었습니다.

• 유지 관리가 필요하거나 한 노드에서 오류가 발생한 경우 가용성이 높아집니다.

두 그림에서 읽기 작업은 참여하는 데이터베이스 간에 부하가 분산되지만 업데이트는 다르게 처리됩니다.

• 왼쪽에서 업데이트는 두 서버 간에 분할됩니다. 예를 들어 데이터베이스에 제품 카탈로그가 포함된 경우 사용자 지정 애플리케이션을 지정하여 A-M으로 시작하는 제품 이름에 대해서는 노드 A 로, N-Z로 시작하는 제품 이름에 대해서는 노드 B 로 업데이트를 전송하도록 할 수 있습니다. 그러면 이후 업데이트가 노드 간에 상호 복제됩니다.

• 오른쪽에서 모든 업데이트는 노드 B로 전달됩니다. 여기에서 업데이트는 노드 A에 복제됩니다. B가 오프라인(예: 유지 관리)인 경우 애플리케이션 서버는 모든 작업을 A로 보낼 수 있습니다. B가 다시 온라인 상태가 되면 업데이트가 해당 업데이트로 전달되고 애플리케이션 서버는 모든 업데이트를 B로 다시 이동하거나 A로 계속 보낼 수 있습니다.

피어 투 피어 복제는 두 방법 중 하나를 지원할 수 있지만 오른쪽의 중앙 업데이트 예제는 표준 트랜잭션 복제와 함께 사용되는 경우가 많습니다.

3개 이상의 참여 데이터베이스가 있는 토폴로지

앞의 그림에서는 전 세계 소프트웨어 지원 조직에 대한 데이터를 제공하는 세 개의 참여 데이터베이스를 보여 줍니다. 이 데이터베이스는 로스앤젤레스, 런던 및 타이베이에 지사를 두고 있습니다. 각 사무실의 지원 엔지니어는 고객 전화를 받고 각 고객 통화에 대한 정보를 입력하고 업데이트합니다. 세 사무실의 표준 시간대는 8시간 간격이므로 근무일에는 겹치지 않습니다. 타이베이 사무소가 문을 닫으면서 런던 사무소가 하루 동안 문을 열고 있습니다. 한 사무실이 문을 닫을 때 통화가 계속 진행 중인 경우 다음 사무실의 담당자에게 전화를 전달하여 엽니다.

각 위치에는 고객 호출에 대한 정보를 입력하고 업데이트할 때 지원 엔지니어가 사용하는 데이터베이스와 애플리케이션 서버가 있습니다. 토폴로지는 시간별로 분할됩니다. 현재 업무를 진행 중인 노드에서만 업데이트가 발생하며 이후 다른 참여 데이터베이스로 업데이트 내용이 이동됩니다. 이 토폴로지는 다음과 같은 이점을 제공합니다.

• 격리 없이 독립성: 각 사무실은 데이터를 독립적으로 삽입, 업데이트 또는 삭제할 수 있지만 다른 모든 참여 데이터베이스에 복제되므로 데이터를 공유할 수도 있습니다.

• 오류가 발생하거나 하나 이상의 참여하는 데이터베이스에서 유지 관리를 허용하는 경우 가용성이 높아질 수 있습니다.

  

  위의 그림에서는 3노드 토폴로지에 노드를 추가하는 방법을 보여 줍니다. 이 시나리오에서는 다음과 같은 이유로 노드를 추가할 수 있습니다.

• 다른 지사가 개설되었습니다.

• 디스크 오류 또는 기타 주요 오류가 발생하는 경우 유지 관리를 지원하거나 내결함성을 높이기 위해 더 높은 가용성을 제공합니다.

3노드 토폴로지와 4노드 토폴로지 모두에서 모든 데이터베이스가 다른 모든 데이터베이스를 게시하고 구독합니다. 이는 하나 이상의 노드에 대한 유지 관리 요구 또는 오류가 있는 경우 최대 가용성을 제공합니다. 노드가 추가되면 성능 및 배포 및 관리의 복잡성과 가용성 및 확장성 요구 사항의 균형을 유지해야 합니다.

피어 투 피어 복제 구성

피어 투 피어 복제 토폴로지 구성은 일련의 표준 트랜잭션 게시 및 구독을 구성하는 것과 유사합니다. 다음 문서에 설명된 단계는 피어 투 피어 토폴로지의 왼쪽에 표시된 구성과 유사하게 3노드 시스템의 구성을 보여 줍니다.

피어 투 피어 복제 사용에 대한 고려 사항

이 섹션에서는 피어 투 피어 복제를 사용할 때 고려해야 할 정보 및 지침을 제공합니다.

일반적인 고려 사항

• 피어 투 피어 복제는 엔터프라이즈 버전의 SQL Server에서만 사용할 수 있습니다.

• 피어 투 피어 복제에 참여하는 모든 데이터베이스에는 동일한 스키마 및 데이터가 있어야 합니다.

  • 개체 이름, 개체 스키마 및 게시 이름은 동일해야 합니다.

  • 게시에서 스키마 변경 내용의 복제를 허용해야 합니다(게시 속성 (기본 설정인 게시 속성 replicate_ddl에 대한 1 설정입니다.) 자세한 내용은 게시 데이터베이스에서 스키마 변경하기를 참조하세요.

  • 행 및 열 필터링은 지원되지 않습니다.

• 각 노드는 자체 배포 데이터베이스를 사용해야 합니다. 이렇게 하면 단일 실패 지점이 발생할 가능성이 없습니다.

• 테이블 및 기타 개체는 단일 게시 데이터베이스의 여러 피어 투 피어 게시에 포함될 수 없습니다.

• 구독을 만들기 전에 피어 투 피어 복제에 게시를 사용하도록 설정해야 합니다.

• 백업이나 replication support only 옵션을 사용하여 구독을 초기화해야 합니다. 자세한 내용은 스냅샷 없이 트랜잭션 구독 초기화를 참조하세요.

• ID 열을 사용하지 마세요. ID를 사용하는 경우 참여하는 각 데이터베이스의 테이블에 할당된 범위를 수동으로 관리해야 합니다. 자세한 내용은 수동 ID 범위 관리를 위한 범위 할당하기를 참조하세요.

기능 제한

피어 투 피어 복제는 트랜잭션 복제의 주요 기능을 지원하지만 다음 옵션은 지원하지 않습니다.

• 스냅샷을 사용하여 초기화 및 다시 초기화

• 행 및 열 필터

• 타임스탬프 열

• 비 SQL Server 게시자 및 구독자

• 즉시 업데이트 구독 및 지연 업데이트 구독

• 익명 구독

• 부분 구독

• 연결 가능한 구독 및 변환 가능한 구독 (이 두 옵션은 모두 SQL Server 2005(9.x)에서 더 이상 사용되지 않습니다.)

• 공유 배포 에이전트

• 배포 에이전트 매개 변수 -SubscriptionStreams 및 로그 판독기 에이전트 매개 변수 -MaxCmdsInTran

• 아티클 속성 @destination_owner 및 @destination_table

• 피어 투 피어 트랜잭션 복제는 피어 투 피어 게시에 대한 단방향 트랜잭션 구독 만들기를 지원하지 않습니다.

• 피어 투 피어 트랜잭션 복제는 계산된 열을 기본 키의 일부로 사용하여 테이블을 게시하는 것을 지원하지 않습니다.

다음 속성에는 특별히 고려할 사항이 있습니다.

• 게시 속성 @allow_initialize_from_backup에는 true 값이 필요합니다.

• 아티클 속성 @replicate_ddl의 값은 true여야 하고 @identityrangemanagementoption의 값은 manual이어야 하며 @status에서는 옵션 24를 설정해야 합니다.

• 아티클 속성 @ins_cmd, @del_cmd, @upd_cmd의 값은 SQL에 설정할 수 없습니다.

• 구독 속성 @sync_type에는 없음 또는 자동 값이 필요합니다.

• SQL Server 2019(15.x) CU 13에는 게시 속성 @p2p_confictdetection_policy이(가) 도입되었습니다. 기본 매개 변수 값은 originatorid이고, 시작자 ID를 기준으로 충돌을 해결합니다. lastwriter 매개 변수 값은 마지막 기록기를 기반으로 충돌을 해결합니다.

유지 보수 고려 사항

일부 작업을 수행하려면 시스템이 정지해야 합니다. 즉 시스템 정지 과정에서는 모든 노드에서 게시된 테이블에 대한 작업을 중지하고 각 노드가 다른 모든 노드의 변경 내용을 받았는지 확인합니다.

작업	SQL Server 2005 피어만 또는 SQL Server 2008 피어 이상과 SQL Server 2005 피어의 혼합	SQL Server 2005 피어만 또는 SQL Server 2008 피어 이상과 SQL Server 2005 피어의 혼합	SQL2008 피어 이상	SQL2008 피어 이상
토폴로지에 노드 추가	전체 토폴로지의 노드 2개: 정지가 필요하지 않음 sync_type = 'initialize with backup'을 사용합니다.	2개 이상의 노드: 정지 필요	sync_type = 'replication support only': 정지 필요.	sync_type = 'initialize with backup' 및 'initialize from lsn': 정지 필요 없음

토폴로지 스키마 변경(아티클 추가 또는 삭제)에는 정지가 필요합니다. 자세한 내용은 피어 투 피어 토폴로지 관리(복제 Transact-SQL 프로그래밍)를 참조하세요.

토폴로지에서 노드를 제거할 때는 정지가 필요하지 않습니다.

sp_changearticle를 사용해 아티클 속성을 변경할 때는 정지가 필요하지 않습니다. P2P의 경우 변경 가능한 항목은 description, ins_cmd, upd_cmd및 del_cmd 속성입니다.

아티클 스키마 변경(열 추가/삭제)에는 정지가 필요하지 않습니다.

• 아티클 추가: 기존 구성에 아티클을 추가하는 경우에는 시스템을 정지하고 CREATE TABLE 문을 실행하여 토폴로지의 각 노드에서 초기 데이터를 로드한 다음 토폴로지의 각 노드에서 새 아티클을 추가해야 합니다.

• 문서 삭제: 모든 노드에서 일관된 상태를 원하는 경우 토폴로지를 정지해야 합니다.

자세한 내용은 복제 토폴로지 정지(복제 Transact-SQL 프로그래밍) 및 피어 투 피어 토폴로지 관리(복제 Transact-SQL 프로그래밍)를 참조하세요.

• 피어 투 피어 토폴로지에 새 노드를 추가하는 경우 새 노드를 추가한 후에 만든 백업에서만 복원해야 합니다.

• 피어 투 피어 토폴로지에서 구독을 다시 초기화할 수 없습니다. 노드에 새로운 데이터 복사본을 유지하려면 해당 노드에서 백업을 복원합니다.

관련 콘텐츠

• 피어 투 피어 토폴로지 관리(복제 Transact-SQL 프로그래밍)
• 스냅샷 및 트랜잭션 복제의 백업 및 복원을 위한 전략
• 트랜잭션 복제