트랜잭션 복제를 위한 업데이트 가능 구독
적용 대상: SQL Server
참고 항목
이 기능은 2012부터 2016까지의 SQL Server 버전에서 계속 지원됩니다. SQL Server의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 애플리케이션은 수정하세요.
트랜잭션 복제는 업데이트 가능 구독 및 피어 투 피어 복제를 통해 구독자에서 업데이트를 지원합니다. 다음은 두 가지 유형의 업데이트 가능 구독입니다.
즉시 업데이트. 구독자에서 데이터를 업데이트하려면 게시자와 구독자를 연결해야 합니다.
지연 업데이트: 구독자에서 데이터를 업데이트하려면 게시자와 구독자를 연결하지 않아도 됩니다. 구독자 또는 게시자가 오프라인 상태일 때 업데이트를 수행할 수 있습니다.
구독자에서 데이터가 업데이트되면 먼저 게시자에 전파된 다음 다른 구독자에게 전파됩니다. 즉시 업데이트를 사용하는 경우 변경 내용은 2단계 커밋 프로토콜을 사용하여 즉시 전파됩니다. 큐에 대기 중인 업데이트가 사용되는 경우 변경 내용은 큐에 저장됩니다. 그러면 네트워크 연결을 사용할 수 있을 때마다 큐에 대기 중인 트랜잭션이 게시자에서 비동기적으로 적용됩니다. 업데이트가 게시자에 비동기적으로 전파되기 때문에 동일한 데이터가 게시자 또는 다른 구독자에 의해 업데이트되었을 수 있으며 업데이트를 적용할 때 충돌이 발생할 수 있습니다. 게시를 만들 때 설정된 충돌 해결 정책에 따라 충돌이 감지되고 해결됩니다.
새 게시 마법사에서 업데이트할 수 있는 구독이 있는 트랜잭션 게시를 만드는 경우 즉시 업데이트와 지연 업데이트를 모두 설정할 수 있습니다. 저장 프로시저를 사용하여 게시를 만드는 경우 하나 또는 두 가지 옵션을 모두 사용하도록 설정할 수 있습니다. 게시에 대한 구독을 만들 때 사용할 업데이트 모드를 지정합니다. 그런 다음 필요한 경우 업데이트 모드 간에 전환할 수 있습니다. 자세한 내용은 다음 섹션 "업데이트 모드 간 전환"을 참조하세요.
트랜잭션 게시에 업데이트할 수 있는 구독을 사용하도록 설정하려면 트랜잭션 게시 에 대한 업데이트 구독을 사용하도록 설정합니다.
트랜잭션 게시에 대해 업데이트할 수 있는 구독을 만들려면 트랜잭션 게시에 업데이트할 수 있는 구독 만들기(Management Studio)를 참조하세요.
업데이트 모드 간 전환
업데이트할 수 있는 구독을 사용할 때는 구독에서 특정 업데이트 모드를 사용하도록 지정한 다음 애플리케이션의 필요에 따라 다른 업데이트 모드로 전환할 수 있습니다. 예를 들어 구독에서 즉시 업데이트를 사용하도록 지정할 수 있지만 시스템 오류로 인해 네트워크 연결이 끊어지면 대기 중인 업데이트로 전환할 수 있습니다.
참고 항목
복제는 업데이트 모드 간에 자동으로 전환되지 않습니다. SQL Server Management Studio를 통해 업데이트 모드를 설정해야 합니다. 또는 애플리케이션이 모드 간을 전환하기 위해 sp_setreplfailovermode(Transact-SQL)를 호출해야 합니다.
즉시 업데이트에서 대기 중인 업데이트로 전환하는 경우 구독자와 게시자가 연결되고 큐 판독기 에이전트가 큐의 보류 중인 모든 메시지를 게시자에 적용할 때까지 즉시 업데이트로 다시 전환할 수 없습니다.
업데이트 모드 간에 전환하려면
업데이트 모드 간에 전환하려면 두 업데이트 모드에 대해 게시와 구독을 사용하도록 설정한 다음 필요한 경우 모드 간에 전환해야 합니다. 자세한 내용은 다음을 참조하세요.
업데이트 가능 트랜잭션 구독에 대한 업데이트 모드 전환
업데이트 가능 구독 사용에 대한 고려 사항
구독 업데이트 또는 지연 업데이트 구독에 게시를 사용하도록 설정한 후에는 게시에 대해 옵션을 사용하지 않도록 설정할 수 없습니다(구독에서 사용할 필요는 없음). 이 옵션을 사용하지 않도록 설정하려면 게시를 삭제하고 새로 만들어야 합니다.
데이터 다시 게시는 지원되지 않습니다.
복제는 추적을 위해 게시된 테이블에 msrepl_tran_version 열을 추가합니다. 이 추가 열로 인해 모든 INSERT 문에는 열 목록이 포함되어야 합니다.
구독 업데이트를 지원하는 게시의 테이블에서 스키마를 변경하려면 스키마를 변경하기 전에 게시자 및 구독자에서 테이블의 모든 활동을 중지하고 보류 중인 데이터 변경 사항을 모든 노드에 전파해야 합니다. 이렇게 하면 미해결 트랜잭션이 보류 중인 스키마 변경과 충돌하지 않습니다. 스키마 변경을 모든 노드로 전파하면 게시된 테이블에 대한 작업을 재개할 수 있습니다. 자세한 내용은 복제 토폴로지 정지(복제 Transact-SQL 프로그래밍)를 참조하세요.
업데이트 모드 간에 전환하려는 경우 구독이 초기화된 후 큐 판독기 에이전트를 한 번 이상 실행해야 합니다(기본적으로 큐 판독기 에이전트는 지속적으로 실행됨).
구독자 데이터베이스가 수평으로 분할되고 파티션에 구독자에는 존재하면서 게시자에는 없는 행이 있다면 구독자는 기존 행을 업데이트할 수 없습니다. 이러한 행을 업데이트하려고 하면 오류가 발생합니다. 테이블에서 이 행을 삭제한 다음 게시자에서 추가해야 합니다.
고유한 필터링된 인덱스를 사용하는 경우 대기 중인 업데이트 가능 구독자를 사용한 트랜잭션 복제의 성능이 저하될 수 있습니다. 고유한 필터링된 인덱스가 있는 아티클에서 충돌이 발생하면 충돌 해결로 인해 필터링된 고유 인덱스가 적용되지 않는 행에 대한 구독자에 대한 추가 삭제 및 삽입이 발생합니다.
구독자에서의 업데이트
구독이 만료되었거나 비활성 상태인 경우에도 구독자의 업데이트가 게시자에 전파됩니다. 이러한 구독이 삭제되거나 다시 초기화되었는지 확인합니다.
TIMESTAMP 또는 IDENTITY 열을 사용하고 이러한 열이 자체 기본 데이터 형식으로 복제되는 경우에는 이러한 열의 값을 구독자에서 업데이트할 수 없습니다.
복제 변경 내용 추적 트리거 내의 삽입되거나 삭제된 테이블에서 읽을 수 없으므로 구독자는 text, ntext 또는 image 값을 업데이트하거나 삽입할 수 없습니다. 마찬가지로 게시자가 데이터를 덮어쓰므로 구독자는WRITETEXT 또는 UPDATETEXT를 사용하여 text 또는 image 값을 업데이트하거나 삽입할 수 없습니다. 대신 text 및 image 열을 별개의 테이블에 분할할 수 있고 트랜잭션 내에서 두 테이블을 수정할 수 있습니다.
구독자에서 큰 개체를 업데이트하려면 text, ntext및 image 데이터 형식 대신 varchar(max), nvarchar(max)및 varbinary(max) 데이터 형식을 사용합니다.
중복을 생성하는 고유 키(기본 키 포함)에 대한 업데이트(예: 양식
UPDATE <column> SET <column> =<column>+1
업데이트는 허용되지 않으며 고유성 위반으로 인해 거부됨). 이는 구독자에서의 업데이트 설정이 영향을 받는 각 행에 대한 개별 UPDATE 문으로 복제에 의해 전파되기 때문입니다.구독자 데이터베이스가 수평으로 분할되고 파티션에 구독자에는 존재하면서 게시자에는 없는 행이 있다면 구독자는 기존 행을 업데이트할 수 없습니다. 이러한 행을 업데이트하려고 하면 오류가 발생합니다. 행을 테이블에서 삭제하고 다시 삽입해야 합니다.
사용자 정의 트리거
애플리케이션에 구독자에서 트리거가 필요한 경우 트리거는 게시자 및 구독자의
NOT FOR REPLICATION
옵션으로 정의해야 합니다. 이렇게 하면 원래 데이터 변경에 대해서만 트리거가 발생하지만 해당 변경 내용이 복제되는 경우에만 트리거가 발생합니다.복제 트리거가 테이블을 업데이트할 때 사용자 정의 트리거가 실행되지 않는지 확인합니다. 이는 사용자 정의 트리거 본문에서 sp_check_for_sync_trigger 프로시저를 호출하여 수행할 수 있습니다. 자세한 내용은 sp_check_for_sync_trigger(Transact-SQL)를 참조하세요.
즉시 업데이트
즉시 업데이트 구독의 경우 구독자의 변경 내용이 게시자에 전파되고 MS DTC(Microsoft Distributed Transaction Coordinator)를 사용하여 적용됩니다. MS DTC가 게시자 및 구독자에 설치 및 구성되었는지 확인합니다. 자세한 내용은 Windows 설명서 를 참조하십시오.
구독을 즉시 업데이트하는 데 사용되는 트리거는 변경 내용을 복제하기 위해 게시자에 대한 연결이 필요합니다.
게시에서 구독을 즉시 업데이트할 수 있고 게시의 아티클에 열 필터가 있는 경우 기본값 없이 null을 허용하지 않는 열을 필터링할 수 없습니다.
대기 중 업데이트
병합 게시에 포함된 테이블은 대기열 업데이트 구독을 허용하는 트랜잭션 게시의 일부로도 발행할 수 없습니다.
기본 키는 모든 쿼리에 대한 레코드 로케이터로 사용되므로 대기 중인 업데이트를 사용하는 경우 기본 키 열에 대한 업데이트는 권장되지 않습니다. 충돌 해결 정책이 구독자 우선으로 설정된 경우 기본 키에 대한 업데이트는 주의해야 합니다. 기본 키에 대한 업데이트가 게시자와 구독자 모두에서 이루어지면 결과는 서로 다른 기본 키를 가진 두 개의 행이 됩니다.
데이터 형식이 SQL_VARIANT인 열의 경우: 데이터를 구독자에서 삽입하거나 업데이트하면 해당 데이터가 구독자에서 큐로 복사될 때 큐 판독기 에이전트에 의해 다음과 같은 방식으로 매핑됩니다.
BIGINT, DECIMAL, NUMERIC, MONEY및 SMALLMONEY 는 NUMERIC으로 매핑됩니다.
BINARY 및 VARBINARY는 VARBINARY 데이터에 매핑됩니다.
충돌 감지 및 해결
"구독자 내용 적용" 충돌 정책을 사용하는 경우: 기본 키 열에 대한 업데이트에 대해서는 충돌 해결이 지원되지 않습니다.
외래 키 제약 조건 오류로 인한 충돌은 복제를 통해 해결되지 않습니다.
충돌이 예상되지 않고 데이터가 잘 분할된 경우(구독자는 동일한 행을 업데이트하지 않음) 게시자와 구독자에서 외래 키 제약 조건을 사용할 수 있습니다.
충돌이 예상되는 경우: "구독자 우선" 충돌 해결을 사용하는 경우 게시자 또는 구독자에서 외래 키 제약 조건을 사용하면 안 됩니다. "게시자 우선" 충돌 해결을 사용하는 경우 구독자에서 외래 키 제약 조건을 사용하면 안 됩니다.