데이터 다시 게시

적용 대상:SQL ServerAzure SQL Managed Instance

재게시 모델에서 게시자는 구독자로 데이터를 보내고 구독자는 다른 모든 구독자에 데이터를 다시 게시합니다. 이는 게시자가 느리거나 비용이 많이 드는 통신 링크를 통해 구독자에게 데이터를 보내야 하는 경우에 유용합니다. 해당 링크의 먼 쪽에 구독자가 많은 경우 다시 게시자를 사용하면 대량의 배포 부하가 링크의 해당 측면으로 이동합니다.

데이터를 다시 게시하려면 다음 단계를 수행합니다.

1. 게시자에서 게시를 만듭니다.

2. 재게시 구독자에 대한 게시에 대한 구독을 만듭니다.

3. 구독을 초기화합니다. 게시가 다시 게시 구독자에서 생성되기 전에 구독을 초기화해야 합니다. 그렇지 않으면 복제본(replica) 실패합니다.

4. 구독 데이터베이스의 재게시 구독자에서 게시를 만듭니다.

5. 다른 구독자에 대해 재게시 구독자에서 게시에 대한 구독을 만듭니다.

6. 구독을 초기화합니다.

다음 그림에서는 게시자와 재게시자가 모두 자체 로컬 배포자로 작동합니다. 여기에 원격 배포자를 설정하면 각 배포자는 속도가 느리거나 비용이 많이 드는 통신 연결의 같은 쪽에 게시자로 있어야 합니다. 게시자는 안정적인 고속 통신 연결로 배포자에 연결되어야 합니다.

모든 서버는 게시자와 구독자 모두의 역할을 할 수 있습니다. 예를 들어 테이블에 대한 게시가 런던에 있고 미국 4개 도시(시카고, 뉴욕, 샌디에이고 및 시애틀)에 배포되어야 하는 다이어그램을 고려해 보세요. 이 경우 다음과 같이 뉴욕 사이트가 조건에 맞기 때문에 뉴욕에 있는 서버를 런던에서 시작된 게시된 테이블로 구독하도록 선택합니다.

• 런던으로 돌아가는 네트워크 링크는 비교적 안정적입니다.

• 런던-뉴욕 통신 비용은 허용됩니다.

• 뉴욕에서 미국 다른 모든 구독자 사이트로 가는 좋은 네트워크 통신 라인이 있습니다.

  

복제는 다음 표에 나와 있는 재게시 시나리오를 지원합니다.

*병합 게시에서 @published_in_tran_pub 속성을 설정해야 합니다. 기본적으로 트랜잭션 복제에서 구독자의 테이블은 읽기 전용으로 처리됩니다. 병합 복제에서 트랜잭션 구독의 테이블 데이터를 변경하는 경우 데이터가 일치하지 않을 수 있습니다. 이러한 위험을 방지하려면 병합 게시에서 이러한 테이블을 다운로드 전용으로 지정하는 것이 좋습니다. 이렇게 하면 병합 구독자가 테이블에 데이터 변경 내용을 업로드할 수 없습니다. 자세한 내용은 다운로드 전용 아티클로 병합 복제 성능 최적화를 참조하세요.

참고 항목

배포 구성
데이터 및 데이터베이스 개체 게시
게시 구독
구독 초기화
데이터 동기화