장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)Failover and Failover Modes (Always On Availability Groups)

이 항목은 다음에 적용됩니다. 예SQL Server(2016부터 시작)아니요Azure SQL 데이터베이스아니요Azure SQL 데이터 웨어하우스아니요병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

가용성 그룹의 컨텍스트 내에서는 일반적으로 가용성 복제본의 주 역할과 보조 역할을 장애 조치(Failover)라는 프로세스에서 서로 바꿀 수 있습니다.Within the context of an availability group, the primary role and secondary role of availability replicas are typically interchangeable in a process known as failover. 자동 장애 조치(데이터가 손실되지 않음), 계획된 수동 장애 조치(데이터가 손실되지 않음)와 강제 장애 조치(failover)라고 불리는 강제 수동 장애 조치(데이터가 손실될 수 있음)의 세 가지 형태가 있습니다.Three forms of failover exist: automatic failover (without data loss), planned manual failover (without data loss), and forced manual failover (with possible data loss), typically called forced failover. 자동 및 계획된 수동 장애 조치(Failover)는 모든 데이터를 보존합니다.Automatic and planned manual failover preserve all your data. 가용성 그룹은 가용성 복제본의 수준에서 장애 조치(Failover)됩니다.An availability group fails over at the availability-replica level. 즉, 가용성 그룹은 해당 보조 복제본 중 하나(현재 장애 조치(Failover) 대상)로 장애 조치(Failover)됩니다.That is, an availability group fails over to one of its secondary replicas (the current failover target).

참고

따라서 데이터 파일 손실, 데이터베이스 삭제, 트랜잭션 로그 손상 등으로 인해 주의 대상 데이터베이스가 발생할 경우 이러한 데이터베이스 수준의 문제로는 가용성 그룹의 장애 조치(Failover)가 수행되지 않습니다.Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or corruption of a transaction log, do not cause an availability group to failover.

장애 조치(Failover) 동안에는 장애 조치(Failover) 대상이 주 역할을 맡아 데이터베이스를 복구하고 이 데이터베이스를 새로운 주 데이터베이스로 하여 온라인 상태로 만듭니다.During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary databases. 이전 주 복제본은 사용 가능한 경우 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다.The former primary replica, when available, switches to the secondary role, and its databases become secondary databases. 잠재적으로 여러 오류에 대한 응답이나 관리를 위해 이러한 역할이 상호 또는 다른 장애 조치(Failover) 대상으로 전환될 수 있습니다.Potentially, these roles can switch back and forth (or to a different failover target) in response to multiple failures or for administrative purposes.

지정된 가용성 복제본에서 지원하는 장애 조치(Failover)의 형태는 장애 조치(Failover) 모드 속성으로 지정됩니다.The form(s) of failover that a given availability replica supports is specified by the failover mode property. 지정된 가용성 복제본의 경우 가능한 장애 조치(Failover) 모드는 다음과 같이 복제본의 가용성 모드 에 따라 다릅니다.For a given availability replica, the possible failover modes depends on the availability mode of the replica, as follows:

  • 동기-커밋 복제본 - 두 가지 설정(자동 또는 수동)을 지원합니다.Synchronous-commit replicas support two settings—automatic or manual. "자동" 설정은 자동 장애 조치(Failover)와 수동 장애 조치(Failover)를 모두 지원합니다.The "automatic" setting supports both automatic failover and manual failover. 데이터 손실을 방지하기 위해 자동 장애 조치(Failover) 및 계획된 장애 조치(Failover)에서는 장애 조치(Failover) 대상이 동기화 상태가 정상(장애 조치(Failover) 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화된 상태)인 동기-커밋 보조 복제본이어야 합니다.To prevent data loss, automatic failover and planned failover require that the failover target be a synchronous-commit secondary replica with a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database). 보조 복제본이 이러한 조건을 모두 충족하지 않을 때는 항상 강제 장애 조치(Failover)만 지원됩니다.Whenever a secondary replica does not meet both of these conditions, it supports only forced failover. 강제 장애 조치(Failover)는 또한 역할이 RESOLVING 상태인 복제본을 지원합니다.Note that forced failover is also supported a replicas whose role is in the RESOLVING state.

  • 비동기-커밋 복제본 은 수동 장애 조치(Failover) 모드만 지원합니다.Asynchronous-commit replicas support only the manual failover mode. 또한, 절대 동기화되지 않기 때문에 강제 장애 조치(Failover)만 지원합니다.Moreover, because they are never synchronized, they support only forced failover.

참고

장애 조치(Failover) 후 주 데이터베이스에 액세스해야 하는 클라이언트 응용 프로그램은 새로운 주 복제본에 연결되어야 합니다.After a failover, client applications that need to access the primary databases must connect to the new primary replica. 또한 새로운 보조 복제본이 읽기 전용 액세스를 허용하도록 구성되면 읽기 전용 클라이언트 응용 프로그램이 해당 복제본에 연결할 수 있습니다.Also, if the new secondary replica is configured to allow read-only access, read-only client applications can connect to it. 클라이언트가 가용성 그룹에 연결하는 방법에 대한 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server)를 참조하세요.For information about how clients connect to an availability group, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

이 항목의 섹션:Sections in This Topic:

용어 및 정의 Terms and Definitions

자동 장애 조치(Failover)Automatic failover
주 복제본이 손실되는 경우 자동으로 발생하는 장치 조치(failover)입니다.A failover that occurs automatically on the loss of the primary replica. 자동 장애 조치(Failover)는 현재 주 복제본과 하나의 보조 복제본이 모두 AUTOMATIC으로 설정된 장애 조치(Failover) 모드로 구성되고 보조 복제본이 현재 동기화된 경우에만 지원됩니다.Automatic failover is supported only when the current primary and one secondary replica are both configured with failover mode set to AUTOMATIC and the secondary replica currently synchronized. 주 복제본 또는 보조 복제본의 장애 조치(Failover) 모드가 MANUAL인 경우 장애 조치(Failover)를 수행할 수 없습니다.If the failover mode of either the primary or secondary replica is MANUAL, automatic failover cannot occur.

계획된 수동 장애 조치(Failover)(데이터가 손실되지 않음)Planned manual failover (without data loss)
계획된 수동 장애 조치(Failover) 또는 수동 장애 조치(Failover)는 일반적으로 관리 목적을 위해 데이터베이스 관리자가 시작하는 장애 조치(Failover)입니다.Planned manual failover, or manual failover, is a failover that is initiated by a database administrator, typically, for administrative purposes. 계획된 수동 장애 조치(Failover)는 주 복제본과 보조 복제본이 동기-커밋 모드에 대해 구성되고 보조 복제본이 현재 동기화된(SYNCHRONIZED 상태) 경우에만 지원됩니다.A planned manual failover is supported only if both the primary replica and secondary replica are configured for synchronous-commit mode and the secondary replica is currently synchronized (in the SYNCHRONIZED state). 대상 보조 복제본이 동기화되면 보조 데이터베이스에서 장애 조치(Failover)를 수행할 준비가 되었기 때문에 주 복제본이 충돌하더라도 수동 장애 조치(Failover)(데이터가 손실되지 않음)가 가능합니다.When the target secondary replica is synchronized, manual failover (without data loss) is possible even if the primary replica has crashed because the secondary databases are ready for failover. 데이터베이스 관리자가 수동 장애 조치(Failover)를 수동으로 시작합니다.A database administrator manually initiates a manual failover.

강제 장애 조치(failover)(데이터가 손실될 수 있음)Forced failover (with possible data loss)
보조 복제본이 주 복제본과 동기화되지 않거나 주 복제본이 실행되고 있지 않아서 보조 복제본의 장애 조치(failover)가 준비되지 않았을 때 데이터베이스 관리자가 시작할 수 있는 장애 조치(Failover)입니다.A failover that can be initiated by a database administrator when no secondary replica is SYNCHRONIZED with the primary replica or the primary replica is not running and no secondary replica is failover ready. 강제 장애 조치(Failover)는 데이터가 손실될 수 있는 위험이 있으며 재해 복구용으로만 사용하는 것이 좋습니다.Forced failover risks possible data loss and is recommended strictly for disaster recovery. 강제 장애 조치(failover)는 수동으로만 시작될 수 있기 때문에 강제 수동 장애 조치(failover)라고도 합니다.Forced failover is also known as forced manual failover because it can only be initiated manually. 이 장애 조치(Failover)는 비동기-커밋 가용성 모드에서 지원되는 유일한 장애 조치(Failover) 형태입니다.This is the only form of failover supported by in asynchronous-commit availability mode.

자동 장애 조치(Failover) 설정Automatic failover set
지정된 가용성 그룹 내에서 자동 장애 조치(Failover)를 사용하는 동기-커밋 모드(있는 경우)에 대해 구성된 가용성 복제본의 쌍(현재 주 복제본 포함)입니다.Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. 자동 장애 조치(Failover) 설정automatic failover set은(는) 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 효과가 있습니다.An 자동 장애 조치(Failover) 설정automatic failover settakes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

동기 커밋 장애 조치(Failover) 설정Synchronous-commit failover set
지정된 가용성 그룹 내에서 동기-커밋 모드(있는 경우)로 구성된 2개 또는 3개의 가용성 복제본(현재 주 복제본 포함) 집합입니다.Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. 동기 커밋 장애 조치(Failover) 설정synchronous-commit failover set은(는) 보조 복제본이 수동 장애 조치(Failover) 모드로 구성되고 하나 이상의 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 효과가 있습니다.A 동기 커밋 장애 조치(Failover) 설정synchronous-commit failover settakes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

전체 장애 조치(Failover) 설정Entire failover set
지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(Failover) 모드와 상관없이 작업 상태가 현재 ONLINE인 모든 가용성 복제본 집합입니다.Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. 전체 장애 조치(Failover) 설정entire failover set은(는) 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 관련이 있습니다.The 전체 장애 조치(Failover) 설정entire failover setbecomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

장애 조치(Failover) 개요 Overview of Failover

다음 표에서는 다양한 가용성 모드 및 장애 조치(Failover) 모드에서 지원되는 장애 조치(Failover) 형태를 요약합니다.The following table summarizes which forms of failover are supported under different availability and failover modes. 각 쌍에 대해 유효한 가용성 모드 및 장애 조치(Failover) 모드는 주 복제본 모드와 하나 이상의 보조 복제본 모드의교차로 결정됩니다.For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas.

비동기-커밋 모드Asynchronous-commit mode 수동 장애 조치(Failover) 모드를 사용하는 동기-커밋 모드Synchronous-commit mode with manual-failover mode 자동 장애 조치(Failover) 모드를 사용하는 동기-커밋 모드Synchronous-commit mode with automatic-failover mode
자동 장애 조치(Failover)Automatic failover 아니요No 아니요No Yes
계획된 수동 장애 조치(Failover)Planned manual failover 아니요No Yes Yes
강제 장애 조치(failover)Forced failover Yes Yes \Yes\**

\동기화된 보조 복제본에 강제 장애 조치(Failover) 명령을 실행하면 보조 복제본은 수동 장애 조치(Failover)의 경우와 동일하게 작동합니다.\**If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a manual failover.

장애 조치(Failover) 중에 데이터베이스를 사용할 수 없는 시간은 장애 조치(Failover)의 유형과 원인에 따라 달라집니다.The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.

중요

포함된 데이터베이스를 제외하고 장애 조치(Failover) 후 클라이언트 연결을 지원하려면 이전 주 데이터베이스에 정의된 로그인 및 작업을 새로운 주 데이터베이스에서 수동으로 다시 만들어야 합니다.To support client connections after failover, except for contained databases, logins and jobs defined on any of the former primary databases must be manually recreated on the new primary database. 자세한 내용은 가용성 그룹의 데이터베이스에 대한 로그인 및 작업 관리(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For more information, see Management of Logins and Jobs for the Databases of an Availability Group (SQL Server).

장애 조치(Failover) 집합Failover Sets

지정된 가용성 그룹에 대해 가능한 장애 조치(Failover)의 형태는 장애 조치(Failover) 설정의 관점에서 이해할 수 있습니다.The forms of failover that are possible for a given availability group can be understood in terms of failover sets. 장애 조치(Failover) 설정은 다음과 같이 지정된 형태의 장애 조치(Failover)를 지원하는 주 복제본과 보조 복제본으로 구성됩니다.A failover set consists of the primary replica and secondary replicas that support a given form of failover, as follows:

  • 자동 장애 조치(Failover) 설정Automatic failover set (옵션): 지정된 가용성 그룹 내에서 자동 장애 조치(Failover)를 사용하는 동기-커밋 모드(있는 경우)로 구성된 가용성 복제본의 쌍(현재 주 복제본 포함)입니다. 자동 장애 조치(Failover) 설정Automatic failover set (optional): Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. 자동 장애 조치(Failover) 설정은 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 효과가 있습니다.An automatic failover set takes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

  • 동기 커밋 장애 조치(Failover) 설정Synchronous-commit failover set (옵션): 지정된 가용성 그룹 내에서 동기-커밋 모드(있는 경우)로 구성된 2개 또는 3개의 가용성 복제본(현재 주 복제본 포함) 집합입니다. 동기 커밋 장애 조치(Failover) 설정Synchronous-commit failover set (optional): Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. 동기 커밋 장애 조치(Failover) 설정은 보조 복제본이 수동 장애 조치(Failover) 모드에 대해 구성되고 하나 이상의 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 효과가 있습니다.A synchronous-commit failover set takes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

  • 전체 장애 조치(Failover) 설정Entire failover set : 지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(Failover) 모드와 상관없이 작업 상태가 현재 ONLINE인 모든 가용성 복제본 집합입니다. 전체 장애 조치(Failover) 설정Entire failover set : Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. 전체 장애 조치(Failover) 설정은 보조 복제본이 주 복제본과 현재 SYNCHRONIZED된 경우에만 관련이 있습니다.The entire failover set becomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

    자동 장애 조치(Failover)를 사용하는 동기 커밋으로 가용성 복제본을 구성하면 가용성 복제본은 자동 장애 조치(Failover) 설정automatic failover set의 일부가 됩니다.When you configure an availability replica as synchronous commit with automatic failover, the availability replica becomes part of the 자동 장애 조치(Failover) 설정automatic failover set. 하지만 이 집합이 적용되는지 여부는 현재 주 복제본에 따라 다릅니다.However whether the set takes effect depends the current primary. 지정된 시간에 실제로 가능한 장애 조치(Failover) 형태는 현재 적용되는 장애 조치(Failover) 집합에 따라 다릅니다.The forms of failover that are actually possible at a given time depends on what failover sets are currently in effect.

    예를 들어, 다음과 같은 네 개의 가용성 복제본이 있는 가용성 그룹을 고려합니다.For example, consider an availability group that has four availability replicas, as follows:

복제본Replica 가용성 모드 및 장애 조치(Failover) 모드 설정Availability Mode and Failover Mode Settings
변수를 잠그기 위한A 자동 장애 조치(Failover)를 사용하는 동기 커밋Synchronous commit with automatic failover
BB 자동 장애 조치(Failover)를 사용하는 동기 커밋Synchronous commit with automatic failover
CC 계획된 수동 장애 조치(failover)만 사용하는 동기-커밋Synchronous commit with planned manual failover only
DD 강제 장애 조치(Failover)만 사용하는 비동기 커밋Asynchronous commit (with only forced failover)

각 보조 복제본에 대한 장애 조치(Failover) 동작은 어떤 가용성 복제본이 현재 주 복제본인지에 따라 결정됩니다.The failover behavior for each secondary replica depends on which availability replica is currently the primary replica. 기본적으로 지정된 보조 복제본에 대해 장애 조치(Failover) 동작은 현재 주 복제본에서 최악의 경우입니다.Basically, for a given secondary replica, the failover behavior is the worst case given the current primary replica. 다음 그림에서는 현재 주 복제본에 따라 보조 복제본의 장애 조치(Failover) 동작이 어떻게 달라지는지와 보조 복제본의 장애 조치(Failover) 동작이 강제 장애 조치(Failover)만 사용하는 비동기-커밋 모드용으로 구성되었는지 자동 장애 조치(Failover)를 사용하거나 사용하지 않는 동기-커밋 모드용으로 구성되었는지를 보여 줍니다.The following figure illustrates how the failover behavior of secondary replicas varies depending on the current primary replica, and whether it is configured for asynchronous-commit mode (with only forced failover) or synchronous-commit mode (with or without automatic failover).

주 복제본 구성이 장애 조치에 미치는 영향How primary replica configuration affects failover

Automatic Failover Automatic Failover

자동 장애 조치(Failover)를 수행하면 주 복제본이 사용할 수 없게 된 후 정규화된 보조 복제본이 주 역할로 자동으로 전환됩니다.An automatic failover causes a qualified secondary replica to automatically transition to the primary role after the primary replica becomes unavailable. 자동 장애 조치(Failover)는 주 복제본을 호스팅하는 WSFC 노드가 보조 복제본을 호스팅하는 노드에 대해 로컬인 경우에 가장 적합합니다.Automatic failover is best suited when the WSFC node that hosts the primary replica is local to the node that hosts the secondary replica. 이는 데이터 동기화가 컴퓨터 간의 메시지 대기 시간이 짧은 경우 가장 잘 작동하고 클라이언트 연결이 로컬로 유지될 수 있기 때문입니다.This is because data synchronization works best with low message latency between computers and because client connections can remain local.

섹션 내용In This Section:

자동 장애 조치(Failover)에 필요한 상태 Conditions Required for an Automatic Failover

자동 장애 조치(Failover)는 다음 상태에서만 수행됩니다.Automatic failover occurs only under the following conditions:

  • 자동 장애 조치(Failover) 설정이 있습니다.An automatic failover set exists. 이 설정은 모두 동기-커밋 모드로 구성되고 자동 장애 조치(Failover)로 설정된 주 복제본과 보조 복제본( 자동 장애 조치(Failover) 대상)으로 구성됩니다.This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover. 주 복제본이 수동 장애 조치(Failover)로 설정되면 보조 복제본이 자동 장애 조치(Failover)로 설정된 경우에도 자동 장애 조치(Failover)가 발생할 수 없습니다.If the primary replica is set to MANUAL failover, automatic failover cannot occur, even if a secondary replica is set to AUTOMATIC failover.

    자세한 내용은 가용성 모드(Always On 가용성 그룹)라는 프로세스에서 서로 바꿀 수 있습니다.For more information, see Availability Modes (Always On Availability Groups).

  • 자동 장애 조치(Failover) 대상의 동기화 상태는 정상 상태, 즉 장애 조치(Failover) 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화되는 상태입니다.The automatic failover target has a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database).

    Always On 가용성 그룹은 자동 장애 조치(Failover) 설정에서 두 복제본의 상태를 모니터링합니다.Always On Availability Groups monitors the health of both replicas in an automatic failover set. 복제본 중 하나가 실패하면 가용성 그룹의 상태는 CRITICAL로 설정됩니다.If either replica fails, the availability group's health state is set to CRITICAL. 보조 복제본이 실패하면 자동 장애 조치(Failover) 대상을 사용할 수 없기 때문에 자동 장애 조치(Failover)가 발생할 수 없습니다.If the secondary replica fails, automatic failover is not possible because the automatic failover target is unavailable. 주 복제본이 실패하면 가용성 그룹이 보조 복제본으로 장애 조치(Failover)됩니다.If the primary replica fails, the availability group will fail over to the secondary replica. 이전 주 복제본이 온라인 상태가 될 때까지는 자동 장애 조치(Failover) 대상이 존재하지 않습니다.Until the former primary replica comes online, no automatic failover target exists. 어떤 경우든, 드물기는 하지만 순차적 실패가 일어날 때 가용성을 보장하기 위해 다른 보조 복제본을 자동 장애 조치(Failover) 대상으로 구성하는 것이 좋습니다.In either case, to ensure availability in the unlikely case of a sequential failure, we recommend that you configure a different secondary replica as the automatic failover target.

    자세한 내용은 Always On 정책을 사용하여 가용성 그룹의 상태 보기(SQL Server)가용성 복제본의 장애 조치(failover) 모드 변경(SQL Server)을 참조하세요.For more information, see Use Always On Policies to View the Health of an Availability Group (SQL Server) and Change the Failover Mode of an Availability Replica (SQL Server).

  • WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터는 쿼럼이 있습니다.The Windows Server Failover Clustering (WSFC) cluster has quorum. 자세한 내용은 WSFC 쿼럼 모드 및 투표 구성(SQL Server)을 참조하세요.For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

  • 주 복제본이 사용할 수 없게 되었으며 유연한 장애 조치(Failover) 정책에 정의된 장애 조치(Failover) 상태 수준을 충족합니다.The primary replica has become unavailable, and the failover-condition levels defined by your the flexible failover policy have been met. 장애 조치 상태 수준에 대한 자세한 내용은 가용성 그룹 자동 장애 조치에 대한 유연한 장애 조치(Failover) 정책(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For information about failover-condition levels, see Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

자동 장애 조치 작동 방법 How Automatic Failover Works

자동 장애 조치(Failover)는 다음과 같은 일련의 동작을 시작합니다.An automatic failover initiates the following sequence of actions:

  1. 현재 주 복제본을 호스팅하는 서버 인스턴스가 여전히 실행 중인 경우 주 복제본의 상태를 DISCONNECTED로 변경하고 모든 클라이언트의 연결을 끊습니다.If the server instance that is hosting the current primary replica is still running, it changes the state of the primary databases to DISCONNECTED and disconnects all clients.

  2. 로그 레코드가 대상 보조 복제본의 Recovery Queue에서 대기 중인 경우 보조 복제본이 나머지 로그 레코드에 적용되어 보조 데이터베이스의 롤포워드를 마칩니다.If any log records are waiting in recovery queues on the target secondary replica, the secondary replica applies the remaining log records to finish rolling forward the secondary databases.

    참고

    지정된 데이터베이스에 로그를 적용하는 데 필요한 시간은 시스템 속도, 최근 작업 로드 및 Recovery Queue에 있는 로그 양에 따라 달라집니다.The amount of time required to apply the log to a given database depends on the speed of the system, the recent work load, and the amount of log in the recovery queue.

  3. 이전 보조 복제본이 주 역할로 전환됩니다.The former secondary replica transitions to the primary role. 해당 데이터베이스는 주 데이터베이스가 됩니다.Its databases become the primary databases. 새로운 주 복제본은 커밋되지 않은 트랜잭션(복구의 실행 취소 단계)을 최대한 빠르게 롤백합니다.The new primary replica rolls back any uncommitted transactions (the undo phase of recovery) as quickly as possible. 잠금은 클라이언트가 데이터베이스를 사용하는 동안 백그라운드에서 롤백을 수행할 수 있도록 이러한 커밋되지 않은 트랜잭션을 격리합니다.Locks isolate these uncommitted transactions, allowing roll back to occur in the background while clients use the database. 이 프로세스에서는 커밋된 트랜잭션이 롤백되지 않습니다.This process does not roll back any committed transactions.

    지정된 보조 데이터베이스가 연결될 때까지 NOT_SYNCHRONIZED로 간략하게 표시됩니다.Until a given secondary database is connected, it is briefly marked as NOT_SYNCHRONIZED. 롤백 복구가 시작되기 전에 보조 데이터베이스는 새로운 주 데이터베이스에 연결하여 SYNCHRONIZED 상태로 빨리 전환될 수 있습니다.Before the rollback recovery starts, secondary databases can connect to the new primary databases and quickly transition to the SYNCHRONIZED state. 일반적으로 최상의 경우는 장애 조치(Failover) 후에 보조 역할에 유지되는 세 번째 동기 커밋 복제본입니다.The best case is usually for a third synchronous-commit replica that remains in the secondary role after the failover.

  4. 나중에 이전 주 복제본을 호스팅하는 서버 인스턴스가 다시 시작되면 이제 다른 가용성 복제본이 주 역할을 소유하고 있음을 인식합니다.Later, when the server instance that is hosting the former primary replica restarts, it recognizes that another availability replica now owns the primary role. 이전 주 복제본은 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다.The former primary replica transitions to the secondary role, and its databases become secondary databases. 새로운 보조 복제본은 현재 주 복제본에 연결하고 최대한 빠르게 해당 데이터베이스를 현재 주 데이터베이스와 동기화합니다.The new secondary replica connects to the current primary replica and catches its database up to the current primary databases as quickly as possible. 새로운 보조 복제본이 해당 데이터베이스를 다시 동기화한 후 즉시 장애 조치(Failover)를 반대 방향으로 다시 수행할 수 있습니다.As soon as the new secondary replica has resynchronized its databases, failover is again possible, in the reverse direction.

자동 장애 조치(Failover)를 구성하려면 To Configure Automatic Failover

언제든지 자동 장애 조치(Failover)를 지원하도록 가용성 복제본을 구성할 수 있습니다.An availability replica can be configured to support automatic failover at any point.

To configure automatic failoverTo configure automatic failover

  1. 보조 복제본이 동기-커밋 가용성 모드를 사용하도록 구성되어 있는지 확인합니다.Ensure that the secondary replica is configured to use the synchronous-commit availability mode. 자세한 내용은 가용성 복제본의 가용성 모드 변경(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For more information, see Change the Availability Mode of an Availability Replica (SQL Server).

  2. 장애 조치(Failover) 모드를 자동으로 설정합니다.Set the failover mode to automatic. 자세한 내용은 가용성 복제본의 장애 조치(failover) 모드 변경(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For more information, see Change the Failover Mode of an Availability Replica (SQL Server).

  3. 필요에 따라 가용성 그룹의 유연한 장애 조치(Failover) 정책을 변경하여 자동 장애 조치(Failover)를 발생시킬 수 있는 오류의 유형을 지정할 수 있습니다.Optionally, change the flexible failover policy of the availability group to specify the sorts of failures that can cause an automatic failover to occur. 자세한 내용은 유연한 장애 조치(failover) 정책을 구성하여 자동 장애 조치(failover)의 상태 제어(Always On 가용성 그룹)장애 조치(failover) 클러스터 인스턴스용 장애 조치(failover) 정책라는 프로세스에서 서로 바꿀 수 있습니다.For more information, see Configure the Flexible Failover Policy to Control Conditions for Automatic Failover (Always On Availability Groups) and Failover Policy for Failover Cluster Instances.

계획된 수동 장애 조치(Failover)(데이터가 손실되지 않음) Planned Manual Failover (Without Data Loss)

수동 장애 조치(Failover)를 수행하면 대상 보조 복제본을 호스팅하는 서버 인스턴스에서 데이터베이스 관리자가 수동 장애 조치(Failover) 명령을 실행한 후에 동기화된 보조 복제본이 주 역할로 전환됩니다.A manual failover causes a synchronized secondary replica to transition to the primary role after a database administrator issues a manual-failover command on the server instance that hosts the target secondary replica. 수동 장애 조치(Failover)를 지원하려면 보조 복제본과 현재 주 복제본을 모두 동기-커밋 모드(있는 경우)로 구성해야 합니다.To support manual failover, the secondary replica and the current primary replica must both be configured for synchronous-commit mode, if any. 가용성 복제본의 모든 보조 데이터베이스를 가용성 그룹에 조인하고 해당 주 데이터베이스와 동기화해야 합니다. 즉, 보조 복제본을 동기화해야 합니다.Every secondary database on the availability replica must be joined to the availability group and synchronized with its corresponding primary database (that is, the secondary replica must be synchronized). 그러면 이전 주 데이터베이스에서 커밋된 모든 트랜잭션이 새로운 주 데이터베이스에서도 커밋됩니다.This guarantees that every transaction that was committed on a former primary database has also been committed on the new primary database. 따라서 새로운 주 데이터베이스는 기존의 주 데이터베이스와 동일합니다.Therefore, the new primary databases are identical to the old primary databases.

다음 그림에서는 계획된 장애 조치(Failover) 단계를 보여 줍니다.The following figure illustrates the stages of a planned failover:

  1. 장애 조치(Failover) 전에 Node01의 서버 인스턴스가 주 복제본을 호스팅합니다.Before the failover, the primary replica is hosted by the server instance on Node01.

  2. 데이터베이스 관리자가 계획된 장애 조치(Failover)를 시작합니다.A database administrator initiates a planned failover. 장애 조치(Failover) 대상은 Node02의 서버 인스턴스가 호스팅하는 가용성 복제본입니다.The failover target is the availability replica hosted by the server instance on Node02.

  3. Node02의 장애 조치(Failover) 대상은 새로운 주 복제본이 됩니다.The failover target (on Node02) becomes the new primary replica. 계획된 장애 조치(Failover)이기 때문에 이전의 주 복제본은 장애 조치(Failover) 중에 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스로서 즉시 온라인 상태가 됩니다.Because this is a planned failover, the former primary replica switches to the secondary role during the failover and brings its databases online as secondary databases immediately.

    계획된 수동 장애 조치에 대한 설명Illustation of a planned manual failover

    섹션 내용In This Section:

수동 장애 조치에 필요한 조건 Conditions Required for a Manual Failover

수동 장애 조치(Failover)를 지원하려면 현재 주 복제본을 동기-커밋 모드로 설정해야 하며 보조 복제본은 다음과 같아야 합니다.To support a manual failover, the current primary replica must be set to synchronous-commit mode and a secondary replica must be:

  • 동기-커밋 모드에 대해 구성되어 있어야 합니다.Configured for synchronous-commit mode.

  • 주 복제본과 현재 동기화되어 있어야 합니다.Currently synchronized with the primary replica.

    가용성 그룹을 수동으로 장애 조치(Failover)하려면 새로운 주 복제본이 될 보조 복제본에 연결해야 합니다.To manually fail over an availability group, you must be connected to the secondary replica that is to become the new primary replica.

계획된 수동 장애 조치(Failover) 작동 방법 How a Planned Manual Failover Works

대상 보조 복제본에서 시작해야 하는 계획된 수동 장애 조치(Failover)는 다음과 같은 일련의 동작을 시작합니다.A planned manual failover, which must be initiated on the target secondary replica, initiates the following sequence of actions:

  1. 원래 주 데이터베이스에서 새로운 사용자 트랜잭션이 수행되는지 확인하기 위해 WSFC 클러스터는 오프라인으로 전환하는 요청을 주 복제본에 보냅니다.To ensure that no new user transactions occur on the original primary databases, the WSFC cluster sends a request to the primary replica to go offline.

  2. 보조 데이터베이스의 Recovery Queue에 대기 중인 로그가 있으면 보조 복제본은 해당 보조 데이터베이스의 롤포워드를 마칩니다.If any log is waiting in the recovery queue of any secondary database, the secondary replica finishes rolling forward that secondary database. 소요 시간은 시스템 속도, 최근 작업 및 Recovery Queue에 있는 로그 양에 따라 달라집니다.The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the recovery queue. Recovery Queue의 현재 크기를 확인하려면 Recovery Queue 성능 카운터를 사용합니다.To learn the current size of the recovery queue, use the Recovery Queue performance counter. 자세한 내용은 SQL Server, 데이터베이스 복제본을 참조하세요.For more information, see SQL Server, Database Replica.

    참고

    Recovery Queue의 크기를 제한하여 장애 조치(Failover) 시간을 조정할 수 있습니다.The failover time can be regulated by limiting the size of the recovery queue. 그러나 이 경우 보조 복제본에서 동기화 상태를 계속 유지해야 하므로 주 복제본의 속도가 느려질 수 있습니다.However, this can cause the primary replica to slow down to allow the secondary replica to keep up.

  3. 보조 복제본은 새로운 주 복제본이 되고 이전 주 복제본은 새로운 보조 복제본이 됩니다.The secondary replica becomes the new primary replica, and the former primary replica becomes the new secondary replica.

  4. 새로운 주 복제본은 커밋되지 않은 모든 트랜잭션을 롤백하고 해당 데이터베이스를 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다. 모든 보조 데이터베이스는 새로운 주 데이터베이스에 연결하여 다시 동기화할 때까지 잠시 동안 NOT SYNCHRONIZED로 표시됩니다.The new primary replica rolls back any uncommitted transactions and brings its databases online as the primary databases.All secondary databases are briefly marked as NOT SYNCHRONIZED until they connect and resynchronize to the new primary databases. 이 프로세스에서는 커밋된 트랜잭션이 롤백되지 않습니다.This process does not roll back any committed transactions.

  5. 이전 주 복제본이 다시 온라인 상태가 되면 이 데이터베이스가 보조 역할을 맡고 이전 주 데이터베이스는 보조 데이터베이스가 됩니다.When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. 새로운 보조 복제본은 새로운 보조 데이터베이스를 해당 주 데이터베이스와 빠르게 다시 동기화합니다.The new secondary replica quickly resynchronizes the new secondary databases with the corresponding primary databases.

    참고

    새로운 보조 복제본이 해당 데이터베이스를 다시 동기화한 후 즉시 장애 조치(Failover)를 반대 방향으로 다시 수행할 수 있습니다.As soon as the new secondary replica has resynchronized the databases, failover is again possible, but in the reverse direction.

    장애 조치(Failover) 후 클라이언트는 현재 주 데이터베이스에 다시 연결해야 합니다.After failover, clients must reconnect to the current primary database. 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server)개념을 소개합니다.For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

업그레이드 중에 가용성 유지 Maintaining Availability During Upgrades

하드웨어나 소프트웨어를 업그레이드할 때 가용성 그룹의 데이터베이스 관리자는 수동 장애 조치(Failover)를 사용하여 데이터베이스 가용성을 유지 관리할 수 있습니다.The database administrator for your availability groups can use manual failovers to maintain database availability when you upgrade hardware or software. 소프트웨어 업그레이드에 가용성 그룹을 사용하려면 대상 보조 복제본을 호스팅하는 서버 인스턴스 및/또는 컴퓨터 노드는 업그레이드를 이미 수신한 상태여야 합니다.To use an availability group for software upgrades, the server instance and/or computer node that hosts the target secondary replica must have already received the upgrades. 자세한 내용은 Always On 가용성 그룹 복제본 인스턴스 업그레이드를 참조하세요.For more information, see Upgrading Always On Availability Group Replica Instances.

강제 장애 조치(failover)(데이터가 손실될 수 있음) Forced Failover (with Possible Data Loss)

가용성 그룹의 강제 장애 조치(Failover)(데이터가 손실될 수 있음)는 보조 복제본을 웜 대기 서버로 사용할 수 있는 재해 복구 방법입니다. 강제 장애 조치(Failover)를 수행하면 데이터가 손실될 위험이 있으므로 반드시 필요한 경우에만 주의해서 사용해야 합니다.Forcing failover of an availability group (with possible data loss) is a disaster recovery method that allows you to use a secondary replica as a warm standby server.Because forcing failover risks possible data loss, it should be used cautiously and sparingly. 데이터 손실을 감수하더라도 즉시 가용성 데이터베이스 서비스를 복원해야 하는 경우에만 강제 장애 조치(Failover)를 수행하는 것이 좋습니다.We recommend forcing failover only if you must restore service to your availability databases immediately and are willing to risk losing data. 강제 장애 조치(failover)를 위한 사전 요구 사항 및 권장 사항에 대한 자세한 내용과 강제 장애 조치(failover)를 사용하여 치명적인 오류에서 복구하는 예제 시나리오는 가용성 그룹의 강제 수동 장애 조치(Failover) 수행(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For more information about the prerequisites and recommendations for forcing failover and for an example scenario that uses a forced failover to recover from a catastrophic failure, see Perform a Forced Manual Failover of an Availability Group (SQL Server).

경고

강제 장애 조치(Failover)를 수행하려면 WSFC 클러스터에 쿼럼이 있어야 합니다.Forcing failover requires that the WSFC cluster have quorum. 쿼럼을 구성하고 쿼럼을 강제 실행하는 방법은 SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)라는 프로세스에서 서로 바꿀 수 있습니다.For information about configuring quorum and forcing quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.

섹션 내용In This Section:

강제 장애 조치(Failover) 작동 방법 How Forced Failover Works

강제 장애 조치는 주 역할을 역할이 SECONDARY 또는 RESOLVING 상태인 대상 복제본으로 전환하기 시작합니다.Forcing failover initiates a transition of the primary role to a target replica whose role is in the SECONDARY or RESOLVING state. 장애 조치 대상은 새로운 주 복제본이 되고 클라이언트에 데이터베이스 복사본을 즉시 서비스합니다.The failover target becomes the new primary replica and immediately serves its copies of the databases to clients. 이전 주 복제본이 사용 가능하게 되면 보조 역할로 전환되고 해당 데이터베이스는 데이터베이스가 됩니다.When the former primary replica becomes available, it will transition to the secondary role and its databases will become secondary databases.

모든 보조 데이터베이스(사용할 수 있는 경우 이전 주 데이터베이스 포함)는 일시 중지됩니다.All secondary databases (including the former primary databases, when they become available) are SUSPENDED. 일시 중지된 보조 데이터베이스의 이전 데이터 동기화 상태에 따라 해당 주 데이터베이스에 대한 누락된 커밋된 데이터를 복원하는 데 적합할 수 있습니다.Depending on the previous data synchronization state of a suspended secondary database, it might be suitable for salvaging missing committed data for that primary database. 읽기 전용 액세스용으로 구성된 보조 복제본에서는 보조 데이터베이스를 쿼리하여 누락된 데이터를 수동으로 검색할 수 있습니다.On a secondary replica that is configured for read-only access, you can query the secondary databases to manually discover missing data. 그런 다음 새로운 주 데이터베이스에 대해 Transact-SQLTransact-SQL 문을 실행하여 필요에 따라 변경할 수 있습니다.Then you can issue Transact-SQLTransact-SQL statements on the new primary databases to make any necessary changes.

강제 장애 조치(Failover)의 위험 Risks of Forcing Failover

강제 장애 조치(Failover)를 수행하면 데이터가 손실될 수 있다는 점을 이해해야 합니다.It is essential to understand that forcing failover can cause data loss. 대상 복제본이 주 복제본과 통신할 수 없으며 따라서 데이터베이스의 동기화를 보장할 수 없기 때문에 데이터가 손실될 수 있습니다.Data loss is possible because the target replica cannot communicate with the primary replica and, therefore, cannot guarantee that the databases are synchronized. 강제 장애 조치(Failover)를 수행하면 새 복구 분기가 시작됩니다.Forcing failover starts a new recovery fork. 원래 주 데이터베이스와 보조 데이터베이스는 서로 다른 복구 분기에 있기 때문에 각 데이터베이스에는 다른 데이터베이스에 없는 데이터가 포함됩니다. 원래 각 주 데이터베이스에는 Send Queue에서 이전 보조 데이터베이스로 아직 전송되지 않은 모든 변경 사항(보내지 않은 로그)이 포함되며, 이전 보조 데이터베이스에는 강제 장애 조치(Failover)를 수행한 후 발생한 모든 변경 사항이 포함됩니다.Because the original primary databases and secondary databases are on different recovery forks, each of them now contains data that the other database does not contain: each original primary database contains whatever changes were not yet sent from its send queue to the former secondary database (the unsent log); the former secondary databases contain whatever changes occur after failover was forced.

주 복제본이 실패하여 강제 장애 조치(Failover)가 수행된 경우 발생 가능한 데이터 손실은 실패 전에 트랜잭션 로그를 보조 복제본으로 보냈는지 여부에 따라 달라집니다.If failover is forced because the primary replica has failed, potential data loss is depends on whether any transaction logs had not been sent to the secondary replica before the failure. 비동기-커밋 모드에서는 보내지 않은 누적 로그가 항상 있을 수 있습니다.Under the asynchronous-commit mode, accumulated unsent log is always a possibility. 동기-커밋 모드에서는 보조 데이터베이스가 동기화될 때까지만 보내지 않은 누적 로그가 있을 수 있습니다.Under synchronous-commit mode, this is possible only until the secondary databases becomes synchronized.

다음 표에서는 강제 장애 조치(Failover)할 복제본의 특정 데이터베이스에 대한 데이터 손실 가능성을 요약하여 보여 줍니다.The following table summarizes the possibility of data loss for a particular database on the replica to which you force failover.

보조 복제본의 가용성 모드Availability mode of Secondary Replica 데이터베이스가 동기화되는지 여부Is database synchronized? 데이터가 손실될 가능성이 있는지 여부Is data loss possible?
Synchronous-commitSynchronous-commit Yes 아니요No
Synchronous-commitSynchronous-commit 아니요No Yes
Asynchronous-commitAsynchronous-commit 아니요No Yes

보조 데이터베이스는 두 개의 복구 분기만 추적하므로 강제 장애 조치(Failover)를 여러 번 수행할 경우 이전 강제 장애 조치(Failover)와 데이터 동기화를 시작한 보조 데이터베이스는 재개하지 못할 수도 있습니다.Secondary databases track only two recovery forks, so if you perform multiple forced failovers, any secondary database that did start data synchronization with the previous force failover might not be able to resume. 이 경우 재개할 수 없는 보조 데이터베이스를 올바른 시점으로 복원된 가용성 그룹에서 제거한 후 이 가용성 그룹에 다시 조인해야 합니다.If this occurs, any secondary databases that cannot be resumed will need to be removed from the availability group, restored to the correct point in time, and rejoined to the availability group. 여러 복구 분기 지점에 대해 복원을 수행할 수 없으므로 둘 이상의 강제 장애 조치(Failover) 수행한 후 로그 백업을 수행해야 합니다.A restore will not work across multiple recovery forks, therefore, be sure to perform a log backup after performing more than one forced failover.

강제 쿼럼 후에 강제 장애 조치(failover)가 필요한 이유 Why Forced Failover is Required After Forcing Quorum

WSFC 클러스터에서 쿼럼을 수행한 후에는(강제 쿼럼) 각 가용성 그룹에 대해 강제 장애 조치(failover)(데이터 손실 가능)를 수행해야 합니다.After quorum is forced on the WSFC cluster (forced quorum) you need to perform a forced failover (with possible data loss) on each availability group. 강제 장애 조치(failover)가 필요한 이유는 WSFC 클러스터 값의 실제 상태가 손실되었을 수 있기 때문입니다.The forced failover is required because the real state of the WSFC cluster values might have been lost. 강제 쿼럼 후 정상적인 장애 방지가 필요한 이유는 동기화되지 않은 보조 복제본이 다시 구성된 WSFC 클러스터에서 동기화된 것으로 나타날 수 있기 때문입니다.Preventing normal failovers after a forced quorum is required because of the possibility than an unsynchronized secondary replica would appear to be synchronized on the reconfigured WSFC cluster.

세 개의 노드에서 가용성 그룹을 호스트하는 WSFC 클러스터를 예로 들어 보겠습니다. 노드 A는 주 복제본을 호스팅하며 노드 B와 노드 C는 보조 복제본을 호스팅합니다.For example, consider a WSFC cluster that hosts an availability group on three nodes: Node A hosts the primary replica and Node B and Node C each hosts a secondary replica. 로컬 보조 복제본이 동기화하는 동안 노드 C는 WSFC 클러스터에서 연결이 끊어집니다.Node C gets disconnected from the WSFC cluster while the local secondary replica is SYNCHRONIZED. 그러나 노드 A와 노드 B는 정상 상태의 쿼럼을 유지하고 가용성 그룹을 온라인 상태로 유지합니다.But Node A and Node B retain a healthy quorum and the availability group remains online. 노드 A에서 주 복제본은 계속해서 업데이트를 허용하고 노드 B에서 보조 복제본은 계속해서 주 복제본과 동기화합니다.On Node A, the primary replica continues to accept updates, and on Node B, the secondary replica continues to synchronize with the primary replica. 노드 C에서 보조 복제본은 비동기화되고 주 복제본 뒤에서 점점 뒤쳐집니다.The secondary replica on Node C becomes unsynchronized and falls increasingly behind the primary replica. 그러나, 노드 C는 연결이 끊어졌기 때문에 복제본의 동기화 상태가 잘못 유지됩니다.However, because Node C is disconnected, the replica remains, incorrectly, in the SYNCHRONIZED state.

쿼럼이 손실되고 노드 A에서 강제 적용되면 WSFC 클러스터에서 가용성 그룹의 동기화 상태는 보조 복제본이 노드 C에 UNSYNCHRONIZED로 표시되는 올바른 상태여야 합니다.If quorum is lost and is then forced on Node A, the synchronization state of the availability group on the WSFC cluster should be correct—with the secondary replica on Node C shown as UNSYNCHRONIZED. 그러나 노드 C에서 쿼럼이 강제 적용되면 가용성 그룹의 동기화는 잘못됩니다.However, if quorum is forced on Node C, the synchronization of the availability group will be incorrect. 노드 C 연결이 끊어지면 클러스터의 동기화 상태는 되돌아가서 노드 C의 보조 복제본이 SYNCHRONIZED로 잘못 표시됩니다.The synchronization state on the cluster will have reverted back to when Node C was disconnected—with the secondary replica on Node C incorrectly shown as SYNCHRONIZED. 계획된 수동 장애 조치(failover)는 데이터의 안전성을 보장하므로 쿼럼이 강제 적용된 후 가용성 그룹이 다시 온라인 상태가 되도록 허용되지 않습니다.Since planned manual failovers guarantee the safety of the data, they are disallowed for bring an availability group back online after quorum is forced.

잠재적인 데이터 손실 추적 Tracking Potential Data Loss

WSFC 클러스터의 쿼럼이 정상 상태이면 데이터베이스에 대한 현재의 잠재적 데이터 손실을 예측할 수 있습니다.When the WSFC cluster has a healthy quorum, you can estimate the current potential for data loss on databases. 지정된 보조 복제본의 경우 현재의 잠재적 데이터 손실은 로컬 보조 데이터베이스의 내용이 해당 주 데이터베이스의 내용보다 얼마나 오래되었는지에 따라 다릅니다.For a given secondary replica, the current potential for data loss depends on how far the local secondary databases are lagging behind the corresponding primary databases. 지연 양은 시간에 따라 다르기 때문에 동기화되지 않은 보조 데이터베이스에 대한 잠재적인 데이터 손실을 주기적으로 추적하는 것이 좋습니다.Because the amount of lag varies over time, we recommend that you periodically track potential data loss for your unsynchronized secondary databases. 지연 간격 추적은 각각의 주 데이터베이스 및 보조 데이터베이스에 대한 마지막 커밋 LSN 및 마지막 커밋 시간을 다음과 같이 비교합니다.Tracking lag involves comparing the Last Commit LSN and Last Commit Time for each primary database and its secondary databases, as follows:

  1. 주 복제본에 연결합니다.Connect to the primary replica.

  2. sys.dm_hadr_database_replica_states 동적 관리 뷰의 last_commit_lsn (마지막으로 커밋된 트랜잭션의 LSN) 및 last_commit_time (마지막 커밋의 시간) 열을 쿼리합니다.Query the last_commit_lsn (LSN of the last committed transaction) and last_commit_time (time of the last commit) columns of the sys.dm_hadr_database_replica_states dynamic management view.

  3. 각각의 주 데이터베이스와 보조 데이터베이스에 대해 반환되는 값을 비교합니다.Compare the values returned for each primary database and each of its secondary databases. 마지막 커밋 LSN 간 차이는 지연 양을 나타냅니다.The difference between their Last Commit LSNs indicate the amount of lag.

  4. 데이터베이스 또는 데이터베이스 집합의 지연 양이 지정된 기간 동안 원하는 최대 지연을 초과할 때 알림을 트리거할 수 있습니다.You can trigger an alert when the amount of lag on a database or set of databases exceeds your desired maximum lag for a given period of time. 예를 들어, 각 주 데이터베이스에서 1분마다 실행되는 작업을 통해 쿼리를 실행할 수 있습니다.For example, the query can be run by a job that executes every minute on each primary database. 작업이 실행된 마지막 시간 이후 주 데이터베이스와 보조 데이터베이스의 last_commit_time 간 차이가 RPO(복구 지점 목표)(예: 5분)를 초과하는 경우 작업에서 알림이 발생할 수 있습니다.If the difference between the last_commit_time of a primary database and any of its secondary databases has exceeded the recovery point objective (RPO) (for example, 5 minutes) since the last time the job executed, the job can raise an alert.

중요

WSFC 클러스터에 쿼럼이 부족하거나 쿼럼이 강제로 적용되는 경우 last_commit_lsnlast_commit_time 은 NULL입니다.When the WSFC cluster lacks quorum or quorum has been forced, last_commit_lsn and last_commit_time are NULL. 쿼럼 강제 수행 후 데이터 손실을 방지하는 방법에 대한 자세한 내용은 가용성 그룹의 강제 수동 장애 조치(Failover) 수행(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.For information about how you might be able to avoid data loss after you forced quorum, see "Potential Ways to Avoid Data Loss After Quorum is Forced" in Perform a Forced Manual Failover of an Availability Group (SQL Server).

잠재적 데이터 손실 관리 Managing the Potential Data Loss

강제 장애 조치(failover) 후 모든 보조 데이터베이스가 일시 중지됩니다.After failover is forced, all secondary databases are suspended. 여기에는 이전 주 복제본이 다시 온라인 상태가 되고 이제 보조 복제본임을 확인한 후의 이전 주 데이터베이스가 포함됩니다.This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. 각 보조 복제본에서 일시 중지된 각 데이터베이스를 개별적으로 수동 재개해야 합니다.You must manually resume each suspended database individually on each secondary replica.

이전 주 복제본을 사용할 수 있게 되면 데이터베이스가 손상되지 않았다고 가정할 경우 잠재적 데이터 손실을 관리할 수 있습니다.Once the former primary replica is available, assuming that its databases are undamaged, you can attempt to manage the potential data loss. 잠재적 데이터 손실을 관리하는 데 사용할 수 있는 방법은 원래 주 복제본이 새로운 주 복제본에 연결했는지 여부에 따라 달라집니다.The available approach for managing potential data loss depends on whether the original primary replica has connected to the new primary replica. 원래 주 복제본이 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 투명하게 다시 연결할 수 있습니다.Assuming that the original primary replica can access the new primary instance, reconnecting occurs automatically and transparently.

원래 주 복제본이 다시 연결된 경우The Original Primary Replica Has Reconnected

일반적으로 실패 후에 원래 주 복제본이 다시 시작되면 신속하게 해당 파트너에 다시 연결합니다.Typically, after a failure, when the original primary replica restarts it quickly reconnects to its partner. 다시 연결할 때 원래 주 복제본은 보조 복제본이 됩니다.On reconnecting, the original primary replica becomes the secondary replica. 해당 데이터베이스는 보조 데이터베이스가 되고 SUSPENDED 상태가 됩니다.Its databases becomes the secondary databases and enter the SUSPENDED state. 새로운 보조 데이터베이스는 재개하지 않으면 롤백되지 않습니다.The new secondary databases will not be not rolled back unless you resume them.

그러나 일시 중지된 데이터베이스에 액세스할 수 없으므로 데이터베이스를 검사하여 지정된 데이터베이스를 재개할 경우 손실될 데이터를 평가할 수 없습니다.However, the suspended databases are inaccessible, so you cannot inspect them to evaluate what data would be lost if you were to resume a given database. 따라서 다음과 같이 데이터 손실을 감수할지 여부에 따라 보조 데이터베이스를 재개할지 또는 제거할지를 결정합니다.Therefore, the decision on whether to resume or remove a secondary database depends on whether you are willing to accept any data loss, as follows:

  • 데이터 손실이 허용되지 않는 경우 가용성 그룹에서 데이터베이스를 제거하여 복원해야 합니다.If losing any data would be unacceptable, you should remove the databases from the availability group to salvage them.

    이제 데이터베이스 관리자는 이전 주 데이터베이스를 복구하여 손실된 데이터를 복구할 수 있습니다.The database administrator can now recover the former primary databases and attempt to recover the data that would have been lost. 하지만 이전 주 데이터베이스가 온라인 상태가 되면 현재 주 데이터베이스에서 분기되므로, 데이터베이스 관리자는 제거된 데이터베이스 또는 현재 주 데이터베이스에 클라이언트가 액세스할 수 없도록 하여 데이터베이스의 추가 분기를 방지하고 클라이언트 장애 조치(Failover) 문제를 예방해야 합니다.However, when a former primary database comes online, it is divergent from the current primary database, so the database administrator needs to make either the removed database or the current primary database inaccessible to clients to avoid further divergence of the databases and to prevent client-failover issues.

  • 비즈니스 목표에 따라 데이터 손실이 허용되는 경우 보조 데이터베이스를 재개할 수 있습니다.If losing data would be acceptable to your business goals, you can resume the secondary databases.

    새로운 보조 데이터베이스를 재개하면 데이터베이스 동기화의 첫 번째 단계로 해당 데이터베이스가 롤백됩니다.Resuming a new secondary database causes it to be rolled back as the first step in synchronizing the database. 실패 시 Send Queue에서 대기 중인 로그 레코드가 있으면 커밋된 경우에도 해당 트랜잭션이 손실됩니다.If any log records were waiting in the send queue at the time of failure, the corresponding transactions are lost, even if they were committed.

원래 주 복제본이 다시 연결되지 않은 경우The Original Primary Replica Has Not Reconnected

원래 주 복제본이 네트워크를 통해 새로운 주 복제본에 다시 연결하지 않도록 일시적으로 차단할 수 있으면 원래 주 데이터베이스를 검사하여 데이터베이스를 재개할 경우 손실될 데이터를 평가할 수 있습니다.If you can temporarily prevent the original primary replica from reconnecting over the network to the new primary replica, you can inspect the original primary databases to evaluate what data would be lost if they were resumed.

  • 잠재적 데이터 손실이 허용되는 경우If the potential data loss is acceptable

    원래 주 복제본을 새로운 주 복제본에 다시 연결하도록 허용합니다.Allow the original primary replica to reconnect to the new primary replica. 다시 연결하면 새로운 보조 데이터베이스가 일시 중지됩니다.Reconnecting causes the new secondary databases to be suspended. 데이터베이스에서 데이터 동기화를 시작하려면 데이터베이스를 재개하면 됩니다.To start data synchronization on a database, simply resume it. 새로운 보조 복제본은 해당 데이터베이스에 대한 원래 복구 분기를 삭제하므로 이전 보조 복제본으로 보내거나 받지 않은 모든 트랜잭션이 손실됩니다.The new secondary replica drops the original recovery fork for that database, losing any transactions that were never sent to or received by the former secondary replica.

  • 데이터 손실이 허용되지 않는 경우If the data loss is unacceptable

    일시 중지된 데이터베이스를 재개할 경우 손실될 중요한 데이터가 원래 주 데이터베이스에 들어 있으면 가용성 그룹에서 원래 주 데이터베이스를 제거하여 해당 데이터를 보존할 수 있습니다.If the original primary database contains critical data that would be lost if you resumed the suspended database, you can preserve the data on the original primary database by removing it from the availability group. 이렇게 하면 데이터베이스는 RESTORING 상태가 됩니다.This causes the database to enter the RESTORING state. 이 시점에서 제거된 데이터베이스의 비상 로그를 백업하는 것이 좋습니다.At this point, we recommend that you attempt to back up the tail of the removed database's log. 그러면 원래 주 데이터베이스에서 복원하려는 데이터를 내보낸 후 현재 주 데이터베이스로 가져와서 현재 주 데이터베이스(이전 보조 데이터베이스)를 업데이트할 수 있습니다.Then, you can update the current primary (the former secondary database) by exporting the data you want to salvage from the original primary database and importing it into the current primary database. 업데이트된 주 데이터베이스의 전체 데이터베이스 백업을 최대한 빨리 수행하는 것이 좋습니다.We recommend taking a full database backup of the updated primary database as quickly as possible.

    그러면 새로운 보조 복제본을 호스팅하는 서버 인스턴스에서 RESTORE WITH NORECOVERY를 사용하여 이 백업(및 최소한 하나 이상의 후속 로그 백업)을 복원하여 일시 중지된 보조 데이터베이스를 삭제하고 새로운 보조 데이터베이스를 만들 수 있습니다.Then, on the server instance that hosts the new secondary replica, you can delete the suspended secondary database and create a new secondary database by restoring this backup (and least one subsequent log backup) using RESTORE WITH NORECOVERY. 해당 보조 데이터베이스를 재개할 때까지 현재 주 데이터베이스의 추가 로그 백업을 늦추는 것이 좋습니다.We recommend delaying additional log backups of the current primary databases until the corresponding secondary databases are resumed.

경고

보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안에는 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다.Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. 또한 일시 중지된 상태로 남아 있는 로컬 데이터베이스가 있으면 동기 커밋 보조 복제본의 동기화 상태가 정상으로 전환될 수 없습니다.Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

장애 조치(Failover) 동작을 구성하려면To configure failover behavior

참고 항목See Also

Always On 가용성 그룹 개요(SQL Server) Overview of Always On Availability Groups (SQL Server)
가용성 모드(Always On 가용성 그룹) Availability Modes (Always On Availability Groups)
SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링) Windows Server Failover Clustering (WSFC) with SQL Server
Always On 가용성 그룹 및 데이터베이스 미러링에 대한 데이터베이스 간 트랜잭션 및 분산 트랜잭션(SQL Server) Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
장애 조치(failover) 클러스터 인스턴스용 장애 조치(failover) 정책 Failover Policy for Failover Cluster Instances
가용성 그룹 자동 장애 조치에 대한 유연한 장애 조치 정책(SQL Server)Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server)