데이터베이스 미러링 구현

데이터베이스 미러링 구현에 대한 기본 정보는 SQL Server 2005 온라인 설명서의 데이터베이스 미러링에 대한"How To" 항목에서 찾을 수 있습니다. 이 절에서는 몇 가지 최상의 사례와 함께 데이터베이스 미러링 구현의 특정 예를 살펴 보도록 하겠습니다.

데이터베이스 미러링 모니터링

SQL Server 2005 Management Studio의 Object Explorer에서 주 또는 미러 데이터베이스를 검토하여 각 데이터베이스 미러 링 상태를 감지할 수 있습니다. 주 서버가 미러 서버와 동기화되면 Object Explorer는 주 데이터베이스 이름 옆에 (주 서버, Synchronized) 메시지를 추가하고 미러 서버 이름 옆에 (미러 서버, Synchronized) 메시지를 추가합니다. 주 서버에서 호출하면 Database Properties 대화 상자에 있는 Mirroring 페이지의 Status 상자를 관찰하여 데이터베이스 미러링 세션 상태를 조사할 수도 있습니다. 미러 데이터베이스에서는 Database Properties 대화 상자가 열리지 않습니다.

데이터베이스 미러링 카탈로그 뷰, sys.database_mirroring 및 sys.database_mirroring_witnesses를 쿼리할 수도 있습니다. 카탈로그 뷰를 사용하여 미러링 세션에서 데이터베이스 상태를 조사하는 방법에 대한 자세한 내용은 이 문서 앞부분의 Database Dynamics 절에서"데이터베이스 미러링 카탈로그 뷰 메타데이터"를 참조하십시오. 카탈로그 뷰는 SQL Server 온 라인 설명서에도 자세히 설명되어 있습니다.

데이터베이스 미러링 Perfmon 카운터

Perfmon 카운터를 사용하여 데이터베이스 미러링 세션의 파트너 사이에 트래픽을 모니터링할 수 있습니다. SQL Server Database Mirroring 개체에는 주 서버와 감시 서버를 위한 유용한 Perfmon 카운터가 많이 포함되어 있습니다. SQL Server 온 라인 설명서의"Monitoring Database Mirroring"을 참조하십시오.

Database Mirroring 개체의 각 카운터는 데이터베이스 당 설정할 수 있습니다. 서버에서 둘 이상의 데이터베이스를 미러링하 는 경우 각 데이터베이스의 활동을 개별적으로 또는 모든 데이터베이스의 전체 미러링 활동을 측정할 수 있습니다.

주 서버의 경우 Log Bytes Sent/sec 카운터는 주 서버가 트랜잭션 로그 데이터를 미러 서버로 전송하는 속도를 알려주는 반면, Log Send Queue는 어느 한 시점에 트랜잭션 로그 버퍼에서 어느 정도의 바이트를 미러 서버로 전송되는지 보여줍니다. 트랜 잭션 로그 데이터를 주 서버에서 미러 서버로 전송하면 주 서버의 전송 대기열이 고갈되지만 새 로그 레코드가 로그 버퍼에 들어오면 크기가 커집니다. 주 서버의 Transaction Delay 카운터는 미러 데이터베이스가 수신하는 로그 레코드의 승인을 기다 리므로 주 서버에 발생하는 지연을 보여줍니다. Pages Sent/sec는 동기화를 지원하기 위해 데이터베이스를 미러 서버로 전송 하는 주 서버와 관련된 것입니다.

미러 서버에서 Log Bytes Received/sec는 미러가 주 서버와 얼마나 상태를 잘 유지하는지 보여줍니다. 위의 Log Bytes Sent/sec 카운터를 참조하십시오. Redo Queue 카운터는 진행 중인 재실행 단계 동안 미러 서버가 주 서버에서 트랜잭션을 재실행하는 데 사용하는 재실행 대기열 크기를 보여줍니다. Redo Bytes/sec는 미러 서버가 재실행 대기열에서 이러한 트랜 잭션을 재실행하는 속도를 보여줍니다.

각 파트너에 대해 Sends/sec and Receives/sec 카운터는 서버가 통신하는 속도에 대해 알 수 있도록 개별 전송 및 수신 작업 수를 보여줍니다. Bytes Sent/sec 및 Bytes Received/sec 카운터는 이러한 전송과 수신에 대해 각 파트너 서버에서 전송하고 수신한 총 바이트 수를 보여줍니다.

재실행 및 추적 시간 예측

Redo Queue 및 Redo Bytes/sec의 값을 사용하여 미러 데이터베이스가 재실행을 완료하고 사용할 수 있게 되며 장애 조치가 발생하는 데 걸리는 시간을 예측할 수 있습니다. 예측은 다음과 같은 간단한 수식으로 구성됩니다.

마찬가지로 Log Send Queue 및 Log Bytes Received/sec 카운터를 사용하여 주 서버의 활동이 앞서 있고 이후로 다운된 경우 미러가 주 서버를 추적하는 데 걸리는 시간을 예측할 수 있습니다. 예측은 다음 수식을 통해 가능합니다.

Profiler 이벤트

SQL Server 2005 Profiler에는 데이터베이스 미러링을 위한 하나의 이벤트 클래스가 포함되어 있습니다. Database:Database Mirroring State Change 이벤트는 서버가 상태 변경을 모니터링하는지 여부를 기록합니다. SQL Server 온라인 설명서의 "Database Mirroring State Change Event Class"항목을 참조하십시오. 이 이벤트 클래스를 사용할 때 Database Name과 State 열을 포함하는 것이 유용합니다. 이 이벤트를 사용하여 데이터베이스 미러링 세션에서 상태 변경을 경고할 수 있습니다.

데이터베이스 미러링 문제 해결

오류 가능성이 가장 많은 두 영역은 설치와 실행 시간 동안입니다.

설치 문제 해결

데이터베이스 미러링을 설치했지만 시작하지 않은 경우 설치 동안 수행한 단계를 다시 추적하십시오.

미러 서버가 주 서버를 닫을 충분한 시간이 있는지 확인하십시오. 모니터링을 시작할 때 다음 메시지가 나타나는 경우 데이터베이스"AdventureWorks"의 원격 복사본이 데이터베이스 로그의 로컬 복사본에 포함된 시점으로 롤 포워드되지 않았 습니다. (Microsoft SQL Server, 오류: 1412)

미러가 추적되지 않은 것을 알고 있습니다. 주 서버에서 로그 레코드를 받을 수 있는 지점으로 미러를 추적하기 위해 주 서버에 서 미러 서버로 트랜잭션 로그 백업을 적용할 필요가 없습니다(NORECOVERY 사용).

각 서버의 SQL Server Windows 서비스 계정이 다른 서버에서 신뢰되는지 확인하십시오. 서버가 신뢰되지 않는 도메인에 있는 경우 인증서가 올바른지 확인하십시오.

sys.database_mirroring_endpoints 카탈로그 뷰를 쿼리하여 종단시오.

또한 정규화된 컴퓨터 이름이 올바르며 서버에 있는 인스턴스에서 미러링하는 경우 포트 번호는 고유해야 합니다. 각 SQL Server 서비스 로그인은 종단점에 대한 CONNECT 권한이 있어야 합니다.

마지막으?할을 적절히 정의했는지 확인하십시오.

ALTER DATABASE 명령에서 올바른 파트너 이름을 식별했는지 확인하십시오. 주 서버와 미러 서버에서 sys.database_ mirroring 카탈로그 뷰에서 파트너 이름을 조사할 수 있습니다 (고가용성 모드에 있는 경우 sys.database_mirroring_witnesses witness).

실행 시간 오류 문제 해결

데이터베이스 미러링을 올바르게 설치했고 실행 중에 오류가 발생하는 경우 세션의 현재 상태를 확인하십시오. 오류로 인해 SUSPENDED 상태가 된 경우 미러에서 재실행 오류가 발생했을 수 있습니다. 재실행(데이터 드라이브의 여유 공간) 및 로그 저장(로그 드라이브의 여유 공간)을 위한 충분한 디스크 공간이 미러 서버에 있는지 확인하십시오. 세션을 다시 시작할 다시 시작할 준비가 되면 ALTER DATABASE를 사용하여 세션을 RESUME하십시오.

주 데이터베이스에 연결할 수 없는 경우 안전성이 FULL이고 주 서버가 쿼럼을 구성할 수 없기 때문일 수 있습니다. 예를 들어, 이는 시스템이 높은 수준의 보호 모드에 있고(안전성이 FULL이지만 감시 서버는 없음) 미러는 미러 서버가 이전의 주 서버에서 연결이 끊어진 경우 발생할 수 있습니다. 미러에서 다음 명령을 사용하여 미러 서버를 강제로 복구합니다.

문제는 미러 데이터베이스를 복구한 후에 주 서버가 되고 쿼럼을 구성할 수 없으므로 데이터베이스를 서비스할 수 없다는 것 입니다. 이 경우 안전성을 OFF로 설정하여 데이터베이스를 서비스할 수 있습니다.

안정성 대 성능

데이터베이스 미러링 성능은 활동 유형과 트랜잭션 안정성 설정의 함수입니다.

주 서버의 성능은 미러 서버에 대한 로그 레코드의 전송에 영향을 받습니다. 데이터베이스 미러링이 주 서버에 주는 오버헤드 는 활동 유형의 함수입니다. 데이터베이스 미러링은 데이터베이스 서버의 정상 트랜잭션 활동이 로그 레코드를 미러 서버에 전송하는 오버헤드를 마스크하기 때문에 많은 사용자의 많은 긴 트랜잭션에서 가장 잘 수행됩니다. 단일 사용자가 많은 수의 작은 트랜잭션을 순서대로 수행하면 각 트랜잭션에 대한 데이터베이스 미러링의 오버헤드는 더 두드러집니다.

주 서버의 성능은 안전성 설정에 의해서도 영향을 받습니다. 안전성이 FULL이면 주 서버는 트랜잭션 커밋 메시지를 다시 클라 이언트에 실행하기 전에 로그 레코드를 수신한 미러에 의해 승인을 기다려야 합니다. 많은 사용자와 긴 트랜잭션에서 이 오버 헤드는 중요하지 않습니다. 단일 스레드와 많은 작은 트랜잭션이 있는 시스템은 안전성이 OFF인 상태에서 더 잘 작동할 수 있습니다.

미러 서버가 데이터 수정 트랜잭션을 계속 재생하기 때문에 미러 서버의 데이터 캐시는‘새로운’데이터입니다. 즉, 데이터 캐시는 주 서버에서 이루어진 같은 종류의 변경을 기반으로 데이터와 인덱스 페이지로 채워집니다. 미러 캐시를 주 서버 캐시 와 비슷하게 만들려면 데이터베이스 미러링이 SELECT 힌트를 미러에 전달하여 데이터 쿼리에 사용되는 캐시가 미러 서버에서 재생성되도록 합니다. 이는 미러 서버를 주 서버와 비슷하게 만들고 장애 조치의 경우 나머지 재실행 시간을 줄이는 데 도움 을 줍니다. 명확하게 데이터베이스 스냅샷에 대한 쿼리를 포함하여 미러 서버의 추가 활동은 캐시의 상태에 영향을 미치고 장애 조치의 경우 재실행 단계를 완료하는 기간을 증가시킬 수 있습니다.

데이터베이스 미러링 테스트

데이터베이스 미러링을 테스트하는 자체 시스템을 설치할 때 여러 가지 옵션을 사용할 수 있습니다. 모든 미러링은 데이터베이 스 미러링 세션의 서버가 개별 SQL Server 인스턴스여야 합니다. 따라서 SQL Server 2005의 관련 엔진의 여러 인스턴스를 설 치하는 경우 단일 실제 서버에서 데이터베이스 미러링에 대해 배우고 테스트할 수 있습니다. 단일 가상 서버에서 여러 인스턴 스를 테스트할 수도 있지만 실제 서버에서 수행하는 경우 테스트는 더욱 안전해집니다.

로드나 스트레스를 목적으로 데이터베이스 미러링을 테스트할 때는 별개의 실제 서버가 필요합니다. 단일 서버에 인스턴스가 둘 또는 세 개 있으면 실제 서버의 리소스를 비현실적으로 공유할 수 있습니다. 동일하게 중요한 것은 서버 사이의 적절한 연결 입니다. 주 서버와 미러 서버 사이의 네트워크 연결이 좋을 수록 로그 레코드와 메시지의 전송 속도가 더 나아집니다.

가장 현실적인 테스트는 실제 대상 서버 또는 최종 시스템과 같은 실제 속성을 갖고 있는 테스트 베드에서 수행됩니다. 단일 서버에서 여러 인스턴스를 테스트랄 때 인스턴스 중 하나를 중지하거나 시스템을 종료하여 데이터베이스 미러링에서 서버 손실의 효과를 시뮬레이션만할 수 있습니다. 여러 실제 서버가 있으면 네트워크 케이블의 연결을 끊어 연결 손실을 테스트할 수도 있습니다.

다음 사례는 테스트 조건을 만드는 데 도움을 줄 수 있습니다.

• 서버 오류를 테스트하려면 SQL 구성 관리자를 통하거나 SHUTDOWN WITH NOWAIT를 사용하여 SQL Server 인스턴스를 종료하십시오.
• 통신 오류를 테스트하려면 서버에서 네트워크 케이블을 제거합니다.
• 데이터베이스 오류를 테스트하려면 SQL Server 서버를 테스트하고 기본.mdf 파일 이름을 바꾸려면 SQL Server를 다시 시작합니다.
• 미러에서 재실행 오류를 일으키려면 미러 서버에 없는 드라이버 볼륨의 주 데이터베이스에 파일을 추가합니다.
• 미러 서버에서 재실행 오류를 일으키는 또 다른 방법은 미러 서버 데이터 파일을 공간이 부족한 디스크에서 실행시키는 것입 니다.
• 주 서버에서 데이터베이스를 강제로 종료하려면 주 서버 데이터 파일을 공간이 부족한 디스크에서 강제로 시작합니다.
• 로그 버퍼 저장이 주 서버 또는 미러 버퍼에서 강제 실행되도록 하려면 로그 파일을 공간이 부족한 디스크에서 강제로 실행 합니다.

미러 서버의 장애 조치 준비

데이터베이스 미러링은 엄격히 데이터베이스 간 관계입니다. 데이터베이스 데이터만 주 서버에??다. 로그 전달과 복제와 마찬가지로 장애 조치의 경우 완벽하게 역할을 맡도록 미러 데이터베이스를 사용하 여 대기 서?려할 수준은 여러 가지가 있습니다.

실제 서버 수준에서 대기 서버는 가능한 유사한 실제 CPU와 메모리 구성을 갖고 있어야 하며, 그렇지 않으면 대기 서버는 장애 조치 후에 수행됩니다. 데이터베이스 응용 프로그램을 지원하는 지원 응용 프로그램, 모니터 또는 기타 실행 파일도 있을 수 있으며 미러 서버에서 구성해야 합니다.

SQL Server 수준에서 대기 서버는 같은 SQL Server 구성(예 그러나 가장 기본적인 것은 로그인과 해당 권한이 될 것입니다. 주 서버의 모든 활성 SQL Server 로그인은 미러 서버에도 있어야 합니다. 그렇지 않으면 응용 프로그램은 장애 조치의 경우 새로운 주 서버로 사용할 수 없게 됩니다. SQL Server Integration Services 에는 한 서버에서 다른 서버로 로그인과 암호를 복사하는 데 사용할 수 있는 Transfer Logins 작업이 있지만 이러한 로그인에 대한 데이터베이스 권한을 설정해야 할 수 있습니다. 다른 도메인에 있는 서버로 로그인을 전송하는 경우 SID가 일치하지 않을 수 있으며 일치시켜야 합니다.

대기 서버로 마이그레이션해야 할 주 SQL Server에 여러 가지 지원 개체가 있을 수 있습니다. 몇 가지를 열거해 보면 SQL Agent 작업과 경고, SQL Server Integration Services 패키지, 지원 데이터베이스, 링크된 서버 정의, 백업 서비스, 유지 관리 계획, SQL Mail 또는 Database Mail 설정, Distributed Transaction Coordinator 설정 등이 있습니다.

SQL Agent 작업을 대기 서버로 전송하면 대부분 사용하지 말아야 합니다. 장애 조치의 경우 이러한 작업을 사용해야 합니다.

장애 조치 후에 응용 프로그램이 SQL Server 인증을 사용하는 경우 새로운 주 데이터베이스의 사용자가 새로운 주 SQL Server에서 로그인을 확인해야 합니다. 이를 위한 가장 좋은 도구는 저장 프로시저 sp_change_users_login입니다.

다중 데이터베이스 문제

많은 응용 프로그램이 단일 서버에서 여러 데이터베이스를 사용합니다. 한 응용 프로그램이 여러 데이터베이스를 참조하거나 모든 응용 프로그램이 여러 데이터베이스를 사용할 수도 있습니다. 그러나 데이터베이스 미러링은 한 번에 한 데이터베이스만 사용합니다. 데이터베이스 아키텍처에 미러링을 설계할 때는 이것을 고려해야 합니다.

고가용성 모드가 필요할 경우 가장 좋은 방법은 한 응용 프로그램을 한 데이터베이스와 일치시키는 것입니다. 자동 장애 조치가 발생하는 경우 응용 프로그램은 더 이상 주 서버에 데이터베이스를 요구하지 않습니다. 단일 서버에 여러 데이터베이스가 있고 고가용성 모드에서 작동하는 경우 어떤 일이 발생할 수 있는지 고려하십시오. 실제 서버 중단, SQL Server 인스턴스 오류 또는 통신 오류가 발생한 경우 모든 데이터베이스는 대기 서버로 자동으로 장애 조치되며 미러 서버는 새로운 주 데이터베이스가 됩니다. 감시 서버를 볼 수 있는 경우 응용 프로그램은 새로운 주 데이터베이스에 연결할 수 있습니다. 그러나 데이터베이스 중 하나에서 디스크 오류로 손상된 페이지가 발생하여 한 데이터베이스만 장애 조치된 경우 어떤 일이 발생할까요? 이 경우 응용 프로그램이 적절한 모든 데이터베이스에 연결하는 것이 불가능할 수 있습니다.

따라서 여러 데이터베이스에 의존하는 응용 프로그램은 데이터베이스 미러링의 고가용성 모드에 적합하지 않을 것입니다.

자동 장애 조치가 없지만 다른 데이터베이스 서버가 동기화를 유지하는 고성능 방법이 없다는 것을 인식하여 안전성 OFF를 사용할 수 있습니다.