Azure SQL Database 및 SQL Managed Instance에 대 한 고가용성High availability for Azure SQL Database and SQL Managed Instance

적용 대상: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database 및 SQL Managed Instance에서 고가용성 아키텍처의 목표는 데이터베이스가 가동 중 이며 최소 99.99%의 시간 동안 실행 되도록 보장 하는 것입니다. 다른 계층의 특정 SLA에 대 한 자세한 내용은 유지 관리 작업 및 중단의 영향을 걱정 하지 않고 Azure SQL Database 및 SQL Managed Instance에 대 한 sla를 참조 하세요.The goal of the high availability architecture in Azure SQL Database and SQL Managed Instance is to guarantee that your database is up and running minimum of 99.99% of time (For more information regarding specific SLA for different tiers, Please refer SLA for Azure SQL Database and SQL Managed Instance), without worrying about the impact of maintenance operations and outages. Azure는 패치, 백업, Windows 및 Azure SQL 업그레이드와 같은 중요 한 서비스 작업 뿐만 아니라 기본 하드웨어, 소프트웨어, 네트워크 오류 등의 계획 되지 않은 이벤트도 자동으로 처리 합니다.Azure automatically handles critical servicing tasks, such as patching, backups, Windows and Azure SQL upgrades, as well as unplanned events such as underlying hardware, software, or network failures. Azure SQL Database의 기본 데이터베이스가 패치 되거나 장애 조치 (failover) 되 면 앱에서 재시도 논리 를 사용 하는 경우 가동 중지 시간이 눈에 띄지 않습니다.When the underlying database in Azure SQL Database is patched or fails over, the downtime is not noticeable if you employ retry logic in your app. SQL Database 및 SQL Managed Instance는 데이터를 항상 사용할 수 있도록 하는 가장 중요 한 상황 에서도 신속 하 게 복구할 수 있습니다.SQL Database and SQL Managed Instance can quickly recover even in the most critical circumstances ensuring that your data is always available.

고가용성 솔루션은 커밋된 데이터가 오류로 인해 손실 되지 않도록 하 고, 유지 관리 작업이 작업에 영향을 주지 않으며, 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 설계 되었습니다.The high availability solution is designed to ensure that committed data is never lost due to failures, that maintenance operations do not affect your workload, and that the database will not be a single point of failure in your software architecture. 데이터베이스를 업그레이드하거나 유지 관리하는 동안 워크로드를 중지해야 하는 유지 관리 기간이나 가동 중지 시간이 없습니다.There are no maintenance windows or downtimes that should require you to stop the workload while the database is upgraded or maintained.

고가용성 아키텍처 모델에는 다음 두 가지가 있습니다.There are two high availability architectural models:

  • 계산 및 저장소의 분리를 기반으로 하는 표준 가용성 모델 입니다.Standard availability model that is based on a separation of compute and storage. 원격 저장소 계층의 고가용성 및 안정성을 기반으로 합니다.It relies on high availability and reliability of the remote storage tier. 이 아키텍처는 유지 관리 작업 중에 일부 성능 저하를 허용할 수 있는 예산 기반 비즈니스 응용 프로그램을 대상으로 합니다.This architecture targets budget-oriented business applications that can tolerate some performance degradation during maintenance activities.
  • 데이터베이스 엔진 프로세스의 클러스터를 기반으로 하는 프리미엄 가용성 모델 입니다.Premium availability model that is based on a cluster of database engine processes. 항상 사용 가능한 데이터베이스 엔진 노드의 쿼럼이 항상 존재 한다는 사실에 의존 합니다.It relies on the fact that there is always a quorum of available database engine nodes. 이 아키텍처는 높은 IO 성능을 가진 중요 업무용 응용 프로그램을 대상으로 하며, 트랜잭션 속도는 유지 관리 작업 중에 작업에 대 한 최소 성능 영향을 보장 합니다.This architecture targets mission critical applications with high IO performance, high transaction rate and guarantees minimal performance impact to your workload during maintenance activities.

SQL Database 및 SQL Managed Instance은 안정적인 최신 버전의 SQL Server 데이터베이스 엔진 및 Windows 운영 체제에서 실행 되며, 대부분의 사용자는 업그레이드가 지속적으로 수행 되는 것을 알 수 없습니다.SQL Database and SQL Managed Instance both run on the latest stable version of the SQL Server database engine and Windows operating system, and most users would not notice that upgrades are performed continuously.

Basic, Standard 및 범용 서비스 계층 로컬 중복 가용성Basic, Standard, and General Purpose service tier locally redundant availability

Basic, Standard 및 범용 서비스 계층에서는 서버 리스 및 프로 비전 된 계산에 대 한 표준 가용성 아키텍처를 활용 합니다.The Basic, Standard, and General Purpose service tiers leverage the standard availability architecture for both serverless and provisioned compute. 다음 그림은 분리 된 계산 및 저장소 계층을 포함 하는 네 가지 노드를 보여 줍니다.The following figure shows four different nodes with the separated compute and storage layers.

컴퓨팅과 스토리지의 분리

표준 가용성 모델에는 두 개의 계층이 있습니다.The standard availability model includes two layers:

  • 프로세스를 실행 하 고 임시 및 캐시 된 데이터만 포함 하는 상태 비저장 계산 계층 ( sqlservr.exe 예: TempDB, 연결 된 SSD의 모델 데이터베이스 및 메모리에 계획 캐시, 버퍼 풀 및 columnstore 풀)을 포함 합니다.A stateless compute layer that runs the sqlservr.exe process and contains only transient and cached data, such as TempDB, model databases on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. 이 상태 비저장 노드는 sqlservr.exe 노드의 상태를 초기화 하 고 제어 하며 필요한 경우 다른 노드로 장애 조치 (failover)를 수행 하는 Azure Service Fabric에 의해 작동 됩니다.This stateless node is operated by Azure Service Fabric that initializes sqlservr.exe, controls health of the node, and performs failover to another node if necessary.
  • Azure Blob 저장소에 저장 된 데이터베이스 파일 (.mdf/.ldf)이 포함 된 상태 저장 데이터 계층입니다.A stateful data layer with the database files (.mdf/.ldf) that are stored in Azure Blob storage. Azure blob storage에는 기본 제공 되는 데이터 가용성 및 중복성 기능이 있습니다.Azure blob storage has built-in data availability and redundancy feature. 프로세스가 충돌 하는 경우에도 데이터 파일에 있는 로그 파일 또는 페이지의 모든 레코드가 유지 되도록 보장 sqlservr.exe 합니다.It guarantees that every record in the log file or page in the data file will be preserved even if sqlservr.exe process crashes.

데이터베이스 엔진 또는 운영 체제가 업그레이드 되거나 오류가 검색 될 때마다 Azure Service Fabric는 sqlservr.exe 사용 가능한 용량이 충분 한 상태 비저장 프로세스를 다른 상태 비저장 계산 노드로 이동 합니다.Whenever the database engine or the operating system is upgraded, or a failure is detected, Azure Service Fabric will move the stateless sqlservr.exe process to another stateless compute node with sufficient free capacity. Azure Blob storage의 데이터는 이동의 영향을 받지 않으며 데이터/로그 파일이 새로 초기화 된 프로세스에 연결 됩니다 sqlservr.exe .Data in Azure Blob storage is not affected by the move, and the data/log files are attached to the newly initialized sqlservr.exe process. 이 프로세스는 99.99%의 가용성을 보장 하지만, 새 sqlservr.exe 프로세스가 콜드 캐시로 시작 되기 때문에 많은 워크 로드에서 성능 저하가 발생할 수 있습니다.This process guarantees 99.99% availability, but a heavy workload may experience some performance degradation during the transition since the new sqlservr.exe process starts with cold cache.

범용 서비스 계층 영역 중복 가용성 (미리 보기)General Purpose service tier zone redundant availability (Preview)

범용 서비스 계층에 대 한 영역 중복 구성은 서버 리스 및 프로 비전 된 계산 모두에 제공 됩니다.Zone redundant configuration for the general purpose service tier is offered for both serverless and provisioned compute. 이 구성은 Azure 가용성 영역   를 활용 하 여 Azure 지역 내의 여러 물리적 위치에서 데이터베이스를 복제 합니다.This configuration utilizes Azure Availability Zones  to replicate databases across multiple physical locations within an Azure region.영역 중복성을 선택 하면 응용 프로그램 논리를 변경 하지 않고 새로운 및 기존 serverlesss 및 프로 비전 된 범용 단일 데이터베이스와 탄력적 풀을 심각한 데이터 센터 중단을 포함 하 여 훨씬 더 큰 오류 집합으로 복원할 수 있습니다. By selecting zone redundancy, you can make your new and existing serverlesss and provisioned general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic.

범용 계층에 대 한 영역 중복 구성에는 두 개의 계층이 있습니다.Zone redundant configuration for the general purpose tier has two layers:

  • ZRS (영역 중복 저장소)에 저장 된 데이터베이스 파일 (.mdf/.ldf)이 포함 된 상태 저장 데이터 계층입니다.A stateful data layer with the database files (.mdf/.ldf) that are stored in ZRS(zone-redundant storage). ZRS 를 사용 하 여 데이터 및 로그 파일은 실제로 분리 된 세 개의 Azure 가용성 영역에서 동기적으로 복사 됩니다.Using ZRS the data and log files are synchronously copied across three physically-isolated Azure availability zones.
  • sqlservr.exe 프로세스를 실행 하 고 TempDB와 같은 임시 및 캐시 된 데이터만 포함 하는 상태 비저장 계산 계층, 연결 된 SSD의 모델 데이터베이스 및 메모리에 계획 캐시, 버퍼 풀 및 columnstore 풀을 포함 합니다.A stateless compute layer that runs the sqlservr.exe process and contains only transient and cached data, such as TempDB, model databases on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. 이 상태 비저장 노드는 sqlservr.exe를 초기화 하 고, 노드의 상태를 제어 하 고, 필요한 경우 다른 노드로 장애 조치 (failover)를 수행 하는 Azure Service Fabric에 의해 작동 합니다.This stateless node is operated by Azure Service Fabric that initializes sqlservr.exe, controls health of the node, and performs failover to another node if necessary. 영역 중복 서버 리스 및 프로 비전 된 범용 데이터베이스의 경우 예비 용량이 있는 노드는 장애 조치 (failover)를 위해 다른 가용성 영역에서 쉽게 사용할 수 있습니다.For zone redundant serverless and provisioned general purpose databases, nodes with spare capacity are readily available in other Availability Zones for failover.

범용 서비스 계층에 대 한 고가용성 아키텍처의 영역 중복 버전은 다음 다이어그램에 설명 되어 있습니다.The zone redundant version of the high availability architecture for the general purpose service tier is illustrated by the following diagram:

범용에 대 한 영역 중복 구성

중요

영역 중복 구성은 Gen5 계산 하드웨어를 선택한 경우에만 사용할 수 있습니다.Zone redundant configuration is only available when the Gen5 compute hardware is selected. 이 기능은 SQL Managed Instance에서 사용할 수 없습니다.This feature is not available in SQL Managed Instance. 서버 리스 및 프로 비전 된 범용 계층에 대 한 영역 중복 구성은 미국 동부, 미국 동부 2, 미국 서 부 2, 북부 유럽, 유럽 서부, 동남 아시아, 오스트레일리아 동부, 일본 동부, 영국 남부 및 프랑스 중부 지역 에서만 사용할 수 있습니다.Zone redundant configuration for serverless and provisioned general purpose tier is only available in the following regions: East US, East US 2, West US 2, North Europe, West Europe, Southeast Asia, Australia East, Japan East, UK South, and France Central.

참고

크기가 80 vcore 인 범용 데이터베이스는 영역 중복 구성으로 인해 성능이 저하 될 수 있습니다.General Purpose databases with a size of 80 vcore may experience performance degradation with zone redundant configuration. 또한 백업, 복원, 데이터베이스 복사, 지리적 DR 관계 설정 등의 작업을 수행 하 고 영역 중복 데이터베이스를 중요 비즈니스용에서 범용으로 다운 그레이드 하는 경우 1tb 보다 큰 단일 데이터베이스의 성능이 저하 될 수 있습니다.Additionally, operations such as backup, restore, database copy, setting up Geo-DR relationships, and downgrading a zone redundant database from Business Critical to General Purpose may experience slower performance for any single databases larger than 1 TB. 자세한 내용은 데이터베이스 크기 조정에 대 한 대기 시간 설명서 를 참조 하세요.Please see our latency documentation on scaling a database for more information.

참고

미리 보기는 예약 인스턴스 아래에서 다루지 않습니다.The preview is not covered under Reserved Instance

프리미엄 및 중요 비즈니스용 서비스 계층 로컬 중복 가용성Premium and Business Critical service tier locally redundant availability

프리미엄 및 중요 비즈니스용 서비스 계층은 단일 노드에 계산 리소스 ( sqlservr.exe 프로세스)와 저장소 (로컬에 연결 된 SSD)를 통합 하는 프리미엄 가용성 모델을 활용 합니다.Premium and Business Critical service tiers leverage the Premium availability model, which integrates compute resources (sqlservr.exe process) and storage (locally attached SSD) on a single node. 고가용성은 3 ~ 4 개 노드 클러스터를 만드는 추가 노드에 계산과 저장소를 복제 하 여 수행 됩니다.High availability is achieved by replicating both compute and storage to additional nodes creating a three to four-node cluster.

데이터베이스 엔진 노드의 클러스터

기본 데이터베이스 파일 (.mdf/.ldf)은 연결 된 SSD 저장소에 배치 되어 워크 로드에 매우 짧은 대기 시간 IO를 제공 합니다.The underlying database files (.mdf/.ldf) are placed on the attached SSD storage to provide very low latency IO to your workload. 고가용성은 SQL Server Always On 가용성 그룹와 비슷한 기술을 사용 하 여 구현 됩니다.High availability is implemented using a technology similar to SQL Server Always On availability groups. 클러스터에는 읽기/쓰기 고객 작업에 액세스할 수 있는 단일 주 복제본과 데이터 복사본을 포함 하는 최대 3 개의 보조 복제본 (계산 및 저장소)이 포함 되어 있습니다.The cluster includes a single primary replica that is accessible for read-write customer workloads, and up to three secondary replicas (compute and storage) containing copies of data. 주 노드는 계속 해 서 보조 노드에 대 한 변경 내용을 적용 하 고 각 트랜잭션을 커밋하기 전에 데이터를 하나 이상의 보조 복제본에 동기화 되도록 합니다.The primary node constantly pushes changes to the secondary nodes in order and ensures that the data is synchronized to at least one secondary replica before committing each transaction. 이 프로세스를 통해 어떤 이유로 든 주 노드가 충돌 하는 경우 항상 완전히 동기화 된 노드는로 장애 조치 (failover) 됩니다.This process guarantees that if the primary node crashes for any reason, there is always a fully synchronized node to fail over to. 장애 조치 (failover)는 Azure Service Fabric에 의해 시작 됩니다.The failover is initiated by the Azure Service Fabric. 보조 복제본이 새 주 노드가 되 면 클러스터에 충분 한 노드 (쿼럼 집합)가 있는지 확인 하기 위해 다른 보조 복제본이 생성 됩니다.Once the secondary replica becomes the new primary node, another secondary replica is created to ensure the cluster has enough nodes (quorum set). 장애 조치 (failover)가 완료 되 면 Azure SQL 연결이 자동으로 새 주 노드로 리디렉션됩니다.Once failover is complete, Azure SQL connections are automatically redirected to the new primary node.

추가 혜택으로 프리미엄 가용성 모델에는 읽기 전용 Azure SQL 연결을 보조 복제본 중 하나로 리디렉션하는 기능이 포함 되어 있습니다.As an extra benefit, the premium availability model includes the ability to redirect read-only Azure SQL connections to one of the secondary replicas. 이 기능을 읽기 확장이라고 합니다. 주 복제본에서 분석 워크 로드와 같은 읽기 전용 작업을 오프 로드 하기 위해 추가 요금 없이 100% 추가 계산 용량을 제공 합니다.This feature is called Read Scale-Out. It provides 100% additional compute capacity at no extra charge to off-load read-only operations, such as analytical workloads, from the primary replica.

프리미엄 및 중요 비즈니스용 서비스 계층 영역 중복 가용성Premium and Business Critical service tier zone redundant availability

기본적으로 프리미엄 가용성 모델에 대 한 노드 클러스터는 동일한 데이터 센터에 만들어집니다.By default, the cluster of nodes for the premium availability model is created in the same datacenter. Azure 가용성 영역도입 된 SQL Database 중요 비즈니스용 데이터베이스의 여러 복제본을 동일한 지역의 다른 가용성 영역에 저장할 수 있습니다.With the introduction of Azure Availability Zones, SQL Database can place different replicas of the Business Critical database to different availability zones in the same region. 단일 실패 지점을 제거하기 위해 제어 링은 세 개의 GW(게이트웨이 링)로 여러 영역에 걸쳐 복제됩니다.To eliminate a single point of failure, the control ring is also duplicated across multiple zones as three gateway rings (GW). 특정 게이트웨이 링에 대한 라우팅은 ATM(Azure Traffic Manager)에서 제어됩니다.The routing to a specific gateway ring is controlled by Azure Traffic Manager (ATM). 프리미엄 또는 중요 비즈니스용 서비스 계층의 영역 중복 구성은 추가 데이터베이스 중복성을 만들지 않으므로 추가 비용 없이 사용 하도록 설정할 수 있습니다.Because the zone redundant configuration in the Premium or Business Critical service tiers does not create additional database redundancy, you can enable it at no extra cost. 영역 중복 구성을 선택 하면 응용 프로그램 논리를 변경 하지 않고도 심각한 데이터 센터 중단을 포함 하 여 훨씬 더 큰 오류 집합에 대해 프리미엄 또는 중요 비즈니스용 데이터베이스를 탄력적으로 복원할 수 있습니다.By selecting a zone redundant configuration, you can make your Premium or Business Critical databases resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes to the application logic. 기존 프리미엄 또는 중요 비즈니스용 데이터베이스 또는 풀을 영역 중복 구성으로 변환할 수도 있습니다.You can also convert any existing Premium or Business Critical databases or pools to the zone redundant configuration.

영역 중복 데이터베이스에는 서로 다른 데이터 센터의 복제본이 있기 때문에 네트워크 대기 시간이 늘어나면 커밋 시간이 늘어날 수 있으므로 일부 OLTP 작업의 성능에 영향을 줄 수 있습니다.Because the zone redundant databases have replicas in different datacenters with some distance between them, the increased network latency may increase the commit time and thus impact the performance of some OLTP workloads. 언제든지 영역 중복 설정을 사용하지 않도록 설정하여 단일 영역 구성으로 돌아갈 수 있습니다.You can always return to the single-zone configuration by disabling the zone redundancy setting. 이 프로세스는 일반 서비스 계층 업그레이드와 비슷한 온라인 작업입니다.This process is an online operation similar to the regular service tier upgrade. 프로세스가 완료되면 데이터베이스 또는 풀이 영역 중복 링에서 단일 영역 링으로 또는 그 반대로 마이그레이션됩니다.At the end of the process, the database or pool is migrated from a zone redundant ring to a single zone ring or vice versa.

중요

중요 비즈니스용 계층을 사용할 때 영역 중복 구성은 Gen5 계산 하드웨어를 선택한 경우에만 사용할 수 있습니다.When using the Business Critical tier, zone redundant configuration is only available when the Gen5 compute hardware is selected. 영역 중복 데이터베이스를 지 원하는 지역에 대 한 최신 정보는 지역별 서비스 지원을 참조 하세요.For up to date information about the regions that support zone redundant databases, see Services support by region.

참고

이 기능은 SQL Managed Instance에서 사용할 수 없습니다.This feature is not available in SQL Managed Instance.

다음 다이어그램에서는 고가용성 아키텍처의 영역 중복 버전을 보여 줍니다.The zone redundant version of the high availability architecture is illustrated by the following diagram:

고가용성 아키텍처 영역 중복

분산 서비스 계층 가용성Hyperscale service tier availability

하이퍼 확장 서비스 계층 아키텍처는 분산 함수 아키텍처 에 설명 되어 있으며 현재 SQL Managed Instance가 아닌 SQL Database에만 사용할 수 있습니다.The Hyperscale service tier architecture is described in Distributed functions architecture and is only currently available for SQL Database, not SQL Managed Instance.

하이퍼 확장 기능 아키텍처

Hyperscale의 가용성 모델에는 다음 4 개의 계층이 포함 됩니다.The availability model in Hyperscale includes four layers:

  • 프로세스를 실행 하 sqlservr.exe 고, 연결 된 SSD에서 포함 되지 않은 RBPEX cache, TempDB, model 데이터베이스 등과 같은 임시 및 캐시 된 데이터만 포함 하 고 메모리의 계획 캐시, 버퍼 풀 및 columnstore 풀을 포함 하는 상태 비저장 계산 계층입니다.A stateless compute layer that runs the sqlservr.exe processes and contains only transient and cached data, such as non-covering RBPEX cache, TempDB, model database, etc. on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. 이 상태 비저장 계층에는 기본 계산 복제본과 장애 조치 (failover) 대상으로 사용할 수 있는 선택적 개수의 보조 계산 복제본이 포함 됩니다.This stateless layer includes the primary compute replica and optionally a number of secondary compute replicas that can serve as failover targets.
  • 페이지 서버에서 구성 된 상태 비저장 저장소 계층입니다.A stateless storage layer formed by page servers. 이 계층은 sqlservr.exe 계산 복제본에서 실행 되는 프로세스에 대 한 분산 저장소 엔진입니다.This layer is the distributed storage engine for the sqlservr.exe processes running on the compute replicas. 각 페이지 서버에는 연결 된 SSD의 RBPEX cache 및 메모리에 캐시 된 데이터 페이지와 같은 임시 및 캐시 된 데이터만 포함 됩니다.Each page server contains only transient and cached data, such as covering RBPEX cache on the attached SSD, and data pages cached in memory. 각 페이지 서버에는 부하 분산, 중복성 및 고가용성을 제공 하기 위해 활성-활성 구성의 쌍을 이루는 페이지 서버가 있습니다.Each page server has a paired page server in an active-active configuration to provide load balancing, redundancy, and high availability.
  • 로그 서비스 프로세스를 실행 하는 계산 노드, 트랜잭션 로그 방문 영역 및 트랜잭션 로그 장기 저장소로 구성 된 상태 저장 트랜잭션 로그 저장소 계층입니다.A stateful transaction log storage layer formed by the compute node running the Log service process, the transaction log landing zone, and transaction log long term storage. 방문 영역 및 장기 저장소는 트랜잭션 로그에 대 한 가용성 및 중복성 을 제공 하는 Azure Storage을 사용 하 여 커밋된 트랜잭션에 대 한 데이터 내 구성을 보장 합니다.Landing zone and long term storage use Azure Storage, which provides availability and redundancy for transaction log, ensuring data durability for committed transactions.
  • Azure Storage에 저장 되 고 페이지 서버에서 업데이트 되는 데이터베이스 파일 (.mdf/.ndf)이 포함 된 상태 저장 데이터 저장소 계층입니다.A stateful data storage layer with the database files (.mdf/.ndf) that are stored in Azure Storage and are updated by page servers. 이 계층은 Azure Storage의 데이터 가용성 및 중복성 기능을 사용 합니다.This layer uses data availability and redundancy features of Azure Storage. 이를 통해 데이터 파일의 모든 페이지가 하이퍼 확장 아키텍처 충돌의 다른 계층에 있는 프로세스 또는 계산 노드가 실패 하는 경우에도 유지 됩니다.It guarantees that every page in a data file will be preserved even if processes in other layers of Hyperscale architecture crash, or if compute nodes fail.

모든 하이퍼 규모 계층의 계산 노드는 Azure Service Fabric에서 실행 되며, 각 노드의 상태를 제어 하 고 필요에 따라 사용 가능한 정상 노드로 장애 조치 (failover)를 수행 합니다.Compute nodes in all Hyperscale layers run on Azure Service Fabric, which controls health of each node and performs failovers to available healthy nodes as necessary.

하이퍼 규모의 고가용성에 대 한 자세한 내용은 hyperscale의 데이터베이스 고가용성을 참조 하세요.For more information on high availability in Hyperscale, see Database High Availability in Hyperscale.

ADR(가속 데이터베이스 복구)Accelerated Database Recovery (ADR)

ADR (가속화 된 데이터베이스 복구) 는 특히 장기 실행 트랜잭션이 있을 때 데이터베이스 가용성을 크게 향상 시키는 새로운 데이터베이스 엔진 기능입니다.Accelerated Database Recovery (ADR) is a new database engine feature that greatly improves database availability, especially in the presence of long running transactions. ADR는 현재 Azure SQL Database, Azure SQL Managed Instance 및 Azure Synapse 분석에 사용할 수 있습니다.ADR is currently available for Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics.

응용 프로그램 오류 복원 력 테스트Testing application fault resiliency

고가용성은 데이터베이스 애플리케이션에 대해 투명하게 작동하는 SQL Database 및 SQL Managed Instance 플랫폼의 기본 부분입니다.High availability is a fundamental part of the SQL Database and SQL Managed Instance platform that works transparently for your database application. 그러나 애플리케이션을 프로덕션 환경에 배포하기 전에 계획되거나 계획되지 않은 이벤트 중에 시작된 자동 장애 조치(failover) 작업이 애플리케이션에 어떤 영향을 미치는지 테스트해보고 싶을 수 있습니다.However, we recognize that you may want to test how the automatic failover operations initiated during planned or unplanned events would impact an application before you deploy it to production. 특수 API를 호출 하 여 데이터베이스, 탄력적 풀 또는 관리 되는 인스턴스를 다시 시작 하 여 장애 조치 (failover)를 수동으로 트리거할 수 있습니다.You can manually trigger a failover by calling a special API to restart a database, an elastic pool, or a managed instance. 영역 중복 데이터베이스 또는 탄력적 풀의 경우 API 호출로 인해 이전 주 데이터베이스의 가용성 영역과 다른 가용성 영역에서 새 주 데이터베이스로 클라이언트 연결이 리디렉션됩니다.In the case of a zone redundant database or elastic pool, the API call would result in redirecting client connections to the new primary in an Availability Zone different from the Availability Zone of the old primary. 따라서 장애 조치 (failover)가 기존 데이터베이스 세션에 미치는 영향을 테스트 하는 것 외에도 네트워크 지연 시간이 변경 되어 종단 간 성능이 변경 되는지 확인할 수 있습니다.So in addition to testing how failover impacts existing database sessions, you can also verify if it changes the end-to-end performance due to changes in network latency. 다시 시작 작업은 개입 하지 않으며 많은 수의 플랫폼에서 스트레스를 발생 시킬 수 있기 때문에 각 데이터베이스, 탄력적 풀 또는 관리 되는 인스턴스에 대해 15 분 마다 하나의 장애 조치 (failover) 호출만 허용 됩니다.Because the restart operation is intrusive and a large number of them could stress the platform, only one failover call is allowed every 15 minutes for each database, elastic pool, or managed instance.

장애 조치 (failover)는 PowerShell, REST API 또는 Azure CLI를 사용 하 여 시작할 수 있습니다.A failover can be initiated using PowerShell, REST API, or Azure CLI:

배포 유형Deployment type PowerShellPowerShell REST APIREST API Azure CLIAzure CLI
데이터베이스Database AzSqlDatabaseFailoverInvoke-AzSqlDatabaseFailover 데이터베이스 장애 조치Database failover az rest 를 사용 하 여에서 REST API 호출을 호출할 수 있습니다 Azure CLIaz rest may be used to invoke a REST API call from Azure CLI
탄력적 풀Elastic pool AzSqlElasticPoolFailoverInvoke-AzSqlElasticPoolFailover 탄력적 풀 장애 조치 (failover)Elastic pool failover az rest 를 사용 하 여에서 REST API 호출을 호출할 수 있습니다 Azure CLIaz rest may be used to invoke a REST API call from Azure CLI
관리되는 인스턴스Managed Instance AzSqlInstanceFailoverInvoke-AzSqlInstanceFailover 관리 되는 인스턴스-장애 조치Managed Instances - Failover az sql mi 장애 조치az sql mi failover

중요

장애 조치 (Failover) 명령은 Hyperscale 데이터베이스의 읽기 가능한 보조 복제본에 사용할 수 없습니다.The Failover command is not available for readable secondary replicas of Hyperscale databases.

결론Conclusion

Azure SQL Database 및 Azure SQL Managed Instance 기능은 Azure 플랫폼과 긴밀 하 게 통합 되는 기본 제공 고가용성 솔루션입니다.Azure SQL Database and Azure SQL Managed Instance feature a built-in high availability solution, that is deeply integrated with the Azure platform. 이는 장애 검색 및 복구에 대 한 Service Fabric, 데이터 가용성 영역 보호를 위한 Azure Blob storage, 높은 내결함성 (Azure SQL Managed Instance 아직 적용 되지 않은 문서에서 설명한 대로)에 따라 달라 집니다.It is dependent on Service Fabric for failure detection and recovery, on Azure Blob storage for data protection, and on Availability Zones for higher fault tolerance (as mentioned earlier in document not applicable to Azure SQL Managed Instance yet). 또한 SQL Database 및 SQL Managed Instance는 복제 및 장애 조치 (failover)를 위해 SQL Server 인스턴스에서 Always On 가용성 그룹 기술을 활용 합니다.In addition, SQL Database and SQL Managed Instance leverage the Always On availability group technology from the SQL Server instance for replication and failover. 이러한 기술을 조합 하 여 응용 프로그램에서 혼합 된 저장소 모델의 이점을 완전히 실현 하 고 가장 까다로운 Sla를 지원할 수 있습니다.The combination of these technologies enables applications to fully realize the benefits of a mixed storage model and support the most demanding SLAs.

다음 단계Next steps