Azure SQL 데이터 동기화는 선택된 테이블을 허브 데이터베이스와 하나 이상의 멤버 데이터베이스 간에 동기화 상태로 유지하는 데 일반적으로 사용됩니다. 때때로 **데이터 "간극"**을 발견할 수 있습니다. 이는 특정 시간대에 원본에는 존재하지만 대상에는 누락된 행의 하위 집합을 의미하며, 새로운 변경 사항에 대한 동기화는 그 이후로도 계속되지만 말이죠. 이 게시물은 고객이 동기화 그룹 내 단일 테이블에서 누락된 행을 보고하고, 누락된 레코드만 동기화하는 방법을 요청했던 실제 지원 시나리오를 바탕으로 지원되는 복구 패턴과 피해야 할 사항을 설명합니다.
시나리오: 데이터 동기화는 계속되지만 일부 행이 누락됨
참조된 사례에서 고객은 다음을 관찰했습니다:
- 특정 테이블에서 멤버 측에 간극(일정 기간 동안 누락된 행)이 있었지만, 그 이후의 새로운 데이터는 정상적으로 동기화되었습니다.
- 그들은 테이블을 재구축하거나 완전히 재초기화하지 않고, 누락된 행만 동기화하는 Microsoft 지원 방법을 문의했습니다.
이는 합리적인 목표이지만, Data Sync는 서비스 관리형 추적 아티팩트에 의존하므로 복구 방법이 중요합니다.
유혹: "추적 테이블을 편집하거나 내부 트리거를 호출하여 누락된 데이터를 푸시할 수 있을까요?"
자주 제기되는 아이디어는 내부 아티팩트를 조작하여 Data Sync가 누락된 행을 "강제로" 가져가도록 하는 것입니다:
- Data Sync 추적 테이블(예: DataSync 스키마 아래의
*_dss_tracking테이블)에 직접 쓰거나 프로비저닝 마커를 변경하는 것. - Data Sync가 생성한 트리거를 수동으로 호출하거나 내부 로직에 의존하는 것. 이 사례 논의에서는 특히
_dss_insert_trigger,_dss_update_trigger,_dss_delete_trigger와 같은 내부 트리거를 언급했습니다.
왜 이것이 권장되지 않거나 고객용 솔루션으로 지원되지 않는가
해당 사례에서 Microsoft 엔지니어링 팀의 지침은 명확했습니다:
- 내부 Data Sync 트리거를 수동으로 호출하는 것은 지원되지 않으며 이러한 트리거는 런타임에 서비스에서 생성되며 수동 사용을 위한 것이 아니므로 데이터 손상 위험을 높일 수 있습니다.
- Data Sync 추적/메타데이터 테이블을 직접 조작하는 것은 권장되지 않습니다. 고객 스레드에서도 이러한 추적 테이블이 Data Sync 내부의 일부이며, 수동 "푸시" 시나리오에 사용하는 것은 지원되는 접근 방식이 아니라고 강조합니다.
또한, 고객과의 대화는 중요한 개념적 요점을 강조합니다: 추적 테이블은 서비스가 변경 사항을 추적하는 방식의 일부이며, 사용자가 관리하는 복제 큐로 취급되어서는 안 됩니다.
지원되는 복구 옵션 #1 (권장): 기본 테이블을 통해 변경 감지 재실행
가장 지원 가능한 접근 방식은 Data Sync가 정상적인 변경 추적 경로를 통해 누락된 행을 감지하도록 하는 것입니다. 즉, 서비스 관리 내부가 아닌 기본/원본 테이블에 대해 작업하는 것입니다.
실용적인 패턴: 추적 재시작을 위한 "No-op 업데이트"
제품 팀과의 내부 논의에서 권장된 패턴은 내부 트리거를 수동으로 호출하지 않고, Data Sync의 정상적인 추적 로직이 트리거되도록 원본/기본 테이블을 업데이트(심지어 "no-op" 할당으로도)하는 것이었습니다.
예시 패턴 (개념적):
UPDATE t
SET some_column = some_column -- no-op: 값 변경 없음
FROM dbo.YourTable AS t
WHERE <대상에서 누락된 행을 식별하는 필터>;
이 접근 방식은 지원되는 메커니즘을 통해 변경 감지를 안전하게 "재구동"하는 방법으로 스레드에서 명시적으로 언급되었습니다.
운영 지침 (실용적):
- 특히 큰 테이블의 경우 트랜잭션/로그 영향을 줄이고 장기 실행 작업을 피하기 위해 작은 배치로 업데이트를 적용합니다.
- 먼저 영향받는 행 집합을 검증합니다 (예: 허브와 멤버 간의 키 비교).
지원되는 복구 옵션 #2: 영향받는 테이블의 프로비저닝 해제 및 재프로비저닝 (안전한 "재설정" 경로)
간극이 크거나, 행 집합을 격리하기 어렵거나, 추적 아티팩트의 깨끗한 재정렬을 원하는 경우, 해당 사례에서 논의된 운영 접근 방식은 다음과 같습니다:
- 동기화 중지
- 동기화 그룹에서 테이블 제거 (서비스가 추적 개체를 프로비저닝 해제하도록 함)
- 필요에 따라 대상 상태 수정/정리
- 테이블을 다시 추가하고 Data Sync가 재프로비저닝 및 재동기화하도록 함
이 옵션은 시스템 관리 아티팩트를 직접 건드리는 것을 피하려는 경우 가장 안전한 경우가 많습니다.
참고: 프로덕션 환경에서는 운영 제약으로 인해 고객이 테이블을 잘라내거나 비울 수 없을 수도 있습니다. 이 경우 서비스가 더 많은 행별 평가를 수행해야 할 수 있으므로 동기화 시간이 더 오래 걸릴 수 있습니다. 이 "트레이드오프"는 해당 사례의 맥락에서 논의되었습니다.
진단: Azure SQL Data Sync 상태 검사기 사용
메타데이터 드리프트, 누락된 개체 또는 프로비저닝 불일치가 의심될 때, 해당 사례에서는 AzureSQLDataSyncHealthChecker 스크립트 사용을 권장했습니다.
이 도구는 다음을 수행합니다:
- 동기화 메타데이터 데이터베이스에 대해 허브/멤버 메타데이터 및 스코프를 검증합니다.
- 누락된 아티팩트 및 기타 불일치를 강조할 수 있는 로그를 생성합니다.
- Data Sync 문제 해결을 더 빠르게 돕기 위한 것입니다.
"간극" 발생의 가능성 있는 원인: Data Sync 중 스키마 변경 (스냅샷 격리 충돌)
해당 사례 논의에서 원격 분석은 동기화 프로세스가 변경 사항을 열거하는 동안 발생하는 동시 DDL/스키마 변경(스냅샷 격리 + 메타데이터 변경)과 일치하는 오류를 언급했습니다.
관련된 잘 알려진 오류는 SQL Server 오류 3961입니다. 이는 스냅샷 격리 트랜잭션이 메타데이터가 동시 DDL 문에 의해 수정되었기 때문에 실패할 때 발생합니다. 메타데이터는 버전 관리되지 않기 때문입니다. Microsoft는 이 동작을 문서화하고 메타데이터 변경이 스냅샷 격리 의미 체계와 충돌하는 이유를 설명합니다.
예방 지침 (실용적)
- 활성 동기화 기간 동안 스키마 배포(DDL) 실행을 피하세요.
- Data Sync와 함께 스키마 변경을 위한 통제된 워크플로를 사용하세요. 동기화 도중 메타데이터 변경을 방지하기 위해 변경 사항을 일시 중지/조정합니다. (지속적인 Data Sync 작업 및 유지 관리를 위한 일반적인 모범 사례가 존재합니다.)
주요 요점
- Data Sync 추적 테이블/트리거를 사용자 관리 "복제 내부"로 취급하지 마십시오. 내부 트리거를 수동으로 호출하거나 추적 테이블을 편집하는 것은 고객용 지원 복구 메커니즘이 아닙니다.
- 간극을 기본 테이블 작업(삽입/업데이트)을 통해 복구하여 서비스가 정상적인 경로를 통해 변경 사항을 캡처하도록 하십시오. "no-op 업데이트"는 누락된 행 집합을 이미 알고 있을 때 유용한 실용적인 패턴입니다.
- 크거나 복잡한 간극의 경우, 안전한 재설정 접근 방식을 고려하십시오: 동기화 그룹에서 테이블을 제거하고 다시 추가하여 아티팩트를 재프로비저닝합니다.
- 메타데이터 일관성을 검증하고 추측을 줄이려면 AzureSQLDataSyncHealthChecker를 사용하십시오.
- 배포 중에 간헐적인 오류가 발생하는 경우, 스키마 변경 + 스냅샷 격리 패턴 (예: 오류 3961)이 가능한 원인임을 고려하고 그에 따라 DDL 변경을 예약하십시오.