가용성 그룹의 강제 수동 장애 조치(Failover) 수행(SQL Server)Perform a Forced Manual Failover of an Availability Group (SQL Server)

이 항목 적용 대상: 예SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse 이 항목에서는 SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL 또는 SQL Server 2017SQL Server 2017의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다. This topic describes how to perform a forced failover (with possible data loss) on an Always On availability group by using SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL, or PowerShell in SQL Server 2017SQL Server 2017. 강제 장애 조치(failover)는 예정된 수동 장애 조치(failover) 가 가능하지 않을 때 재해 복구용으로만 사용하기 위한 수동 장애 조치(failover)의 한 형태입니다.A forced failover is a form of manual failover that is intended strictly for disaster recovery, when a planned manual failover is not possible. 동기화되지 않은 보조 복제본으로 강제 장애 조치(failover)를 수행하면 데이터 손실이 발생할 수 있습니다.If you force failover to an unsynchronized secondary replica, some data loss is possible. 따라서 서비스를 즉시 가용성 그룹으로 복원해야 하고 데이터 손실 위험을 감수할 수 있는 경우에만 강제 장애 조치(failover)를 수행하는 것이 좋습니다.Therefore, we strongly recommend that you force failover only if you must restore service to the availability group immediately and you are willing to risk losing data.

강제 장애 조치(failover) 후 가용성 그룹이 장애 조치된 장애 조치failover) 대상은 새로운 주 복제본이 됩니다.After a forced failover, the failover target to which the availability group was failed over becomes the new primary replica. 남은 보조 복제본에 있는 보조 데이터베이스는 일시 중지되기 때문에 수동으로 다시 시작해야 합니다.The secondary databases in the remaining secondary replicas are suspended and must be manually resumed. 이전의 주 복제본을 사용할 수 있게 되면 이 복제본은 보조 역할로 전환됩니다. 따라서 이전의 주 데이터베이스는 보조 데이터베이스가 되고 SUSPENDED 상태로 전환됩니다.When the former primary replica becomes available, it transitions to the secondary role, causing the former primary databases to become secondary databases and transition into the SUSPENDED state. 지정된 보조 데이터베이스를 다시 시작하기 전에 해당 데이터베이스에서 손실된 데이터를 복구할 수도 있습니다.Before you resume a given secondary database, you might be able to recover lost data from it. 그러나 보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안에는 지정된 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다.However, notice that transaction log truncation is delayed on a given primary database while any of its secondary databases is suspended.

중요

주 데이터베이스를 사용한 데이터 동기화는 보조 데이터베이스가 재개될 때까지 발생하지 않습니다.Data synchronization with the primary database will not occur until the secondary database is resumed. 보조 데이터베이스를 재개하는 방법에 대한 정보는 이 문서의 뒷 부분에 나오는 후속 작업: 강제 장애 조치(Failover) 후 필수 태스크 를 참조하세요.For information about resuming a secondary database, see Follow Up: Essential Tasks After a Forced Failover later in this article.

강제 장애 조치(failover)는 다음과 같은 응급 상황에 수행해야 합니다.Performing a forced failover is necessary in the following emergency situations:

  • WSFC 클러스터에서강제 쿼럼을 수행한 후에는 각 가용성 그룹에 대해 강제 장애 조치(failover)(데이터 손실 가능)를 수행해야 합니다.After forcing quorum on the WSFC cluster (forced quorum), you need to force failover each availability group (with possible data loss). 강제 장애 조치(failover)가 필요한 이유는 WSFC 클러스터 값의 실제 상태가 손실되었을 수 있기 때문입니다.Forcing failover is required because the real state of the WSFC cluster values might have been lost. 그러나 강제 쿼럼을 수행하기 전에 주 복제본이었던 복제본을 호스팅하는 시스템 인스턴스에서 강제 장애 조치(failover)를 수행할 수 있거나 강제 쿼럼을 수행하기 전에 동기화된 보조 복제본으로 강제 장애 조치(failover)를 수행할 수 있으면 데이터 손실을 방지할 수 있습니다.However, you can avoid data loss, if are able to force failover on the server instance that was hosting the replica that was the primary replica before you forced quorum or to a secondary replica that was synchronized before you forced quorum. 자세한 내용은 이 항목의 뒷부분에 나오는 강제 쿼럼 후 데이터 손실을 방지할 수 있는 잠재적인 방법을 참조하세요.For more information, see Potential Ways to Avoid Data Loss After Quorum is Forced, later in this topic.

    중요

    강제적인 방법이 아니라 자연스러운 방법으로 쿼럼을 다시 얻으면 가용성 복제본이 일반적인 방법으로 복구됩니다.If quorum is regained by natural means instead of being forced, the availability replicas will go through normal recovery. 쿼럼을 다시 얻은 후에도 여전히 주 복제본을 사용할 수 없는 경우 동기화된 보조 복제본으로 예정된 수동 장애 조치(failover)를 수행할 수 있습니다.If the primary replica is still unavailable after quorum is regained, you can perform a planned manual failover to a synchronized secondary replica.

    강제 쿼럼에 대한 자세한 내용은 강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For information about forcing quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server). 강제 쿼럼 후에 강제 장애 조치(failover)가 필요한 이유에 대한 자세한 내용은 장애 조치(failover) 및 장애 조치(failover) 모드(Always On 가용성 그룹)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For information about why forcing failover is required after forcing quorum, see Failover and Failover Modes (Always On Availability Groups).

  • WSFC 클러스터에 정상 상태의 쿼럼이 있어도 주 복제본을 사용할 수 없는 경우 역할이 SECONDARY 또는 RESOLVING 상태인 복제본으로 강제 장애 조치(failover)(데이터 손실 가능)를 수행할 수 있습니다.If the primary replica becomes unavailable when the WSFC cluster has a healthy quorum, you can force failover (with possible data loss), to any replica whose role is in the SECONDARY or RESOLVING state. 가능하면 주 복제본이 손실될 당시 동기화된 동기-커밋 보조 복제본으로 장애 조치(failover)를 수행하세요.If possible, force failover to a synchronous-commit secondary replica that was synchronized when the primary replica was lost.

    WSFC 클러스터에 정상 상태의 쿼럼이 있을 때 동기화된 보조 복제본에서 강제 장애 조치(failover) 명령을 실행하면 해당 복제본이 실제로 예정된 수동 장애 조치(failover)를 수행합니다.When the WSFC cluster has a healthy quorum, if you issue a force failover command on a synchronized secondary replica, the replica actually performs a planned manual failover.

참고

강제 장애 조치(failover)를 위한 필수 조건 및 권장 사항에 대한 자세한 내용과 강제 장애 조치(failover)를 사용하여 치명적인 오류에서 복구하는 예제 시나리오는 이 항목의 뒷부분에 나오는 예제 시나리오: 강제 장애 조치(Failover)를 사용하여 치명적인 오류 복구를 참조하세요.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 Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure, later in this topic.

시작하기 전에Before You Begin

제한 사항Limitations and Restrictions

  • 장애 조치(failover)를 수행할 수 없는 유일한 시간은 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터에 쿼럼이 부족할 때입니다.The only time that you cannot perform a forced failover is when Windows Server Failover Clustering (WSFC) cluster lacks quorum.

  • 가용성 그룹의 강제 장애 조치(failover) 중 데이터가 손실될 수 있습니다.Data loss is possible during the forced failover of an availability group. 또한 강제 장애 조치(failover)를 시작할 때 주 복제본이 실행 중인 경우 클라이언트는 여전히 이전의 주 데이터베이스에 연결되어 있을 수 있습니다.In addition, if the primary replica is running when you initiate a forced failover, clients might still be connected to former primary databases. 따라서 주 복제본이 더 이상 실행되지 않는 경우와 가용성 그룹의 데이터베이스에 액세스를 복원하기 위해 데이터 손실 위험을 감수할 수 있는 경우에만 강제 장애 조치(failover)를 수행하는 것이 좋습니다.Therefore, we strongly recommend that you force failover only if the primary replica is no longer running and if you are willing to risk losing data in order to restore access to databases in the availability group.

  • 보조 데이터베이스가 REVERTING 또는 INITIALIZING 상태일 때는 강제 장애 조치(failover)를 수행해도 해당 데이터베이스가 주 데이터베이스로 시작되지 않습니다.When a secondary database in the REVERTING or INITIALIZING state, forcing failover would cause the database to fail to start as a primary database. 데이터베이스가 INTIAILIZGING 상태에 있었다면 데이터베이스 백업에서 누락된 로그 레코드를 적용하거나 처음부터 데이터베이스를 전체 복원해야 합니다.If the database was in the INTIAILIZGING state the you will need to apply the missing log records from a database backup or fully restore the database from scratch. 데이터베이스가 REVERTING 상태에 있었다면 데이터베이스를 백업에서 전체 복원해야 합니다.If the database was in the REVERTING state you will need to fully restore the database from backups.

  • 장애 조치(failover) 명령은 장애 조치(failover) 대상에서 해당 명령을 수락하는 즉시 반환하지만A failover command returns as soon as the failover target has accepted the command. 데이터베이스 복구는 가용성 그룹의 장애 조치가 끝난 후 비동기로 수행됩니다.However, database recovery occurs asynchronously after the availability group has finished failing over.

  • 장애 조치(failover) 시 가용성 그룹 내에서 데이터베이스 간 일관성은 유지되지 않을 수 있습니다.Cross-database consistency across databases within the availability group might not be maintained on failover.

    참고

    데이터베이스 간 트랜잭션 및 분산 트랜잭션 지원은 SQL Server 및 운영 체제 버전에 따라 달라집니다.Support for cross-database and distributed transactions vary by SQL Server and operating system versions. 자세한 내용은 Always On 가용성 그룹 및 데이터베이스 미러링에 대한 데이터베이스 간 트랜잭션 및 분산 트랜잭션(SQL Server)를 참조하세요.For more information, see Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server).

필수 구성 요소Prerequisites

  • WSFC 클러스터에 쿼럼이 있습니다.The WSFC cluster has quorum. 클러스터에 쿼럼이 없는 경우 강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.If the cluster lacks quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

  • 역할이 SECONDARY 또는 RESOLVING 상태인 복제본을 호스팅하는 서버 인스턴스에 연결할 수 있어야 합니다.You must be able to connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state.

권장 사항Recommendations

  • 주 복제본이 여전히 실행되는 동안에는 강제 장애 조치(failover)를 수행하지 마세요.Do not force failover while the primary replica is still running.

  • 가능하면 보조 데이터베이스가 NOT SYNCHRONIZED, SYNCHRONIZED 또는 SYNCHRONIZING 상태인 장애 조치(failover) 대상으로만 강제 장애 조치(failover)를 수행하세요.If possible, force failover only to a failover target whose secondary databases are either in the NOT SYNCHRONIZED, SYNCHRONIZED, or SYNCHRONIZING state. 보조 데이터베이스가 INTIAILIZGING 또는 REVERTING 상태일 경우 강제 장애 조치(failover)의 영향에 대한 자세한 내용은 이 항목의 앞 부분에서 제한 사항을 참조하세요.For information about the implications of forcing failover when a secondary database is in the INTIAILIZGING or REVERTING state, see Limitations and Restrictions, earlier in this topic.

  • 일반적으로 서로 다른 비동기 커밋 보조 복제본에서 주 데이터베이스를 기준으로 지정된 보조 데이터베이스의 대기 시간이 비슷해야 합니다.Typically, the latency of a given secondary database, relative to the primary database, should be similar on different asynchronous-commit secondary replicas. 그러나 강제 장애 조치(failover)를 수행하는 경우 데이터 손실이 중요한 문제가 될 수 있습니다.However, when forcing failover, data loss can be a significant concern. 따라서 서로 다른 보조 복제본에서 데이터베이스 복사본의 상대적 대기 시간을 결정하는 데 시간이 걸린다는 사실을 고려해야 합니다.Therefore, consider taking time to determine the relative latency of the copies of the databases on different secondary replicas. 지정된 보조 데이터베이스의 복사본 중 최소 대기 시간을 갖는 복사본을 확인하려면 해당 로그 끝 LSN을 비교합니다.To determine which copy of a given secondary database has the least latency, compare their end-of-log LSNs. 로그 끝 LSN이 클수록 대기 시간이 짧습니다.A higher the end-of-log LSN indicates less latency.

    로그 LSN 끝을 비교하려면 각 온라인 보조 복제본에 연결한 다음 각 로컬 보조 데이터베이스의 end_of_log_lsn 값에 대해 sys.dm_hadr_database_replica_states 를 쿼리합니다.To compare end-of-log LSNs, connect to each online secondary replica, in turn, and query sys.dm_hadr_database_replica_states for the end_of_log_lsn value of each local secondary database. 그런 다음 각 데이터베이스의 여러 다른 복사본의 로그 끝 LSN을 비교합니다.Then, compare the end-of-log LSNs of the different copies of each database. 각 보조 복제본마다 각 데이터베이스의 가장 큰 LSN이 다를 수 있습니다.Note that different databases might have their highest LSNs on different secondary replicas. 이 경우 가장 적절한 장애 조치(failover) 대상은 서로 다른 데이터베이스의 데이터에 두는 상대적 중요도에 따라 달라집니다.In this case, the most appropriate failover target depends on the relative importance that you place on the data in the different databases. 즉, 이러한 데이터베이스 중 데이터 손실을 가장 최소화하려는 데이터베이스를 고려합니다.That is, for which of these databases would you most want to minimize possible data loss?

  • 클라이언트가 원래 주 복제본에 연결할 수 있는 경우 강제 장애 조치(failover)를 수행하면 분리 장애(split-brain) 동작이 발생할 위험이 있습니다.If clients are able to connect to the original primary, a forced failover incurs some risk of split brain behavior. 강제 장애 조치(failover)를 수행하기 전에 클라이언트가 원래 주 복제본에 액세스하지 않도록 하는 것이 좋습니다.Before you force failover, we strongly recommend that you prevent clients from accessing the original primary replica. 그렇지 않으면 강제로 장애 조치한 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.Otherwise, after failover is forced, the original primary databases and the current primary databases could be updated independently of the other.

강제 쿼럼 후 데이터 손실을 방지할 수 있는 잠재적인 방법Potential Ways to Avoid Data Loss After Quorum is Forced

쿼럼이 손실된 후 오류 조건에 따라 다음과 같이 데이터 손실을 방지할 수 있습니다.Under some failure conditions after quorum is lost, you can avoid prevent data loss, as follows:

  • 원래 주 복제본이 온라인 상태가 된 경우If the original primary replica comes online

    쿼럼이 손실된 경우 WSFC 쿼럼 강제 적용으로 가용성 그룹의 주 복제본을 호스팅하는 클러스터 노드를 복원하면 이 가용성 그룹에 대한 데이터 손실을 방지할 수 있습니다.If quorum is lost and forcing WSFC quorum restores the cluster node that hosts the primary replica of an availability group, you can prevent data loss for this availability group. 주 복제본에 연결하고 강제 장애 조치(failover)(FAILOVER_ALLOW_DATA_LOSS)를 수행합니다.Connect to the primary replica and perform a forced failover (FAILOVER_ALLOW_DATA_LOSS). 이렇게 하면 주 복제본이 다시 온라인 상태가 됩니다.This brings the primary replica back online. 원래 주 복제본으로 강제 장애 조치(failover)를 수행하므로 데이터가 손실되지 않습니다.Because you perform the forced failover to the original primary replica, there is no data loss.

  • 동기화된 동기-커밋 보조 복제본이 온라인 상태가 된 경우If a synchronized synchronous-commit secondary replica comes online

    쿼럼이 손실된 경우 WSFC 쿼럼 강제 적용으로 가용성 그룹의 동기화된 보조 복제본을 호스팅하는 클러스터 노드를 복원하면 이 가용성 그룹에 대한 데이터 손실을 방지할 수 있습니다.If quorum is lost and forcing WSFC quorum restores a cluster node that hosts a synchronized secondary replica for an availability group, you should be able to prevent data loss for this availability group. 쿼럼 손실 당시 복원된 노드가 실행 중이었다면 sys.dm_hadr_database_replica_cluster_states 동적 관리 뷰의 is_failover_ready 열을 쿼리하여 지정된 데이터베이스에서 데이터 손실이 발생할 수 있었는지 여부를 확인할 수 있습니다.If the restored node was up at the time that quorum was lost, you can determine whether data loss could occur on a given database by querying the is_failover_ready column of the sys.dm_hadr_database_replica_cluster_states dynamic management view. 예를 들어 sql108w2k8r22라는 서버 인스턴스가 있다고 가정할 경우 다음 쿼리를 실행합니다.For example, for a server instance named sql108w2k8r22, issue the following query:

    SELECT * FROM sys.dm_hadr_database_replica_cluster_states  
       WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas   
          WHERE replica_server_name ='sql108w2k8r22')  
    

    주의

    쿼럼 손실 당시 복원된 노드가 실행되고 있지 않았다면 주 복제본이 오프라인으로 전환될 당시의 실제 클러스터 상태가 is_failover_ready 에 반영되지 않을 수 있습니다.If the restored node was not up at the time quorum was lost, is_failover_ready may not reflect the cluster's actual state at the time the primary replica went offline. 따라서 is_failover_ready 값은 실패 당시 호스트 노드가 실행 중이었던 경우에만 유효합니다.Therefore, the is_failover_ready value is only good if the host node at the time of the failure. 자세한 내용은 장애 조치(failover) 및 장애 조치(failover) 모드(Always On 가용성 그룹)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For more information, see "Why Forced Failover is Required After Forcing Quorum" in Failover and Failover Modes (Always On Availability Groups).

    is_failover_ready 가 1이면 데이터베이스가 클러스터에서 동기화된 상태로 표시되고 장애 조치(failover)를 수행할 준비가 됩니다.If is_failover_ready = 1, the database is marked as synchronized in the cluster and is ready for a failover. 지정된 보조 복제본의 모든 데이터베이스에 대해 is_failover_ready 가 1이면 이 데이터 복제본에서 데이터 손실 없이 강제 장애 조치(failover)(FORCE_FAILOVER_ALLOW_DATA_LOSS)를 수행할 수 있습니다.If is_failover_ready = 1 on every database on a given secondary replica, you can perform a forced failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) without data loss on this secondary replica. 그러면 동기화된 보조 복제본이 주 역할에서 온라인 상태가 됩니다. 즉, 모든 데이터가 그대로 있는 상태에서 새로운 주 복제본이 됩니다.The synchronized secondary replica comes online in the primary role, that is, as the new primary replica, with all the data intact.

    is_failover_ready 가 0이면 데이터베이스가 클러스터에서 동기화된 상태로 표시되지 않고 계획된 수동 장애 조치(failover)를 수행할 준비가 되지 않습니다 .If is_failover_ready = 0, the database is not marked as synchronized in the cluster and is not ready for a planned manual failover. 호스트 보조 복제본으로 강제 장애 조치(failover)를 수행하면 이 데이터베이스에서 데이터가 손실됩니다.If you force failover to the host secondary replica, data will be lost on this database.

    참고

    보조 복제본으로 강제 장애 조치(failover)를 수행할 때 손실되는 데이터의 양은 주 복제본과 장애 조치 대상(failover) 간의 시간차에 의해 결정됩니다.When you force failover to a secondary replica, the amount of data loss will depend on how far the failover target is lagging behind the primary replica. 그러나 WSFC 클러스터에 쿼럼이 부족하거나 쿼럼이 강제로 적용된 경우에는 잠재적 데이터 손실 양을 평가할 수 없습니다.Unfortunately, when the WSFC cluster lacks quorum or quorum has been forced, you cannot assess the amount of potential data loss. 그러나 WSFC 클러스터가 정상 상태의 쿼럼을 다시 얻으면 잠재적 데이터 손실 추적을 시작할 수 있습니다.Note, however, that once the WSFC cluster regains a healthy quorum, you could begin to track potential data loss. 자세한 내용은 장애 조치(failover) 및 장애 조치(failover) 모드(Always On 가용성 그룹)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For more information, see "Tracking Potential Data Loss" in Failover and Failover Modes (Always On Availability Groups).

보안Security

사용 권한Permissions

가용성 그룹에 대한 ALTER AVAILABILITY GROUP 권한, CONTROL AVAILABILITY GROUP 권한, ALTER ANY AVAILABILITY GROUP 권한 또는 CONTROL SERVER 권한이 필요합니다.Requires ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.

SQL Server Management Studio 사용Using SQL Server Management Studio

강제 장애 조치(failover)를 수행하려면(데이터가 손실될 수 있음)To force failover (with possible data loss)

  1. 개체 탐색기에서, 장애 조치해야 할 가용성 그룹에서 역할이 SECONDARY 또는 RESOLVING인 복제본을 호스팅하는 서버 인스턴스에 연결하고 서버 트리를 확장합니다.In Object Explorer, connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over, and expand the server tree.

  2. Always On 고가용성 노드 및 가용성 그룹 노드를 확장합니다.Expand the Always On High Availability node and the Availability Groups node.

  3. 장애 조치할 가용성 그룹을 마우스 오른쪽 단추로 클릭하고 장애 조치(Failover) 명령을 선택합니다.Right-click the availability group to be failed over, and select the Failover command.

  4. 그러면 가용성 그룹 장애 조치(failover) 마법사가 시작됩니다.This launches the Failover Availability Group Wizard. 자세한 내용은 이 항목의 뒷부분에 나오는 가용성 그룹 장애 조치(Failover) 마법사 사용(SQL Server Management Studio)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For more information, see Use the Fail Over Availability Group Wizard (SQL Server Management Studio).

  5. 가용성 그룹을 강제로 장애 조치한 후 필요한 후속 단계를 완료합니다.After forcing an availability group to fail over, complete the necessary follow-up steps. 자세한 내용은 이 항목의 뒷부분에 있는 후속 작업: 강제 장애 조치(Failover) 후 필수 태스크를 참조하세요.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

Transact-SQL 사용Using Transact-SQL

강제 장애 조치(failover)를 수행하려면(데이터가 손실될 수 있음)To force failover (with possible data loss)

  1. 장애 조치해야 할 가용성 그룹에서 역할이 SECONDARY 또는 RESOLVING인 복제본을 호스팅하는 서버 인스턴스에 연결합니다.Connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that that needs to be failed over.

  2. 다음과 같은 ALTER AVAILABILITY GROUP 문을 사용합니다.Use the ALTER AVAILABILITY GROUP statement, as follows:

    ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSSALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

    여기서 group_name 은 가용성 그룹의 이름입니다.where group_name is the name of the availability group.

    다음 예에서는 AccountsAG 가용성 그룹을 로컬 보조 복제본으로 강제로 장애 조치(failover)합니다.The following example forces the AccountsAG availability group to fail over to the local secondary replica.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
    
  3. 가용성 그룹을 강제로 장애 조치한 후 필요한 후속 단계를 완료합니다.After forcing an availability group to fail over, complete the necessary follow-up steps. 자세한 내용은 이 항목의 뒷부분에 있는 후속 작업: 강제 장애 조치(Failover) 후 필수 태스크를 참조하세요.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

PowerShell 사용Using PowerShell

강제 장애 조치(failover)를 수행하려면(데이터가 손실될 수 있음)To force failover (with possible data loss)

  1. 장애 조치해야 할 가용성 그룹에서 역할이 SECONDARY 또는 RESOLVING인 복제본을 호스팅하는 서버 인스턴스로 디렉터리를 변경합니다(cd).Change directory (cd) to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that that needs to be failed over.

  2. Switch-SqlAvailabilityGroup cmdlet을 다음 형식 중 하나로 된 AllowDataLoss 매개 변수와 함께 사용합니다.Use the Switch-SqlAvailabilityGroup cmdlet with the AllowDataLoss parameter in one of the following forms:

    • -AllowDataLoss-AllowDataLoss

      기본적으로 -AllowDataLoss 매개 변수를 사용하면 Switch-SqlAvailabilityGroup 에서 강제 장애 조치(failover)를 수행하면 커밋되지 않은 트랜잭션이 손실될 수 있음을 알리고 확인을 요청하는 메시지가 나타납니다.By default -AllowDataLoss parameter causes Switch-SqlAvailabilityGroup to prompt you to remind you that forcing failover might result in the loss of uncommitted transactions and to request confirmation. 계속하려면 Y를 입력하고, 작업을 취소하려면 N을 입력합니다.To continue, enter Y; to cancel the operation, enter N.

      다음 예제에서는 MyAg 이라는 서버 인스턴스의 보조 복제본으로 가용성 그룹 SecondaryServer\InstanceName의 강제 장애 조치(failover)(데이터가 손실될 수 있음)를 수행합니다.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the secondary replica on the server instance named SecondaryServer\InstanceName. 이 작업을 확인하라는 메시지가 나타납니다.You will be prompted to confirm this operation.

      Switch-SqlAvailabilityGroup `  
         -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
         -AllowDataLoss  
      
    • -AllowDataLoss-Force-AllowDataLoss-Force

      확인하지 않고 강제 장애 조치(failover)를 시작하려면 -AllowDataLoss-Force 매개 변수를 모두 지정합니다.To initiate a forced failover without confirmation, specify both the -AllowDataLoss and -Force parameters. 이 작업은 명령을 스크립트에 포함시키고 사용자 상호 작용 없이 명령을 실행하려는 경우에 유용합니다.This is useful if you want to include the command in a script and run it without user interaction. 그러나 강제 장애 조치(Failover)를 수행하면 가용성 그룹에 참여하는 데이터베이스에서 데이터가 손실될 수 있으므로 -Force 옵션은 주의해서 사용해야 합니다.However, use the -Force option with caution, because a forced failover might result in the loss of data from databases participating the availability group.

      다음 예제에서는 MyAg 이라는 서버 인스턴스로 가용성 그룹 SecondaryServer\InstanceName의 강제 장애 조치(failover)(데이터가 손실될 수 있음)를 수행합니다.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the server instance named SecondaryServer\InstanceName. -Force 옵션을 사용하면 이 작업의 확인 메시지가 표시되지 않습니다.The -Force option suppresses confirmation of this operation.

      Switch-SqlAvailabilityGroup `  
         -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
         -AllowDataLoss -Force  
      

    참고

    cmdlet의 구문을 보려면 PowerShell 환경에서 Get-Help SQL ServerSQL Server cmdlet을 사용합니다.To view the syntax of a cmdlet, use the Get-Help cmdlet in the SQL ServerSQL Server PowerShell environment. 자세한 내용은 Get Help SQL Server PowerShell을 참조하세요.For more information, see Get Help SQL Server PowerShell.

  3. 가용성 그룹을 강제로 장애 조치한 후 필요한 후속 단계를 완료합니다.After forcing an availability group to fail over, complete the necessary follow-up steps. 자세한 내용은 이 항목의 뒷부분에 있는 후속 작업: 강제 장애 조치(Failover) 후 필수 태스크를 참조하세요.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

    SQL Server PowerShell 공급자를 설정하고 사용하려면To set up and use the SQL Server PowerShell provider

후속 작업: 강제 장애 조치(Failover) 후 필수 태스크Follow Up: Essential Tasks After a Forced Failover

  1. 강제 장애 조치 후 장애 조치한 보조 복제본은 새로운 주 복제본이 됩니다.After a forced failover, the secondary replica to which you failed over becomes the new primary replica. 그러나 해당 가용성 복제본이 클라이언트에 액세스할 수 있도록 하려면 다음과 같이 WSFC 쿼럼을 다시 구성하거나 가용성 그룹의 가용성 모드 구성을 조정해야 할 수 있습니다.However, to make that availability replica accessible to clients, you might need to reconfigure the WSFC quorum or adjust the availability-mode configuration of the availability group, as follows:

    • 자동 장애 조치(Failover) 설정automatic failover set 외부로 장애 조치(failover)한 경우: 새로운 가용성 그룹 구성을 반영하도록 WSFC 노드의 쿼럼 투표를 조정합니다.If you failed over outside of the 자동 장애 조치(Failover) 설정automatic failover set: Adjust the quorum votes of the WSFC nodes to reflect your new availability group configuration. 대상 보조 복제본을 호스팅하는 WSFC 노드에 WSFC 쿼럼 투표가 없는 경우 WSFC 쿼럼을 강제 적용해야 할 수 있습니다.If the WSFC node that hosts the target secondary replica does not have a WSFC quorum vote, you might need to force WSFC quorum.

      참고

      자동 장애 조치(Failover) 설정automatic failover set 는 자동 장애 조치(failover)를 사용하는 동기-커밋 모드에 대해 2개의 가용성 복제본(이전의 주 복제본 포함)이 구성된 경우에만 존재합니다.An 자동 장애 조치(Failover) 설정automatic failover set exists only if two availability replicas (including the previous primary replica) are configured for synchronous-commit mode with automatic failover.

      쿼럼 투표를 조정하려면To adjust quorum votes

    • 동기 커밋 장애 조치(Failover) 설정synchronous-commit failover set 외부에서 장애 조치(failover)한 경우: 원하는 동기-커밋 및 자동 장애 조치(failover) 구성을 반영하도록 새로운 주 복제본과 나머지 보조 복제본에서 가용성 모드와 장애 조치(failover) 모드를 조정하는 것이 좋습니다.If you failed over outside of the 동기 커밋 장애 조치(Failover) 설정synchronous-commit failover set: We recommend that you consider adjusting the availability mode and failover mode on the new primary replica and on remaining secondary replicas to reflect your desired synchronous-commit and automatic failover configuration.

      참고

      동기 커밋 장애 조치(Failover) 설정synchronous-commit failover set 은 현재 주 복제본이 동기-커밋 모드용으로 구성되어 있는 경우에만 존재합니다.A 동기 커밋 장애 조치(Failover) 설정synchronous-commit failover set exists only if the current primary replica is configured for synchronous-commit mode.

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

  2. 강제 장애 조치(failover) 후 모든 보조 데이터베이스가 일시 중지됩니다.After a forced failover, 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.

    재개된 보조 데이터베이스는 해당 주 데이터베이스와 데이터 동기화를 시작합니다.When a secondary database is resumed, it initiates data synchronization with the corresponding primary database. 보조 데이터베이스는 새로운 주 데이터베이스에서 커밋되지 않은 로그 레코드를 모두 롤백합니다.The secondary database rolls back any log records that were never committed on the new primary database. 따라서 사후 장애 조치(Post-failover) 주 데이터베이스에서 발생할 수 있는 데이터 손실이 우려되는 경우에는 동기 커밋 보조 데이터베이스 중 하나에서 일시 중지된 데이터베이스에 대한 데이터베이스 스냅숏을 만들어야 합니다.Therefore, if you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one of the synchronous-commit secondary databases.

    중요

    보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안에는 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다.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.

    데이터베이스 스냅숏을 만들려면To create a database snapshot

    주의

    모든 보조 데이터베이스를 재개한 후 그룹을 다시 장애 조치하기 전에 다음 장애 조치(failover) 대상의 모든 보조 데이터베이스가 SYNCHRONIZING 상태로 전환될 때까지 기다립니다.After resuming all the secondary databases, before attempting to fail over the group again, wait for every secondary database on the next failover target to enter the SYNCHRONIZING state. 데이터베이스가 아직 SYNCHRONIZING 상태가 아닌 경우 해당 데이터베이스는 주 데이터베이스로 온라인 상태가 될 수 없으며 데이터베이스에 대한 데이터 동기화를 다시 설정하려면 트랜잭션 로그를 복원하거나 전체 데이터베이스 백업을 복원하거나 다시 이전의 주 복제본으로 장애 조치해야 할 수 있습니다.If any database is not yet SYNCHRONIZING, that database will be prevented from coming online as a primary database, and re-establishing data synchronization for the database might require restoring transaction logs, restoring a full database backup, or failing over back to the previous primary replica.

  3. 실패한 가용성 복제본이 가용성 복제본으로 돌아가지 않거나 너무 늦게 돌아가서 새로운 주 데이터베이스에서 트랜잭션 로그 잘림을 지연시킬 수 없는 경우 가용성 그룹에서 오류 상태의 복제본을 제거하여 로그 파일에 사용할 디스크 공간이 부족하지 않도록 할 수 있습니다.If an availability replica that failed will not be returning to the availability replica or will return too late for you to delay transaction log truncation on the new primary database, consider removing the failed replica from the availability group to avoid running out of disk space for your log files.

    보조 복제본을 제거하려면To remove a secondary replica

  4. 하나 이상의 추가 강제 장애 조치(Failover)가 포함된 강제 장애 조치를 수행하는 경우 각 추가 강제 장애 조치 후 로그 백업을 수행합니다.If you follow a forced failover with one or more additional forced failovers, perform a log backup after each additional forced failover in the series. 그 이유에 대한 자세한 내용은 장애 조치(failover) 및 장애 조치(failover) 모드(Always On 가용성 그룹)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.For information about the reason for this, see "Risks of Forcing Failover" in the "Forced Manual Failover (with Possible Data Loss)" section of Failover and Failover Modes (Always On Availability Groups).

    로그 백업을 수행하려면To perform a log backup

예제 시나리오: 강제 장애 조치(Failover)를 사용하여 치명적인 오류 복구Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure

주 복제본이 실패하고 사용할 수 있는 동기화된 보조 복제본이 없는 경우 가용성 그룹을 강제 장애 조치(failover)하는 것이 적절한 대처 방법이 될 수 있습니다.If the primary replica fails and no synchronized secondary replica is available, forcing the availability group to fail over might be an appropriate response. 강제 장애 조치(failover)의 적합성은 (1) SLA(서비스 수준 계약)에서 허용하는 기간보다 오랫동안 주 복제본이 오프라인 상태가 될 것으로 예상되는지 여부와 (2) 주 데이터베이스를 빨리 사용 가능하게 하기 위해 잠재적인 데이터 손실 위험을 감수할지 여부에 따라 결정됩니다.The appropriateness of forcing a failover depends on: (1) whether you expect the primary replica to be offline for longer than your service level agreement (SLA) tolerates, and (2) whether you are willing to risk potential data loss in order to make primary databases available quickly. 가용성 그룹을 강제 장애 조치(failover)해야 한다고 판단되는 경우 실제 강제 장애 조치(failover)는 여러 단계 프로세스 중 한 단계일 뿐입니다.If you decide that an availability group requires a forced failover, the actual forced failover is but one step of a multi-step process.

이 항목에서는 강제 장애 조치(failover)를 사용하여 치명적인 오류를 복구하는 데 필요한 단계를 보여 주기 위해 가능한 재해 복구 시나리오를 제공합니다.To illustrate the steps that are required to use a forced failover to recover from a catastrophic failure, this topic presents one possible disaster recovery scenario. 예제 시나리오에서는 원래 토폴로지가 주 복제본을 비롯한 세 개의 동기 커밋 가용성 복제본을 호스팅하는 기본 데이터 센터와 두 개의 동기 커밋 보조 복제본을 호스팅하는 원격 데이터 센터로 구성된 가용성 그룹을 고려합니다.The example scenario considers an availability group whose original topology consists of a main data center that hosts three synchronous-commit availability replicas, including the primary replica, and a remote data center that hosts two asynchronous-commit secondary replicas. 다음 그림에서는 이 예제 가용성 그룹의 원래 토폴로지를 보여 줍니다.The following figure illustrates the original topology of this example availability group. 가용성 그룹은 기본 데이터 센터에 세 개의 노드(노드 01, 노드 02노드 03)가 있고 원격 데이터 센터에 두 개의 노드(노드 04노드 05)가 있는 다중 서브넷 WSFC 클러스터에 의해 호스트됩니다.The availability group is hosted by a multi-subnet WSFC cluster with three nodes in the main data center (Node 01, Node 02, and Node 03) and two nodes in a remote data center (Node 04 and Node 05).

가용성 그룹의 원래 토폴로지Original topology of availability group

기본 데이터 센터가 예기치 않게 종료됩니다.The main data center shuts down unexpectedly. 기본 데이터 센터의 세 가용성 복제본이 오프라인 상태가 되고 해당 데이터베이스를 사용할 수 없게 됩니다.Its three availability replicas to go offline, and their databases become unavailable. 다음 그림에서는 이 장애가 가용성 그룹의 토폴로지에 주는 영향을 보여 줍니다.The following figure illustrates the impact of this failure on the topology of the availability group.

기본 데이터 센터의 장애 발생 후 토폴로지Topology after failure of main data center

DBA(데이터베이스 관리자)는 가용성 그룹을 원격 비동기 커밋 보조 복제본 중 하나로 강제 장애 조치(failover)하는 것이 가능한 최고의 대처 방법이라고 결정합니다.The database administrator (DBA) determines that the best possible response is to force failover of the availability group to one of the remote, asynchronous-commit secondary replicas. 이 예제에서는 가용성 그룹을 원격 복제본으로 강제 장애 조치(failover)하고 가용성 그룹을 원래 토폴로지로 돌려 놓는 경우와 관련된 일반적인 단계를 보여 줍니다.This example illustrates the typical steps involved when you force failover of the availability group to a remote replica and, eventually, return the availability group to its original topology.

여기에 제시된 실패 응답은 다음과 같은 두 단계로 구성되어 있습니다.The failure-response presented here consists of the following two phases:

Responding to the Catastrophic Failure of the Main Data CenterResponding to the Catastrophic Failure of the Main Data Center

다음 그림에서는 기본 데이터 센터에서의 치명적 오류에 대한 응답으로 원격 데이터 센터에서 수행되는 일련의 동작을 보여 줍니다.The following figure illustrates the series of actions performed at the remote data center in response a catastrophic failure at the main data center.

기본 데이터 센터의 장애에 대응하기 위한 단계Steps for responding to failure of main data cente

이 그림의 단계는 다음 단계를 나타냅니다.The steps in this figure indicate the following steps:

단계Step 동작Action 링크Links
1.1. DBA 또는 네트워크 관리자는 WSFC 클러스터가 정상 쿼럼인지 확인합니다.The DBA or network administrator ensures that the WSFC cluster has a healthy quorum. 이 예제에서는 쿼럼을 강제 실행해야 합니다.In this example, quorum needs to be forced. WSFC 쿼럼 모드 및 투표 구성(SQL Server)WSFC Quorum Modes and Voting Configuration (SQL Server)

강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)
2.2. DBA는 노드 04에서 최소 대기 시간을 사용하여 서버 인스턴스에 연결하고 강제 수동 장애 조치(failover)를 수행합니다.The DBA connects to the server instance with the least latency (on Node 04) and performs a forced manual failover. 강제 장애 조치(failover)는 이 보조 복제본을 주 역할로 전환하고 나머지 보조 복제본( 노드 05)에서 보조 데이터베이스를 일시 중지합니다.The forced failover transitions this secondary replica to the primary role and suspends the secondary databases on the remaining secondary replica (on Node 05). sys.dm_hadr_database_replica_states(Transact-SQL) ( sys.dm_hadr_database_replica_states 열을 쿼리합니다.sys.dm_hadr_database_replica_states (Transact-SQL) (Query the end_of_log_lsn column. 자세한 내용은 이 항목의 앞부분에 나오는 권장 사항을 참조하세요.)For more information, see Recommendations, earlier in this topic.)
3.3. DBA는 수동으로 나머지 보조 복제본에서 보조 데이터베이스를 재개합니다.The DBA manually resumes each of the secondary databases on the remaining secondary replica. 가용성 데이터베이스 재개(SQL Server)Resume an Availability Database (SQL Server)

가용성 그룹을 원래 토폴로지로 복귀Returning the Availability Group to its Original Topology

다음 그림에서는 기본 데이터 센터가 다시 온라인 상태가 되고 WSFC 노드가 WSFC 클러스터와의 통신을 다시 설정한 후 가용성 그룹을 원래 토폴로지로 돌려 놓는 일련의 동작을 보여 줍니다.The following figure illustrates the series of actions that return the availability group to its original topology after the main data center comes back online and the WSFC nodes re-establish communication with the WSFC cluster.

중요

WSFC 클러스터 쿼럼을 강제 적용하는 경우 오프라인 노드가 다시 시작될 때 다음 조건에 모두 부합하면 오프라인 노드가 새 쿼럼을 형성할 수 있습니다. (a) 강제 쿼럼 집합의 노드 간에 네트워크 연결이 없는 경우 (b) 다시 시작되는 노드가 대부분 클러스터 노드인 경우.If the WSFC cluster quorum has been forced, as the offline nodes restart they could form a new quorum if the following conditions both exist: (a) there is no network connectivity between any of the nodes in the forced-quorum set, and (b) the restarting nodes are the majority of the cluster nodes. 이 경우 가용성 그룹에 두 개의 독립적인 주 복제본(각 데이터 센터에 하나씩)이 있는 "분리 장애(split-brain)"가 발생합니다.This would result in a "split brain" condition in which the availability group would possess two independent primary replicas, one at each data center. 쿼럼을 강제 실행하여 소수 쿼럼 집합을 만들기 전에 강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)의 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다.Before forcing quorum to create a minority quorum set, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

그룹을 원래 토폴로지로 복귀하는 단계Steps to return the group to its original topology

이 그림의 단계는 다음 단계를 나타냅니다.The steps in this figure indicate the following steps:

단계Step 링크Links
1.1. 기본 데이터 센터의 노드가 다시 온라인 상태가 되고 WSFC 클러스터와의 통신을 다시 설정합니다.The nodes in the main data center come back online and re-establish communication with the WSFC cluster. 해당 가용성 복제본이 일시 중지된 데이터베이스가 있는 보조 복제본으로 온라인 상태가 되고 DBA가 곧 이 데이터베이스를 각각 수동으로 재개해야 합니다.Their availability replicas come online as secondary replicas with suspended databases, and the DBA will need to manually resume each of these databases soon. 가용성 데이터베이스 재개(SQL Server)Resume an Availability Database (SQL Server)

팁: 사후 장애 조치(failover) 주 데이터베이스에서 데이터가 손실될 가능성이 있는 경우에는 동기 커밋 보조 데이터베이스 중 하나에서 일시 중지된 데이터베이스에 대한 데이터베이스 스냅숏을 만들어야 합니다.Tip: If you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one the synchronous-commit secondary database. 보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안에는 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다.Keep in mind that the transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. 또한 일시 중지된 상태로 남아 있는 로컬 데이터베이스가 있으면 동기 커밋 보조 복제본의 동기화 상태가 정상으로 전환될 수 없습니다.Also the synchronization health of the synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.
2.2. 데이터베이스를 재개하면 DBA가 새 주 복제본을 동기 커밋 모드로 일시적으로 변경합니다.Once the databases are resumed, the DBA changes the new primary replica to synchronous-commit mode temporarily. 여기에는 다음 두 단계가 포함됩니다.This involves two steps:

1) 오프라인 가용성 복제본 하나를 비동기 커밋 모드로 변경합니다.1) Change one offline availability replica to asynchronous-commit mode.

2) 새 주 복제본을 동기 커밋 가용성 모드로 변경합니다.2) Change the new primary replica to synchronous-commit mode. 참고: 이 단계에서는 다시 시작된 동기 커밋 보조 데이터베이스를 동기화된 상태로 설정할 수 있습니다.Note: This step enables resumed synchronous-commit secondary databases to become SYNCHRONIZED.
가용성 복제본의 가용성 모드 변경(SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)
3.3. 노드 03 (원래 주 복제본)에서 동기 커밋 보조 복제본이 정상 동기화 상태가 되면 DBA는 해당 복제본에 대해 계획된 수동 장애 조치(failover)를 수행하여 다시 주 복제본이 되도록 합니다.Once the synchronous-commit secondary replica on Node 03 (the original primary replica) enters the HEALTHY synchronization state, the DBA performs a planned manual failover to that replica, to make it the primary replica again. 노드 04 의 복제본은 보조 복제본으로 돌아갑니다.The replica on Node 04 returns to being a secondary replica. sys.dm_hadr_database_replica_states(Transact-SQL)sys.dm_hadr_database_replica_states (Transact-SQL)

Always On 정책을 사용하여 가용성 그룹의 상태 보기(SQL Server)Use Always On Policies to View the Health of an Availability Group (SQL Server)

가용성 그룹의 계획된 수동 장애 조치(Failover) 수행(SQL Server)Perform a Planned Manual Failover of an Availability Group (SQL Server)
4.4. DBA는 새 주 복제본에 연결하고 다음 작업을 수행합니다.The DBA connects to the new primary replica and:

1) 원격 센터의 이전 주 복제본을 다시 비동기 커밋 모드로 변경합니다.1) Changes the former primary replica (in the remote center) back to asynchronous-commit mode.

2) 기본 데이터 센터의 비동기 커밋 보조 복제본을 다시 동기 커밋 모드로 변경합니다.2) Changes the asynchronous-commit secondary replica in the main data center back to synchronous-commit mode.
가용성 복제본의 가용성 모드 변경(SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)

관련 태스크Related Tasks

쿼럼 투표를 조정하려면To adjust quorum votes

관련 내용Related Content

참고 항목See Also

Always On 가용성 그룹 개요(SQL Server) Overview of Always On Availability Groups (SQL Server)
가용성 모드(Always On 가용성 그룹) Availability Modes (Always On Availability Groups)
장애 조치 및 장애 조치 모드(Always On 가용성 그룹) Failover and Failover Modes (Always On Availability Groups)
가용성 복제본에 대한 클라이언트 연결 액세스 정보(SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
가용성 그룹 모니터링(SQL Server) Monitoring of Availability Groups (SQL Server)
SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)Windows Server Failover Clustering (WSFC) with SQL Server