푸시 트랜잭션 복제를 사용하여 3 개의 원격 서버에 대용량 데이터베이스 (1TB에 가깝게)를 복제했습니다. 구독자는 읽기 전용입니다. 매월 하루에 많은 데이터가 다른 소스에서 삽입되고 업데이트됩니다. 하루가 지나면 복제가 항상 실패하고 매월 백업에서 수동으로 복제를 초기화합니다.트랜잭션 복제와 로그 전달을 혼합합니까?
삽입 일 전에 로그 전달으로 전환하고 대량 삽입을 로그 전달한 후 트랜잭션 복제로 다시 전환 할 수 있습니까? 따라서 재 초기화를 위해 큰 백업 파일을 복사 할 필요가 없습니까?
아니요. 로그 전달이 물리적 인 동안 트랜잭션 복제는 논리적입니다. 둘 사이에서 자유롭게 전환 할 수는 없습니다. 그러나 구독자가 처음으로 읽기 전용으로되어있는 경우 트랜잭션 복제는 업데이트가 약간 지연되고 로그가있을 때마다 대기 사이트에서 독자의 연결을 끊어야하는 비용으로 로그 전달이 가능한 상태로 교체 될 수 있습니다 적용됩니다 (대개 이것은 소리가 나지 않는 곳에는 거의 없습니다). 얼마나 효율적이고 덜 문제가되는 로그 전달이 트랜잭션 복제와 비교되는지를 감안할 때, 나는 이것을 대체하기 위해 1 초를 주저하지 않을 것입니다.
일정에 따라 초기화를 다시해야합니까? 필자는 복제 토폴로지를 다시 시작해야 할 필요없이 실제로 오랜 시간 동안 진행 시켰습니다. 그리고 우리가 그랬을 때, 그것은 좋은 플레이를하지 않는 스키마 변경이 있었기 때문이었습니다. 많은 양의 데이터가 복제에 실패했다고하면 그게 무슨 뜻입니까? 복제는 큰 데이터 변경 사항을 구독자에게 기꺼이 제공합니다. 대기 시간 제한이있는 경우 게시자에서 대기 시간을 늘리거나 큰 거래를 작은 거래로 나눌 수 있습니다. 또한 로그 판독기 에이전트에 대한 MaxCmdsInTran 옵션을 으로 설정하는 옵션이 있습니다.은 트랜잭션을 해독합니다.