피어 투 피어 트랜잭션 복제

  • 아티클

업데이트: 2006년 12월 12일

피어 투 피어 트랜잭션 복제는 복제에 참여하는 임의의 데이터베이스에서 데이터를 읽거나 수정할 수 있는 응용 프로그램용으로 디자인되었습니다. 예를 들면 다음과 같은 이유로 온라인 쇼핑 응용 프로그램에 피어 투 피어 복제를 사용하는 것이 좋습니다. 데이터를 읽는 쿼리를 여러 데이터베이스로 분산시켜 응용 프로그램 성능을 향상시킬 수 있습니다. 또한 데이터베이스를 호스팅하는 서버 중 하나를 사용할 수 없는 경우 동일한 데이터 복사본이 포함된 나머지 서버로 트래픽을 라우팅하도록 응용 프로그램을 프로그래밍할 수 있습니다. 작업을 모든 노드로 분산시킬 수 있으므로 읽기 성능이 향상됩니다. 결국 모든 변경 내용이 모든 노드로 전파되므로 토폴로지의 집계 업데이트, 삽입 및 삭제 성능이 단일 노드와 유사해집니다.

피어 투 피어 토폴로지의 모든 노드는 피어입니다. 각 노드는 동일한 스키마와 데이터를 게시하고 구독합니다. 모든 노드에서 변경(삽입, 업데이트 및 삭제) 작업을 수행할 수 있습니다. 변경 내용이 두 번 이 상 노드 전체에서 순환되는 것을 방지하기 위해 변경 내용이 지정된 노드에 적용되면 복제가 이를 인식합니다.

[!참고] 데이터에 액세스하여 내용을 변경하는 사용자 지정 응용 프로그램에서는 삽입, 업데이트 및 삭제를 분할하여 한 노드에서 발생한 지정된 행에 대한 수정 내용이 다른 노드에서 해당 행을 수정하기 전에 토폴로지의 다른 모든 데이터베이스와 동기화되도록 해야 합니다. 응용 프로그램의 여러 노드에서 지정된 행에 대해 동시에 서로 다른 수정 내용을 적용하는 경우에는 충돌 처리에 적합한 병합 복제를 사용합니다. 병합 복제에 대한 자세한 내용은 병합 복제 개요를 참조하십시오.

표준 트랜잭션 복제에서는 구독자가 읽기 전용이라고 가정하며 계층 구조가 지원됩니다. 일반적으로 단일 게시자는 데이터를 하나 이상의 구독자에 게시합니다. 표준 트랜잭션 복제는 재게시 계층도 지원합니다. 재게시 계층에서는 업데이트 내용이 게시자에서 재게시 구독자 집합으로 배달되고 그 다음에 업데이트 내용이 다시 해당 구독자 집합에서 최종 리프 노드 구독자 집합으로 배달됩니다. 구독을 업데이트하면 구독자가 변경 내용을 게시자에게 밀어넣을 수 있지만 구독자와 게시자 사이에서 변경 내용이 이동될 때 계층을 따르므로 정렬도 계속 계층 구조를 유지합니다. 읽기 전용 트랜잭션 복제 및 구독 업데이트가 있는 트랜잭션 복제와는 달리 피어 투 피어 복제 토폴로지에 있는 노드 사이의 관계는 계층 관계가 아닌 피어 관계이므로 각 노드에는 동일한 스키마와 데이터가 포함됩니다.

[!참고] 참여하는 여러 데이터베이스에서 업데이트를 수행할 수 있지만 피어 투 피어 토폴로지에는 즉시 게시 업데이트 옵션이나 지연 게시 업데이트 옵션이 필요하지 않거나 허용되지 않습니다. 즉시 업데이트 및 지연 업데이트에 대한 자세한 내용은 트랜잭션 복제를 위한 업데이트 가능 구독을 참조하십시오.

피어 투 피어 토폴로지

다음 시나리오에서는 피어 투 피어 복제의 일반적 사용을 설명합니다.

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

피어 투 피어 복제, 2노드

위의 그림에서는 참여하는 데이터베이스 두 개를 각각 보여 주며 사용자 트래픽이 응용 프로그램 서버를 통해 데이터베이스로 전송됩니다. 이러한 구성은 웹 사이트에서 작업 그룹 응용 프로그램에 이르기까지 다양한 응용 프로그램에 사용할 수 있으며 다음과 같은 이점을 제공합니다.

  • 두 개 이상의 서버에서 분산하여 읽게 되므로 읽기 성능이 향상됩니다.
  • 유지 관리가 필요하거나 한 노드에서 오류가 발생하는 경우에도 가용성이 높습니다.

두 그림에서는 참여하는 데이터베이스 간에 읽기 작업 로드의 균형이 조정되지만 업데이트는 다르게 처리됩니다.

  • 왼쪽 그림에서 업데이트는 두 개의 서버 사이에 분할되어 있습니다. 예를 들어 데이터베이스에 제품 카탈로그가 포함된 경우 사용자 지정 응용 프로그램에서 A-M으로 시작하는 제품 이름에 대해서는 노드 "A"로, N-Z로 시작하는 제품 이름에 대해서는 노드 "B"로 업데이트를 전송하게 만들 수 있습니다. 그런 다음 업데이트 내용이 다른 노드로 복제되도록 합니다.
  • 오른쪽 그림에서는 업데이트 내용이 모두 노드 "B"로 전송됩니다. 그런 다음 업데이트 내용이 노드 "A"로 복제됩니다. "B"가 유지 관리 등의 이유로 오프라인 상태인 경우 응용 프로그램 서버는 모든 작업을 "A"로 전송할 수 있습니다. "B"가 다시 온라인 상태가 되면 업데이트 내용을 이동할 수 있으며 응용 프로그램 서버는 모든 업데이트 내용을 다시 "B"로 이동하거나 계속 "A"로 전송할 수 있습니다.

피어 투 피어 복제에는 두 가지 방법이 모두 지원되지만 표준 트랜잭션 복제에서는 오른쪽의 중앙 업데이트 예가 주로 사용됩니다.

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

여러 위치로 피어 투 피어 복제

위의 그림에서는 LA, 런던 및 타이베이에 지사가 있는 전세계적 소프트웨어 기술 지원 업체에 백엔드를 제공하는 3개의 참여하는 데이터베이스를 보여 줍니다. 각 지사의 기술 지원 엔지니어는 고객의 전화를 받으며 각 통화에 대한 정보를 입력하고 업데이트합니다. 세 지사의 표준 시간대는 8시간씩 차이가 나므로 업무 시간이 중복되지 않습니다. 타이베이 지사가 업무를 마감하면 런던 지사가 업무를 시작합니다. 한 지사가 업무를 마감할 때 진행 중인 통화가 있으면 해당 통화는 다음으로 업무가 시작되는 지사의 담당자에게 전송됩니다.

각 위치에는 데이터베이스와 응용 프로그램 서버가 있어 기술 지원 엔지니어가 고객 통화에 대한 정보를 입력하고 업데이트할 때 사용할 수 있습니다. 토폴로지는 시간별로 분할되므로 현재 업무를 진행 중인 노드에서만 업데이트가 발생합니다. 그런 다음 업데이트 내용이 참여하는 다른 데이터베이스로 이동됩니다. 이러한 토폴로지를 사용하면 다음과 같은 이점이 있습니다.

  • 격리하지 않아도 독립적으로 운영될 수 있습니다. 각 지사에서는 데이터를 독립적으로 삽입, 업데이트 또는 삭제할 수 있지만 참여하는 다른 모든 데이터베이스에 데이터가 복제되므로 데이터를 공유할 수 있습니다.
  • 참여하는 데이터베이스 중 하나에 오류가 발생하거나 유지 관리가 필요한 경우에도 가용성이 높습니다.
    피어 투 피어 복제, 3-4노드

위의 그림에서는 3개의 노드 토폴로지에 노드를 하나 더 추가하는 것을 보여 줍니다. 다음 시나리오에서 노드를 추가할 수 있습니다.

  • 다른 지사가 개설되었습니다.
  • 치명적인 오류 발생 시 내결함성을 높이기 위해 또는 유지 관리를 지원하기 위해 더 높은 가용성을 제공하려고 합니다.
  • 3개의 노드 토폴로지 및 4개의 노드 토폴로지의 경우 모두에 모든 데이터베이스가 다른 모든 데이터베이스를 게시하고 구독하므로 하나 이상의 노드에 유지 관리가 필요하거나 오류가 발생하는 경우 최대 가용성을 제공합니다. 노드를 추가한 다음에는 성능과 배포 및 관리의 복잡성과 가용성 및 확장성 요구 사이에서 균형을 유지해야 합니다.

피어 투 피어 복제 구성

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

피어 투 피어 트랜잭션 복제를 구성하려면

피어 투 피어 복제 사용 시 고려 사항

피어 투 피어 복제 사용 시 다음 사항을 고려하십시오.

일반적인 고려 사항

  • 피어 투 피어 복제는 SQL Server 2005 Enterprise Edition에서만 사용할 수 있습니다.
  • 참여하는 모든 데이터베이스에는 동일한 스키마와 데이터가 포함되어야 합니다.
    • 참여하는 모든 데이터베이스의 개체 이름, 개체 스키마 및 게시 이름이 서로 동일해야 합니다.
    • 게시에서 스키마 변경 내용을 복제(게시 속성 replicate_ddl을 기본값인 1로 설정)할 수 있어야 합니다. 자세한 내용은 게시 데이터베이스의 스키마 변경을 참조하십시오.
    • 행 및 열 필터링은 지원되지 않습니다.
  • 각 노드가 고유한 배포 데이터베이스를 사용하는 것이 좋습니다. 이렇게 하면 단일 지점에서 오류가 발생할 가능성이 없어집니다.
  • 테이블 및 기타 개체는 단일 게시 데이터베이스 내의 여러 피어 투 피어 게시에 포함될 수 없습니다.
  • 구독을 만들려면 먼저 게시에 피어 투 피어 복제를 사용할 수 있도록 설정해야 합니다.
  • 백업이나 'replication support only' 옵션을 사용하여 구독을 초기화해야 합니다. 자세한 내용은 스냅숏 없이 트랜잭션 구독 초기화를 참조하십시오.
  • 충돌 감지 및 해결 기능은 제공되지 않습니다. 지정된 행에 대한 업데이트는 데이터베이스가 해당 피어와 동기화될 때까지 한 데이터베이스에서만 수행되어야 합니다. 예를 들어 응용 프로그램에서 행 집합에 대한 업데이트를 특정 노드로 전송하도록 하여 이를 수행할 수 있습니다.
  • ID 열은 사용하지 않는 것이 좋습니다. ID를 사용하는 경우 참여하는 각 데이터베이스에서 테이블에 할당된 범위를 수동으로 관리해야 합니다. 자세한 내용은 ID 열 복제 항목의 "ID 범위 수동 관리를 위한 범위 할당" 섹션을 참조하십시오.

기능 제한

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

  • 스냅숏을 사용하여 초기화 및 다시 초기화
  • 행 및 열 필터
  • 타임스탬프 열
  • 비-SQL Server(Non-SQL Server) 게시자 및 구독자
  • 즉시 구독 업데이트 및 지연 구독 업데이트
  • 익명 구독
  • 부분 구독
  • 연결 가능한 구독 및 변환 가능한 구독(모두 SQL Server 2005에서 사용되지 않음)
  • 공유 배포 에이전트
  • 배포 에이전트 매개 변수 -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 값은 'none' 또는 'automatic'이어야 합니다.

유지 관리 고려 사항

변경 내역

릴리스 내역

2006년 12월 12일
변경된 내용
  • 이 기능은 SQL Server 2005 Enterprise Edition에서만 사용할 수 있다는 사실을 명시했습니다.

2006년 7월 17일
변경된 내용
  • 피어 투 피어 복제에서 사용할 수 있는 트랜잭션 복제 기능에 대한 정보를 업데이트했습니다.

참고 항목

개념

스냅숏 및 트랜잭션 복제의 백업 및 복원을 위한 전략
트랜잭션 복제에 대한 게시 유형

관련 자료

How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)

도움말 및 정보

SQL Server 2005 지원 받기