데이터베이스 미러링 세션 중 역할 전환(SQL Server)Role Switching During a Database Mirroring Session (SQL Server)

이 항목 적용 대상: 예SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse 데이터베이스 미러링 세션에서는 역할 전환 프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다. Within the context of a database mirroring session, the principal and mirror roles are typically interchangeable in a process known as role switching. 역할 전환 시 미러 서버는 주 서버에 대한 장애 조치(Failover) 파트너 역할을 하며 주 역할을 넘겨 받아 해당 데이터베이스 복사본을 복원하고 새로운 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다.In role switching, the mirror server acts as the failover partner for the principal server, taking over the principal role, recovering its copy of the database and bringing it online as the new principal database. 이전 주 서버는 가능할 경우 미러 서버 역할을 맡으며 이 서버의 데이터베이스는 새 미러 데이터베이스가 됩니다.The former principal server, when available, assumes the mirror role, and its database becomes the new mirror database. 여러 오류에 대한 응답이나 관리 용도로 역할이 전환될 수 있습니다.Potentially, the roles can switch back and forth either in response to multiple failures or for administrative purposes.

참고

이 항목에서는 사용자가 데이터베이스 미러링 운영 모드에 대해 잘 알고 있다고 가정합니다.This topic assumes that you are familiar with the database mirroring operating modes. 자세한 내용은 Database Mirroring Operating Modes을 참조하세요.For more information, see Database Mirroring Operating Modes.

다음 그림에서는 일련의 자동 또는 수동 장애 조치를 수행하는 동안 주 역할과 미러 역할을 전환하는 미러링 파트너 Partner_APartner_B를 보여 줍니다.The following illustration shows mirroring partners, Partner_A and Partner_B, switching the principal and mirror roles over a series of automatic or manual failovers.

역할 간에 두 번 전환하는 파트너Partners switching twice between roles

중요

역할 전환 후 이전 주 데이터베이스에서 실행하던 작업을 새로운 주 데이터베이스에서 다시 만들어 실행해야 합니다.After a role switch, jobs that ran on the former principal database must be recreated on the new principal server to run there. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.For more information, see Management of Logins and Jobs After Role Switching (SQL Server).

역할 전환에는 자동 장애 조치(failover), 수동 장애 조치(failover) 및 강제 서비스(데이터 손실 가능)의 3가지 유형이 있습니다.Three types of role switching exist: automatic failover, manual failover, and forced service (with possible data loss). 각 유형에 대한 지원은 세션의 운영 모드에 따라 달라집니다.Support for each form depends on the operating mode of the session.

참고

이러한 운영 모드에 대한 자세한 내용은 데이터베이스 미러링 운영 모드을 참조하세요.If you are unfamiliar with these operating modes, see Database Mirroring Operating Modes.

  • 수동 장애 조치(Failover)Manual failover

    보안 우선 모드는 수동 장애 조치를 지원합니다.High-safety mode supports manual failover. 데이터베이스 소유자는 데이터베이스가 동기화될 때마다 수동 장애 조치를 시작할 수 있습니다.Whenever the database is synchronized, the database owner can initiate a manual failover.

    수동 장애 조치는 관리 목적으로 제공됩니다.Manual failover is provided for administrative purposes. 자세한 내용은 이 항목의 뒷부분에 나오는 수동 장애 조치(failover)를 참조하십시오.For more information, see Manual Failover, later in this topic.

  • 자동 장애 조치(Failover)Automatic failover

    미러링 모니터 서버가 있는 경우 보안 우선 모드에서 자동 장애 조치가 지원됩니다.In the presence of a witness, high-safety mode supports automatic failover. 자동 장애 조치는 미러링 모니터 서버와 미러 서버가 서로 연결되어 있고 데이터베이스가 이미 동기화된 경우 주 서버가 손실될 때에만 수행됩니다.Automatic failover occurs only on the loss of the principal server when the witness and mirror server are still connected to each other and the database is already synchronized. 자세한 내용은 이 항목의 뒷부분에 나오는 자동 장애 조치(failover)를 참조하십시오.For more information, see Automatic Failover, later in this topic.

  • 강제 서비스(데이터 손실 가능)Forced service (with possible data loss)

    강제 서비스는 미러링 모니터 서버가 설정되어 있지 않은 보안 우선 모드와 성능 우선 모드에서 지원됩니다.Forcing service is supported in high-safety mode when no witness is set and in high-performance mode. 주 서버를 손실한 경우 데이터베이스 소유자는 데이터베이스를 사용할 수 있도록 미러 서버에 서비스를 강제 적용할 수 있으며 이 경우 데이터가 손실될 수 있습니다.On the loss of the principal server, the database owner can make the database available by forcing service to the mirror server (with possible data loss).

    참고

    성능 우선 모드에서는 WITNESS 속성을 OFF로 설정하는 것이 좋습니다.We recommend that the WITNESS property be set to OFF in high-performance mode. 그렇지 않으면 데이터베이스를 온라인 상태로 만들려는 경우 미러 서버가 미러링 모니터에 연결해야 합니다.Otherwise, to bring the database online, the mirror server must connected to the witness.

    자세한 내용은 이 항목의 뒷부분에 나오는 강제 서비스(데이터 손실 가능)를 참조하세요.For more information, see Forced Service (with Possible Data Loss), later in this topic.

    다음 표에서는 각 운영 모드에서 지원되는 장애 조치 유형을 요약합니다.The following table summarizes which forms of failover are supported under each of the operating modes.

성능 우선High performance 미러링 모니터 서버가 없는 보안 우선 모드High-safety mode without a witness 미러링 모니터 서버가 있는 보안 우선 모드High-safety mode with a witness
자동 장애 조치(Failover)Automatic failover 아니요No 아니요No Yes
수동 장애 조치(Failover)Manual failover 아니요No Yes Yes
강제 서비스Forced service Yes Yes 아니요No

역할 전환 후 모든 데이터베이스 사용자가 새로운 주 데이터베이스에 액세스할 수 있게 하려면 특정 메타데이터가 두 파트너에 모두 있어야 합니다.After a role switch, certain metadata must exist on both partners to ensure that all of the database users can access the new principal database. 또한 데이터베이스가 정기적인 일정에 따라 계속 백업되게 하려면 새로운 주 서버에서 백업 작업을 만들어야 합니다.In addition, backup jobs must be created on the new principal server, to ensure that the database continues to be backed up on its regular schedule. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.For more information, see Management of Logins and Jobs After Role Switching (SQL Server).

역할 전환 중에 데이터베이스 미러링의 서비스가 중단되는 시간은 역할 전환의 유형 및 원인에 따라 달라집니다.During a role switch, the amount of time that database mirroring will be out of service depends on the type of role switching and on the cause. 자세한 내용은 역할 전환 중 서비스 중단 예측(데이터베이스 미러링)프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다.For more information, see Estimate the Interruption of Service During Role Switching (Database Mirroring).

Manual FailoverManual Failover

수동 장애 조치(Failover)는 데이터베이스에서 클라이언트의 연결을 끊고 파트너의 역할을 반대로 바꿉니다.Manual failover disconnects the clients from the database and reverses the roles of the partners. 이러한 수동 장애 조치는 보호 우선 모드에서만 지원됩니다.Only high-safety mode supports manual failover.

섹션 내용In This Section:

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

데이터베이스 관리자는 수동 장애 조치를 사용하여 가용성에 영향을 주지 않고 하드웨어 또는 소프트웨어를 업그레이드할 수 있습니다.The database administrator can use manual failover for upgrading hardware or software without sacrificing availability. 소프트웨어 업그레이드 시 데이터베이스 미러링을 사용하려면 미러 서버 및/또는 시스템에 이미 해당 업그레이드가 있어야 합니다.To use database mirroring for software upgrades, the mirror server and/or system must have already received the upgrades.

참고

데이터베이스 미러링에서 롤링 업그레이드를 수행할 수도 있지만 이 기능은 이후 변경 내용을 알 수 없으므로 보장되지 않습니다.Database mirroring should be able to do a rolling upgrade, but this is not guaranteed, because future changes are unknown. 자세한 내용은 Upgrading Mirrored Instances을 참조하세요.For more information, see Upgrading Mirrored Instances.

다음 그림에서는 데이터베이스 서버 인스턴스를 업그레이드하는 동안 데이터베이스 가용성을 유지하기 위해 수동 장애 조치를 사용하는 예를 설명합니다.The following figure illustrates an instance of using manual failover to maintain database availability while you upgrade a database server instance. 업그레이드가 완료되면 관리자는 필요에 따라 원래 서버 인스턴스로 장애 조치를 수행할 수 있습니다.When the upgrade is completed, an administrator may optionally fail over back to the original server instance. 이는 관리자가 미러링 세션을 중지하고 미러 서버를 다른 곳에서 사용하려는 경우에 유용합니다.This is useful when the administrator wants to stop the mirroring session and use the mirror server elsewhere. 이러한 방법으로 일련의 데이터베이스 서버 인스턴스를 업데이트할 때 단일 서버 인스턴스를 반복적으로 사용할 수 있습니다.In this way, a single server instance can be used repeatedly when updating a series of database server instances.

계획된 수동 장애 조치Planned manual failover

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

수동 장애 조치를 수행하려면 트랜잭션 보안이 FULL(보호 우선 모드)로 설정되어야 합니다.Manual failover requires transaction safety to be set to FULL (that is, high-safety mode). 파트너가 연결되어 있으며 데이터베이스가 이미 동기화된 경우 수동 장애 조치가 지원됩니다.When the partners are connected and the database is already synchronized, manual failover is supported.

수동 장애 조치 작동 방법How Manual Failover Works

수동 장애 조치의 동작 순서는 다음과 같습니다.Manual failover initiates the following sequence of actions:

  1. 주 서버는 주 데이터베이스에서 클라이언트의 연결을 끊고 비상 로그를 미러 서버로 보낸 다음 미러 역할로 전환하기 위해 미러링 상태를 SYNCHRONIZING으로 설정합니다.The principal server disconnects clients from the principal database, sends the tail of the log to the mirror server, and, in preparation for switching to the mirror role, sets the mirroring state to SYNCHRONIZING.

  2. 미러 서버는 주 서버에서 받은 마지막 로그 레코드의 LSN(로그 시퀀스 번호)을 장애 조치 LSN으로 기록합니다.The mirror server records the log sequence number (LSN) of the last log record received from the principal as the failover LSN.

    참고

    이 LSN을 보려면 sys.database_mirroring(Transact-SQL)에서 mirroring_failover_lsn 열을 선택합니다.To view this LSN, select the mirroring_failover_lsn column from sys.database_mirroring (Transact-SQL).

  3. Redo Queue에서 대기 중인 로그가 있으면 미러 서버가 미러 데이터베이스의 롤포워드를 마칩니다.If any log is waiting in the redo queue, the mirror server finishes rolling forward the mirror database. 소요 시간은 시스템 속도, 최근 작업 및 Redo Queue에 있는 로그 양에 따라 달라집니다.The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the redo queue. 동기 운영 모드의 경우 Redo Queue의 크기를 제한하여 장애 조치 시간을 조정할 수 있습니다.For a synchronous operating mode, the failover time can be regulated by limiting the size of the redo queue. 그러나 이 경우 미러 서버에서 동기화 상태를 계속 유지해야 하므로 주 서버의 속도가 느려질 수 있습니다.However, this can cause the principal server to slow down to allow the mirror server to keep up.

    참고

    Redo Queue의 현재 크기를 확인하려면 데이터베이스 미러링 성능 개체의 Redo Queue 성능 카운터를 사용합니다. 자세한 내용은 데이터베이스 미러링 모니터링(SQL Server)을 참조하세요.To learn the current size of the redo queue, use the Redo Queue performance counter in the database mirroring performance object (for more information, see Monitoring Database Mirroring (SQL Server)).

  4. 미러 서버는 새 주 서버가 되고 이전 주 서버는 새 미러 서버가 됩니다.The mirror server becomes the new principal server, and the former principal server becomes the new mirror server.

  5. 새 주 서버는 커밋되지 않은 모든 트랜잭션을 롤백하고 해당 데이터베이스의 복사본을 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다.The new principal server rolls back any uncommitted transactions and brings its copy of the database online as the principal database.

  6. 이전 주 서버가 미러 역할을 맡아 이전 주 데이터베이스가 미러 데이터베이스가 됩니다.The former principal takes on the mirror role, and the former principal database becomes the mirror database. 새 미러 서버는 신속하게 새 미러 데이터베이스를 새 주 데이터베이스와 다시 동기화합니다.The new mirror server quickly resynchronizes the new mirror database with the new principal database.

    참고

    새 미러 서버에서 데이터베이스를 다시 동기화하면 장애 조치가 다시 가능해지지만 역방향으로 진행됩니다.As soon as the new mirror server has resynchronized the databases, failover is again possible, but in the reverse direction.

    장애 조치 후 클라이언트는 현재의 주 데이터베이스에 다시 연결해야 합니다.After failover, clients must reconnect to the current principal database. 자세한 내용은 데이터베이스 미러링 세션에 클라이언트 연결(SQL Server)프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다.For more information, see Connect Clients to a Database Mirroring Session (SQL Server).

    수동 장애 조치를 시작하려면To initiate manual failover

Automatic FailoverAutomatic Failover

자동 장애 조치(failover)는 미러링 모니터 서버에서 보호 우선 모드(자동 장애 조치(failover)를 지원하는 보호 우선 모드)로 실행되는 데이터베이스 미러링 세션에서만 지원됩니다.Automatic failover is supported only in database mirroring sessions running with a witness in high-safety mode (high-safety mode with automatic failover). 자동 장애 조치를 지원하는 보호 우선 모드에서 데이터베이스가 동기화된 후 주 데이터베이스를 사용할 수 없게 되면 자동 장애 조치가 수행됩니다.In high-safety mode with automatic failover, once the database is synchronized, if the principal database becomes unavailable, an automatic failover occurs. 자동 장애 조치가 수행되면 미러 서버가 주 서버의 역할을 맡고 해당 데이터베이스의 복사본이 주 데이터베이스로 온라인 상태가 됩니다.An automatic failover causes the mirror server to take over the role of principal server and bring its copy of the database online as the principal database. 데이터베이스가 동기화되어야 한다는 점에서 주 데이터베이스에서 커밋된 모든 트랜잭션이 미러 데이터베이스에서도 커밋되기 때문에 장애 조치 중에 데이터 손실이 방지됩니다.Requiring that the database be synchronized prevents data loss during failover, because every transaction committed on the principal database is also committed on the mirror database.

중요

자동 장애 조치로 안정성을 개선하려면 미러 데이터베이스와 주 데이터베이스가 서로 다른 컴퓨터에 있어야 합니다.For automatic failover to improve reliability, the mirror and principal databases must reside on different computers.

섹션 내용In This Section:

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

자동 장애 조치(Failover)에는 다음 조건이 필요합니다.Automatic failover requires the following conditions:

  • 데이터베이스 미러링 세션이 보호 우선 모드로 실행되고 있어야 하고 미러링 모니터 서버가 있어야 합니다.The database mirroring session must be running in high-safety mode and must possess a witness. 자세한 내용은 Database Mirroring Operating Modes을 참조하세요.For more information, see Database Mirroring Operating Modes.

  • 미러 데이터베이스가 이미 동기화된 상태여야 합니다.The mirror database must already be synchronized. 이는 미러 서버로 보낸 모든 로그가 디스크에 기록되었음을 나타냅니다.This guarantees that all of the log sent to the mirror server has been written to disk.

  • 데이터베이스 미러링 구성의 나머지 부분과 주 서버 간의 통신이 끊어졌지만 미러 서버와 미러링 모니터 서버는 쿼럼을 유지합니다.The principal server has lost communication with the rest of the database mirroring configuration, while the mirror and witness retain quorum. 그러나 모든 서버 인스턴스의 통신이 끊어지고 나중에 미러링 모니터 서버와 미러 서버에서 통신을 회복한 경우에는 자동 장애 조치가 수행되지 않습니다.If all server instances lose communication, however, and the witness and the mirror server later regain communication, automatic failover does not occur.

  • 미러 서버에서 주 서버가 손실된 것을 감지했습니다.The mirror server has detected the loss of the principal server.

    미러 서버에서 주 서버의 오류를 감지하는 방법은 하드 오류인지 또는 소프트 오류인지에 따라 달라집니다.How the mirror server detects a failure of the principal server depends on whether it is a hard or soft failure. 자세한 내용은 Possible Failures During Database Mirroring을 참조하세요.For more information, see Possible Failures During Database Mirroring.

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

위의 조건 하에서 자동 장애 조치는 다음과 같은 일련의 동작을 시작합니다.Under the preceding conditions, automatic failover initiates the following sequence of actions:

  1. 주 서버가 계속 실행되고 있으면 주 데이터베이스의 상태를 DISCONNECTED로 변경하고 주 데이터베이스로부터 모든 클라이언트의 연결을 끊습니다.If the principal server is still running, it changes the state of the principal database to DISCONNECTED and disconnects all clients from the principal database.

  2. 미러링 모니터 서버와 미러 서버가 주 서버를 사용할 수 없다고 등록합니다.The witness and mirror servers register that the principal server is unavailable.

  3. Redo Queue에서 대기 중인 로그가 있으면 미러 서버가 미러 데이터베이스의 롤포워드를 마칩니다.If any log is waiting in the redo queue, the mirror server finishes rolling forward the mirror database.

    참고

    로그를 적용하는 데 필요한 시간은 시스템 속도, 최근 작업 및 Redo Queue에 있는 로그 양에 따라 달라집니다.The amount of time required to apply the log depends on the speed of the system, the recent work load, and the amount of log in the redo queue.

  4. 이전의 미러 데이터베이스는 새로운 주 데이터베이스로 사용할 수 있도록 온라인 상태로 변경되고 복구 작업은 가능한 빨리 커밋되지 않은 모든 트랜잭션을 롤백하여 정리합니다.The former mirror database moves online as the new principal database, and recovery cleans up all uncommitted transactions by rolling them back as quickly as possible. 이러한 트랜잭션은 잠금에 의해 격리됩니다.Locks isolate those transactions.

  5. 이전의 주 서버는 세션에 다시 참가할 때 해당 장애 조치 파트너가 이제 주 역할을 소유함을 인식합니다.When the former principal server rejoins the session, it recognizes that its failover partner now owns the principal role. 이전의 주 서버는 데이터베이스를 미러 데이터베이스로 만들어 미러 역할을 수행하게 됩니다.The former principal server takes on the role of mirror, making its database the mirror database. 새 미러 서버는 가능한 빨리 새 미러 데이터베이스를 주 데이터베이스와 동기화합니다.The new mirror server synchronizes the new mirror database with the principal database as quickly as possible. 새 미러 서버에서 데이터베이스를 다시 동기화하면 장애 조치가 다시 가능해지지만 역방향으로 진행됩니다.As soon as the new mirror server has resynchronized the databases, failover is again possible, but in the reverse direction.

    다음 그림에서는 자동 장애 조치의 단일 인스턴스를 보여 줍니다.The following illustration shows a single instance of automatic failover.

    자동 장애 조치(Failover)Automatic failover

    처음에는 세션에 전체 쿼럼이 있으며 세 서버가 모두 연결되어 있습니다.Initially, all three servers are connected (the session has full quorum). Partner_A 는 주 서버이고 Partner_B 는 미러 서버입니다.Partner_A is the principal server and Partner_B is the mirror server. 먼저Partner_A (또는 Partner_A의 주 데이터베이스)를 사용할 수 없게 됩니다.Partner_A (or the principal database on Partner_A) becomes unavailable. 미러링 모니터 서버와 Partner_B 에서 주 서버를 더 이상 사용할 수 없다는 것을 인식하고 세션이 쿼럼을 유지합니다.The witness and Partner_B both recognize that the principal is no longer available the session retains quorum. Partner_B 가 주 서버가 되고 해당 데이터베이스 복사본을 새로운 주 데이터베이스로 사용할 수 있도록 만듭니다.Partner_B becomes the principal server and makes its copy of the database available as the new principal database. 마지막으로 Partner_A 가 세션에 다시 연결되고 Partner_B 가 주 역할을 담당하고 있음을 확인합니다.Eventually, Partner_A reconnects to the session and discovers that Partner_B now owns the principal role. 그런 다음Partner_A 는 미러 역할을 수행합니다.Partner_A then takes on the mirror role.

    장애 조치 후 클라이언트는 현재의 주 데이터베이스에 다시 연결해야 합니다.After failover, clients must reconnect to the current principal database. 자세한 내용은 데이터베이스 미러링 세션에 클라이언트 연결(SQL Server)프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다.For more information, see Connect Clients to a Database Mirroring Session (SQL Server).

참고

MicrosoftMicrosoft DTC(Distributed Transaction Coordinator)를 사용하여 트랜잭션을 준비했지만 장애 조치가 발생했을 때 커밋되지 않은 트랜잭션은 데이터베이스에 장애 조치를 취한 다음 중단된 것으로 간주됩니다.Transactions that have been prepared using the MicrosoftMicrosoft Distributed Transaction Coordinator but are still not committed when a failover occurs, are considered aborted after the database has failed over.

자동 장애 조치(failover)를 해제하려면(SQL Server Management Studio)To Disable Automatic Failover (SQL Server Management Studio)

데이터베이스 속성 미러링 페이지를 열고 다음 옵션 중 하나를 선택하여 운영 모드를 변경합니다.Open the Database PropertiesMirroring page, and change the operating mode by selecting one of the following options:

  • 자동 장애 조치(Failover)가 없는 보호 우선(동기)High safety without automatic failover (synchronous)

    이 모드에서 데이터베이스는 계속 동기화되지만 수동으로 장애 조치를 수행할 수 있습니다.In this mode, the database continues to be synchronized, and manual failover remains possible.

  • 성능 우선(비동기)High performance (asynchronous)

    이 모드에서는 미러 데이터베이스가 주 데이터베이스보다 지연될 수 있으며 수동 장애 조치를 수행할 수 없습니다.In this mode, the mirror database might lag somewhat behind the principal database, and manual failover is no longer possible.

자동 장애 조치를 해제하려면(Transact-SQL 사용)To Disable Automatic Failover (Using Transact-SQL)

데이터베이스 미러링 세션의 특정 시점에서 데이터베이스 소유자는 미러링 모니터를 해제하여 자동 장애 조치를 해제할 수 있습니다.At any point in a database mirroring session, the database owner can disable automatic failover by turning off the witness.

미러링 모니터 해제To turn off the witness

Forced Service (with Possible Data Loss)Forced Service (with Possible Data Loss)

데이터베이스 미러링은 미러 서버를 웜 대기 서버로 사용할 수 있는 강제 서비스(데이터 손실 가능)를 재해 복구 방법으로 제공합니다.Database mirroring provides forcing service (with possible data loss) as a disaster recovery method to allow you to use a mirror server as a warm standby server. 미러링 세션에서 주 서버가 미러 서버와 연결이 끊긴 경우에만 서비스를 강제 적용할 수 있습니다.Forcing service is possible only if the principal server is disconnected from the mirror server in a mirroring session. 서비스를 강제 적용하면 데이터가 손실될 수 있으므로 반드시 필요한 경우에만 주의해서 사용해야 합니다.Because forcing service risks possible data loss, it should be used cautiously and sparingly.

강제 서비스 지원은 세션의 운영 모드와 상태에 따라 다음과 같이 달라집니다.Support for forced service depends on the operating mode and the state of the session, as follows:

  • 일반적으로 성능 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다.Typically, high-performance mode supports forcing service whenever the principal server is disconnected. 그러나 필요한 것은 아니지만 성능 우선 모드 세션에 미러링 모니터 서버가 있을 수 있습니다.However, though unnecessary, a witness can exist for a high-performance mode session. 이 경우 서비스를 강제 적용하려면 미리 서버와 미러링 모니터 서버가 서로 연결되어 있어야 합니다.In this case, forcing service requires that the mirror server and witness are connected to each other.

  • 자동 장애 조치(Failover) 없는 보호 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다.High-safety mode without automatic failover supports forcing service whenever the principal server is disconnected.

  • 자동 장애 조치 있는 보호 우선 모드에서는 미러 서버가 마지막으로 주 서버에 연결되었을 때 미러 데이터베이스를 롤백하지 않은 경우 미러 서버와 미러링 모니터 서버가 서로 연결되어 있고 모두 주 서버에 연결되어 있지 않을 때마다 강제 서비스 적용을 지원합니다.High-safety mode with automatic failover supports forcing service whenever the mirror server and witness are connected to each other and neither is connected to the principal server (as long as the mirror server was not in the process of rolling back the mirror database when it was last connected to the principal).

    데이터 손실을 감수하더라도 즉시 데이터베이스 서비스를 복원해야 하는 경우에만 서비스를 강제 적용하는 것이 좋습니다.We recommend forcing service only if you must restore service to the database immediately and are willing to risk losing data. 서비스를 강제 적용할 경우 미러링이 재개될 때 데이터베이스를 다시 동기화하기가 쉽다는 점을 제외하고 미러링을 제거하는 것과 같은 효과가 있으며 데이터가 손실될 수 있습니다.The effect of forcing service is similar to removing mirroring, except that forcing service facilitates resynchronizing the databases when mirroring is resumed, at the risk of possible data loss. 서비스를 강제 적용하면 주 역할을 미러 데이터베이스로 원활하게 전환하는 작업이 시작됩니다.Forcing service initiates a smooth transition of the principal role to the mirror database. 미러 서버는 주 서버의 역할을 맡으며 클라이언트에 즉시 데이터베이스 복사본을 제공합니다.The mirror server assumes the role of principal server and immediately serves its copy of the database to clients. 새로운 주 데이터베이스는 미러 없이 노출된 상태로 실행됩니다.The new principal database runs without a mirror (that is, it runs exposed).

중요

주 서버가 단순히 데이터베이스 미러링 세션과 연결이 끊어졌지만 여전히 실행되고 있으면 일부 클라이언트가 계속해서 원래 주 데이터베이스에 액세스할 수 있습니다.If the principal server was merely disconnected from the database mirroring session and is still running, some clients might continue to access the original principal database. 서비스를 강제 적용하기 전에 클라이언트가 원래 주 서버에 액세스하지 않도록 하는 것이 중요합니다.Before you force service, it is important to prevent clients from accessing the original principal server. 그렇지 않으면 서비스가 강제 적용된 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.Otherwise, after service is forced, the original principal database and the current principal database could be updated independently of the other.

섹션 내용In This Section:

강제 서비스의 일반적인 사례Typical Case of Forced Service

다음 그림에서는 강제 서비스(데이터 손실 가능)의 일반적인 사례를 보여 줍니다.The following figure illustrates a typical case of forced service (with possible data loss).

데이터 손실 가능성이 있는 서비스 강제 적용Forcing service with possible data loss

그림에서 원래 주 서버 Partner_A가 미러 서버 Partner_B에서 사용할 수 없게 되어 미러 데이터베이스의 연결이 끊깁니다.In the figure, the original principal server, Partner_A, becomes unavailable to the mirror server, Partner_B, causing the mirror database to be disconnected. 클라이언트에서 Partner_A 를 사용할 수 없는지 확인한 후 데이터베이스 관리자가 Partner_B에 서비스를 강제로 적용하며, 이 경우 데이터가 손실될 수 있습니다.After ensuring that Partner_A is not available to clients, the database administrator forces service, with possible data loss, on Partner_B. Partner_B 가 주 서버가 되고 데이터베이스가 노출된 상태 (즉, 미러되지 않은 상태)로 실행됩니다.Partner_B becomes the principal server and runs with the database exposed (that is, unmirrored). 이때 클라이언트는 Partner_B에 다시 연결할 수 있습니다.At this point, clients can reconnect to Partner_B.

Partner_A 를 사용할 수 있게 되면 새로운 주 서버에 다시 연결하여 세션에 다시 참여하고 미러 역할을 담당합니다.When Partner_A becomes available, it reconnects to the new principal server, rejoining the session and assuming the mirror role. 미러링 세션이 새 미러 데이터베이스를 동기화하지 않고 즉시 일시 중단됩니다.The mirroring session is suspended immediately, without having synchronized the new mirror database. 세션이 일시 중단되면 데이터베이스 관리자가 세션을 재개할지 또는 극단적인 경우 미러링을 제거하고 이전 주 데이터베이스에서 데이터를 복원할지 결정할 수 있습니다.Suspending the session allows the database administrator to decide whether to resume the session or, in extreme cases, remove mirroring and attempt to salvage data from the former principal database. 여기서는 데이터베이스 관리자가 미러링을 재개하도록 선택합니다.In this case, the database administrator chooses to resume mirroring. 이때 Partner_A 는 미러 서버의 역할을 맡고 이전 주 데이터베이스를 성공적으로 동기화된 마지막 트랜잭션 시점까지 롤백합니다. 서비스가 강제 적용되기 전에 미러 서버의 디스크에 기록되지 않은 커밋된 트랜잭션은 손실됩니다.At that point, Partner_A takes over the role of mirror server and rolls back the former principal database to the point in time of the last successfully synchronized transaction; if any committed transactions were not written to disk on the mirror server before service was forced, they are lost. 그런 다음Partner_A 는 이전 미러 서버가 새로운 주 서버가 된 이후의 변경 내용을 새로운 주 데이터베이스에 적용하여 새 미러 데이터베이스를 롤포워드합니다.Partner_A then rolls forward the new mirror database by applying any changes made on the new principal database since the former mirror server became the new principal server.

참고

성능 우선 모드에서는 미러링 모니터 서버가 필요하지 않지만 미러링 모니터 서버가 구성된 경우 현재 미러 서버에 연결되어 있어야만 서비스를 강제 적용할 수 있습니다.Although high-performance mode does not require a witness, if one is configured, forcing service is possible only if the witness is currently connected to the mirror server.

서비스 강제 적용 시의 위험Risks of Forcing Service

서비스를 강제 적용하면 데이터가 손실될 수 있음을 이해하는 것이 중요합니다.It is essential to understand that forcing service can cause data loss. 데이터 손실은 미러 서버가 주 서버와 통신할 수 없어 두 데이터베이스의 동기화를 보장할 수 없기 때문에 발생합니다.Data loss is possible because the mirror server cannot communicate with the principal server and, therefore, cannot guarantee that the two databases are synchronized. 서비스를 강제 적용하면 새 복구 분기가 시작됩니다.Forcing service starts a new recovery fork. 원래 주 데이터베이스와 미러 데이터베이스가 서로 다른 복구 분기에 있으므로 이제 각 데이터베이스에는 다른 데이터베이스에 없는 데이터가 포함됩니다. 원래 주 데이터베이스에는 Send Queue에서 이전의 미러 데이터베이스로 아직 전송되지 않은 변경 내용(보내지 않은 로그)이 포함되고 이전의 미러 데이터베이스에는 서비스가 강제 적용된 후 발생한 변경 내용이 포함됩니다.Because the original principal database and mirror database are on different recovery forks, each database now contains data that the other database does not: the original principal database contains whatever changes were not yet sent from its send queue to the former mirror database (the unsent log); the former mirror database contains whatever changes occur after service was forced.

주 서버가 실패하여 서비스가 강제 적용된 경우 발생 가능한 데이터 손실은 실패 전에 미러 서버로 보내지 않은 트랜잭션 로그가 있는지 여부에 따라 달라집니다.If service is forced because the principal server has failed, potential data loss is depends on whether any transaction logs were not sent to the mirror server before the failure. 보호 우선 모드에서는 미러 데이터베이스가 동기화될 때까지만 보내지 않은 로그가 있을 수 있습니다.Under high-safety mode, this is possible only until the mirror database becomes synchronized. 성능 우선 모드에서는 보내지 않은 로그가 항상 누적되어 있을 수 있습니다.Under the high-performance mode, accumulated unsent log is always a possibility.

강제 서비스 적용의 의미는 부분적으로 세션에 미러링 모니터 서버가 있는지 여부에 따라 달라집니다.The implications of forcing service depend partly on whether the session has a witness:

  • 미러링 모니터 서버가 없을 경우 네트워크 연결이 끊기는 등의 이유로 파트너의 연결이 끊어지면 서비스를 강제 적용할 수 있습니다.In the absence of a witness, service can be forced if the partners become disconnected, for example, because their network connection is broken. 원래 주 서버가 여전히 실행되고 있으면 두 파트너가 모두 주 역할을 소유합니다.If the original principal server is still running, both partners own the principal role. 새로운 주 서버에 연결하는 클라이언트는 현재 버전의 데이터베이스에 액세스하고 원래 주 서버에 연결하는 클라이언트는 원래 주 데이터베이스에 액세스합니다.Clients connecting to the new principal server will access the current version of the database, while clients connecting to the original principal server will access the original principal database. 이 경우 데이터 손실 가능성이 커집니다.This situation increases the potential for data loss. 파트너가 다시 연결할 수 있으면 원래 주 서버는 미러 역할을 맡고 미러링이 일시 중단되기 전에 데이터베이스 상태를 "복구 중"으로 변경합니다.If the partners are allowed to reconnect, the original principal server assumes the mirror role and changes the status of its database to "recovering," before mirroring is suspended. 세션이 재개되면 가장 최근에 연결이 끊어질 때 해당 로그가 Send Queue에 있었던 원래 주 데이터베이스의 트랜잭션이 손실됩니다.If the session is resumed, transactions on the original principal database whose log was in the send queue as of the most recent disconnection are lost. 서비스가 강제 적용된 후에 발생한 모든 트랜잭션도 손실됩니다.In addition, any the transactions that occurred after service was forced are also lost.

  • 미러링 모니터 서버가 있을 경우 미러 서버가 주 서버 및 미러링 모니터 서버와 모두 연결이 끊어지면 주 서버가 노출된 상태로 실행됩니다. 단, 주 서버와 미러링 모니터 서버는 서로 연결되어 있어야 합니다.In the presence of a witness, if the mirror server is disconnected from both the principal server and the witness, as long as the latter two remain connected to each other, the principal runs exposed. 그런 다음 주 서버가 미러링 모니터 서버와 연결이 끊어지면 데이터베이스 제공을 중지합니다.If the principal server then becomes disconnected from the witness, it stops serving the database. 이후에 미러 서버가 미러링 모니터 서버에 다시 연결하면 서비스를 강제 적용할 수 있습니다.Thereafter, if the mirror server reconnects to the witness, forcing service becomes possible. 서비스가 강제 적용된 경우 원래 주 서버가 다시 연결하면 원래 주 서버가 노출된 상태로 실행되는 동안 수행된 모든 변경 내용이 손실됩니다.If service is forced, all the changes made while the original principal server was running exposed will be lost if the original principal server reconnects.

    자세한 내용은 이 항목의 뒷부분에 나오는 잠재적 데이터 손실 관리를 참조하십시오.For more information, see Managing the Potential Data Loss, later in this topic.

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

서비스가 강제 적용된 후 이전 주 서버를 사용할 수 있게 되면 데이터베이스가 손상되지 않았다고 가정할 경우 잠재적 데이터 손실을 관리할 수 있습니다.After service is forced, once the former principal server is available, assuming that its database is undamaged, you can attempt to manage the potential data loss. 잠재적 데이터 손실을 관리하는 데 사용 가능한 방법은 원래 주 서버가 파트너에 다시 연결하여 미러링 세션에 다시 참여했는지 여부에 따라 달라집니다.The available approach for managing potential data loss depends on whether the original principal server has reconnected to its partner and rejoined the mirroring session. 원래 주 서버가 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 투명하게 다시 연결할 수 있습니다.Assuming that the original principal server can access the new principal instance, reconnecting occurs automatically and transparently.

원래 주 서버가 다시 연결된 경우The Original Principal Server Has Reconnected

일반적으로 실패 후에 원래 주 서버가 다시 시작되면 신속하게 해당 파트너에 다시 연결합니다.Typically, after a failure, when the original principal server restarts it quickly reconnects to its partner. 다시 연결할 때 원래 주 서버는 미러 서버가 됩니다.On reconnecting, the original principal server becomes the mirror server. 해당 데이터베이스는 미러 데이터베이스가 되고 세션이 일시 중단되기 전에 복구 상태가 됩니다.Its database becomes the mirror database and enters the recovering state before the session is suspended. 미러링을 재개하지 않으면 미러 데이터베이스는 롤백되지 않습니다.The mirror database will not be not rolled back unless you resume mirroring.

그러나 복구 중인 데이터베이스에 액세스할 수 없으므로 데이터베이스를 검사하여 미러링을 재개할 때 손실될 데이터를 평가할 수 없습니다.However, the recovering database is inaccessible; therefore, you cannot inspect it to evaluate what data would be lost if you were to resume mirroring. 따라서 데이터 손실을 감수할지 여부에 따라 미러링을 재개할지 또는 제거할지 결정합니다.Therefore, the decision on whether to resume or remove mirroring depends on whether you are willing to accept any data loss at all.

  • 데이터 손실이 허용되지 않는 경우 미러링을 제거하여 데이터를 복원해야 합니다.If losing any data would be unacceptable, you should remove mirroring to salvage them.

    미러링을 제거하면 데이터베이스 관리자가 원래 주 데이터베이스를 복구하여 손실되었을 데이터를 복구할 수 있습니다.Removing mirroring would allow the database administrator to recover the original principal database and attempt to recover the data that would have been lost. 그러나 이전 미러 데이터베이스가 온라인 상태가 되면 이전 파트너가 동일한 이름으로 다른 데이터베이스를 제공합니다.However, when the former mirror database comes online, the former partners will be serving divergent databases with the same name. 데이터베이스 관리자는 데이터베이스 중 하나를 클라이언트에서 액세스할 수 없도록 만들어 데이터베이스가 더 이상 달라지지 않도록 하고 클라이언트 장애 조치 문제를 방지해야 합니다.The database administrator needs to make one of the databases inaccessible to clients to avoid further divergence of the database and to prevent client-failover issues.

  • 데이터 손실이 허용되는 경우 미러링을 재개할 수 있습니다.If losing any data would be acceptable, you can resume mirroring.

    미러링을 재개하면 데이터베이스 동기화의 첫 번째 단계로 새 미러 데이터베이스가 롤백됩니다.Resuming mirroring causes the new mirror database 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 Principal Server Has Not Reconnected

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

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

    원래 주 서버가 해당 파트너에 다시 연결할 수 있도록 합니다.Allow the original principal server to reconnect to its partner. 다시 연결하면 미러링이 일시 중단됩니다.Reconnecting causes mirroring to be suspended. 미러링을 계속하려면 세션을 재개하면 됩니다.To proceed with mirroring, simply resume the session. 이전 주 서버가 미러 역할을 맡습니다.The former principal server assumes the mirror role. 새 미러 서버는 원래 복구 분기를 삭제하므로 이전 미러 서버로 보내거나 받지 않은 모든 트랜잭션이 손실됩니다.The new mirror server drops the original recovery fork, losing any transactions that were never sent to or received by the former mirror server.

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

    세션을 재개할 때 손실되는 중요한 데이터가 원래 주 데이터베이스에 포함되어 있으면 미러링을 제거하여 원래 주 서버의 데이터를 유지할 수 있습니다.If the original principal database contains critical data that would be lost if you resumed the session, you can preserve the data on the original principal server by removing mirroring. 이때 주 서버의 비상 로그를 백업하는 것이 좋습니다.We recommend that you attempt to back up the tail of the principal's log at this point. 그러면 원래 주 데이터베이스에서 유지하려는 데이터를 내보낸 후 현재 주 데이터베이스로 가져와서 현재 주 데이터베이스(이전 미러 데이터베이스)를 업데이트할 수 있습니다.Then, you can update the current principal (the former mirror database) by exporting the data you want to salvage from the original principal database and importing it into the current principal database. 업데이트된 데이터베이스의 전체 데이터베이스 백업을 가능한 한 빨리 수행하는 것이 좋습니다.We recommend taking a full database backup of the updated database as quickly as possible.

    업데이트된 데이터베이스를 초기 주 데이터베이스로 사용하여 미러링을 다시 설정하려면 이 백업과 하나 이상의 후속 로그 백업을 사용하여 새 미러 데이터베이스를 만듭니다.To re-establish mirroring with the updated database as the initial principal database, use this backup (and least one subsequent log backup) to create a new mirror database. 미러링이 제거된 후에 수행된 모든 로그 백업을 적용해야 합니다.Every log backup taken after mirroring was removed must be applied. 따라서 새 미러링 세션이 시작될 때까지 주 데이터베이스의 추가 로그 백업을 지연하는 것이 좋습니다.Therefore, we recommend delaying additional log backups of the principal database until the new mirroring session starts.

강제 장애 조치(Failover) 관리를 위한 관련 태스크Related Tasks For Managing a Forced Failover

서비스를 강제로 수행하려면To force service

참고 항목See Also

역할 전환 중 서비스 중단 예측(데이터베이스 미러링) Estimate the Interruption of Service During Role Switching (Database Mirroring)
데이터베이스 미러링 중에 발생 가능한 오류 Possible Failures During Database Mirroring
데이터베이스 미러링 세션에 클라이언트 연결(SQL Server) Connect Clients to a Database Mirroring Session (SQL Server)
데이터베이스 미러링 모니터 서버 Database Mirroring Witness
전체 데이터베이스 복원(전체 복구 모델) Complete Database Restores (Full Recovery Model)
데이터베이스 미러링 운영 모드 Database Mirroring Operating Modes
미러링 상태(SQL Server)Mirroring States (SQL Server)