사이트 간 VPN을 넘는 push 및 pull 복제 에이전트

에이전트의 위치, 즉 데이터의 위치가 아니라 에이전트의 위치가 SQL Server 구독을 결정하는 요인입니다. 에이전트를 실행하는 컴퓨터가 연결을 열고, 특정 계정으로 실행되며, 동기화가 멈출 때 책임을 집니다. 사이트 간 VPN에서 그 차이는 세부 사항이 아니라 설계 그 자체입니다. 네트워크를 그리기 전에 에이전트 연결을 그리십시오.

세 가지 역할, 두 가지가 아닙니다

Publisher는 아티클 데이터를 소유하고, Distributor는 배포 데이터베이스를 소유하며, Subscriber는 변경 내용을 받습니다. Log Reader Agent는 트랜잭션 복제를 위해 Distributor에서 실행됩니다. Distribution Agent는 구독 유형에 따라 위치가 바뀌는 에이전트이며, 그래서 네트워크 설계를 좌우합니다. VPN 규칙을 논하기 전에 이 역할들을 정리하십시오.

push 구독은 Distribution Agent를 Distributor에서 실행하고, pull 구독은 그것을 Subscriber에서 실행하는데, 이는 Microsoft의 구독 문서에서 설명합니다. 네트워크 대화의 모든 것은 어느 컴퓨터인지에서 비롯됩니다. 구독마다 네 가지 사실을 적으십시오: 에이전트의 호스트, 프로세스 ID, 사용하는 데이터베이스 로그인, 도달해야 할 리소스. 다이어그램 화살표가 아니라 이 사실들이 어느 방향이 동작해야 하는지 알려 줍니다.

push는 에이전트가 Distributor에 산다는 뜻입니다

push 구독에서는 Distributor가 VPN을 넘어 Subscriber로 연결을 엽니다. 구독자 측의 수신기, 방화벽, SQL 로그인이 원격 측에서 오는 연결을 받아들여야 합니다. Distributor의 서비스 계정에는 구독자 데이터베이스에 대한 권한도 필요합니다. 구독을 만들기 전에 이 인바운드 경로를 계획해야 하는데, 나중에 발견하는 것은 보통 다시 만드는 일이기 때문입니다.

스냅샷 배포는 정상 상태 복제가 결코 사용하지 않는 경로를 추가합니다. 스냅샷이 파일 공유에 배치되어 있으면 Distribution Agent가 그 공유에서 읽고 구독자 계정이 같은 UNC 경로에 도달해야 합니다. 몇 주 동안 흐르는 변경 스트림은 재초기화가 동작할지에 대해 아무것도 말해 주지 않습니다. 그래서 스냅샷 공유는 처음부터 계획에 들어가야 합니다.

push를 단방향 트래픽으로 읽지 마십시오. 에이전트에는 응답, 승인, 그리고 자체 인증 교환이 필요합니다. 데이터가 한 방향으로 움직이더라도 경로는 연결 수준에서 양방향이어야 합니다.

pull은 에이전트가 Subscriber에 산다는 뜻입니다

pull 구독은 연결을 뒤집습니다: Subscriber가 Distribution Agent를 실행하고 Distributor에 접속합니다. 이 배치는 지사에서 나가는 연결을 허용하고 들어오는 연결을 차단하는 VPN 정책에 맞습니다. 또한 일정 결정을 지사 서버를 돌보는 사람의 손에 맡깁니다. 지사 팀이 자체 동기화를 소유하고 자체 실패를 알아차려야 할 때 이것을 고르십시오.

구독자의 SQL Server Agent 서비스 계정에는 배포 데이터베이스와 스냅샷 공유에 대한 읽기 권한이 필요합니다. 그 계정이 복제 오류에 나타나는 ID이며, 도메인 권한이 없는 로컬 서비스 계정은 네트워크 장애처럼 보이지만 실제로는 자격 증명 장애인 지점에서 실패합니다. 터널을 디버그하기 전에 계정을 확인하십시오. 로그인을 고치는 편이 네트워크의 무죄를 증명하는 것보다 대개 빠릅니다.

소유권은 에이전트를 따릅니다. 중앙 팀이 일정과 실패를 모두 소유해야 할 때 push를 고르십시오. 무엇을 고르든 구독 옆에 적어 두어 다음 엔지니어가 어디를 먼저 볼지 알 수 있게 하십시오.

재게시는 팬아웃을 바꿀 뿐 소유권은 바꾸지 않습니다

구독자를 추가 구독자에게 재게시하도록 구성할 수 있으며, 그러면 하나의 지사 데이터베이스가 각자 WAN을 넘어 당기지 않고 여러 로컬 소비자에게 서비스할 수 있습니다. 중간 데이터베이스는 이제 게시와 자체 에이전트를 보유합니다. 이전에는 없던 권한, 모니터링, 복구 계획도 상속합니다. 그 추가 역할이 반복되는 WAN 배포를 없애는 대가입니다.

문서화된 순서가 중요합니다: 다운스트림 게시를 만들기 전에 들어오는 구독을 초기화하십시오. 이것을 건너뛸 서류 작업이 아니라 검증이 따르는 수명 주기 단계로 다루십시오. 순서를 뒤집으면 구성된 것처럼 보이지만 아무것도 전달하지 않는 체인이 생깁니다.

쓰기 모델을 명시하십시오. 읽기 전용 데이터 세트를 로컬 소비자에게 복제하는 것은 여러 사이트에서 쓰기를 받아들이는 것과 다른 설계이며, 화살표 체인이 충돌 해결을 만들지는 않습니다. 지사가 써야 한다면 그것은 자체 토폴로지를 가진 별개의 결정입니다. 의존성도 드러내야 합니다: 재게시자가 멈추면 그 아래의 모든 소비자는 낡은 상태가 됩니다.

배치를 처음부터 끝까지 입증하십시오

기억을 믿는 대신 배포 데이터베이스에서 구독 유형을 읽고, 그다음 변경 내용이 실제로 도착하는지 확인하십시오:

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

subscription_type 값이 0이면 push이고 1이면 pull이며, 제자리에서 바꿀 수 없으므로 불일치는 구독을 편집하는 것이 아니라 다시 만드는 것을 뜻합니다. 보류 명령 호출은 선택한 에이전트가 작업을 옮기고 있는지 아니면 그저 실행 중인지 알려 줍니다. 구독자 테이블이 비어 있는데 보류 명령이 없다고 보고하는 구독은 백로그가 늘고 있다고 보고하는 구독과 다른 결함이며, 둘은 서로 다른 소유자에게 이어집니다.

실제 변경으로 마무리하십시오: Publisher에서 한 행을 삽입하거나 업데이트하고, 에이전트의 보고를 기다린 뒤 그 행을 Subscriber에서 읽으십시오. 에이전트가 어떻게 복구되는지 보려면 짧은 VPN 중단을 넘겨 한 번 더 해 보십시오. 그 테스트를 견디는 구독은 문서화하고 방어할 수 있는 배치를 갖습니다.