역할 전환 중 서비스 중단 예측(데이터베이스 미러링)

적용 대상:SQL Server

역할 전환 중에 데이터베이스 미러링이 서비스 중단되는 시간은 역할 전환 유형 및 역할 전환의 원인에 따라 달라집니다.

• 자동 장애 조치(failover)의 경우 미러 서버에서 주 서버 인스턴스가 실패했음을 인식하는 데 필요한 시간(오류 검색)과 데이터베이스를 장애 조치(failover)하는 데 필요한 시간(장애 조치(failover) 시간)이라는 두 가지 요인이 서비스 중단 시간에 영향을 줍니다.

• 강제 서비스 작업의 경우 오류가 발생하더라도 오류를 감지하고 대응하는 것은 사람의 대응력에 따라 달라집니다. 그러나 서비스 중단 가능성을 예측하는 것은 강제 서비스 명령이 실행된 후 미러 서버가 역할을 전환하는 데 걸리는 시간을 예측하는 것으로 제한됩니다.

  참고 항목

  일부 오류 유형과 같은 특정 조건을 검색하는 데 필요한 시간을 줄이기 위해 해당 조건에 대한 경고를 정의할 수 있습니다.

• 수동 장애 조치의 경우 장애 조치 명령이 실행된 후 데이터베이스를 장애 조치하는 데 필요한 시간만 고려됩니다.

오류 검색

시스템에서 오류를 알 수 있는 시간은 오류 유형에 따라 달라집니다. 예를 들어 네트워크 오류는 거의 즉시 발견되며 응답하지 않는 서버를 발견하는 데는 10초가 걸립니다(기본 시간 제한 사용).

데이터베이스 미러링 세션 및 자동 장애 조치(failover)를 사용하는 안전성이 높은 모드의 시간 제한 검색 중 실패를 일으킬 수 있는 오류에 대한 자세한 내용은 데이터베이스 미러링 중 가능한 실패를 참조하세요.

장애 조치 시간

장애 조치(failover) 시간은 주로 이전 미러 서버에서 Redo Queue에 남아 있는 로그를 롤포워드해야 하는 시간과 짧은 추가 시간으로 구성됩니다. 미러 서버에서 로그 레코드를 처리하는 방법은 데이터베이스 미러링(SQL Server)을 참조하세요. 장애 조치(failover) 시간 예측에 대한 자세한 내용은 이 항목의 뒷부분에 있는 장애 조치(failover) 다시 실행 속도 예측을 참조하세요.

중요

인덱스 또는 테이블이 생성된 후 변경되는 트랜잭션 중에 장애 조치(failover)가 발생하는 경우 장애 조치(failover)가 평소보다 오래 걸릴 수 있습니다. 예를 들어 테이블에 대한 BEGIN TRANSACTION, CREATE INDEX 및 SELECT INTO 작업 중에 장애 조치(failover)를 수행하면 장애 조치(failover) 시간이 늘어날 수 있습니다. COMMIT TRANSACTION 또는 ROLLBACK TRANSACTION 문으로 완료될 때까지 이러한 트랜잭션 중에 장애 조치(failover) 시간이 늘어날 가능성이 있습니다.

Redo Queue

데이터베이스를 롤포워드하려면 현재 미러 서버의 Redo Queue에 있는 로그 레코드를 적용해야 합니다. Redo Queue 는 미러 서버의 디스크에 기록되었지만 미러 데이터베이스에서 롤포워드되지 않은 로그 레코드로 구성됩니다.

데이터베이스의 장애 조치(failover) 시간은 미러 서버가 Redo Queue에서 로그를 롤포워드할 수 있는 속도에 따라 달라지며, 이는 주로 시스템 하드웨어 및 현재 작업 부하에 의해 결정됩니다. 주 데이터베이스의 사용량이 많으므로 주 서버는 미러 서버에서 로그를 롤포워드할 수 있는 시간보다 훨씬 빠르게 로그를 미러 서버로 전달할 수도 있습니다. 이 경우 미러 서버가 Redo Queue에서 로그를 롤포워드하는 동안 장애 조치(failover)에 상당한 시간이 걸릴 수 있습니다. Redo Queue의 현재 크기를 확인하려면 데이터베이스 미러링 성능 개체의 Redo Queue 카운터를 사용하세요. 자세한 내용은 SQL Server, Database Mirroring Object을(를) 참조하세요.

장애 조치(failover) 다시 실행 속도 예측

프로덕션 데이터베이스의 테스트 복사본을 사용하여 로그 레코드를 롤포워드하는 데 필요한 시간(다시 실행 속도)을 측정할 수 있습니다.

장애 조치(failover) 중에 롤포워드 시간을 예측하는 방법은 미러 서버가 다시 실행 단계에서 사용하는 스레드 수에 따라 달라집니다. 스레드 수는 다음에 따라 달라집니다.

• SQL Server Standard 버전에서 미러 서버는 항상 단일 스레드를 사용하여 데이터베이스를 롤포워드합니다.

• SQL Server Enterprise 버전에서는 CPU가 5개 미만인 컴퓨터의 미러 서버도 단일 스레드만 사용합니다. 5개 이상의 CPU를 사용하는 미러 서버는 장애 조치(failover) 중에 롤포워드 작업을 여러 스레드 간에 분산합니다(병렬 다시 실행이라고 함). 병렬 다시 실행은 CPU 4개당 스레드 하나를 사용하도록 최적화되었습니다.

단일 스레드 다시 실행 속도 예측

단일 스레드 다시 실행의 경우 장애 조치(failover) 중에 미러 데이터베이스를 롤포워드하는 데는 로그 백업 복원이 동일한 양의 로그를 롤포워드하는 데 걸리는 시간과 거의 동일한 시간이 걸립니다. 장애 조치(failover) 시간을 예측하려면 미러 실행하려는 환경에서 테스트 데이터베이스를 생성합니다. 그런 다음 프로덕션 데이터베이스에서 로그 백업을 수행합니다. 해당 로그 백업에 대한 다시 실행 속도를 측정하려면 테스트 데이터베이스에 대한 로그 백업 WITH NORECOVERY를 복원하는 데 걸리는 시간을 측정합니다.

미러 서버의 다시 실행 속도를 알고 나면 다시 실행할 현재 로그의 양(Redo Queue 성능 카운터로 측정)을 다시 실행 속도로 나누어 지정된 시점에 데이터베이스를 장애 조치(failover)하는 데 걸리는 시간을 예측할 수 있습니다. 정상적인 조건에서 미러 서버가 주 서버의 부하를 따라갈 수 있는 경우 Redo Queue는 작거나 0에 가까우며 장애 조치(failover)에 몇 초밖에 걸리지 않습니다.

병렬 다시 실행 속도 예측

SQL Server Enterprise 버전에서 병렬 다시 실행은 CPU 4개당 스레드 하나를 사용하도록 최적화되었습니다. 병렬 다시 실행의 롤포워드 시간을 예측하려면 테스트 데이터베이스보다 실행 중인 테스트 시스템에 액세스하는 것이 더 정확합니다. 미러 서버에서 Redo Queue를 모니터링하는 동안 주 서버의 로드를 늘리십시오. 정상 작업 시 Redo Queue는 0에 가깝습니다. Redo Queue가 지속적으로 증가하기 시작할 때까지 주 서버의 부하를 늘립니다. 그러면 시스템이 최대 다시 실행 속도로 실행되며 이 시점의 다시 실행 바이트/초 성능 카운터가 최대 다시 실행 속도를 나타냅니다. 자세한 내용은 SQL Server, Database Mirroring Object을(를) 참조하세요.

자동 장애 조치(failover) 중 서비스 중단 예측

다음 그림에서는 오류 검색 및 장애 조치 시간이 Partner_B에서 자동 장애 조치를 완료하는 데 필요한 전체 시간에 어떤 영향을 주는지를 보여 줍니다. 장애 조치(failover)에는 데이터베이스를 롤포워드하는 시간(다시 실행 단계)과 더불어 데이터베이스를 온라인 상태로 만드는 데 약간의 시간이 필요합니다. 커밋되지 않은 트랜잭션을 롤백하는 실행 취소 단계는 새 주 데이터베이스가 온라인 상태가 된 후 발생하며 장애 조치(failover) 후에도 계속됩니다. 데이터베이스는 실행 취소 단계에서 사용할 수 있습니다.

참고 항목

데이터베이스 미러링 운영 모드
데이터베이스 미러링 세션 중 역할 전환(SQL Server)
데이터베이스 미러링 모니터링(SQL Server)