비동기 데이터베이스 미러링(성능 우선 모드)
업데이트: 2005년 12월 5일
트랜잭션 보안을 OFF로 설정하면 데이터베이스 미러링 세션은 비동기적으로 작동합니다. 비동기 작업은 성능 우선 모드의 운영 모드만 지원합니다. 이 모드는 성능을 강화하지만 고가용성은 저하됩니다. 성능 우선 모드에서는 주 서버와 미러 서버만 사용됩니다. 미러 서버의 문제점은 주 서버에 영향을 주지 않습니다. 주 서버가 손실되면 미러 데이터베이스는 DISCONNECTED로 표시되지만 웜 대기로 사용할 수 있습니다.
성능 우선 모드는 하나의 역할 전환 형식인 강제 서비스(데이터 손실 가능)만 지원합니다. 이 서비스에서는 미러 서버를 웜 대기 서버로 사용합니다. 강제 서비스는 주 서버 실패에 대한 가능한 응답 중 하나입니다. 데이터가 손실될 수 있으므로 미러 서버에 서비스를 강제하기 전에 다른 대안을 고려해야 합니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "주 서버 실패에 대한 응답"을 참조하십시오.
다음 그림에서는 성능 우선 모드를 사용한 세션 구성을 보여 줍니다.
.gif "파트너만 있는 세션 구성")
성능 우선 모드에서 주 서버가 미러 서버로 트랜잭션 로그를 보내면 미러 서버의 확인을 기다리지 않고 즉시 클라이언트로 확인 메시지를 보냅니다. 트랜잭션은 미러 서버에서 로그를 디스크에 쓸 때까지 기다리지 않고 커밋됩니다. 비동기 작업을 통해 주 서버는 최소 트랜잭션 대기 시간을 사용하여 실행됩니다.
미러 서버는 주 서버가 보낸 로그 레코드를 유지하려고 합니다. 그러나 일반적으로 두 데이터베이스 간의 차이가 크지는 않지만 미러 데이터베이스는 주 데이터베이스보다 약간 뒤처질 수 있습니다. 그러나 주 서버에 작업이 크거나 미러 서버 시스템이 과부화된 경우 이 시간 간격은 상당히 커질 수 있습니다.
성능 우선 모드가 적합한 경우
성능 우선 모드는 주 서버와 미러 서버가 상당한 거리로 분리되어 있고 주 서버가 작은 오류의 영향을 받지 않도록 하려는 재해 복구 시나리오에서 유용할 수 있습니다.
[!참고] 로그 전달은 데이터베이스 미러링을 보완하며 비동기 데이터베이스 미러링의 대안으로 사용될 수 있습니다. 로그 전달의 장점에 대한 자세한 내용은 고가용성 구성을 참조하십시오. 데이터베이스 미러링을 통해 로그 전달을 사용하는 방법은 데이터베이스 미러링 및 로그 전달을 참조하십시오.
성능 우선 모드에 대한 미러링 모니터 서버의 영향
Transact-SQL을 사용하여 성능 우선 모드를 구성하는 경우 SAFETY 속성이 OFF로 설정되어 있으면 WITNESS 속성도 OFF로 설정하는 것이 좋습니다. 미러링 모니터 서버는 성능 우선 모드에서 작동할 수 있지만 어떤 이점도 제공하지 않으며 위험만 수반됩니다.
파트너 중 하나의 작동이 중단될 때 세션에서 미러링 모니터 서버의 연결이 끊어지면 데이터베이스를 사용할 수 없게 됩니다. 이는 성능 우선 모드에 미러링 모니터 서버가 필요하지는 않지만 미러링 모니터 서버가 설정된 경우 세션에 둘 이상의 서버 인스턴스로 구성된 쿼럼이 필요하기 때문입니다. 세션에서 쿼럼이 손실되면 데이터베이스를 제공할 수 없습니다.
성능 우선 모드 세션에 미러링 모니터 서버가 설정되어 있을 때 쿼럼의 적용은 다음을 의미합니다.
- 미러 서버가 손실되면 주 서버가 미러링 모니터 서버에 연결되어야 합니다. 그렇지 않으면 미러링 모니터 서버나 미러 서버가 세션에 다시 참여할 때까지 주 서버가 데이터베이스를 오프라인 상태로 유지합니다.
- 주 서버가 손실된 경우 미러 서버에 서비스를 강제하려면 미러 서버가 미러링 모니터 서버에 연결되어야 합니다.
[!참고] 쿼럼 유형에 대한 자세한 내용은 쿼럼: 미러링 모니터 서버가 데이터베이스 가용성에 미치는 영향을 참조하십시오.
주 서버 실패에 대한 응답
주 서버에 장애가 발생하면 데이터베이스 소유자가 선택할 수 있는 응답은 다음과 같습니다.
주 서버를 다시 사용할 수 있을 때까지 데이터베이스를 사용하지 않습니다.
주 데이터베이스와 해당 트랜잭션 로그가 영향을 받지 않은 경우 이 선택은 가용성을 저하시켜 모든 커밋된 트랜잭션을 유지합니다.데이터베이스 미러링 세션을 중지하고 데이터베이스를 수동으로 업데이트한 다음 새 데이터베이스 미러링 세션을 시작합니다.
주 데이터베이스가 손실되었지만 주 서버가 계속 실행 중이면 주 데이터베이스에서 즉시 비상 로그 백업을 시도하십시오. 비상 로그 백업에 성공한 경우 미러링을 제거하는 것이 좋습니다. 미러링을 제거한 다음 모든 데이터를 유지하는 이전 미러 데이터베이스로 해당 로그를 복원할 수 있습니다.[!참고] 비상 로그 백업에 실패하고 주 서버의 복구를 기다릴 수 없는 경우 세션 상태를 유지 관리할 수 있는 강제 서비스를 고려하십시오.
미러 서버에서 강제 서비스(데이터 손실 가능)를 실행합니다.
강제 서비스는 엄밀한 의미에서 재해 복구 방법이며 반드시 필요한 경우에만 사용해야 합니다. 강제 서비스는 주 서버가 다운되고 세션이 비동기적이며(트랜잭션 보안이 OFF로 설정됨) 세션에 미러링 모니터 서버가 없거나(WITNESS 속성이 OFF로 설정됨) 미러링 모니터 서버가 미러 서버에 연결된 경우(쿼럼이 있음)에만 사용할 수 있습니다.
강제 서비스를 사용하면 미러 서버는 주 서버 역할로 간주되며 주 서버의 데이터베이스 복사본을 클라이언트에게 제공합니다. 강제 서비스를 사용하면 주 서버가 미러 서버로 보내지 않은 트랜잭션 로그는 모두 손실됩니다. 따라서 강제 서비스는 데이터 손실이 허용되고 즉각적인 데이터베이스 가용성이 중요한 상황에서만 사용되어야 합니다. 강제 서비스 작동 방법과 최상의 사용 방법은 강제 서비스(데이터 손실 가능)를 참조하십시오.
참고 항목
개념
강제 서비스(데이터 손실 가능)
동기 데이터베이스 미러링(보호 우선 모드)
Transact-SQL 설정 및 데이터베이스 미러링 작업 모드
로그 전달 이해