고가용성 및 재해 복구 구성

SQL Server에서 재해 복구 및 고가용성 솔루션을 구성하는 주요 부분은 Azure Virtual Machine에서 실행되는 SQL Server에서 동일하게 유지됩니다. 고가용성 솔루션은 오류로 인해 커밋된 데이터가 손실되지 않고, 워크로드가 유지 관리 작업의 영향을 받지 않고, 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 보장하도록 설계되었습니다.

대부분의 Azure SQL 서비스 계층은 로컬 중복성에서 영역 중복 모델에 이르기까지 다양한고가용성 옵션을 제공합니다.

다음으로, Azure의 PaaS 제품에 대한 재해 복구 및 고가용성을 위한 특정 솔루션을 살펴봅니다.

지속적인 백업

Azure SQL Database는 데이터베이스의 일반 백업과 연속 백업을 보장합니다. 그러면 읽기 액세스 지역 중복 스토리지(RA-GRS)로 복제됩니다.

매주 전체 백업, 12~24시간마다 차등 백업, 5~10분마다 트랜잭션 로그 백업은 자동화된 백업 전략의 일부입니다. 확장 백업 가용성(최대 10년)의 경우 단일 데이터베이스와 풀된 데이터베이스 모두에 대해 LTR(장기 보존)을 구성할 수 있습니다.

LTR(장기 보존)

Azure는 일반적인 제한을 초과하여 설정할 수 있는 보존 정책을 제공하며, 이는 장기 보존 필요한 시나리오에 유용합니다. 최대 10년 동안 보존 정책을 설정할 수 있으며 이 옵션은 기본적으로 사용하지 않도록 설정되어 있습니다.

이미지는 Azure Portal에서 장기 보존 정책을 설정하는 방법을 보여 줍니다. 데이터베이스를 선택하면 화면 오른쪽에 패널이 표시되어 기본 설정을 변경할 수 있습니다.

장기 보존에 대한 자세한 내용은 장기 보존 - Azure SQL Database 및 Azure SQL Managed Instance참조하세요.

지오-복원

SQL Database 및 SQL Managed Instance에 대한 백업은 기본적으로 지역 중복입니다. 이렇게 하면 덜 엄격한 재해 복구 시나리오에 유용한 기능인 다른 지리적 지역으로 데이터베이스를 쉽게 복원할 수 있습니다.

백업 스토리지는 일반 데이터베이스 파일 스토리지와 별도로 청구됩니다. 그러나 SQL Database를 프로비전할 때 추가 비용 없이 데이터베이스에 대해 선택한 데이터 계층의 최대 크기로 백업 스토리지가 만들어집니다.

지역 복원 작업의 기간은 데이터베이스 크기, 복원 작업에 관련된 트랜잭션 로그 수 및 대상 지역에서 처리되는 동시 복원 요청의 양을 비롯한 여러 기본 구성 요소의 영향을 받을 수 있습니다.

PITR (Point-in-time Restore, 특정 시점 복원)

정의된 보존에 따라 특정 시점으로 데이터베이스를 복원할 수 있지만, PITR은 백업이 시작된 동일한 서버에서 데이터베이스를 복원하는 경우에만 지원됩니다. Azure Portal, Azure PowerShell, Azure CLI 또는 REST API를 사용하여 SQL Database를 복원할 수 있습니다.

활성 지리적 복제

Azure SQL Database의 가용성을 높이는 한 가지 방법은 활성 지역 복제사용하는 것입니다. 활성 지역 복제는 비동기적으로 최신 상태로 유지되는 보조 데이터베이스 복제본을 다른 지역에 만듭니다.

이 복제본은 SQL Server의 AlwaysOn 가용성 그룹과 유사하게 읽을 수 있습니다. Azure는 가용성 그룹을 사용하여 이 기능을 유지 관리하므로 일부 용어가 유사합니다.

활성 지역 복제는 고객이 주요 재해 시 주 데이터베이스를 보조 지역으로 장애 조치(failover)할 때 이를 프로그래밍 방식으로 또는 수동으로 수행할 수 있도록 함으로써 비즈니스 연속성을 제공합니다.

지역 복제 관계와 관련된 모든 데이터베이스는 동일한 서비스 계층을 가져야 합니다. 또한 쓰기 작업이 많기 때문에 복제 성능 문제를 방지하려면 주 복제본과 컴퓨팅 크기가 동일한 보조 복제본을 구성하는 것이 좋습니다.

데이터베이스의 블레이드에 액세스하고, 데이터 관리 섹션에서 복제본선택한 다음, + 복제본만들어 Azure SQL Database에 대한 지역 복제를 수동으로 구성할 수 있습니다.

보조 복제본이 설정되면 장애 조치(failover)를 수동으로 시작할 수 있는 옵션이 있습니다. 이 프로세스에서는 역할이 반전됩니다. 보조 복제본은 주 복제본의 역할을 가정하고 원래 주 복제본은 보조 복제본이 됩니다.

구독 간 지역 복제

특정 시나리오에서는 주 데이터베이스와 다른 구독에 보조 복제본을 구성해야 할 수도 있습니다. 여기서 구독 간 지역 복제 기능이 사용됩니다.

구독 간 지역 복제를 구성하는 데 필요한 단계에 대한 자세한 내용은 구독 간 지역 복제 참조하세요.

자동 장애 조치 그룹

자동 장애 조치(failover) 그룹 Azure SQL Database와 Azure SQL Managed Instance 모두에서 지원하는 고가용성 기능입니다. 자동 장애 조치(failover) 그룹을 사용하면 데이터베이스가 다른 지역에 복제되는 방법과 장애 조치(failover)가 발생할 수 있는 방법을 관리할 수 있습니다. 자동 장애 조치(failover) 그룹에 할당된 이름은 *.database.windows.net 도메인 내에서 고유해야 합니다.

자동 장애 조치(failover) 그룹에는 여러 데이터베이스가 포함될 수 있습니다. 주 데이터베이스와 보조 데이터베이스의 크기는 동일합니다.

azure SQL Database 및 Azure SQL Managed Instance에 대한 자동 장애 조치(failover) 그룹의

자동 장애 조치(failover) 그룹은 AG와 유사한 기능인 수신기를 제공하는데, 수신기는 읽기/쓰기 작업과 읽기 전용 작업을 모두 허용합니다. 두 가지 유형의 수신기가 있습니다. 하나는 읽기-쓰기용이고 다른 하나는 읽기 전용 트래픽용입니다. 장애 조치(failover)의 백그라운드에서 DNS가 업데이트되므로 클라이언트는 추상화된 수신기 이름을 가리킬 수 있으며 다른 어떤 것도 알 필요가 없습니다. 읽기/쓰기 복사본을 포함하는 데이터베이스 서버는 주 서버이고, 주 서버에서 트랜잭션을 수신하는 서버는 보조 서버입니다.

자동 장애 조치(failover) 그룹에는 두 가지 정책이 있습니다.

장애 조치(failover)는 자동 장애 조치(failover)가 설정된 경우에도 수동으로 시작할 수 있는 프로세스입니다. 그러나 장애 조치(failover) 유형은 데이터 손실이 발생하는지 여부에 영향을 줄 수 있습니다. 예를 들어 계획되지 않은 장애 조치(failover)가 강제로 수행되고 보조 데이터베이스가 주 데이터베이스와 완전히 동기화되지 않은 경우 데이터가 손실될 수 있습니다.

GracePeriodWithDataLossHours 기본값이 1시간으로 설정된 장애 조치(failover)를 시작하기 전에 Azure가 대기하는 기간을 결정합니다. RPO(복구 지점 목표)가 엄격하고 데이터 손실이 옵션이 아닌 경우 이 값을 더 높게 설정할 수 있습니다. 즉, Azure는 장애 조치(failover)를 시작하기 전에 더 오래 대기하지만 보조 데이터베이스가 주 데이터베이스와 완전히 동기화되는 데 더 많은 시간을 제공하므로 데이터 손실을 줄일 수 있습니다.

Azure SQL Database의 고가용성 및 재해 복구에 대한 자세한 내용은 Azure SQL Database 고가용성 및 재해 복구 검사 목록 참조하세요.