Azure SQL Managed Instance 는 PaaS(완전 관리형 PaaS) 데이터베이스 엔진입니다. SQL Server와의 거의 100% 기능 호환성을 제공합니다. Azure SQL Managed Instance는 사용자 개입 없이 업그레이드, 패치, 백업 및 모니터링과 같은 대부분의 데이터베이스 관리 기능을 처리합니다. 안정적인 최신 버전의 SQL Server 데이터베이스 엔진 및 기본 제공 고가용성이 있는 패치된 운영 체제에서 실행됩니다.
Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.
이 문서에서는 일시적인 오류, 가용성 영역 중단 및 지역 중단을 비롯한 다양한 잠재적 중단 및 문제에 대해 Azure SQL Managed Instance를 복원할 수 있도록 하는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법, 서비스 유지 관리를 처리하는 방법 및 Azure SQL SLA(Managed Instance 서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.
안정성을 위한 프로덕션 배포 권장 사항
SQL Managed Instance의 대부분의 프로덕션 배포의 경우 다음 권장 사항을 고려합니다.
고가용성 및 재해 복구(DR) 검사 목록에 제공된 지침을 따릅니다.
영역 중복을 사용하도록 설정합니다.
자동화된 백업을 구성하고 백업에 ZRS(영역 중복 스토리지) 또는 GRS(지역 중복 스토리지)를 사용합니다.
정기적으로 백업 및 복원 프로세스를 테스트할 계획을 세웁니다.
안정성 아키텍처 개요
범용 SQL 관리형 인스턴스는 Azure Service Fabric 이 관리하는 단일 노드에서 실행됩니다. 데이터베이스 엔진이나 운영 체제가 업그레이드되거나 오류가 감지될 때마다, SQL Managed Instance는 Service Fabric과 함께 작동하여 사용 가능한 여유 용량이 충분한 상태 없는 컴퓨팅 노드로 무상태 데이터베이스 엔진 프로세스를 이동합니다. 데이터베이스 파일은 중복 기능이 기본 제공된 Azure Blob Storage에 저장됩니다. 데이터 및 로그 파일은 원래의 컴퓨팅 노드에서 분리되어 새로 초기화된 데이터베이스 엔진 프로세스에 연결됩니다.
중요 비즈니스용 SQL Managed Instance는 클러스터에서 여러 복제본을 사용합니다. 클러스터에는 다음 두 가지 유형의 복제본이 포함됩니다.
읽기-쓰기 고객 워크로드에 액세스할 수 있는 단일 주 복제본
데이터 복사본을 포함하는 최대 5 개의 보조 복제본 (컴퓨팅 및 스토리지)
주 복제본은 변경 내용을 지속적이고 순차적으로 보조 복제본에 푸시하여 각 트랜잭션을 커밋하기 전에 충분한 수의 보조 복제본에 데이터가 영구적으로 저장되도록 보장합니다. 이 프로세스는 주 복제본 또는 읽기 가능한 보조 복제본을 사용할 수 없게 되면 장애 조치(failover)에 대해 항상 완전히 동기화된 복제본을 사용할 수 있도록 보장합니다.
SQL Managed Instance 및 Service Fabric 은 복제본 간에 장애 조치(failover)를 시작합니다. 보조 복제본이 새 주 복제본이 되면 클러스터에 쿼럼을 유지하기에 충분한 수의 복제본이 있는지 확인하기 위해 다른 보조 복제본이 만들어집니다. 장애 조치(failover)가 완료되면 Azure SQL 연결은 연결 문자열에 따라 새 주 복제본 또는 읽을 수 있는 보조 복제본으로 자동으로 리디렉션됩니다.
Redundancy
기본적으로 SQL Managed Instance는 주 지역의 단일 데이터 센터에 컴퓨팅 노드 및 데이터를 분산하여 중복성을 달성합니다. 이 방법은 다음과 같은 예상 및 예기치 않은 가동 중지 시간 동안 데이터를 보호합니다.
고객이 시작한 관리 작업으로 인한 짧은 가동 중지 시간
서비스 유지 관리 작업
소규모 네트워크 또는 전원 오류
다음 구성 요소를 포함하는 문제 및 데이터 센터 중단:
서비스에 전원을 공급하는 컴퓨터가 실행 중인 랙
SQL Database 엔진을 실행하는 VM(가상 머신)을 호스트하는 물리적 컴퓨터 입니다.
SQL Database 엔진을 실행하는 VM
SQL Database 엔진 문제
계획되지 않은 지역화된 잠재적 중단
SQL Managed Instance가 중복성을 제공하는 방법에 대한 자세한 내용은 로컬 및 영역 중복성을 통한 가용성을 참조하세요.
일시적인 오류에 대한 복원력
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.
SQL Managed Instance는 패치, 백업, Windows 및 SQL Database 엔진 업그레이드와 같은 중요한 서비스 작업을 자동으로 처리합니다. 또한 기본 하드웨어, 소프트웨어 또는 네트워크 오류와 같은 계획되지 않은 이벤트를 처리합니다. SQL Managed Instance는 가장 중요한 상황에서도 신속하게 복구할 수 있으므로 데이터를 항상 사용할 수 있습니다. 대부분의 사용자는 업그레이드가 지속적으로 수행된다는 사실을 알아차리지 못합니다.
인스턴스가 패치되거나 장애 조치되면 애플리케이션에서 재시도 논리를 사용하는 경우 가동 중지 시간이 최소화됩니다. 일시적인 오류에 대한 애플리케이션의 복원력을 테스트할 수 있습니다.
가용성 영역 오류에 대한 복원력
비고
영역 중복성은 현재 차세대 범용 서비스 계층에 사용할 수 없습니다.
가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.
영역 중복 구성을 사용하도록 설정하면 애플리케이션 논리를 변경하지 않고도 대규모 장애(데이터 센터의 대규모 중단 포함)에 대해 SQL Managed Instance가 복원력을 갖도록 할 수 있습니다.
SQL Managed Instance는 상태 비지정 컴퓨팅 노드를 다른 가용성 영역에 배치하여 영역 중복성을 달성합니다. 현재 활성 SQL Database 엔진 프로세스가 포함된 노드에 연결된 상태 저장 ZRS에 의존합니다. 중단이 발생하면 SQL 데이터베이스 엔진 프로세스가 무상태 컴퓨팅 노드 중 하나에서 활성화되고, 그런 다음 상태 저장 스토리지의 데이터에 액세스합니다.
SQL Managed Instance는 여러 가용성 영역에 SQL 관리형 인스턴스의 복제본을 배치하여 영역 중복성을 달성합니다. 단일 실패 지점을 제거하기 위해 제어 링도 여러 영역에 복제됩니다. 컨트롤 플레인 트래픽은 가용성 영역 전반에 배포된 부하 분산 장치로 라우팅됩니다. Azure Traffic Manager는 컨트롤 플레인에서 부하 분산 장치로 트래픽 라우팅을 제어합니다.
요구 사항
지역 지원: SQL Managed Instance에 대한 영역 중복성은 일부 지역에서 지원됩니다. 자세한 내용은 지원되는 지역을 참조하세요.
백업 스토리지 중복성: SQL 관리형 인스턴스에 대한 영역 중복을 사용하도록 설정하려면 백업 스토리지 중복성을 ZRS 또는 GZRS ( 지역 영역 중복 스토리지 )로 설정합니다.
비용
영역 중복을 사용하도록 설정하면 SQL 관리형 인스턴스 및 영역 중복 백업에 대한 추가 비용이 발생합니다. 자세한 내용은 가격 책정을 참조하세요.
중요 비즈니스용 서비스 계층의 영역 중복 인스턴스가 포함된 일정 기간 동안 할인된 가격으로 컴퓨팅 리소스를 사용하기로 약정하면 비용을 절감할 수 있습니다. 자세한 내용은 SQL Managed Instance에 대한 예약을 참조하세요.
가용성 영역 지원 구성
이 섹션에서는 SQL 관리되는 인스턴스에 대한 가용성 영역 지원을 구성하는 방법을 설명합니다.
영역 중복을 사용하도록 설정: 새 인스턴스와 기존 인스턴스에서 영역 중복을 구성하는 방법을 알아보려면 영역 중복 구성을 참조하세요.
SQL Managed Instance에 대한 모든 크기 조정 작업은 영역 중복 사용 여부에 관계없이 온라인으로 수행되며, 가동 중지 시간이 거의 없거나 전혀 필요하지 않습니다. 자세한 내용은 관리 작업 기간을 참조하세요.
영역 중복 사용 안 함: 영역 중복을 사용하도록 설정하는 것과 동일한 단계에 따라 영역 중복을 사용하지 않도록 설정할 수 있습니다. 이 프로세스는 일반 서비스 계층 목표 업그레이드와 유사한 온라인 작업입니다. 프로세스가 끝나면 인스턴스가 영역 중복 인프라에서 단일 영역 인프라로 마이그레이션됩니다.
모든 영역이 정상인 경우의 동작
이 섹션에서는 SQL 관리되는 인스턴스가 영역 중복으로 구성되고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.
영역 간 트래픽 라우팅: 일반 작업 중에 요청은 SQL Managed Instance 컴퓨팅 계층을 실행하는 노드로 라우팅됩니다.
영역 간 데이터 복제: 데이터베이스 파일은 현재 활성 SQL Database 엔진 프로세스가 포함된 노드에 연결된 ZRS를 사용하여 Azure Storage에 저장됩니다.
쓰기 작업은 동기적이며 모든 가용성 영역에서 데이터가 성공적으로 복제될 때까지 완료된 것으로 간주되지 않습니다. 이 동기 복제는 영역 오류 발생 시 강력한 일관성과 데이터 손실이 없도록 합니다. 그러나 로컬 중복 스토리지에 비해 쓰기 대기 시간이 약간 더 높아질 수 있습니다.
영역 간 트래픽 라우팅: 일반 작업 중에 요청은 SQL Managed Instance의 주 복제본으로 라우팅됩니다.
영역 간 데이터 복제: 주 복제본은 지속적이고 순차적으로 다른 가용성 영역에 있는 보조 복제본에 변경 내용을 푸시합니다. 이 프로세스는 각 트랜잭션을 커밋하기 전에 충분한 수의 보조 복제본에 데이터가 저장되어 있는지 확인합니다. 해당 복제본은 서로 다른 가용성 영역에 있습니다. 이 프로세스는 어떤 이유로든 주 복제본이나 읽기 가능한 보조 복제본을 사용할 수 없게 되더라도 완전히 동기화된 복제본을 항상 장애 조치(failover)에 사용할 수 있도록 보장합니다.
영역 중복 인스턴스에는 서로 다른 데이터 센터에 복제본이 있기 때문에 네트워크 대기 시간이 늘어나면 트랜잭션 커밋 시간이 늘어나게 될 수 있습니다. 이러한 증가는 일부 OLTP(온라인 트랜잭션 처리) 워크로드의 성능에 영향을 줄 수 있습니다. 대부분의 애플리케이션은 이러한 추가 대기 시간에 중요하지 않습니다.
영역 오류 중 동작
이 섹션에서는 SQL 관리형 인스턴스가 영역 중복으로 구성되고 하나 이상의 가용성 영역을 사용할 수 없는 경우 예상되는 사항에 대해 설명합니다.
- 검색 및 응답: SQL Managed Instance는 가용성 영역의 오류를 감지하고 대응하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작하기 위해 어떤 작업도 수행할 필요가 없습니다.
- 알림: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Resource Health 를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다. 또한 Azure Service Health를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
- 활성 요청: 가용성 영역을 사용할 수 없는 경우 오류가 있는 가용성 영역에서 처리 중인 모든 요청은 종료되고 다시 시도해야 합니다. 이러한 유형의 문제에 대해 애플리케이션을 복원할 수 있도록 하려면 일시적인 오류에 대한 복원력 지침을 참조하세요.
트래픽 경로 변경: SQL Managed Instance는 Service Fabric과 함께 작동하여 데이터베이스 엔진을 다른 가용성 영역에 있고 충분한 사용 가능한 용량이 있는 적합한 상태 비지방 컴퓨팅 노드로 이동합니다. 장애 조치(failover)가 완료되면 새로운 연결은 자동으로 새 기본 컴퓨팅 노드로 리디렉션됩니다.
새 데이터베이스 엔진 프로세스가 콜드 캐시로 시작되므로 워크로드가 많은 경우 한 컴퓨팅 노드에서 다른 컴퓨팅 노드로 전환하는 동안 성능이 저하될 수 있습니다.
- 트래픽 경로 변경: SQL Managed Instance는 Service Fabric과 함께 작동하여 주 복제본이 될 다른 가용성 영역에서 적합한 복제본을 선택합니다. 보조 복제본이 새 주 복제본이 되면 클러스터에 쿼럼을 유지하기에 충분한 수의 복제본이 있는지 확인하기 위해 다른 보조 복제본이 만들어집니다. 장애 조치(failover)가 완료되면 연결 문자열에 따라 새 연결이 새 주 복제본 또는 읽을 수 있는 보조 복제본으로 자동으로 리디렉션됩니다.
예상 가동 중지 시간: 가용성 영역 장애 조치(failover) 중에 약간의 가동 중지 시간이 발생할 수 있습니다. 가동 중지 시간은 일반적으로 30초 미만이며, 일시적인 오류 지침에 대한 복원력을 따르는 경우 애플리케이션에서 허용해야 합니다.
예상되는 데이터 손실: 가용성 영역 장애 조치(failover) 중에 커밋된 트랜잭션에 대한 데이터 손실은 예상되지 않습니다. 진행 중인 트랜잭션을 다시 시도해야 합니다.
영역 복구
가용성 영역이 복구되면 SQL Managed Instance는 Service Fabric과 함께 작동하여 복구된 영역에서 작업을 복원합니다. 고객의 개입이 필요하지 않습니다.
영역 오류 테스트
SQL Managed Instance 플랫폼은 영역 중복 인스턴스에 대한 트래픽 라우팅, 장애 조치(failover) 및 장애 복구(failback)를 관리합니다. 이 기능은 완전히 관리되므로 가용성 영역 오류 프로세스를 시작하거나 유효성을 검사할 필요가 없습니다. 그러나 애플리케이션의 오류 처리의 유효성을 검사할 수 있습니다.
지역 전체 오류에 대한 복원력
개별 SQL Managed Instance는 단일 지역 내에 배포됩니다. 하지만 별도의 Azure 지역에 보조 SQL Managed Instance를 배포하고 장애 조치(failover) 그룹을 구성할 수 있습니다.
장애 조치 그룹
장애 조치(failover) 그룹은 장애 조치(failover) 정책에 따라 데이터를 자동으로 지리적으로 복제하고 지역적 장애가 발생하면 자동 또는 수동으로 장애 조치(failover)를 수행할 수 있습니다.
이 섹션에서는 장애 조치(failover) 그룹에 대한 주요 정보를 요약하지만 장애 조치(failover) 그룹 개요 및 모범 사례를 검토하여 작업 방법 및 구성 방법에 대해 자세히 알아보세요.
장애 조치(Failover) 정책
장애 조치(failover) 그룹을 만들 때 장애 조치(failover) 정책을 선택합니다. 이 정책은 중단을 검색하고 장애 조치(failover)를 수행하는 담당자를 지정합니다. 두 가지 유형의 장애 조치(failover) 정책을 구성할 수 있습니다.
고객 관리 장애 조치(failover) (권장): 고객 관리 장애 조치(failover) 정책을 사용하는 경우 데이터 손실이 발생하지 않는 장애 조치( failover)를 수행할지 또는 데이터 손실을 초래할 수 있는 강제 장애 조치(failover)를 수행할지 결정할 수 있습니다. 강제 장애 조치(failover)는 주 인스턴스에 액세스할 수 없는 경우 중단 중에 복구 방법으로 사용됩니다.
Microsoft에서 관리하는 장애 조치(failover): Microsoft에서 관리하는 장애 조치(failover)는 예외적인 상황에서만 강제 장애 조치(failover)를 트리거하는 데 사용됩니다.
중요합니다
고객이 관리하는 장애 조치 옵션을 사용하여 재해 복구 계획을 개발, 테스트 및 구현합니다. 극단적인 상황에서만 사용될 수 있는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요. Microsoft에서 관리하는 장애 조치(failover)는 전체 지역에 대해 시작될 가능성이 높습니다. 개별 장애 조치(failover) 그룹, SQL Managed Instance, 구독 또는 고객에 대해서는 시작할 수 없습니다. 장애 조치는 서로 다른 Azure 서비스에 대해 각기 다른 시간에 발생할 수 있습니다. 고객 관리 장애 조치(failover)를 사용하는 것이 좋습니다.
지역 지원
장애 조치(failover) 그룹 내에서 SQL Managed Instance에 대해 원하는 Azure 지역을 선택할 수 있습니다. 광역 네트워크의 대기 시간이 높기 때문에 지역에서 복제는 비동기 복제 메커니즘을 사용합니다. 네트워크 지연을 줄이려면 대기 시간이 짧은 지역을 선택합니다. Azure 지역 간의 대기 시간에 대한 자세한 내용은 Azure 네트워크 왕복 대기 시간 통계를 참조하세요.
비용
여러 지역에 여러 개의 SQL Managed Instance를 만들면 각 SQL Managed Instance에 대해 요금이 청구됩니다.
하지만 보조 인스턴스에 읽기 워크로드나 연결된 애플리케이션이 없는 경우 복제본을 대기 인스턴스로 지정하여 라이선스 비용을 절감할 수 있습니다. 자세한 내용은 SQL Managed Instance에 대한 라이선스 없는 대기 복제본 구성을 참조하세요.
SQL Managed Instance 가격 책정에 대한 자세한 내용은 서비스 가격 책정 정보를 참조하세요.
다중 지역 지원 구성
장애 조치(failover) 그룹을 구성하는 방법을 알아보려면 SQL Managed Instance에 대한 장애 조치(failover) 그룹 구성을 참조하세요.
용량 계획 및 관리
장애 조치(failover) 중에 트래픽은 보조 SQL Managed Instance로 리디렉션됩니다. 보조 SQL Managed Instance가 트래픽을 수신할 준비가 되어 있는 것이 중요합니다. 주 인스턴스와 동일한 서비스 계층, 하드웨어 세대 및 컴퓨팅 크기를 사용하여 보조 SQL Managed Instance를 만듭니다.
장애 조치(failover) 그룹에서 SQL 관리형 인스턴스의 크기를 조정하는 방법에 대한 자세한 내용은 인스턴스 크기 조정을 참조하세요.
모든 지역이 정상인 경우의 동작
이 섹션에서는 SQL 관리형 인스턴스가 다중 지역 장애 조치(failover) 그룹을 사용하도록 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.
지역 간 트래픽 라우팅: 일반 작업 중에 읽기-쓰기 요청은 주 지역의 단일 주 인스턴스로 전송됩니다.
장애 조치(failover) 그룹은 별도의 읽기 전용 수신기 엔드포인트도 제공합니다. 일반적인 작업 중에 이 엔드포인트는 보조 인스턴스에 연결하여 연결 문자열에 지정된 읽기 전용 트래픽을 라우팅합니다.
장애 조치(failover) 그룹이 각 인스턴스에 트래픽을 보내는 방법 및 트래픽을 읽기 전용 수신기 엔드포인트로 보내는 방법에 대한 자세한 내용은 장애 조치(failover) 그룹 개요 및 모범 사례를 참조하세요.
지역 간 데이터 복제: 기본적으로 데이터는 주 인스턴스에서 보조 SQL Managed Instance로 비동기식으로 복제됩니다.
지역 복제는 비동기이므로 강제 장애 조치를 수행하는 경우 데이터 손실이 발생할 수 있습니다. 강제 장애 조치(failover) 중에 발생할 수 있는 데이터 손실을 파악하기 위해 복제 지연을 모니터링할 수 있습니다. 자세한 내용은 DR 검사 목록을 참조하세요.
장애 조치(failover) 중에 비동기 복제에서 데이터 손실을 제거해야 하는 경우 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그에서 전송 및 강화되었음을 확인할 때까지 호출 스레드를 차단하도록 애플리케이션을 구성합니다. 이 방법을 사용하려면 사용자 지정 개발이 필요하며 애플리케이션의 성능이 저하됩니다. 자세한 내용은 중요한 데이터의 손실 방지를 참조하세요.
지역 오류 중 동작
이 섹션에서는 SQL 관리형 인스턴스가 다중 지역 장애 조치(failover) 그룹을 사용하도록 구성되고 주 지역에 중단이 발생할 때 예상되는 사항에 대해 설명합니다.
검색 및 응답: 검색 및 응답에 대한 책임은 장애 조치(failover) 그룹에서 사용하는 장애 조치(failover) 정책에 따라 달라집니다.
고객 관리 장애 조치(failover) 정책: 고객은 지역에서 장애를 검색하고 장애 조치(failover) 그룹의 보조 인스턴스로 장애 조치(failover) 또는 강제 장애 조치(failover)를 트리거하는 책임을 맡습니다.
장애 조치(failover)를 수행하는 경우 SQL Managed Instance는 장애 조치(failover) 절차를 수행하기 전에 데이터가 보조 인스턴스와 동기화되기를 기다립니다.
강제 장애 조치(failover)를 수행하는 경우 SQL Managed Instance는 주 인스턴스에서 최근 변경 내용이 전파되는 것을 기다리지 않고 보조 인스턴스를 주 역할로 즉시 전환합니다. 이러한 형식의 장애 조치(failover)로 인해 데이터 손실이 발생할 수 있습니다.
Microsoft 관리 장애 조치(failover) 정책: Microsoft 관리 장애 조치(failover)는 예외적인 상황에서 수행됩니다. Microsoft에서 장애 조치(failover)를 트리거하면 장애 조치(failover) 그룹은 장애 조치(failover) 그룹 내의 보조 인스턴스로 강제 장애 조치(failover)를 자동으로 수행합니다. 그러나 장애 조치(failover)가 발생하는 시기를 제어할 수 있도록 프로덕션 워크로드에 대해 고객 관리 장애 조치(failover) 정책을 사용하는 것이 좋습니다.
- 알림: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Resource Health 를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다. 또한 Azure Service Health를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 장애 조치(failover)가 발생하면 처리 중인 모든 요청이 종료되고 다시 시도되어야 합니다. 이러한 유형의 문제에 대해 애플리케이션을 복원할 수 있도록 하려면 일시적인 오류에 대한 복원력을 참조하세요.
예상 데이터 손실: 데이터 손실의 양은 애플리케이션을 구성하는 방법에 따라 달라집니다. 자세한 내용은 장애 조치(failover) 그룹 개요 및 모범 사례를 참조하세요.
예상 가동 중지 시간: 장애 조치 그룹 전환 중에 약간의 가동 중지 시간이 있을 수 있습니다. 일반적으로 가동 중지 시간은 60초 미만입니다.
트래픽 경로 변경: 장애 조치(failover) 그룹이 장애 조치(failover) 프로세스를 완료하면 읽기/쓰기 트래픽이 새 주 인스턴스로 자동으로 라우팅됩니다. 애플리케이션이 연결 문자열에서 장애 조치(failover) 그룹의 엔드포인트를 사용하는 경우 장애 조치(failover) 후에 연결 문자열을 수정할 필요가 없습니다.
지역 복구
장애 조치(failover) 그룹은 복원 시 주 지역으로 자동으로 장애 복원되지 않으므로 장애 복원을 시작하는 것은 사용자의 책임입니다.
지역 오류 테스트
장애 조치(failover) 그룹의 장애 조치(failover)를 테스트할 수 있습니다.
장애 조치(failover) 그룹 테스트는 DR 훈련을 수행하는 과정의 일부일 뿐입니다. 자세한 내용은 DR 드릴 수행을 참조하세요.
백업 및 복원
데이터 손실을 비롯한 다양한 위험으로부터 보호하기 위해 데이터베이스의 백업을 수행합니다. 실수로 인한 데이터 손실, 손상 또는 기타 문제를 복구하기 위해 백업을 복원할 수 있습니다. 백업은 지역 복제와 동일하지 않으며 용도가 다르며 다양한 위험을 완화합니다.
SQL Managed Instance는 데이터베이스의 전체, 차등 및 트랜잭션 로그 백업을 자동으로 받습니다. 백업 유형, 해당 빈도, 복원 기능, 스토리지 비용 및 백업 암호화에 대한 자세한 내용은 SQL Managed Instance의 자동화된 백업을 참조하세요.
SQL Managed Instance는 기본 제공 자동화된 백업을 제공하며 사용자 데이터베이스에 대해 사용자가 시작한 복사 전용 백업도 지원합니다. 자세한 내용은 복사 전용 백업을 참조하세요.
백업 복제
SQL Managed Instance에 대한 자동 백업을 구성할 때 백업을 복제하는 방법을 지정할 수 있습니다. ZRS에 저장되도록 구성된 백업은 더 높은 수준의 복원력을 갖습니다. 다음 스토리지 유형 중 하나를 사용하도록 백업을 구성하는 것이 좋습니다.
지역에 가용성 영역이 있는 경우 지역 내 복원력을 위한 ZRS
지역에 가용성 영역이 있고 다른 지역과 쌍을 이루는 경우 지역 간 백업 복원력을 개선하기 위한 GZRS
해당 지역이 가용성 영역을 지원하지 않지만 쌍을 이루는 지역이 있는 경우 GRS
다양한 스토리지 유형 및 해당 기능에 대한 자세한 내용은 Backup 스토리지 중복성을 참조하세요.
지역 복원
지역 복원 기능은 백업 복사본을 다른 Azure 지역으로 복원할 수 있는 기본 DR 솔루션입니다. 지역 백업에는 일반적으로 상당한 가동 중지 시간과 데이터 손실이 빌생합니다. 지역 중단이 발생하는 경우 더 높은 수준의 복구 가능성을 달성하려면 장애 조치(failover) 그룹을 구성해야 합니다.
지역 복원을 사용하는 경우 보조 지역에서 백업을 사용할 수 있도록 하는 방법을 고려해야 합니다.
주 지역이 쌍을 이루는 경우 GZRS 또는 GRS 백업 스토리지를 사용하여 쌍을 이루는 지역으로의 지역 복원을 지원합니다.
주 지역이 페어링되지 않은 경우 사용자 지정 솔루션을 빌드하여 백업을 다른 지역으로 복제할 수 있습니다. 사용자가 시작한 복사 전용 백업을 사용하고 이를 BLOB 개체 복제를 사용하여 다른 지역의 스토리지 계정에 복제하는 스토리지 계정에 저장하는 것이 좋습니다.
서비스 유지 관리에 대한 복원력
SQL Managed Instance가 인스턴스에 대한 유지 관리를 수행하는 경우 SQL 관리형 인스턴스는 완전히 사용 가능하지만 짧은 재구성의 대상이 될 수 있습니다. 유지 관리 이벤트가 발생하면 클라이언트 애플리케이션에서 잠시 연결이 끊어질 수 있습니다. 클라이언트 애플리케이션은 일시적인 오류에 대한 복원력을 높이기 위해 지침을 따라야 합니다.
SQL Managed Instance를 사용하면 서비스 업그레이드 및 기타 유지 관리 작업에 일반적으로 사용되는 유지 관리 기간을 지정할 수 있습니다. 유지 관리 기간을 구성하면 업무 시간 동안 자동 장애 조치(failover)와 같은 부작용을 최소화하는 데 도움이 될 수 있습니다. 계획된 유지 관리에 대한 사전 알림을 받을 수도 있습니다.
자세한 내용은 SQL Managed Instance의 유지 관리 기간을 참조하세요.
서비스 수준 약정
Azure 서비스의 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 해당 가용성 예상 결과치를 달성하기 위해 솔루션이 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.
SQL Managed Instance의 경우 가용성 SLA는 관리 트래픽을 방해하지 않도록 Azure 가상 네트워크가 올바르게 구성된 경우에만 적용됩니다. 이 구성에는 서브넷 크기, NSG(네트워크 보안 그룹), UDR(사용자 정의 경로), DNS 구성 및 네트워크 리소스의 관리 및 사용에 영향을 주는 기타 리소스가 포함됩니다. SQL Managed Instance에 필요한 네트워킹 구성에 대한 자세한 내용은 네트워크 요구 사항을 참조하세요.