RecoveryManager 클래스를 사용하여 분할된 데이터베이스 맵 문제 해결
적용 대상:
Azure SQL Database
RecoveryManager 클래스는 분할된 데이터베이스 환경에서 ADO.NET 애플리케이션이 GSM(글로벌 분할 데이터베이스 맵)과 LSM(로컬 분할 데이터베이스 맵) 간의 모든 불일치를 쉽게 감지하고 수정하는 기능을 제공합니다.
GSM 및 LSM은 분할된 환경에서 각 데이터베이스의 매핑을 추적합니다. 경우에 따라 GSM과 LSM 사이에서 중단이 발생합니다. 이 경우 RecoveryManager 클래스를 사용하여 중단을 검색하고 복구합니다.
RecoveryManager 클래스는 Elastic Database 클라이언트 라이브러리에 포함됩니다.
용어 정의는 Elastic Database 도구 용어집을 참조하세요. ShardMapManager를 사용하여 분할된 솔루션의 데이터를 관리하는 방법을 이해하려면 분할된 데이터베이스 맵 관리를 참조하세요.
복구 관리자를 사용하는 이유
분할된 데이터베이스 환경에는 데이터베이스당 하나의 테넌트 및 서버당 많은 데이터베이스가 있습니다. 환경에 많은 서버가 있을 수도 있습니다. 각 데이터베이스는 분할된 데이터베이스 맵에 매핑되므로 호출을 올바른 서버 및 데이터베이스로 라우팅할 수 있습니다. 데이터베이스는 분할 키에 따라 추적되며 각 분할된 데이터베이스에는 키 값 범위가 할당됩니다. 예를 들어, 분할 키는 "D"에서 "F"로 고객 이름을 나타내고 있을 수 있습니다. 모든 분할된 데이터베이스(데이터베이스라고도 함) 및 해당 매핑 범위의 매핑은 GSM(전역 분할 맵)에 포함되어 있습니다. 각 데이터베이스에는 LSM(로컬 분할된 데이터베이스 맵)으로 알려진 분할된 데이터베이스에 포함된 범위의 맵도 포함되어 있습니다. 앱이 분할된 데이터베이스에 연결되면 빠른 검색을 위해 매핑이 앱과 함께 캐시됩니다. LSM은 캐시된 데이터의 유효성을 검사하는 데 사용됩니다.
GSM 및 LSM은 다음과 같은 이유로 동기화가 중단될 수 있습니다.
- 범위가 더 이상 사용되지 않는 분할된 데이터베이스가 삭제되거나 분할된 데이터베이스의 이름이 변경되었습니다. 분할된 데이터베이스를 삭제하면 고아 분할된 매핑이 발생합니다. 마찬가지로 데이터베이스 이름이 변경되면 고아 분할 매핑이 발생할 수 있습니다. 변경 의도에 따라 분할된 데이터베이스를 제거해야 하거나 분할된 데이터베이스 위치를 업데이트해야 할 수 있습니다. 삭제된 데이터베이스를 복구하려면 삭제된 데이터베이스 복원을 참조하세요.
- 지역 장애 조치(failover) 이벤트가 발생합니다. 계속하려면 애플리케이션에서 서버 이름과 분할된 데이터베이스 맵 관리자의 데이터베이스 이름을 업데이트한 다음, 분할된 데이터베이스 맵의 모든 분할된 데이터베이스에 대한 분할된 데이터베이스 매핑 세부 정보를 업데이트해야 합니다. 지역 장애 조치(failover)가 있는 경우 장애 조치(failover) 워크플로 내에서 이러한 복구 논리를 자동화해야 합니다. 복구 작업을 자동화하면 지역 사용 데이터베이스에 대해 마찰 없는 관리가 가능하며 수동 사용자 작업을 방지할 수 있습니다. 데이터 센터 중단이 있는 경우 데이터베이스를 복구하는 옵션에 대해 알아보려면 비즈니스 연속성 및 재해 복구를 참조하세요.
- 분할된 데이터베이스 또는 ShardMapManager 데이터베이스는 이전 시점으로 복원됩니다. 백업을 사용한 특정 시점 복구에 대해 알아보려면 백업을 사용한 복구를 참조하세요.
Azure SQL 데이터베이스 Elastic Database 도구, 지역 복제 및 복원에 대한 자세한 내용은 다음을 참조하세요.
ShardMapManager에서 RecoveryManager 검색
첫 번째 단계는 RecoveryManager 자격 증명 모음을 만드는 것입니다. GetRecoveryManager 메서드는 현재 ShardMapManager 인스턴스에 대한 복구 관리자를 반환합니다. 분할된 데이터베이스 맵의 모든 불일치를 해결하기 위해서는 먼저 특정 분할된 데이터베이스 맵에 대한 RecoveryManager를 검색해야 합니다.
ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,
ShardMapManagerLoadPolicy.Lazy);
RecoveryManager rm = smm.GetRecoveryManager();
이 예제에서는 RecoveryManager가 ShardMapManager에서 초기화됩니다. ShardMap을 포함하는 ShardMapManager도 이미 초기화되어 있습니다.
이 애플리케이션 코드는 분할된 데이터베이스 맵 자체를 조작하므로 팩터리 메서드에 사용된 자격 증명(선행 예제에서는 smmConnectionString)은 연결 문자열에서 참조하는 GSM 데이터베이스에 대한 읽기-쓰기 권한이 있는 자격 증명이어야 합니다. 일반적으로 이러한 자격 증명은 데이터 종속 라우팅에 대한 연결을 여는 데 사용되는 자격 증명과는 다릅니다. 자세한 내용은 탄력적 데이터베이스 클라이언트에서 자격 증명 사용을 참조하세요.
분할된 데이터베이스를 삭제한 후 ShardMap에서 분할된 데이터베이스 제거
DetachShard 메서드는 분할된 데이터베이스 맵에서 지정된 분할된 데이터베이스를 분리하고 분할된 데이터베이스와 연결된 매핑을 삭제합니다.
- 위치 매개 변수는 분리되는 분할된 데이터베이스의 분할된 위치, 특히 서버 이름 및 데이터베이스 이름입니다.
- shardMapName 매개 변수는 분할된 데이터베이스 맵 이름입니다. 여러 분할된 데이터베이스 맵을 동일한 분할된 데이터베이스 맵 관리자가 관리하는 경우에만 필요합니다. 선택 사항.
Important
업데이트되는 매핑의 범위가 비어 있는 것이 확실한 경우에만 이 기술을 사용하세요. 위 방법에서는 이동하는 범위에서 데이터를 확인하지 않으므로 코드에 검사를 포함하는 것이 가장 좋습니다.
다음은 분할된 데이터베이스 맵에서 분할된 데이터베이스를 제거하는 예제입니다.
rm.DetachShard(s.Location, customerMap);
분할된 데이터베이스 맵은 분할된 데이터베이스 삭제 전 GSM의 분할된 데이터베이스 위치를 반영합니다. 분할된 데이터베이스는 삭제되었으므로 의도적인 것으로 간주되며 분할 키 범위는 더 이상 사용되지 않습니다. 그렇지 않은 경우 특정 시점 복원을 실행할 수 있습니다. 이전 지정 시간에서 분할된 데이터베이스를 복구합니다. (이 경우, 다음 섹션을 검토하여 분할된 데이터베이스의 불일치를 감지하세요.) 복구하려면 특정 시점 복구를 참조하세요.
데이터베이스 삭제가 의도적인 것으로 간주되므로 최종 관리 클린업 작업은 분할된 데이터베이스 맵 관리자에서 분할된 데이터베이스에 대한 항목을 삭제하는 것입니다. 이렇게 하면 응용 프로그램이 예상하지 못한 범위에 정보를 실수로 쓰지 못하게 됩니다.
매핑 차이를 감지하려면
DetectMappingDifferences 메서드는 분할된 데이터베이스 맵(로컬 또는 전역) 중 하나를 진리 원본으로 선택하고 반환하며 분할된 데이터베이스 맵(GSM 및 LSM)의 매핑을 조정합니다.
rm.DetectMappingDifferences(location, shardMapName);
- 위치 는 서버 이름과 데이터베이스 이름을 지정합니다.
- shardMapName 매개 변수는 분할된 데이터베이스 맵 이름입니다. 여러 분할된 데이터베이스 맵을 동일한 분할된 데이터베이스 맵 관리자가 관리하는 경우에만 필요합니다. 선택 사항.
매핑 차이를 해결하려면
ResolveMappingDifferences 메서드드는 분할된 데이터베이스 맵(로컬 또는 전역) 중 하나를 진리 원본으로 선택하고 분할된 데이터베이스 맵(GSM 및 LSM)의 매핑을 조정합니다.
ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
- RecoveryToken 매개 변수는 특정 분할된 데이터베이스에 대한 GSM 및 LSM 간의 매핑에서 차이를 열거합니다.
- MappingDifferenceResolution 열거 는 분할된 데이터베이스 매핑 간 차이를 해결하기 위한 메서드를 나타내는 데 사용됩니다.
- MappingDifferenceResolution.KeepShardMapping은 LSM이 정확한 매핑을 포함하므로 분할된 데이터베이스의 매핑이 사용되는 경우에 권장됩니다. 일반적으로 장애 조치(failover)가 있는 경우 분할된 데이터베이스가 새 서버에 상주합니다. 분할된 데이터베이스는 GSM에서 먼저 제거되므로(RecoveryManager.DetachShard 메서드 사용) GSM에 매핑이 더 이상 존재하지 않습니다. 따라서 분할된 매핑을 다시 설정하기 위해 LSM을 사용해야 합니다.
분할된 데이터베이스를 복원한 후 ShardMap에 연결합니다.
AttachShard 메서드는 지정된 분할된 데이터베이스를 분할된 데이터베이스 맵에 연결합니다. 그런 다음 분할된 데이터베이스 맵 불일치를 감지하고 분할된 데이터베이스 복원 지점에서 분할된 데이터베이스와 일치하도록 매핑을 업데이트합니다. 또한 지정 시간 복원은 타임스탬프가 추가된 새 데이터베이스로 기본 설정되므로 데이터베이스 이름이 원래 데이터베이스 이름(분할된 데이터베이스가 복원되기 전)을 반영하도록 이름이 변경된 것으로 가정합니다.
rm.AttachShard(location, shardMapName)
- 위치 매개 변수는 연결 중인 분할된 데이터베이스의 서버 이름 및 데이터베이스 이름입니다.
- shardMapName 매개 변수는 분할된 데이터베이스 맵 이름입니다. 여러 분할된 데이터베이스 맵을 동일한 분할된 데이터베이스 맵 관리자가 관리하는 경우에만 필요합니다. 선택 사항.
다음은 이전 시점부터 최근에 복원된 분할된 데이터베이스 맵에 분할된 데이터베이스를 추가하는 예제입니다. 분할된 데이터베이스(즉, LSM의 분할된 데이터베이스에 대한 매핑)가 복원되었으므로 GSM의 분할된 데이터베이스 항목과 일치하지 않습니다. 이 예제 코드 외부에서 분할된 데이터베이스가 복원되었고 데이터베이스의 원래 이름으로 바뀌었습니다. 복원되었으므로 LSM의 매핑이 신뢰할 수 있는 매핑이라고 가정합니다.
rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
foreach (RecoveryToken g in gs)
{
rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
}
분할된 데이터베이스의 지역 장애 조치(failover)(복원) 후 분할된 데이터베이스 위치 업데이트
지역 장애 조치 시, 보조 데이터베이스가 쓸 수 있는 상태가 되고 새로운 주 데이터베이스가 됩니다. 서버 이름 및 잠재적으로 데이터베이스(구성에 따라 다름)는 원래 주 데이터베이스와 다를 수 있습니다. 따라서 GSM 및 LSM의 분할된 데이터베이스에 대한 매핑 항목을 수정해야 합니다. 마찬가지로 데이터베이스가 다른 이름이나 위치 또는 이전 시점으로 복원되는 경우 분할된 데이터베이스 맵에서 불일치가 발생할 수 있습니다. 분할된 데이터베이스 맵 관리자는 올바른 데이터베이스에 대한 열린 연결의 배포를 처리합니다. 배포는 분할된 데이터베이스 맵의 데이터와 응용 프로그램의 요청 대상인 분할 키의 값을 기반으로 합니다. 지역 장애 조치 후 이 정보를 정확한 서버 이름, 데이터베이스 이름 및 복구된 데이터베이스의 분할된 데이터베이스 매핑으로 업데이트해야 합니다.
모범 사례
지리적 장애 조치(failover) 및 복구는 일반적으로 Azure SQL 데이터베이스 비즈니스 연속성 기능을 의도적으로 활용하는 애플리케이션의 클라우드 관리자가 관리하는 작업입니다. 비즈니스 연속성 계획에는 비즈니스 작업을 중단 없이 계속할 수 있도록 보장해주는 프로세스, 절차 및 측정이 필요합니다. RecoveryManager 클래스의 일부로 사용할 수 있는 메서드는 GSM 및 LSM이 수행된 복구 작업에 따라 최신 상태로 유지되도록 이 작업 흐름 내에서 사용해야 합니다. 장애 조치 이벤트 후 GSM 및 LSM이 정확한 정보를 반영하도록 제대로 보장하는 5가지 기본 단계가 있습니다. 이러한 단계를 실행하는 애플리케이션 코드를 기존 도구 및 워크플로에 통합할 수 있습니다.
- ShardMapManager에서 RecoveryManager를 검색합니다.
- 분할된 데이터베이스 맵에서 이전 분할된 데이터베이스를 분리합니다.
- 새 분할된 데이터베이스 위치를 포함하여 분할된 데이터베이스 맵에 새 분할된 데이터베이스를 연결합니다.
- GSM과 LSM 간의 매핑에서 불일치를 검색합니다.
- LSM을 신뢰하여 GSM 및 LSM 간의 차이를 해결합니다.
이 예제에서는 다음 작업을 수행합니다.
장애 조치(failover) 이벤트 전에 분할된 데이터베이스 위치를 반영하는 분할된 데이터베이스 맵에서 분할된 데이터베이스를 제거합니다.
새 분할된 데이터베이스 위치를 반영하는 분할된 데이터베이스 맵에 분할된 데이터베이스를 연결합니다("Configuration.SecondaryServer" 매개 변수는 새 서버 이름이지만 데이터베이스 이름은 동일).
각 분할된 데이터베이스에 대한 GSM과 LSM 간의 매핑 차이를 검색하여 복구 토큰을 검색합니다.
각 분할된 데이터베이스의 LSM에서 매핑을 신뢰하여 불일치를 해결합니다.
var shards = smm.GetShards(); foreach (shard s in shards) { if (s.Location.Server == Configuration.PrimaryServer) { ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database); rm.DetachShard(s.Location); rm.AttachShard(slNew); var gs = rm.DetectMappingDifferences(slNew); foreach (RecoveryToken g in gs) { rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping); } } }
추가 리소스
아직 탄력적인 데이터베이스 도구를 사용 하지 않나요? 시작 가이드를 확인합니다. 질문이 있는 경우 SQL Database에 대한 Microsoft Q&A 질문 페이지에서 문의하고, 기능 요청이 있는 경우 SQL Database 사용자 의견 포럼에서 새로운 아이디어를 추가하거나 기존 아이디어에 투표해 주세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기