가용성 모드(Always On 가용성 그룹)Availability 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

Always On 가용성 그룹Always On availability groups에서 가용성 모드 는 지정된 가용성 복제본을 동기 커밋 모드에서 실행할 수 있는지 여부를 결정하는 복제본 속성입니다.In Always On 가용성 그룹Always On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. 각 가용성 복제본에 대해 가용성 모드를 동기 커밋 모드나 비동기 커밋 모드로 구성해야 합니다.For each availability replica, the availability mode must be configured for either synchronous-commit mode or asynchronous-commit mode. 주 복제본이 비동기 커밋 모드로 구성된 경우 주 복제본에서는 보조 복제본이 들어오는 트랜잭션 로그 레코드를 디스크에 기록( 로그 확정)할 때까지 기다리지 않습니다.If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). 특정 보조 복제본이 비동기 커밋 모드로 구성된 경우 주 복제본은 해당 보조 복제본이 로그를 확정할 때까지 기다리지 않습니다.If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. 주 복제본과 특정 보조 복제본이 모두 동기 커밋 모드로 구성된 경우에는 보조 복제본이 주 복제본의 세션 제한 시간내에 주 복제본을 ping하는 데 실패하지 않은 한 주 복제본은 보조 복제본이 로그를 확정했음을 확인할 때까지 기다립니다.If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary's session-timeout period).

참고

보조 복제본이 주 복제본의 세션 제한 시간을 초과할 경우 주 복제본은 일시적으로 해당 보조 복제본에 대해 비동기 커밋 모드로 전환합니다.If primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. 보조 복제본이 주 복제본에 다시 연결할 때는 동기 커밋 모드가 다시 시작됩니다.When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

항목 내용In this Topic:

지원되는 가용성 모드 Supported Availability Modes

Always On 가용성 그룹Always On availability groups 은 아래 설명되어 있는 비동기-커밋 모드 및 동기-커밋 모드라는 두 가지 가용성 모드를 지원합니다. supports two availability modes—asynchronous-commit mode and synchronous-commit mode, as follows:

  • 비동기-커밋 모드 는 여러 가용성 복제본이 상당한 거리를 두고 분산되어 있는 경우에 적합한 재해 복구 솔루션입니다.Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. 모든 보조 복제본이 비동기-커밋 모드로 실행될 경우 주 복제본은 보조 복제본이 로그를 확정할 때까지 기다리지 않습니다.If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. 대신 주 복제본은 로그 레코드를 로컬 로그 파일에 쓴 후 곧바로 트랜잭션 확인을 클라이언트로 보냅니다.Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. 주 복제본은 비동기-커밋 모드로 구성된 보조 복제본에 비해 최소한의 트랜잭션 대기 시간으로 실행됩니다.The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. 현재 주 복제본이 비동기 커밋 가용성 모드로 구성되어 있는 경우 주 복제본은 보조 복제본 각각의 가용성 모드 설정에 관계없이 모든 보조 복제본에 대해 비동기로 트랜잭션을 커밋합니다.If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.

    자세한 내용은 이 항목의 뒷부분에 나오는 비동기-커밋 가용성 모드를 참조하세요.For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • 동기-커밋 모드 는 트랜잭션 대기 시간이 증가하더라도 성능에 비해 고가용성을 강조합니다.Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. 동기-커밋 모드에서는 보조 복제본이 로그를 디스크에 확정할 때까지 트랜잭션이 트랜잭션 확정을 클라이언트에 보내기를 기다립니다.Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. 보조 데이터베이스에서 데이터 동기화가 시작되면 보조 복제본은 해당 주 데이터베이스로부터 들어오는 로그 레코드를 적용하기 시작합니다.When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. 모든 로그 레코드가 확정되면 보조 데이터베이스가 곧바로 SYNCHRONIZED 상태로 전환됩니다.As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. 이후부터 모든 새 트랜잭션은 보조 복제본에 의해 확정된 후 로그 레코드가 로컬 로그 파일에 작성됩니다.Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. 지정된 보조 복제본의 모든 보조 데이터베이스가 동기화된 경우 동기-커밋 모드에서는 수동 장애 조치(Failover)와 필요한 경우 자동 장애 조치를 지원합니다.When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    자세한 내용은 이 항목의 뒷부분에 나오는 동기-커밋 가용성 모드를 참조하세요.For more information, see Synchronous-Commit Availability Mode, later in this topic.

    다음 그림에서는 5개의 가용성 복제본이 있는 가용성 그룹을 보여 줍니다.The following illustration shows an availability group with five availability replicas. 주 복제본 및 하나의 보조 복제본이 자동 장애 조치를 사용하여 동기-커밋 모드에 대해 구성됩니다.The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. 또한 다른 보조 복제본이 계획된 수동 장애 조치만 사용하여 동기-커밋 모드에 대해 구성되고, 두 개의 보조 복제본이 비동기-커밋 모드에 대해 구성됩니다(강제 수동 장애 조치만 지원함, 일반적으로 강제 장애 조치 작업이라고 함).Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

    복제본의 가용성 및 장애 조치 모드Availability and failover modes of replicas

    두 가용성 복제본 간의 동기화와 장애 조치(failover) 동작은 두 복제본의 가용성 모드에 따라 다릅니다.The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. 예를 들어 발생할 동기 커밋의 경우 동기 커밋에 대해 현재 주 복제본 및 보조 복제본을 모두 구성해야 합니다.For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. 이와 마찬가지로 발생할 자동 장애 조치(Failover)의 경우 자동 장애 조치(Failover)에 대해 두 복제본을 모두 구성해야 합니다.Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. 따라서 위에서 그림에 표시된 배포 시나리오 동작은 다음 표로 요약될 수 있으며 이 표에서는 각 잠재 주 복제본과 함께 동작을 설명합니다.Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

현재 주 복제본Current Primary Replica 자동 장애 조치(Failover) 대상Automatic Failover Targets 동기-커밋 모드 다음에 대한 동작Synchronous-Commit Mode Behavior With 비동기-커밋 모드 다음에 대한 동작Asynchronous-Commit Mode Behavior With 자동 장애 조치(Failover) 가능 여부Automatic failover possible
0101 0202 02 및 0302 and 03 0404 Yes
0202 0101 01 및 0301 and 03 0404 Yes
0303 01 및 0201 and 02 0404 아니요No
0404 01, 02 및 0301, 02, and 03 아니요No

일반적으로 노드 04는 비동기 커밋 복제본으로서 재해 복구 사이트에 배포됩니다.Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. 노드 04에 대한 장애 조치(Failover)를 수행한 후 노드 01, 02, 03은 비동기 커밋 모드로 유지된다는 점에서 두 사이트 간의 긴 네트워크 지연 시간으로 인해 가용성 그룹의 잠재적 성능이 저하되는 것을 방지할 수 있습니다.The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability Mode Asynchronous-Commit Availability Mode

비동기-커밋 모드에서는 보조 복제본이 주 복제본과 동기화되지 않습니다.Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. 지정된 보조 데이터베이스가 해당 주 데이터베이스를 따라 잡더라도 보조 데이터베이스는 언제든지 뒤쳐질 수 있습니다.Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. 비동기 커밋 모드는 주 복제본과 보조 복제본이 상당한 거리를 두고 떨어져 있으며 사소한 오류로 인해 주 복제본이 영향을 받지 않도록 하려는 경우나 동기화된 데이터 보호보다 성능을 중요시하는 경우의 재해 복구 시나리오에서 유용합니다.Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in or situations where performance is more important than synchronized data protection. 또한 주 복제본이 보조 복제본의 승인을 기다리지 않기 때문에 보조 복제본의 문제가 주 복제본에 영향을 주지 않습니다.Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

비동기 커밋 보조 복제본은 주 복제본으로부터 받은 로그 레코드를 따라잡으려고 합니다.An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. 그러나 비동기 커밋 보조 데이터베이스는 항상 동기화되지 않은 상태로 있으며 해당 주 데이터베이스보다 뒤쳐질 수 있습니다.But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. 일반적으로 비동기 커밋 보조 데이터베이스와 해당 주 데이터베이스 간의 시간차는 작은 편입니다.Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. 그러나 보조 복제본을 호스팅하는 서버가 과부화되거나 네트워크 속도가 느린 경우에는 이 시간차가 상당히 커질 수 있습니다.But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

비동기-커밋 모드에서 지원되는 유일한 형태의 장애 조치는 강제 장애 조치(데이터가 손실될 수 있음)입니다.The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). 강제 장애 조치는 현재 주 복제본을 상당 기간 사용할 수 없으며 데이터 손실의 위험보다 주 데이터베이스 가용성이 더 중요한 경우에만 최후의 수단으로 사용해야 합니다. 장애 조치(Failover) 대상은 역할이 SECONDARY 또는 RESOLVING 상태인 복제본이어야 합니다.Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. 이때 장애 조치(Failover) 대상은 주 역할로 전환되고 해당 데이터베이스 복사본이 주 데이터베이스가 됩니다.The failover target transitions to the primary role, and its copies of the databases become the primary database. 나머지 보조 데이터베이스(사용 가능하게 된 경우)는 이전 주 데이터베이스와 함께 사용자가 수동으로 개별 데이터베이스를 다시 시작할 때까지 일시 중지됩니다.Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. 비동기 커밋 모드에서는 원래 주 복제본이 이전의 보조 복제본으로 아직 보내지지 않은 트랜잭션 로그가 손실됩니다.Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. 즉, 최근에 커밋된 트랜잭션이 새로운 주 데이터베이스의 일부 또는 모두에 없을 수도 있습니다.This means that some or all of the new primary databases might be lacking recently committed transactions. 강제 장애 조치 작동 방법과 최선의 사용 방법은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)를 참조하세요.For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability Mode Synchronous-Commit Availability Mode

동기-커밋 가용성 모드(동기-커밋 모드)에서는 보조 데이터베이스가 가용성 그룹에 조인한 후에 해당 주 데이터베이스를 따라잡고 SYNCHRONIZED 상태로 전환됩니다.Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. 보조 데이터베이스는 데이터 동기화가 계속되는 한 SYNCHRONIZED로 유지됩니다.The secondary database remains SYNCHRONIZED as long as data synchronization continues. 그러면 지정된 주 데이터베이스에서 커밋된 모든 트랜잭션이 해당 보조 데이터베이스에서도 커밋됩니다.This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. 지정된 보조 복제본의 모든 보조 데이터베이스가 동기화되면 보조 복제본 전체의 동기화 상태가 HEALTHY가 됩니다.When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

섹션 내용In This Section:

데이터 동기화를 방해하는 요인 Factors That Disrupt Data Synchronization

모든 데이터베이스가 동기화되면 보조 복제본이 HEALTHY 상태가 됩니다.Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. 다음 중 하나가 발생하지 않는 한 동기화된 보조 복제본은 정상으로 유지됩니다.The synchronized secondary replica will remain healthy unless one of the following occurs:

  • 네트워크/컴퓨터 지연 또는 결함으로 인해 보조 복제본과 주 복제본 간의 세션 제한 시간이 만료됩니다.A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    참고

    가용성 복제본의 세션-시간 속성에 대한 자세한 내용은 Always On 가용성 그룹 개요(SQL Server)를 참조하세요.For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • 보조 복제본에서 보조 데이터베이스를 일시 중지합니다.You suspend a secondary database on the secondary replica. 보조 복제본이 더 이상 동기화되지 않고 해당 동기화 상태가 NOT_HEALTHY로 표시됩니다.The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. 일시 중지된 보조 데이터베이스가 다시 시작되고 다시 동기화되거나 가용성 그룹에서 제거될 때까지 해당 보조 복제본은 다시 정상이 될 수 없습니다.the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • 가용성 그룹에 주 데이터베이스를 추가합니다.You add a primary database the availability group. 이전에 동기화된 보조 복제본은 NOT_HEALTHY 동기화 상태가 됩니다.Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. 이 상태는 하나 이상의 데이터베이스가 NOT SYNCHRONIZING 동기화 상태임을 나타냅니다.This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. 지정된 보조 복제본은 복제본에서 해당 보조 데이터베이스가 준비되고, 가용성 그룹에 조인하고, 새로운 주 데이터베이스와 동기화될 때까지 다시 HEALTHY가 될 수 없습니다.A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.

  • 주 복제본 또는 보조 복제본을 동기-커밋 가용성 모드로 변경합니다.You change the primary replica or the secondary replica to asynchronous-commit availability mode. 보조 복제본은 동기-커밋 모드로 변경된 후 데이터 동기화가 계속되는 한 HEALTHY 동기화 상태로 유지됩니다.After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. 그러나 주 복제본만 동기-커밋 모드로 변경되는 경우에는 동기-커밋 보조 복제본이 PARTIALLY_HEALTHY 동기화 상태가 됩니다.However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. 이 상태는 하나 이상의 데이터베이스가 SYNCHRONIZING 동기화 상태에 있지만 어떤 데이터베이스도 NOT SYNCHRONIZING 상태에 있지 않음을 나타냅니다.This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.

  • 보조 복제본을 동기-커밋 가용성 모드로 변경합니다.You change any secondary replica to synchronous-commit availability mode. 이렇게 하면 모든 해당 데이터베이스가 SYNCHRONIZED 동기화 상태가 될 때까지This causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. 보조 복제본이 PARTIALLY_HEALTHY 동기화 상태로 표시됩니다.until all of its databases are in the SYNCHRONIZED synchronization state.

가용성 그룹, 가용성 복제본 또는 가용성 데이터베이스의 동기화 상태를 보려면 각각 sys.dm_hadr_availability_group_states , sys.dm_hadr_availability_replica_states 또는 sys.dm_hadr_database_replica_statessynchronization_health또는 synchronization_health_desc열을 쿼리합니다.To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

보조 복제본에서 동기화가 작동하는 방법 How Synchronization Works on a Secondary Replica

동기-커밋 모드에서는 보조 복제본을 가용성 그룹에 조인하고 주 복제본과의 세션을 설정하고 나면 보조 복제본은 들어오는 로그 레코드를 디스크에 기록하고(로그 확정) 확인 메시지를 주 복제본으로 보냅니다.Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. 보조 데이터베이스의 확정된 로그가 주 데이터베이스의 로그 끝을 따라잡으면 보조 데이터베이스의 상태가 SYNCHRONIZED로 설정됩니다.Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. 동기화에 필요한 시간은 세션을 시작할 때 보조 데이터베이스와 주 데이터베이스 간의 격차(처음에 주 복제본으로부터 받은 로그 레코드 수로 측정), 주 데이터베이스의 작업 로드 및 보조 복제본을 호스팅하는 서버 인스턴스 컴퓨터의 속도에 따라 달라집니다.The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

동기화 작업은 다음 방식으로 유지 관리됩니다.Synchronous operation is maintained in the following manner:

  1. 클라이언트로부터 트랜잭션을 받자마자 주 복제본은 트랜잭션에 대한 로그를 트랜잭션 로그에 쓰고 이와 동시에 로그 레코드를 보조 복제본으로 보냅니다.On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.

  2. 주 데이터베이스의 트랜잭션 로그에 로그 레코드가 작성되면 현재 시점에서 해당 로그를 받지 못한 보조 데이터베이스로의 장애 조치가 있을 경우에만 트랜잭션을 실행 취소할 수 있습니다.Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. 주 복제본은 동기-커밋 보조 복제본의 확인을 기다립니다.The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. 보조 복제본은 로그를 확정하고 주 복제본으로 승인을 반환합니다.The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. 보조 복제본의 확인을 받자마자 주 복제본은 커밋 처리를 마치고 확인 메시지를 클라이언트로 보냅니다.On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    참고

    동기-커밋 보조 복제본이 로그를 확정했음을 확인하지 않은 상태에서 제한 시간이 만료되면 주 복제본이 해당 보조 복제본을 실패한 것으로 표시합니다.If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. 보조 복제본의 연결 상태가 DISCONNECTED로 변경되고, 주 복제본이 보조 복제본의 확인을 더 이상 기다리지 않습니다.The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. 이 동작은 실패한 동기-커밋 보조 복제본으로 인해 주 복제본에서 트랜잭션 로그가 확정되지 않는 것을 방지합니다.This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

    동기-커밋 모드에서는 트랜잭션 대기 시간이 다소 늘어나더라도 두 위치의 데이터가 동기화되도록 하여 데이터를 보호합니다.Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

수동 장애 조치만 사용하는 동기-커밋 모드 Synchronous-Commit Mode with Only Manual Failover

이들 복제본이 연결되어 있으며 데이터베이스가 동기화된 경우 수동 장애 조치가 지원됩니다.When these replicas are connected and the database is synchronized, manual failover is supported. 보조 복제본의 작동이 중단되어도 주 복제본은 영향을 받지 않습니다.If the secondary replica goes down, the primary replica is unaffected. SYNCHRONIZED 상태의 복제본이 없으면 주 복제본이 표시된 상태로, 즉 데이터를 보조 복제본에 보내지 않고 실행됩니다.The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). 주 복제본이 손실되면 보조 복제본이 RESOLVING 상태가 되지만 데이터베이스 소유자가 보조 복제본으로의 강제 장애 조치를 수행할 수 있으며 이 경우 데이터가 손실될 수 있습니다.If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). 자세한 내용은 이 항목의 뒷부분에 나오는 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)를 참조하세요.For more information, see Failover and Failover Modes (Always On Availability Groups).

자동 장애 조치를 사용하는 동기-커밋 모드 Synchronous-Commit Mode with Automatic Failover

자동 장애 조치를 사용하면 주 복제본이 손실되어도 데이터베이스를 신속하게 다시 사용할 수 있으므로 고가용성이 보장됩니다.Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. 자동 장애 조치에 대해 가용성 그룹을 구성하려면 현재 주 복제본과 최소 하나의 보조 복제본을 모두 자동 장애 조치를 사용하는 동기-커밋 모드로 설정해야 합니다.To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. 최대 3개의 자동 장애 조치(failover) 복제본을 가질 수 있습니다.You can have up to three automatic failover replicas.

또한 특정 시점에 자동 장애 조치가 가능하려면 이 보조 복제본을 주 복제본과 동기화하고, 즉 보조 데이터베이스를 모두 동기화하고 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터에 쿼럼이 있어야 합니다.Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. 위의 조건에서 주 복제본을 사용할 수 없게 되면 자동 장애 조치가 수행됩니다.If the primary replica becomes unavailable under these conditions, automatic failover occurs. 보조 복제본이 주 복제본의 역할로 전환하여 해당 데이터베이스를 주 데이터베이스로 제공합니다.The secondary replica switches to the role of primary, and it offers its database as the primary database. 자세한 내용은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹) 항목의 "자동 장애 조치" 섹션을 참조하세요.For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

참고

WSFC 쿼럼 및 Always On 가용성 그룹Always On availability groups에 대한 자세한 내용은 WSFC 쿼럼 모드 및 투표 구성(SQL Server)을 참조하세요.For information about WSFC quorum and Always On 가용성 그룹Always On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

가용성 모드와 장애 조치(failover) 모드를 변경하려면To change the availability mode and failover mode

참고 항목See Also

Always On 가용성 그룹 개요(SQL Server) Overview of Always On Availability Groups (SQL Server)
장애 조치 및 장애 조치 모드(Always On 가용성 그룹) Failover and Failover Modes (Always On Availability Groups)
SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)Windows Server Failover Clustering (WSFC) with SQL Server