개요: 장애 조치 그룹 및 활성 지역 복제Overview: Failover groups and active geo-replication

활성 지역 복제를 사용하면 동일하거나 다른 데이터 센터 위치(하위 지역)에 최대 4개의 읽기 기능한 보조 데이터베이스를 구성할 수 있습니다.Active geo-replication enables you to configure up to four readable secondary databases in the same or different data center locations (regions). 데이터 센터 정전이 발생하거나 주 데이터베이스에 연결하지 못하는 경우 쿼리 및 장애 조치(failover)에 보조 데이터베이스를 사용할 수 있습니다.Secondary databases are available for querying and for failover if there is a data center outage or the inability to connect to the primary database. 장애 조치는 사용자의 응용 프로그램에서 수동으로 시작되어야 합니다.The failover must be initiated manually by the application of the user. 장애 조치 후 새 주 데이터베이스에는 다른 연결 끝점이 있습니다.After failover, the new primary has a different connection end-point.

참고

활성 지역 복제는 모든 지역의 현재 모든 서비스 계층에 있는 모든 데이터베이스에 대해 제공됩니다.Active geo-replication is available for all databases in all service tiers in all regions.

Azure SQL Database 자동 장애 조치 그룹(미리 보기 상태)은 규모에 맞게 지역에서 복제 관계, 연결 및 장애 조치를 자동으로 관리하도록 설계된 SQL Database 기능입니다.Azure SQL Database auto-failover groups (in-preview) is a SQL Database feature designed to automatically manage geo-replication relationship, connectivity, and failover at scale. 이 기능을 사용하면 고객은 주 지역에서 SQL Database 서비스의 가용성을 완전히 또는 부분적으로 상실하게 하는 치명적인 지역적 장애 또는 계획되지 않은 다른 이벤트가 발생한 후에 보조 지역의 여러 관련 데이터베이스를 자동으로 복구할 수 있습니다.With it, the customers gain the ability to automatically recover multiple related databases in the secondary region after catastrophic regional failures or other unplanned events that result in full or partial loss of the SQL Database service’s availability in the primary region. 또한 읽을 수 있는 보조 데이터베이스를 사용하여 읽기 전용 워크로드를 오프로드할 수 있습니다.Additionally, they can use the readable secondary databases to offload read-only workloads. 자동 장애 조치 그룹에는 여러 데이터베이스가 포함되므로 주 서버에서 이 그룹을 구성해야 합니다.Because auto-failover groups involve multiple databases, they must be configured on the primary server. 기본 서버와 보조 서버는 모두 동일한 구독에 있어야 합니다.Both primary and secondary servers must be in the same subscription. 자동 장애 조치 그룹은 그룹의 모든 데이터베이스를 다른 지역에 있는 하나의 보조 서버로만 복제할 수 있도록 지원합니다.Auto-failover groups support replication of all databases in the group to only one secondary server in a different region. 자동 장애 조치 그룹 없는 활성 지역 복제는 모든 지역에서 최대 4개의 보조 서버를 허용합니다.Active geo-replication, without auto-failover groups, allows up to four secondaries in any region.

활성 지역 복제를 사용 중이고 어떤 이유로든 주 데이터베이스가 실패하거나 단순히 오프라인으로 전환해야 하는 경우 장애 조치를 보조 데이터베이스 중 하나로 시작할 수 있습니다.If you are using active geo-replication and for any reason your primary database fails, or simply needs to be taken offline, you can initiate failover to any of your secondary databases. 장애 조치가 보조 데이터베이스 중 하나로 활성화된 경우 모든 다른 보조가 새 보조로 자동으로 연결됩니다.When failover is activated to one of the secondary databases, all other secondaries are automatically linked to the new primary. 자동 장애 조치 그룹(미리 보기 상태)을 사용하여 데이터베이스 복구를 관리하고 그룹의 데이터베이스 중 하나 이상에 영향을 미치는 가동 중단이 발생하면 자동 장애 조치를 수행합니다.If you are using auto-failover groups (in-preview) to manage database recovery and any outage that impacts one or several of the databases in the group results in automatic failover. 응용 프로그램 요구 사항에 가장 부합하는 자동 장애 조치 정책을 구성하거나 수동 활성화를 옵트아웃하고 사용할 수 있습니다.You can configure the auto-failover policy that best meets your application needs, or you can opt out and use manual activation. 또한 자동 장애 조치 그룹(미리 보기 상태)은 장애 조치하는 동안 변경되지 않는 읽기-쓰기 및 읽기 전용 수신기 끝점을 제공합니다.In addition, auto-failover groups (in-preview) provide read-write and read-only listener end-points that remain unchanged during failovers. 수동 또는 자동 장애 조치 활성화를 사용하는지 여부에 관계 없이 장애 조치는 그룹의 모든 보조 데이터베이스를 주 데이터베이스로 전환합니다.Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. 데이터베이스 장애 조치가 완료되면 끝점을 새 지역으로 리디렉션하도록 DNS 레코드를 자동으로 업데이트합니다.After the database failover is completed, the DNS record is automatically updated to redirect the end-points to the new region.

활성 지역 복제를 사용하여 서버 또는 탄력적 풀에 있는 개별 데이터베이스 또는 데이터베이스 집합의 복제 및 장애 조치를 관리할 수 있습니다.You can manage replication and failover of an individual database or a set of databases on a server or in an elastic pool using active geo-replication. 다음을 사용하여 수행할 수 있습니다.You can do that using

장애 조치(failover) 후에는 새로운 주 데이터베이스에서 서버 및 데이터베이스의 인증 요구 사항이 구성되어 있는지 확인합니다.After failover, ensure the authentication requirements for your server and database are configured on the new primary. 자세한 내용은 재해 복구 후의 SQL Database 보안을 참조하세요.For details, see SQL Database security after disaster recovery. 이는 활성 지역 복제 및 자동 장애 조치 그룹(미리 보기 상태) 모두에 적용됩니다.This applies both to active geo-replication and auto-failover groups (in-preview).

활성 지역 복제는 SQL Server의 Always On 기술을 활용하여 RCSI(읽기 커밋된 스냅숏 격리)를 통해 주 데이터베이스의 커밋된 트랜잭션을 보조 데이터베이스로 비동기적으로 복제합니다.Active geo-replication leverages the Always On technology of SQL Server to asynchronously replicate committed transactions on the primary database to a secondary database using read committed snapshot isolation (RCSI). 자동 장애 조치 그룹은 활성 지역 복제를 기반으로 하는 그룹 의미 체계를 제공하지만 동일한 비동기 복제 메커니즘이 사용됩니다.Auto-failover groups provide the group semantics on top of active geo-replication but the same asynchronous replication mechanism is used. 지정된 지점에서 보조 데이터베이스는 주 데이터베이스보다 약간 뒤에 있을 수 있는 반면 보조 데이터는 절대 부분 트랜잭션을 갖지 않습니다.While at any given point, the secondary database might be slightly behind the primary database, the secondary data is guaranteed to never have partial transactions. 지역 간 중복을 사용하면 자연 재해, 인간의 치명적인 실수 또는 악의적 행위로 인해 데이터 센터의 일부 또는 전체가 영구적으로 손실되더라도 응용 프로그램을 빠르게 복구할 수 있습니다.Cross-region redundancy enables applications to quickly recover from a permanent loss of an entire datacenter or parts of a datacenter caused by natural disasters, catastrophic human errors, or malicious acts. 특정 RPO 데이터를 비즈니스 연속성 개요에서 찾을 수 있습니다.The specific RPO data can be found at Overview of Business Continuity.

다음 그림은 미국 중북부 지역에 주 데이터베이스, 미국 중남부 지역에 보조 데이터베이스가 구성된 활성 지역 복제의 예입니다.The following figure shows an example of active geo-replication configured with a primary in the North Central US region and secondary in the South Central US region.

지역에서 복제 관계

보조 데이터베이스를 읽을 수 있기 때문에 보고 작업과 같은 읽기 전용 워크로드를 오프로드하는 데 사용할 수 있습니다.Because the secondary databases are readable, they can be used to offload read-only workloads such as reporting jobs. 활성 지역 복제를 사용하는 경우 주 데이터베이스와 동일한 지역에 보조 데이터베이스를 만들 수 있지만 치명적인 장애에 대한 응용 프로그램의 복원성을 높이지는 않습니다.If you are using active geo-replication, it is possible to create the secondary database in the same region with the primary, but it does not increase the application's resilience to catastrophic failures. 자동 장애 조치 그룹(미리 보기 상태)을 사용하는 경우 보조 데이터베이스는 항상 다른 지역에 만들어집니다.If you are using auto-failover groups (in-preview), your secondary database is always created in a different region.

활성 지역 복제는 재해 복구 외에도 다음과 같은 시나리오에서 사용할 수 있습니다.In addition to disaster recovery active geo-replication can be used in the following scenarios:

  • 데이터베이스 마이그레이션: 활성 지역 복제를 사용하여 최소 가동 중지 시간으로 하나의 서버에서 다른 온라인으로 데이터베이스를 마이그레이션할 수 있습니다.Database migration: You can use active geo-replication to migrate a database from one server to another online with minimum downtime.
  • 응용 프로그램 업그레이드: 응용 프로그램을 업그레이드하는 동안 추가 보조 데이터베이스를 장애 복구 복사본으로 만들 수 있습니다.Application upgrades: You can create an extra secondary as a fail back copy during application upgrades.

실제 비즈니스 연속성을 달성하기 위해 데이터 센터 간에 데이터베이스 중복을 추가하는 것은 솔루션의 일부입니다.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. 치명적인 오류 후 응용 프로그램(서비스) 종단 간 복구에는 서비스 및 모든 종속성 서비스를 구성하는 모든 구성 요소의 복구가 필요합니다.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. 이러한 구성 요소의 예에는 클라이언트 소프트웨어(예: 사용자 지정 JavaScript를 사용한 브라우저), 웹 프런트 엔드, 저장소 및 DNS가 포함됩니다.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. 모든 구성 요소는 동일한 오류에 탄력적이며 응용 프로그램의 복구 시간 목표(RTO) 내에서 사용할 수 있는 것이 중요합니다.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. 따라서 모든 종속성 서비스를 확인하고 제고하는 보장 사항 및 기능을 이해해야 합니다.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. 그런 다음 의존하는 서비스 장애 조치 중 서비스 기능을 확인하도록 적절한 단계를 수행해야 합니다.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. 재해 복구를 위한 솔루션 설계에 대한 자세한 내용은 활성 지역 복제를 사용하여 재해 복구를 위한 클라우드 솔루션 설계를 참조하세요.For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

활성 지역 복제 기능Active geo-replication capabilities

활성 지역 복제 기능은 다음과 같은 필수 기능을 제공합니다.The active geo-replication feature provides the following essential capabilities:

  • 자동 비동기 복제: 보조 데이터베이스는 기존 데이터베이스에 추가하는 방법으로만 만들 수 있습니다.Automatic Asynchronous Replication: You can only create a secondary database by adding to an existing database. 보조 데이터베이스는 모든 Azure SQL Database 서버에 만들 수 있습니다.The secondary can be created in any Azure SQL Database server. 한번 만들면 보조 데이터베이스는 주 데이터베이스에서 복사된 데이터로 채워집니다.Once created, the secondary database is populated with the data copied from the primary database. 이 프로세스를 시드라고 합니다.This process is known as seeding. 보조 데이터베이스가 생성 및 시드되면 주 데이터베이스에 대한 업데이트가 보조 데이터베이스에 자동으로 비동기적으로 복사됩니다.After secondary database has been created and seeded, updates to the primary database are asynchronously replicated to the secondary database automatically. 비동기 복제에서는 트랜잭션이 보조 데이터베이스에 복제되기 전에 주 데이터베이스에 커밋됩니다.Asynchronous replication means that transactions are committed on the primary database before they are replicated to the secondary database.
  • 읽을 수 있는 보조 데이터베이스: 응용 프로그램은 주 데이터베이스에 액세스하는 데 사용된 동일한 보안 주체를 사용하여 읽기 전용 작업에 대한 보조 데이터베이스에 액세스할 수 있습니다.Readable secondary databases: An application can access a secondary database for read-only operations using the same or different security principals used for accessing the primary database. 보조 데이터베이스에서 실행되는 쿼리 때문에 주 데이터베이스(로그 재생)의 업데이트 복제가 지연되지 않도록 보장하기 위해 보조 데이터베이스는 스냅숏 격리 모드에서 작동합니다.The secondary databases operate in snapshot isolation mode to ensure replication of the updates of the primary (log replay) is not delayed by queries executed on the secondary.

    참고

    주 데이터베이스에 스키마 업데이트가 있는 경우 보조 데이터베이스에서 로그 재생이 지연됩니다.The log replay is delayed on the secondary database if there are schema updates on the Primary. 후자의 경우 보조 데이터베이스에 대한 스키마 잠금이 필요합니다.The latter requires a schema lock on the secondary database.

  • 여러 번 읽을 수 있는 보조 데이터베이스: 둘 이상의 보조 데이터베이스는 주 데이터베이스와 응용 프로그램의 중복성 및 보호 수준을 높입니다.Multiple readable secondaries: Two or more secondary databases increase redundancy and level of protection for the primary database and application. 보조 데이터베이스가 여러 개 있는 경우 보조 데이터베이스 중 하나가 실패하더라도 응용 프로그램이 계속해서 보호됩니다.If multiple secondary databases exist, the application remains protected even if one of the secondary databases fails. 보조 데이터베이스가 하나밖에 없는 경우 새 보조 데이터베이스를 만들 때까지 응용 프로그램이 더 높은 위험에 노출됩니다.If there is only one secondary database, and it fails, the application is exposed to higher risk until a new secondary database is created.

    참고

    활성 지역 복제를 사용하여 전역으로 분산된 응용 프로그램을 빌드하고 5개 이상의 지역에 있는 데이터에 대한 읽기 전용 액세스를 제공해야 하는 경우 보조 데이터베이스의 보조 데이터베이스를 만들 수 있습니다(체이닝으로 알려진 프로세스).If you are using active geo-replication to build a globally distributed application and need to provide read-only access to data in more than four segions, you can create secondary of a secondary (a process known as chaining). 이렇게 하면 거의 제한이 없는 규모의 데이터베이스 복제를 수행할 수 있습니다.This way you can achieve virtually unlimited scale of database replication. 또한 체이닝을 사용하면 주 데이터베이스의 복제 오버헤드가 줄어듭니다.In addition, chaining reduces the overhead of replication from the primary database. 단점은 리프가 가장 많은 보조 데이터베이스의 복제 지연 시간이 증가하는 것입니다.The trade-off is the increased replication lag on the leaf-most secondary databases.

  • 탄력적 풀 데이터베이스 지원: 모든 탄력적 풀의 모든 데이터베이스에 대해 활성 지역 복제를 구성할 수 있습니다.Support of elastic pool databases: Active geo-replication can be configured for any database in any elastic pool. 보조 데이터베이스는 또 다른 탄력적 풀에 있어도 됩니다.The secondary database can be in another elastic pool. 일반 데이터베이스의 경우 서비스 계층이 같은 한, 보조 데이터베이스가 탄력적 풀일 수 있고 그 반대도 가능합니다.For regular databases, the secondary can be an elastic pool and vice versa as long as the service tiers are the same.

  • 보조 데이터베이스의 구성 가능한 성능 수준: 기본 및 보조 데이터베이스에는 동일한 서비스 계층(Basic, Standard, Premium)이 있어야 합니다.Configurable performance level of the secondary database: Both primary and secondary databases are required to have the same service tier (Basic, Standard, Premium). 보조 데이터베이스는 기본에 비해 낮은 성능 수준(DTU)으로 만들 수 있습니다.A secondary database can be created with lower performance level (DTUs) than the primary. 데이터베이스 쓰기 활동이 많은 응용 프로그램에는 이 방법을 권장하지 않습니다. 복제 지연이 증가하고, 그로 인해 장애 조치(failover) 후 후속 데이터 손실의 위험이 높기 때문입니다.This option is not recommended for applications with high database write activity because the increased replication lag increases the risk of substantial data loss after a failover. 뿐만 아니라 장애 조치(failover) 후 새로운 주 데이터베이스가 더 높은 성능 수준으로 업그레이드될 때까지 응용 프로그램 성능이 영향을 받습니다.In addition, after failover the application’s performance is impacted until the new primary is upgraded to a higher performance level. Azure Portal의 로그 IO 백분율 차트는 복제 부하를 유지하는 데 필요한 보조 데이터베이스의 최소 성능 수준을 예상하는 데 유용하게 사용할 수 있습니다.The log IO percentage chart on Azure portal provides a good way to estimate the minimal performance level of the secondary that is required to sustain the replication load. 예를 들어 주 데이터베이스가 P6(1000 DTU)이면 해당 로그 IO 백분율은 50%이고 보조 데이터베이스는 최소한 P4(500 DTU) 이상이어야 합니다.For example, if your Primary database is P6 (1000 DTU) and its log IO percent is 50% the secondary needs to be at least P4 (500 DTU). sys.resource_stats 또는 ys.dm_db_resource_stats 데이터베이스 뷰를 사용하여 로그 IO 데이터를 검색할 수도 있습니다.You can also retrieve the log IO data using sys.resource_stats or sys.dm_db_resource_stats database views. SQL Database 성능 수준에 대한 자세한 내용은 SQL Database 옵션 및 성능을 참조하세요.For more information on the SQL Database performance levels, see SQL Database options and performance.
  • 사용자 제어 장애 조치(failover) 및 장애 복구: 보조 데이터베이스는 응용 프로그램 또는 사용자에 의해 언제든지 주 데이터베이스 역할로 전환될 수 있습니다.User-controlled failover and failback: A secondary database can explicitly be switched to the primary role at any time by the application or the user. 실제로 가동이 중단되면 보조 데이터베이스를 즉시 주 데이터베이스로 승격하는 "계획되지 않음" 옵션을 사용해야 합니다.During a real outage the “unplanned” option should be used, which immediately promotes a secondary to be the primary. 중지된 주 데이터베이스가 복구되어 작동 가능한 상태가 되면 시스템에서는 복구된 주 데이터베이스를 자동으로 보조 데이터베이스로 표시하고 새로운 주 데이터베이스와 함께 최신 상태로 전환합니다.When the failed primary recovers and is available again, the system automatically marks the recovered primary as a secondary and bring it up-to-date with the new primary. 주 데이터베이스가 가장 최근의 변경 사항을 보조 데이터베이스로 복제하기 전에 중단될 경우 비동기 복제의 특성상 계획되지 않은 장애 조치(failover)가 진행되는 동안 소량의 데이터가 손실될 수 있습니다.Due to the asynchronous nature of replication, a small amount of data can be lost during unplanned failovers if a primary fails before it replicates the most recent changes to the secondary. 보조 데이터베이스가 여러 개 있는 주 데이터베이스가 중단되면 시스템에서 사용자의 개입 없이 자동으로 복제 관계를 다시 구성하고 남아 있는 보조 데이터베이스를 새로 승격되는 주 데이터베이스에 연결합니다.When a primary with multiple secondaries fails over, the system automatically reconfigures the replication relationships and links the remaining secondaries to the newly promoted primary without requiring any user intervention. 장애 조치(failover)를 일으킨 작동 중단 상황이 완화된 후에는 응용 프로그램을 주 지역으로 반환하는 것이 바람직할 수 있습니다.After the outage that caused the failover is mitigated, it may be desirable to return the application to the primary region. 장애 조치(failover)를 수행하려면 “계획됨” 옵션을 사용하여 명령을 호출해야 합니다.To do that, the failover command should be invoked with the “planned” option.
  • 자격 증명과 방화벽 규칙의 동기화 유지: 지역에서 복제된 데이터베이스에 데이터베이스 방화벽 규칙을 사용할 것을 권장합니다. 데이터베이스 방화벽 규칙을 데이터베이스와 함께 복제하면 모든 보조 데이터베이스가 주 데이터베이스와 동일한 방화벽 규칙을 갖기 때문입니다.Keeping credentials and firewall rules in sync: We recommend using database firewall rules for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same firewall rules as the primary. 이렇게 하면 고객이 주 데이터베이스 및 보조 데이터베이스를 호스팅하는 서버에서 수동으로 방화벽 규칙을 구성하고 유지 관리할 필요가 없습니다.This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. 마찬가지로, 데이터 액세스에 포함된 데이터베이스 사용자를 사용하면 주 데이터베이스와 보조 데이터베이스의 사용자 자격 증명이 항상 똑같기 때문에 장애 조치(failover) 시에 로그인과 암호가 불일치하여 중단되는 일이 없습니다.Similarly, using contained database users for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. Azure Active Directory가 추가되면서 고객은 주 데이터베이스 및 보조 데이터베이스에 대한 사용자 액세스를 관리할 수 있으므로 데이터베이스의 자격 증명을 모두 관리할 필요가 없습니다.With the addition of Azure Active Directory, customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.

자동 장애 조치 그룹 기능Auto-failover group capabilities

자동 장애 조치 그룹 기능은 그룹 수준 복제 및 자동 장애 조치를 지원하여 활성 지역 복제의 강력한 추상화를 제공합니다.Auto-failover groups feature provides a powerful abstraction of active geo-replication by supporting group level replication and automatic failover. 또한 추가 수신기 끝점을 제공하여 장애 조치 후 SQL 연결 문자열을 변경할 필요가 없습니다.In addition, it removes the necessity to change the SQL connection string after failover by providing the additional listener end-points.

  • 장애 조치 그룹: 다른 지역의 두 서버 (기본 및 보조 서버) 간에 하나 이상의 장애 조치 그룹을 만들 수 있습니다.Failover group: One or many failover groups can be created between two servers in different regions (primary and secondary servers). 주 지역의 가동 중단으로 인해 주 데이터베이스 전체 또는 일부를 사용할 수 없게 되는 경우를 대비하여 각 그룹에 한 단위로 복구되는 하나 또는 여러 개의 데이터베이스가 포함될 수 있습니다.Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region.
  • 주 서버: 장애 조치 그룹에서 주 데이터베이스를 호스팅하는 서버입니다.Primary server: A server that hosts the primary databases in the failover group.
  • 보조 서버: 장애 조치 그룹에서 보조 데이터베이스를 호스팅하는 서버입니다.Secondary server: A server that hosts the secondary databases in the failover group. 보조 서버는 주 서버와 동일한 지역에 있을 수 없습니다.The secondary server cannot be in the same region as the primary server.
  • 장애 조치 그룹에 데이터베이스 추가: 서버 내 또는 탄력적 풀 내의 여러 데이터베이스를 동일한 장애 조치 그룹에 배치할 수 있습니다.Adding databases to failover group: You can put several databases within a server or within an elastic pool into the same failover group. 그룹에 독립 실행형 데이터베이스를 추가하면 동일한 버전과 성능 수준을 사용하는 보조 데이터베이스가 자동으로 만들어집니다.If you add a standalone database to the group, it automatically creates a secondary database using the same edition and performance level. 탄력적 풀에 주 데이터베이스가 있으면 보조 서버가 동일한 이름을 가진 탄력적 풀에 자동으로 만들어집니다.If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name. 보조 서버에 보조 데이터베이스가 이미 있는 데이터베이스를 추가하면 해당 지역 복제가 그룹에 상속됩니다.If you add a database that already has a secondary database in the secondary server, that geo-replication is inherited by the group.

    참고

    장애 조치 그룹에 속하지 않은 서버에 보조 데이터베이스가 이미 있는 데이터베이스를 추가하면 새 보조 데이터베이스가 보조 서버에 만들어집니다.When adding a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

  • 장애 조치(failover) 그룹 읽기-쓰기 수신기: 현재 주 서버 URL을 가리키는 <failover-group-name>.database.windows.net 형식의 DNS CNAME 레코드입니다.Failover group read-write listener: A DNS CNAME record formed as <failover-group-name>.database.windows.net that points to the current primary server URL. 장애 조치 후 주 데이터베이스가 변경되면 읽기-쓰기 SQL 응용 프로그램이 해당 주 데이터베이스에 투명하게 다시 연결할 수 있습니다.It allows the read-write SQL applications to transparently reconnect to the primary database when the primary changes after failover.

  • 장애 조치(failover) 그룹 읽기 전용 수신기: 현재 보조 서버 URL을 가리키는 <failover-group-name>.secondary.database.windows.net 형식의 DNS CNAME 레코드입니다.Failover group read-only listener: A DNS CNAME record formed as <failover-group-name>.secondary.database.windows.net that points to the secondary server’s URL. 읽기 전용 SQL 응용 프로그램은 지정된 부하 분산 규칙을 사용하여 보조 데이터베이스에 투명하게 연결할 수 있습니다.It allows the read-only SQL applications to transparently connect to the secondary database using the specified load-balancing rules. 필요에 따라 보조 서버를 사용할 수 없을 때 읽기 전용 트래픽을 주 서버로 자동으로 리디렉션할지 여부를 지정할 수 있습니다.Optionally you can specify if you want the read-only traffic to be automatically redirected to the primary server when the secondary server is not available.
  • 자동 장애 조치 정책: 기본적으로 장애 조치 그룹은 자동 장애 조치 정책으로 구성됩니다.Automatic failover policy: By default, the failover group is configured with an automatic failover policy. 장애가 검색되는 즉시 시스템에서 장애 조치를 트리거합니다.The system triggers failover as soon as the failure is detected. 응용 프로그램에서 장애 조치 워크플로를 제어하려는 경우 자동 장애 조치를 해제할 수 있습니다.If you want to control the failover workflow from the application, you can turn off automatic failover.
  • 수동 장애 조치: 자동 장애 조치 구성에 관계 없이 언제든지 장애 조치를 수동으로 시작할 수 있습니다.Manual failover: You can initiate failover manually at any time regardless of the automatic failover configuration. 자동 장애 조치(failover) 정책이 구성되지 않은 경우 장애 조치 그룹의 데이터베이스를 복구하려면 수동 장애 조치(failover)를 수행해야 합니다.If automatic failover policy is not configured, manual failover is required to recover databases in the failover group. 강제 장애 조치 또는 친숙한 장애 조치(전체 데이터 동기화 사용)를 시작할 수 있습니다.You can initiate forced or friendly failover (with full data synchronization). 후자는 활성 서버를 주 지역으로 다시 배치하는 데 사용될 수 있습니다.The latter could be used to relocate the active server to the primary region. 장애 조치(failover)가 완료되면 올바른 서버에 대한 연결을 보장하도록 DNS 레코드가 자동으로 업데이트됩니다.When failover is completed, the DNS records are automatically updated to ensure connectivity to the correct server.
  • 데이터 손실이 있는 유예 기간: 주 및 보조 데이터베이스가 비동기 복제를 사용하여 동기화되기 때문에 장애 조치(failover)로 인해 데이터가 손실될 수 있습니다.Grace period with data loss: Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. 응용 프로그램의 데이터 손실 허용 오차를 반영하도록 자동 장애 조치 정책을 사용자 지정할 수 있습니다.You can customize the automatic failover policy to reflect your application’s tolerance to data loss. GracePeriodWithDataLossHours를 구성하여 데이터 손실이 발생할 수 있는 장애 조치를 시작하기 전에 시스템에서 대기하는 시간을 제어할 수 있습니다.By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

    참고

    시스템에서 그룹의 데이터베이스가 아직 온라인 상태에 있음(예: 가동 중단이 서비스 제어 평면에만 영향을 미침)을 검색하면 GracePeriodWithDataLossHours에서 설정한 값에 관계 없이 전체 데이터 동기화(친숙한 장애 조치)를 통해 장애 조치를 즉시 활성화합니다.When system detects that the databases in the group are still online (for example, the outage only impacted the service control plane), it immediately activates the failover with full data synchronization (friendly failover) regardless of the value set by GracePeriodWithDataLossHours. 이 동작은 복구 중 데이터가 손실되지 않도록 합니다.This behavior ensures that there is no data loss during the recovery. 유예 기간은 친숙한 장애 조치를 수행할 수 없는 경우에만 적용됩니다.The grace period takes effect only when a friendly failover is not possible. 유예 기간이 만료되기 전에 가동 중단이 완화되면 장애 조치가 활성화되지 않습니다.If the outage is mitigated before the grace period expires, the failover is not activated.

  • 여러 장애 조치 그룹: 동일한 서버 쌍에 대해 여러 장애 조치 그룹을 구성하여 장애 조치의 크기를 제어할 수 있습니다.Multiple failover groups: You can configure multiple failover groups for the same pair of servers to control the scale of failovers. 각 그룹은 독립적으로 장애 조치됩니다.Each group fails over independently. 다중 테넌트 응용 프로그램에서 탄력적 풀을 사용하는 경우 이 기능을 사용하여 각 풀에 주 및 보조 데이터베이스를 혼합할 수 있습니다.If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. 이렇게 하면 테넌트의 절반에 대해서만 가동 중단에 따른 영향을 줄일 수 있습니다.This way you can reduce the impact of an outage to only half of the tenants.

항상 사용 가능한 서비스를 빌드하는 모범 사례Best practices of building highly available service

Azure SQL Database를 사용하는 항상 사용 가능한 서비스를 빌드하려면 사용자는 다음 지침을 따라야 합니다.To build a highly available service that uses Azure SQL database, you should follow these guidelines:

  • 장애 조치(failover) 그룹 사용: 다른 지역의 두 서버(기본 및 보조 서버) 간에 하나 이상의 장애 조치(failover) 그룹을 만들 수 있습니다.Use failover group: One or many failover groups can be created between two servers in different regions (primary and secondary servers). 주 지역의 가동 중단으로 인해 주 데이터베이스 전체 또는 일부를 사용할 수 없게 되는 경우를 대비하여 각 그룹에 한 단위로 복구되는 하나 또는 여러 개의 데이터베이스가 포함될 수 있습니다.Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. 장애 조치(failover) 그룹을 사용하는 경우 주 데이터베이스와 서비스 목표가 동일한 지역 보조 데이터베이스가 작성됩니다.The failover group creates geo-secondary database with the same service objective as the primary. 장애 조치 그룹에 기존 지역에서 복제 관계를 추가하는 경우 보조 데이터베이스가 주 데이터베이스와 동일한 서비스 수준 목표를 갖도록 구성했는지 확인합니다.If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service level objective as the primary.
  • OLTP 작업용 읽기-쓰기 수신기 사용: OLTP 작업을 수행할 때 <failover-group-name>.database.windows.net을 서버 URL로 사용하면 자동으로 주 데이터베이스에 연결됩니다.Use read-write listener for OLTP workload: When performing OLTP operations, use <failover-group-name>.database.windows.net as the server URL and the connections are automatically directed to the primary. 이 URL은 장애 조치(failover) 후에 변경되지 않습니다.This URL does not change after the failover.
    장애 조치(failover) 시에는 DNS 레코드가 업데이트되므로 클라이언트 DNS 캐시를 새로 고친 후에만 클라이언트 연결이 새 주 데이터베이스로 리디렉션됩니다.Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.
  • 읽기 전용 작업용 읽기 전용 수신기 사용: 특정 데이터가 부실해도 정상적으로 수행 가능한 논리적으로 격리된 읽기 전용 작업이 있는 경우에는 응용 프로그램에서 보조 데이터베이스를 사용할 수 있습니다.Use read-only listener for read-only workload: If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. 읽기 전용 세션의 경우 <failover-group-name>.secondary.database.windows.net을 서버 URL로 사용하면 자동으로 보조 데이터베이스에 연결됩니다.For read-only sessions, use <failover-group-name>.secondary.database.windows.net as the server URL and the connection is automatically directed to the secondary. 또한 ApplicationIntent=ReadOnly를 사용하여 연결 문자열 읽기 의도를 표시하는 것이 좋습니다.It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly.
  • 성능 저하에 대비: SQL 장애 조치 결정은 응용 프로그램의 나머지 부분 또는 사용되는 다른 서비스에서 독립적입니다.Be prepared for perf degradation: SQL failover decision is independent from the rest of the application or other services used. 응용 프로그램은 한 지역의 일부 구성 요소 및 나머지 지역의 일부 구성 요소와 "혼합"될 수 있습니다.The application may be “mixed” with some components in one region and some in another. 성능 저하를 방지하려면 DR 지역에서 중복 응용 프로그램 배포를 확인하고 이 문서의 지침을 따릅니다.To avoid the degradation, ensure the redundant application deployment in the DR region and follow the guidelines in this article.
    DR 지역의 응용 프로그램이 다른 연결 문자열을 사용하지 않아도 됩니다.Note the application in the DR region does not have to use a different connection string.
  • 데이터 손실에 대비: 가동 중지가 검색되는 경우 SQL은 중요한 지식에 대한 데이터 손실이 없으면 읽기-쓰기 장애 조치(failover)를 자동으로 트리거합니다.Prepare for data loss: If an outage is detected, SQL automatically triggers read-write failover if there is zero data loss to the best of our knowledge. 그렇지 않으면 GracePeriodWithDataLossHours에서 지정한 기간 동안 대기합니다.Otherwise, it waits for the period you specified by GracePeriodWithDataLossHours. GracePeriodWithDataLossHours를 지정한 경우 데이터 손실에 대비합니다.If you specified GracePeriodWithDataLossHours, be prepared for data loss. 일반적으로 중단 시에 Azure에서는 가용성을 우선으로 합니다.In general, during outages, Azure favors availability. 데이터 손실을 방지하려는 경우 GracePeriodWithDataLossHours를 24시간과 같은 충분히 큰 숫자로 설정해야 합니다.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours.

중요

지역에서 복제를 사용하는 800개 이하의 DTU 및 250개 이상의 데이터베이스가 있는 탄력적 풀에는 더 길게 계획된 장애 조치(failover) 및 저하된 성능을 포함한 문제가 발생할 수 있습니다.Elastic pools with 800 or less DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. 이러한 문제는 지역에서 복제 끝점이 지리적으로 광범위하게 분리되어 있거나 여러 보조 끝점이 각 데이터베이스에 대해 사용되는 경우 쓰기 집약적 작업에 발생할 가능성이 높습니다.These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. 이러한 문제의 증상은 지역에서 복제 지연이 시간에 따라 증가하는 경우에 표시됩니다.Symptoms of these issues are indicated when the geo-replication lag increases over time. 이러한 지연은 sys.dm_geo_replication_link_status를 사용하여 모니터링할 수 있습니다.This lag can be monitored using sys.dm_geo_replication_link_status. 이러한 문제가 발생하는 경우 완화 방안에는 풀 DTU의 수를 늘리거나 동일한 풀에 지역에서 복제된 데이터베이스 수를 줄이는 방법이 있습니다.If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

주 데이터베이스 업그레이드 또는 다운그레이드Upgrading or downgrading a primary database

보조 데이터베이스와의 연결을 해제하지 않고 주 데이터베이스를 다른 성능 수준(동일한 서비스 계층 내)으로 업그레이드 또는 다운그레이드할 수 있습니다.You can upgrade or downgrade a primary database to a different performance level (within the same service tier) without disconnecting any secondary databases. 업그레이드하는 경우에는 보조 데이터베이스를 먼저 업그레이드한 다음에 주 데이터베이스를 업그레이드하는 것이 좋습니다.When upgrading, we recommend that you upgrade the secondary database first, and then upgrade the primary. 다운그레이드하는 경우에는 반대 순서로 주 데이터베이스를 먼저 다운그레이드하고 보조 데이터베이스를 다운그레이드합니다.When downgrading, reverse the order: downgrade the primary first, and then downgrade the secondary. 데이터베이스를 다른 서비스 계층으로 업그레이드하거나 다운그레이드할 때 이 권장 사항이 적용됩니다.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

참고

장애 조치 그룹 구성의 일부로 보조 데이터베이스를 만든 경우 보조 데이터베이스를 다운그레이드하지 않는 것이 좋습니다.If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. 이렇게 하면 장애 조치가 활성화된 후 데이터 계층에서 일반 워크로드를 처리할 수 있을 만큼 충분한 용량을 갖출 수 있습니다.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

중요한 데이터 손실 방지Preventing the loss of critical data

광역 네트워크의 높은 대기 시간으로 인해 연속 복사는 비동기 복제 메커니즘을 사용합니다.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. 비동기 복제를 수행하면 오류가 발생하는 경우에 일부 데이터 손실은 불가피합니다.Asynchronous replication makes some data loss unavoidable if a failure occurs. 그러나 일부 응용 프로그램은 데이터 손실이 없어야 합니다.However, some applications may require no data loss. 이러한 중요한 업데이트를 보호하기 위해 응용 프로그램 개발자는 트랜잭션을 커밋한 후 즉시 sp_wait_for_database_copy_sync 시스템 프로시저를 호출할 수 있습니다.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. sp_wait_for_database_copy_sync 호출은 마지막으로 커밋된 트랜잭션이 보조 데이터베이스로 전송될 때까지 호출 스레드를 차단합니다.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. 그러나 전송된 트랜잭션이 보조 데이터베이스에서 재생 및 커밋될 때까지 기다리지 않습니다.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync는 그 범위가 특정 연속 복사 링크로 한정됩니다.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. 주 데이터베이스에 대한 연결 권한이 있는 모든 사용자는 이 프로시저를 호출할 수 있습니다.Any user with the connection rights to the primary database can call this procedure.

참고

sp_wait_for_database_copy_sync는 장애 조치 후 데이터 손실을 방지하지만 읽기 액세스를 위한 전체 동기화를 보장하지 않습니다.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. sp_wait_for_database_copy_sync 프로시저 호출로 인한 지연은 심각할 수 있으며 호출 시 트랜잭션 로그의 크기에 따라 달라집니다.The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

장애 조치(failover) 그룹 및 활성 지역 복제를 프로그래밍 방식으로 관리Programmatically managing failover groups and active geo-replication

앞에서 설명한 대로 자동 장애 조치 그룹(미리 보기 상태)과 활성 지역 복제는 Azure PowerShell 및 REST API를 사용하여 프로그래밍 방식으로 관리할 수도 있습니다.As discussed previously, auto-failover groups (in-preview) and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. 다음 표는 사용 가능한 명령의 집합을 보여 줍니다.The following tables describe the set of commands available.

Azure Resource Manager API 및 역할 기반 보안: 활성 지역 복제는 관리를 위해 Azure SQL Database REST APIAzure PowerShell cmdlet을 비롯한 Azure Resource Manager API 집합을 포함합니다.Azure Resource Manager API and role-based security: Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. 이러한 API는 리소스 그룹을 사용해야 하며 RBAC(역할 기반 보안)를 지원합니다.These APIs require the use of resource groups and support role-based security (RBAC). 액세스 역할을 구현하는 방법에 대한 자세한 내용은 Azure 역할 기반 Access Control을 참조하세요.For more information on how to implement access roles, see Azure Role-Based Access Control.

Transact-SQL을 사용하여 SQL Database 장애 조치(failover) 관리Manage SQL database failover using Transact-SQL

명령Command 설명Description
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) 기존 데이터베이스에 대한 보조 데이터베이스를 만들고 데이터 복제를 시작하려면 ADD SECONDARY ON SERVER 인수를 사용합니다.Use ADD SECONDARY ON SERVER argument to create a secondary database for an existing database and starts data replication
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) 장애 조치를 시작하기 위해 보조 데이터베이스를 기본 데이터베이스로 전환하려면 FAILOVER 또는 FORCE_FAILOVER_ALLOW_DATA_LOSS를 사용합니다.Use FAILOVER or FORCE_FAILOVER_ALLOW_DATA_LOSS to switch a secondary database to be primary to initiate failover
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) SQL Database와 지정된 보조 데이터베이스 간의 데이터 복제를 종료하려면 REMOVE SECONDARY ON SERVER를 사용합니다.Use REMOVE SECONDARY ON SERVER to terminate a data replication between a SQL Database and the specified secondary database.
sys.geo_replication_links(Azure SQL Database)sys.geo_replication_links (Azure SQL Database) Azure SQL Database 논리 서버의 각 데이터베이스에 대한 모든 기존 복제 링크에 대한 정보를 반환합니다.Returns information about all existing replication links for each database on the Azure SQL Database logical server.
sys.dm_geo_replication_link_status(Azure SQL Database)sys.dm_geo_replication_link_status (Azure SQL Database) 지정된 SQL Database의 복제 링크에 대한 마지막 복제 시간, 마지막 복제 지연 및 기타 정보를 가져옵니다.Gets the last replication time, last replication lag, and other information about the replication link for a given SQL database.
sys.dm_operation_status(Azure SQL Database)sys.dm_operation_status (Azure SQL Database) 복제 링크의 상태를 비롯한 모든 데이터베이스 작업에 대한 상태를 표시합니다.Shows the status for all database operations including the status of the replication links.
sp_wait_for_database_copy_sync(Azure SQL Database)sp_wait_for_database_copy_sync (Azure SQL Database) 커밋된 모든 트랜잭션이 복제되고 활성 보조 데이터베이스에서 승인될 때까지 응용 프로그램이 대기하도록 합니다.causes the application to wait until all committed transactions are replicated and acknowledged by the active secondary database.

PowerShell을 사용하여 SQL Database 장애 조치(failover) 관리Manage SQL database failover using PowerShell

CmdletCmdlet 설명Description
Get-AzureRmSqlDatabaseGet-AzureRmSqlDatabase 하나 이상의 데이터베이스를 가져옵니다.Gets one or more databases.
New-AzureRmSqlDatabaseSecondaryNew-AzureRmSqlDatabaseSecondary 기존 데이터베이스에 대한 보조 데이터베이스를 만들고 데이터 복제를 시작합니다.Creates a secondary database for an existing database and starts data replication.
Set-AzureRmSqlDatabaseSecondarySet-AzureRmSqlDatabaseSecondary 장애 조치를 시작하기 위해 보조 데이터베이스로 전환합니다.Switches a secondary database to be primary to initiate failover.
Remove-AzureRmSqlDatabaseSecondaryRemove-AzureRmSqlDatabaseSecondary SQL Database와 지정된 보조 데이터베이스 간의 데이터 복제를 종료합니다.Terminates data replication between a SQL Database and the specified secondary database.
Get-AzureRmSqlDatabaseReplicationLinkGet-AzureRmSqlDatabaseReplicationLink Azure SQL Database와 리소스 그룹 또는 SQL Server 간의 지역에서 복제 링크를 가져옵니다.Gets the geo-replication links between an Azure SQL Database and a resource group or SQL Server.
New-AzureRmSqlDatabaseFailoverGroupNew-AzureRmSqlDatabaseFailoverGroup 장애 조치 그룹을 만들고 주 및 보조 서버 모두에 등록합니다This command creates a failover group and registers it on both primary and secondary servers
Remove-AzureRmSqlDatabaseFailoverGroupRemove-AzureRmSqlDatabaseFailoverGroup 서버에서 장애 조치 그룹을 제거하고 그룹에 포함된 모든 보조 데이터베이스를 삭제합니다.Removes the failover group from the server and deletes all secondary databases included the group
Get-AzureRmSqlDatabaseFailoverGroupGet-AzureRmSqlDatabaseFailoverGroup 장애 조치 그룹 구성을 검색합니다.Retrieves the failover group configuration
Set-AzureRmSqlDatabaseFailoverGroupSet-AzureRmSqlDatabaseFailoverGroup 장애 조치 그룹의 구성을 수정합니다.Modifies the configuration of the failover group
Switch-AzureRMSqlDatabaseFailoverGroupSwitch-AzureRMSqlDatabaseFailoverGroup 장애 조치 그룹의 장애 조치를 보조 서버로 트리거합니다.Triggers failover of the failover group to the secondary server

REST API를 사용하여 SQL Database 장애 조치(failover) 관리Manage SQL database failover using the REST API

APIAPI 설명Description
데이터베이스 생성 또는 업데이트(createMode=Restore)Create or Update Database (createMode=Restore) 주 보조 데이터베이스 또는 보조 데이터베이스를 만들거나, 업데이트하거나, 복원합니다.Creates, updates, or restores a primary or a secondary database.
데이터베이스 만들기 또는 업데이트 상태 가져오기Get Create or Update Database Status 만들기 작업 동안 상태를 반환합니다.Returns the status during a create operation.
보조 데이터베이스를 주 데이터베이스로 설정(계획된 장애 조치(failover))Set Secondary Database as Primary (Planned Failover) 현재 주 복제본 데이터베이스에서 장애 조치(failover)를 통해 주 복제본 데이터베이스로 사용할 데이터베이스를 설정합니다.Sets which replica database is primary by failing over from the current primary replica database.
보조 데이터베이스를 주 데이터베이스로 설정(계획되지 않은 장애 조치(failover))Set Secondary Database as Primary (Unplanned Failover) 현재 주 복제본 데이터베이스에서 장애 조치(failover)를 통해 주 복제본 데이터베이스로 사용할 데이터베이스를 설정합니다.Sets which replica database is primary by failing over from the current primary replica database. 이 작업으로 인해 데이터가 손실될 수 있습니다.This operation might result in data loss.
복제 링크 가져오기Get Replication Link 지역에서 복제 파트너 관계의 지정된 SQL 데이터베이스에 대한 특정 복제 링크를 가져옵니다.Gets a specific replication link for a given SQL database in a geo-replication partnership. sys.geo_replication_links 카탈로그 뷰에 표시되는 정보를 검색합니다.It retrieves the information visible in the sys.geo_replication_links catalog view.
복제 링크 - 데이터베이스 기준 목록Replication Links - List By Database 지역에서 복제 파트너 관계의 지정된 SQL 데이터베이스에 대한 모든 복제 링크를 가져옵니다.Gets all replication links for a given SQL database in a geo-replication partnership. sys.geo_replication_links 카탈로그 뷰에 표시되는 정보를 검색합니다.It retrieves the information visible in the sys.geo_replication_links catalog view.
복제 링크 삭제Delete Replication Link 데이터베이스 복제 링크를 삭제합니다.Deletes a database replication link. 장애 조치(failover) 중에 수행할 수 없습니다.Cannot be done during failover.
장애 조치(failover) 그룹 만들기 또는 업데이트Create or Update Failover Group 장애 조치(failover) 그룹을 만들거나 업데이트합니다.Creates or updates a failover group
장애 조치(failover) 그룹 삭제Delete Failover Group 서버에서 장애 조치 그룹을 제거합니다.Removes the failover group from the server
장애 조치(failover)(계획됨)Failover (Planned) 현재 주 서버에서 이 서버로 장애 조치(failover)합니다.Fails over from the current primary server to this server.
장애 조치(failover)로 인한 데이터 손실 허용Force Failover Allow Data Loss 현재 주 서버에서 이 서버로 장애 조치(failover)합니다.ails over from the current primary server to this server. 이 작업으로 인해 데이터가 손실될 수 있습니다.This operation might result in data loss.
장애 조치 그룹 가져오기Get Failover Group 장애 조치(failover) 그룹을 가져옵니다.Gets a failover group.
서버별 장애 조치(failover) 그룹 나열List Failover Groups By Server 서버에 있는 장애 조치(failover) 그룹을 나열합니다.Lists the failover groups in a server.
장애 조치(failover) 그룹 업데이트Update Failover Group 장애 조치(failover) 그룹을 업데이트합니다.Updates a failover group.

다음 단계Next steps