데이터베이스 백업 및 복원
프로덕션 데이터베이스와 마찬가지로 동기화에 포함되는 데이터베이스도 정기적으로 백업해야 합니다. 백업에서 데이터베이스를 복원해야 하는 경우에는 다음과 같은 두 가지 주요 사항을 고려해야 합니다.
복원 후에 데이터베이스에서 수행한 변경 내용이 클라이언트나 다른 피어로 전파되지 않았을 수 있습니다. 이는 데이터베이스에서 변경 내용을 선택할 때 사용되는 timestamp 값 때문입니다.
예를 들어 클라이언트 및 서버 동기화 중에 Sync Framework는 서버 데이터베이스에서 새 앵커 값을 검색하여 클라이언트 데이터베이스에 저장합니다. 이 값은 동기화 중인 현재 변경 내용 집합의 상한으로 사용됩니다. 자세한 내용은 서버 데이터베이스의 변경 내용 추적를 참조하십시오. 서버 데이터베이스를 복원하고 나면 클라이언트 데이터베이스에 저장되는 값이 서버 데이터베이스에서 반환되는 값보다 논리적으로 앞에 올 수 있습니다.
업로드 및 양방향 시나리오의 경우 클라이언트나 다른 피어에는 새로 복원된 데이터베이스에 없는 변경 내용이 있을 수 있습니다.
이 항목의 예제에서는 클라이언트 및 서버 동기화를 예제로 사용합니다. 유사한 원칙이 피어 투 피어 동기화에 적용되며 피어 투 피어에서 고려할 사항도 설명됩니다. 서버 데이터베이스는 원격 피어입니다. 클라이언트 데이터베이스는 로컬 피어입니다. SqlSyncProvider를 사용하여 동기화된 SQL Server 데이터베이스의 백업 및 복원에 대한 자세한 내용은 방법: 데이터베이스 백업 및 복원(SQL Server)을 참조하십시오.
서버 데이터베이스
클라이언트 데이터베이스가 서버 데이터베이스보다 어떻게 논리적으로 앞설 수 있는지 이해하기 위해 Sync Framework 샘플 데이터베이스의 Sales.Customer 테이블에서 업데이트가 추적되는 방식을 살펴봅니다. UpdateTimestamp 열에는 timestamp 값이 저장되며 새 앵커 명령은 SQL Server MIN_ACTIVE_ROWVERSION 함수에서 값을 반환합니다. 예제에서는 개념을 명확하게 파악할 수 있도록 16진수 값 대신 정수가 사용되었습니다.
데이터베이스가 복원되기 전에 MIN_ACTIVE_ROWVERSION은 값 31을 반환합니다. 이 값은 클라이언트 데이터베이스에 마지막으로 받은 앵커로 저장되었습니다.
데이터베이스가 복원되고 나면 MIN_ACTIVE_ROWVERSION은 값 19를 반환합니다.
UpdateTimestamp 열의 timestamp 값이 32에 도달하도록 업데이트가 수행됩니다.
동기화가 발생하고 MIN_ACTIVE_ROWVERSION이 값 32를 반환합니다. 32가 마지막으로 받은 앵커 값 31보다 크기 때문에 Sales.Customer의 최종 업데이트가 다운로드됩니다. 19와 31 사이의 업데이트는 변경 내용으로 인식되지 않습니다.
타임스탬프 등의 논리 시계를 사용하는 추적 체계의 경우 이와 같이 변경 내용이 인식되지 않는 문제가 발생할 수 있습니다. 날짜 및 시간 기반의 데이터 형식을 사용하는 추적 체계의 경우에는 실제 시계가 데이터베이스의 상태와 독립적으로 앞으로 이동하기 때문에 이러한 문제가 발생하지 않습니다. 피어 투 피어 동기화에서는 타임스탬프가 변경 내용 추적에 필요합니다.
타임스탬프로 인해 발생하는 문제를 처리하려면 다음 방법 중 하나를 사용하십시오.
서버 타임스탬프를 복원 작업이 수행되기 전의 지점까지 이동합니다. 위의 예제에서는 MIN_ACTIVE_ROWVERSION이 31을 반환할 때까지 별도의 테이블에서 더미 업데이트를 수행할 수 있습니다.
이는 피어 투 피어 동기화에 권장되는 방법입니다.
서버에서 각 클라이언트에 대한 앵커를 저장합니다. 위 예제의 경우 백업에서 마지막으로 받은 앵커는 19가 됩니다. 그러므로 후속 업데이트가 인식되고 19에서 32 사이의 모든 변경 내용도 다운로드됩니다. Sync Framework에서는 기본적으로 이 기능을 지원하지 않지만 다음과 같은 방식으로 서버에서 시스템을 만들 수 있습니다.
각 클라이언트에 대한 행이 포함된 테이블을 서버 데이터베이스에 만듭니다. 이 테이블에는 Sync Framework에서 각 클라이언트에 대해 생성하는 ID가 포함된 열과 해당 클라이언트의 앵커가 포함된 열이 들어 있습니다. 동기화 중에 응용 프로그램은 이 열을 새 앵커 값으로 업데이트합니다.
동기화 중인 클라이언트에 대해 가장 낮은 앵커 값을 선택하도록 동기화 명령을 변경합니다. 이 값은 클라이언트 데이터베이스에 저장되는 값 또는 서버 데이터베이스에 저장되는 값일 있습니다. 데이터베이스 복원 작업을 수행하고 나면 서버 데이터베이스의 값이 더 작아야 합니다. 서버 테이블에 값을 쓰고 나서 클라이언트에 변경 내용을 적용하기 전에 오류가 발생하면 클라이언트 데이터베이스의 값이 더 낮은 것입니다. 동기화가 정상적으로 수행되는 경우에는 두 값이 서로 같습니다. 삽입 명령은 다음과 같이 작성할 수 있습니다.
SELECT CustomerId, CustomerName, SalesPerson, CustomerType FROM Sales.Customer WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id) OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor AND InsertId <> @sync_client_id
클라이언트 데이터베이스
동기화 메타데이터 측면에서 서버 데이터베이스를 현재 시점까지 복원해도 서버 백업을 수행한 이후 클라이언트에서 수행한 변경 내용이 데이터베이스에서 누락되어 있을 수 있습니다. 클라이언트는 적절히 응답하기 위해 서버 데이터베이스가 복원되었음을 알아야 합니다. 특정 클라이언트가 마지막으로 동기화된 이후 복원이 발생했는지 여부를 나타내는 서버측 추적 테이블을 사용할 수 있습니다. 각 동기화 세션 중에 클라이언트 응용 프로그램에서는 먼저 이 테이블을 검사하여 일반적으로 동기화될 수 있는지, 아니면 특수 코드를 실행하여 복원된 데이터베이스로 작업해야 할지를 확인합니다.
클라이언트 응용 프로그램에서는 서버 데이터베이스가 복원되었음을 인식한 후 클라이언트 및 서버 데이터베이스를 수렴할 수 있습니다. 이 작업을 수행하는 방법은 다음을 비롯하여 몇 가지가 있습니다.
모든 테이블을 삭제한 다음 서버와 동기화하여 클라이언트 데이터베이스를 다시 초기화합니다. 이 방법이 가장 쉽지만 클라이언트에서의 변경 내용이 모두 손실됩니다.
다시 초기화하는 방법이 피어 투 피어 동기화에 권장됩니다. 피어 데이터베이스 초기화에 대한 자세한 내용은 방법: 공동 작업 동기화 구성 및 실행(SQL Server 이외)에서 "서버 데이터베이스 초기화"를 참조하십시오.
클라이언트 테이블의 복사본을 만든 후 클라이언트 데이터베이스를 다시 초기화합니다. 응용 프로그램에서 다음과 같은 단계를 사용할 수 있습니다.
서버 데이터베이스가 복원되었음을 확인합니다.
클라이언트 데이터베이스에 있는 모든 테이블의 복사본을 만든 다음 원래 테이블을 삭제합니다.
서버와 동기화하여 새 스키마와 데이터를 다운로드합니다.
새 테이블의 행을 만들어진 복사본과 비교합니다.
두 테이블 집합의 차이점을 식별하고 필요한 모든 변경 내용을 새 테이블에 적용합니다.
다시 동기화하여 새 테이블에 적용된 변경 내용을 업로드합니다.