[MSSQL] SQL Server 2005의 데이터베이스 미러링

SQL Server 2005의 데이터베이스 미러링

게시 날짜: 2005년 4월 1일

작성자: Ron Talmage, Solid Quality Learning

이 페이지에서

중요:
소개
데이터베이스 미러링 개요
데이터베이스 미러링 다이내믹스
데이터베이스 미러링 가용성 시나리오
데이터베이스 미러링 구현
데이터베이스 미러링 및 고가용성 기술
결론

중요:

Microsoft 지원 정책은 SQL Server 2005 서비스 팩 1(SP1) 이상과 함께 제공되는 데이터베이스 미러링 기능에만 적용됩니다. SP1 이상이 설치된 SQL Server 2005를 실행하고 있지 않는 경우에는 데이터베이스 미러링을 프로덕션 환경에서 사용할 수 없습니다. Microsoft 지원 서비스는 RTM 릴리스의 데이터베이스 미러링을 사용하는 데이터베이스 또는 응용 프로그램을 지원하지 않습니다.

페이지 위쪽

소개

데이터베이스 미러링은 데이터베이스 가용성 향상을 위해 검토할 수 있는 새로운 SQL Server 2005 기술입니다. 데이터베이스 미러링을 이용하면 트랜잭션 로그 레코드를 서버 간에 직접 전송할 수 있으며 대기 서버로 장애 조치를 빠르게 수행할 수 있습니다. 연결 정보를 자동으로 리디렉션하고 장애 조치 시 대기 서버와 데이터베이스에 자동으로 연결되도록 클라이언트 응용 프로그램 코드를 작성할 수 있습니다. 일반적으로 데이터 손상을 최소화하면서 신속한 장애 조치를 수행하려면 하드웨어 비용이 많이 들고 소프트웨어가 복잡해집니다. 그러나 데이터베이스 미러링은 커밋된 데이터의 손실 없이 신속하게 장애 조치를 수행할 수 있으며 전용 하드웨어가 필요 없고 설정 및 관리가 용이합니다.

페이지 위쪽

데이터베이스 미러링 개요

데이터베이스 미러링에서 원본 SQL Server 2005 인스턴스는 데이터베이스의 트랜잭션 로그 레코드를 다른 대기 SQL Server 인스턴스에 있는 데이터베이스 복사본으로 계속해서 보냅니다. 원본 데이터베이스 및 서버는 주 역할을 담당하고 수신 데이터베이스 및 서버는 미러 역할을 담당합니다. 주 서버와 미러 서버는 서로 분리된 SQL Server 2005 인스턴스여야 합니다.

모든 SQL Server 데이터베이스에서는 데이터 변경 내용이 실제 데이터 페이지에 적용되기 전에 트랜잭션 로그에 기록됩니다. 트랜잭션 로그 레코드는 먼저 메모리에 있는 데이터베이스의 로그 버퍼에 놓여진 다음 최대한 빨리 디스크에 플러시(또는 확정)됩니다. 데이터베이스 미러링에서 주 서버는 주 데이터베이스의 로그 버퍼를 디스크에 기록할 때 해당 로그 레코드 블록을 미러 인스턴스로도 동시에 보냅니다.

로그 레코드 블록을 받은 미러 서버는 먼저 로그 레코드를 미러 데이터베이스의 로그 버퍼에 넣은 다음 최대한 빨리 디스크에 플러시합니다. 이러한 트랜잭션 로그 레코드는 나중에 미러에서 재생됩니다. 미러 데이터베이스에서 주 데이터베이스의 트랜잭션 로그 레코드가 재생되기 때문에 미러 데이터베이스는 주 데이터베이스의 변경 내용을 복제합니다.

주 서버와 미러 서버는 데이터베이스 미러링 세션에서 서로를 파트너로 생각합니다. 데이터베이스 미러링 세션은 한 파트너에서 다른 파트너로 데이터베이스를 미러링할 때 파트너 서버들 간의 관계로 이루어집니다. 주어진 파트너 서버 하나가 한 데이터베이스에 대해서는 주 역할을 담당하고 다른 데이터베이스에 대해서는 미러 역할을 담당할 수 있습니다.

데이터베이스 미러링 세션에서는 두 파트너 서버(주 및 미러)와 함께 미러링 모니터 서버라는 선택적인 세 번째 서버가 있을 수 있습니다. 미러링 모니터 서버의 역할은 자동 장애 조치를 수행하는 것입니다. 고가용성을 위해 데이터베이스 미러링을 사용할 때 주 서버에 갑자기 오류가 발생한 경우 미러 서버가 미러링 모니터 서버로부터 확인을 받으면 미러 서버는 자동으로 주 서버 역할을 수행하게 되고 몇 초 이내에 데이터베이스를 사용할 수 있게 됩니다.

데이터베이스 미러링과 관련하여 다음과 같은 몇 가지 중요한 항목을 고려해야 합니다.

주 데이터베이스는 전체 복구 모델에 포함되어야 합니다. 대량 로그 작업의 결과로 만들어진 로그 레코드는 미러 데이터베이스에 보낼 수 없습니다.
미러 데이터베이스는 NORECOVERY를 사용하여 주 데이터베이스를 복원함으로써 초기화해야 하며 그런 다음 주 트랜잭션 로그 백업 순서에 따라 복원이 이루어져야 합니다.
미러 데이터베이스의 이름은 주 데이터베이스의 이름과 같아야 합니다.
미러 데이터베이스가 복구 중 상태인 경우에는 직접 액세스할 수 없습니다. 미러에 데이터베이스 스냅숏을 만들어서 일정 시점의 미러 데이터베이스를 간접적으로 읽을 수 있습니다. 이 문서의 뒷부분에서 다루는 '데이터베이스 미러링 및 데이터베이스 스냅숏'을 참조하십시오.

참고: 데이터베이스 미러링 관련 용어에 대한 자세한 내용은 SQL Server 2005 온라인 설명서의 "데이터베이스 미러링 개요"를 참조하십시오.

운영 모드

데이터베이스 미러링 세션에는 세 가지 운영 모드가 있습니다. 정확한 모드는 트랜잭션 안전성 설정과 미러링 모니터 서버가 미러링 세션에 포함되어 있는지 여부에 따라 결정됩니다.

표 1: 데이터베이스 미러링 운영 모드

운영 모드	트랜잭션 안전성	전송 메커니즘	쿼럼 필요	미러링 모니터 서버	장애 조치 유형
가용성 우선	FULL	동기	Y	Y	자동 또는 수동
보호 우선	FULL	동기	Y	N	수동만
성능 우선	OFF	비동기	N	해당 사항 없음	강제만

안전성이 FULL이고 미러링 모니터 서버가 설정된 경우 동기 데이터 전송이 발생하며 데이터베이스 서비스를 위해 쿼럼이 필요합니다. 두 파트너 서버가 각각 수행해야 하는 역할(즉, 주 서버와 미러 서버)을 결정하는 쿼럼 투표를 수행하려면 두 개 이상의 서버가 있어야 합니다.

세 가지 운영 모드를 보다 자세하게 살펴보려면 먼저 트랜잭션 안전성과 쿼럼의 역할을 자세하게 알아보아야 합니다.

트랜잭션 안전성

트랜잭션 안전성(또는 '안전성')이 FULL로 설정된 경우 주 서버와 미러 서버는 동기 전송 모드로 동작합니다. 주 서버는 주 데이터베이스 로그 레코드를 디스크에 플러시할 때 해당 레코드를 미러 서버로도 보냅니다. 그런 다음 주 서버는 미러 서버의 응답을 기다립니다. 미러 서버는 동일한 로그 레코드를 미러 서버의 로그 디스크에 플러시한 후 응답을 보냅니다. 안전성이 OFF로 설정된 경우 주 서버는 미러 서버의 승인을 기다리지 않으므로 주 서버와 미러 서버가 완전히 동기화되지 않을 수 있습니다. 즉, 미러 서버가 주 서버와 동일하게 유지되지 않을 수 있습니다.

동기 전송은 미러 데이터베이스의 트랜잭션 로그에 있는 모든 트랜잭션이 주 데이터베이스의 트랜잭션 로그와 동기화되도록 보장하므로 트랜잭션이 안전하게 전송된다고 볼 수 있습니다. 다음 코드를 사용하여 안전성을 FULL로 설정합니다.

코드 복사

ALTER DATABASE [<dbname>] SET SAFETY FULL;

안전성이 OFF로 설정된 경우 주 서버와 미러 서버는 비동기 통신을 수행합니다. 주 서버는 트랜잭션 레코드 블록이 플러시되었음을 알리는 미러 서버의 승인을 기다리지 않습니다. 미러 서버는 최대한 신속하게 트랜잭션을 기록하여 주 서버와 동일한 상태를 유지하려고 하지만 주 서버에 갑자기 오류가 발생하여 미러 서버가 주 서버 역할을 수행하게 되는 경우 일부 트랜잭션이 손실될 수 있습니다. SQL Server 온라인 설명서의 '강제 서비스' 항목을 참조하십시오.

쿼럼 및 미러링 모니터 서버

미러링 모니터 서버가 설정된 경우 데이터베이스 미러링 세션에는 데이터베이스 서비스를 유지하기 위해 쿼럼이 필요합니다. 쿼럼은 동기 데이터베이스 미러링 세션에서 필요한 모든 연결된 서버 간의 최소 관계입니다. 쿼럼에는 두 개 이상의 서버가 필요하기 때문에 미러링 모니터 서버가 설정된 경우에는 안전성 설정과 관계없이 주 서버는 데이터베이스 서비스를 유지하기 위해 하나 이상의 다른 서버와 쿼럼을 구성해야 합니다. 일반적으로 미러링 모니터 서버가 설정되면 안전성 수준도 FULL로 설정됩니다.

미러링 모니터 서버는 주 서버 또는 미러 서버의 쿼럼 구성을 지원합니다. 미러링 모니터 서버가 있을 경우 주 데이터베이스 또는 미러 데이터베이스가 손실되면 나머지 두 서버가 쿼럼을 구성합니다. 주 서버가 미러 서버를 볼 수 없는 경우 주 서버는 미러링 모니터 서버와 함께 쿼럼을 구성하여 데이터베이스 서비스를 유지할 수 있습니다. 마찬가지로 미러 서버와 미러링 모니터 서버가 주 서버를 볼 수 없는 경우 미러 서버는 미러링 모니터 서버와 쿼럼을 구성하고 새로운 주 서버 역할을 수행할 수 있습니다.

미러링 모니터 서버에 오류가 발생한 경우 주 서버와 미러 서버는 계속해서 쿼럼을 구성하기 때문에 미러링 모니터 서버는 데이터베이스 미러링 세션에서 단일 지점 장애로 간주되지 않습니다. 자세한 내용은 SQL Server 온라인 설명서의 "데이터베이스 미러링 세션의 쿼럼" 항목을 참조하십시오.

가용성 우선 운영 모드

가용성 우선 운영 모드는 주 데이터베이스에 오류가 발생한 경우 미러 데이터베이스로의 자동 장애 조치를 수행하여 데이터베이스 가용성을 최대로 유지하도록 지원합니다. 이 운영 모드에서는 안전성을 FULL로 설정하고 미러링 모니터 서버를 데이터베이스 미러링 세션에 포함시켜 정의해야 합니다.

가용성 우선 모드는 서버 간에 빠르고 매우 안정적인 통신 경로를 갖고 있고 단일 데이터베이스에 대한 자동 장애 조치가 필요한 경우에 적합합니다. 안전성이 FULL로 설정된 경우 주 서버는 미러 서버의 응답을 기다려야 하므로 미러 서버의 기능이 주 서버의 성능에 영향을 미칠 수 있습니다. 이 모드에서는 단일 데이터베이스 오류로 인해 자동 장애 조치가 수행될 수 있기 때문에 다중 데이터베이스 응용 프로그램을 사용하는 경우에는 다른 운영 모드를 고려할 수 있습니다. 이 문서의 뒷부분에 나오는 구현 단원의 "다중 데이터베이스 문제"를 참조하십시오.

가용성 우선 모드에서 데이터베이스 미러링은 자체적으로 모니터링을 수행합니다. 주 데이터베이스가 갑자기 사용할 수 없게 되거나 주 서버가 종료되면 미러링 모니터 서버와 미러 서버가 쿼럼을 구성한 다음 미러 SQL Server가 자동 장애 조치를 수행합니다. 바로 이 때 미러 서버 인스턴스의 역할이 변경되면서 새로운 주 서버가 되어 데이터베이스를 복구합니다. 미러 서버는 주 서버의 트랜잭션 로그를 재생해 왔고 미러 서버의 트랜잭션 로그는 주 서버의 트랜잭션 로그와 동기화되어 있기 때문에 미러 서버는 빠르게 사용 가능 상태로 전환됩니다.

또한 SQL Server 2005의 경우 복구 프로세스의 초기 단계부터 사용자가 데이터베이스를 사용하도록 만들 수 있습니다. SQL Server 데이터베이스 복구는 분석 단계, 다시 실행 단계 및 실행 취소 단계의 3단계로 구성됩니다. SQL Server 2005에서 새로 복구된 데이터베이스는 다시 실행 단계가 완료된 후 바로 사용할 수 있습니다. 따라서 데이터베이스 미러링 장애 조치가 발생한 경우 복구된 새로운 주 데이터베이스는 다시 실행 단계가 완료되는 즉시 사용할 수 있게 됩니다. 미러 데이터베이스가 트랜잭션 로그 레코드를 계속 재생해 왔기 때문에 미러 서버는 다시 실행 프로세스만 완료하면 되는데, 이 프로세스는 일반적으로 몇 초 내에 완료할 수 있습니다.

보호 우선 운영 모드

보호 우선 운영 모드 또한 트랜잭션 안전성이 FULL로 설정되지만 미러링 모니터 서버가 미러링 세션에 포함되지 않습니다. 또한 데이터베이스를 서비스하기 위해 주 데이터베이스가 쿼럼을 구성하지 않아도 됩니다. 이 모드에서는 결정권자 역할을 수행하는 미러링 모니터 서버가 없기 때문에 수동 장애 조치만 수행할 수 있습니다. 주 서버에 오류가 발생한 경우 미러 서버와 함께 쿼럼을 구성할 미러링 모니터 서버가 없기 때문에 자동 장애 조치를 수행할 수 없습니다.

정의된 미러링 모니터 서버가 없기 때문에 자동 장애 조치가 발생할 수 없으며, 미러 서버와의 쿼럼을 갑자기 손실한 주 서버는 데이터베이스 서비스를 중단하지 않습니다.

성능 우선 운영 모드

성능 우선 운영 모드에서는 트랜잭션 안전성이 OFF로 설정되고 로그 레코드가 비동기적으로 전송됩니다. 주 서버는 모든 트랜잭션 로그 레코드가 미러 서버에 기록되었음을 알리는 미러 서버의 승인을 기다리지 않습니다. 미러 서버는 최대한 주 서버와 동일한 상태를 유지하려고 시도하지만 특정 시점에서 주 서버의 최신 트랜잭션이 미러 서버의 트랜잭션 로그에 플러시되어 있지 않을 수 있습니다.

안전성이 OFF로 설정되기 때문에 자동 장애 조치를 수행할 수 없으며 데이터 손실이 발생할 수 있습니다. 따라서 이 시나리오에서는 미러링 모니터 서버를 구성하지 않는 것이 좋습니다. 미러링 모니터 서버를 설정한 경우에는 쿼럼이 필요하지만 미러링 모니터 서버를 설정하지 않으면 쿼럼이 필요하지 않습니다. 성능 우선 모드에서는 수동 장애 조치를 사용할 수 없습니다. 수행할 수 있는 유일한 장애 조치 유형은 강제 서비스 장애 조치뿐이며, 이 장애 조치 또한 다음과 같은 수동 작업입니다.

코드 복사

ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

강제 서비스 장애 조치가 수행되면 미러 데이터베이스의 즉시 복구가 실행됩니다. 미러 데이터베이스가 복구될 때 주 서버의 트랜잭션 로그 블록 중 일부를 미러 서버에서 아직 받지 못한 경우 데이터 손실이 발생할 수 있습니다. 성능 우선 모드는 데이터 전송 거리가 멀거나(즉, 원격 사이트 장애 복구) 일부 데이터 손실을 감수할 수 있는 매우 활동적인 데이터베이스를 미러링하는 경우에 적합합니다.

데이터베이스 스냅숏 및 미러 데이터베이스

미러 데이터베이스는 복구 중 상태에 있기 때문에 액세스하거나 읽을 수 없습니다. SQL Server 2005 Enterprise Edition 및 Developer Edition에서는 데이터베이스 스냅숏을 만들어서 특정 시점의 미러 데이터베이스를 읽을 수 있습니다. 데이터베이스 스냅숏은 스냅숏 작성 시점의 일관된 데이터를 보여 주는 읽기 전용 데이터베이스 뷰를 제공합니다.

다른 데이터베이스에 액세스하는 것과 동일한 방법으로 데이터베이스 스냅숏에 액세스할 수 있습니다. 데이터베이스 스냅숏을 쿼리하면 스냅숏을 만든 이후에 변경된 모든 데이터베이스 데이터의 원래 버전은 데이터베이스 스냅숏 파일에서 읽고, 변경되지 않은 데이터는 원본 데이터베이스에서 읽습니다. 결과적으로 스냅숏을 만든 시점의 데이터베이스 데이터를 보게 됩니다. 자세한 내용은 SQL Server 온라인 설명서의 "데이터베이스 미러링을 통해 데이터베이스 스냅숏 사용" 항목을 참조하십시오.

데이터베이스 스냅숏을 만들면 미러 서버에 약간의 오버헤드가 발생하기 때문에 데이터베이스 미러링 성능에 미치는 영향이 어느 정도인지 고려해야 합니다. 한 개의 데이터베이스만을 미러링할 수 있으므로 많은 읽기 전용 보고 서버로 미러링을 확장해야 하는 경우에는 트랜잭션 복제를 사용하는 것이 좋습니다. 자세한 내용은 뒷부분의 구현 단원에 나오는 "데이터베이스 미러링 및 복제"를 참조하십시오.

클라이언트 쪽 리디렉션

SQL Server 2005에서 ADO.NET 또는 SQL Native Client를 사용하여 미러링되고 있는 데이터베이스에 연결한 경우에는 응용 프로그램에서 데이터베이스 미러링 장애 조치가 발생할 때 연결을 자동으로 리디렉션하는 드라이버의 기능을 사용할 수 있습니다. 연결 문자열에 초기 주 서버 및 데이터베이스를 지정해야 하고 선택적으로 장애 조치 파트너 서버를 지정할 수 있습니다.

연결 문자열을 작성하는 방법은 여러 가지이지만 여기에서는 하나의 예로서 다음과 같이 서버 A를 주 서버로 지정하고, 서버 B를 미러 서버로 지정하고, AdventureWorks를 데이터베이스 이름으로 지정합니다.

코드 복사

"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;Integrated Security=True;"

연결 문자열의 장애 조치 파트너는 초기 주 서버에 대한 연결에 오류가 발생한 경우 대체 서버 이름으로 사용됩니다. 초기 주 서버에 대한 연결이 성공한 경우에는 장애 조치 파트너 이름이 사용되지 않지만 드라이버는 주 서버에서 검색한 장애 조치 파트너 이름을 클라이언트 쪽 캐시에 저장합니다.

클라이언트가 주 서버에 성공적으로 연결되었고 데이터베이스 미러링 장애 조치(자동, 수동 또는 강제)가 발생했다고 가정해 봅시다. 나중에 응용 프로그램이 해당 연결을 사용하려고 시도하면 ADO.NET 또는 SQL Native Client 드라이버는 기존 주 서버에 대한 연결이 실패했음을 감지하고 자동으로 장애 조치 파트너 이름에 지정된 새로운 주 서버로 다시 연결하려고 시도합니다. 새 주 서버에 연결되고 새 주 서버에 데이터베이스 미러링 세션용으로 지정된 새 미러 서버가 있으면 드라이버가 새 파트너 장애 조치 서버 이름을 검색하여 클라이언트 캐시에 저장합니다. 클라이언트가 대체 서버에 연결할 수 없는 경우 드라이버는 로그인 시간 제한에 도달할 때까지 각 서버에 대해 교대로 연결을 시도합니다.

ADO.NET 및 SQL Native Client 드라이버에 포함된 데이터베이스 미러링 지원 기능을 사용하면 데이터베이스 미러링 장애 조치를 처리하기 위해 응용 프로그램의 코드를 다시 작성하거나, 응용 프로그램에 특수 코드를 추가할 필요가 없다는 큰 장점이 있습니다.

ADO.NET 또는 SQL Native Client 자동 리디렉션을 사용하지 않더라도 다른 기술을 사용하여 응용 프로그램을 장애 조치할 수 있습니다. 예를 들어, 네트워크 부하 분산을 사용하면 클라이언트를 가상 서버 이름에 연결한 상태에서 한 서버에서 다른 서버로 연결을 수동으로 리디렉션할 수 있습니다. 리디렉션 코드와 재시도 논리를 직접 작성할 수도 있습니다.

그러나 클라이언트 리디렉션과 데이터베이스 미러링을 조정하는 이러한 모든 기술에는 중요한 제한 사항이 있습니다. 데이터베이스 미러링은 서버 수준에서는 발생하지 않고 데이터베이스 수준에서만 발생합니다. 응용 프로그램에서 한 서버에 있는 여러 데이터베이스를 사용하거나 여러 부분으로 구성된 개체 이름을 사용하여 여러 데이터베이스에 쿼리하는 경우에는 주의해야 합니다. 여러 데이터베이스가 하나의 서버에 있고 이러한 데이터베이스가 대기 서버로 미러링된 경우 여러 데이터베이스 중 하나가 대기 서버로 미러링되고 나머지 데이터베이스는 원본 서버에 남아 있을 수 있습니다. 이러한 경우 하나의 데이터베이스만 주 데이터베이스이고 나머지는 미러 데이터베이스이기 때문에 대기 서버에 대해 교차 데이터베이스 쿼리가 수행되지 않도록 하기 위해서는 쿼리하는 데이터베이스당 하나의 연결이 필요합니다.

데이터베이스 미러링 및 SQL Server 2005 Edition

다음 표에서는 다양한 SQL Server 2005 Edition에서 지원되는 데이터베이스 미러링 기능을 보여 줍니다.

표 2: 데이터베이스 미러링 및 SQL Server 2005 Edition

다음과 같은 몇 가지 데이터베이스 미러링 기능을 사용하려면 QL Server 2005 Enterprise 또는 Developer Edition이 필요합니다.

안전성이 OFF로 설정된 성능 우선 모드(비동기 데이터 전송)
데이터베이스 스냅숏
여러 스레드를 사용하여 미러 데이터베이스에서 트랜잭션 로그 재생(병렬 다시 실행)

SQL Express 및 Workgroup Edition은 미러링 모니터 서버로 사용할 수 있지만 데이터베이스 미러링의 파트너 서버로 사용할 수는 없습니다.

페이지 위쪽

데이터베이스 미러링 다이내믹스

SQL Server 2005 데이터베이스 미러링을 보다 깊이 있게 이해하려면 데이터베이스 미러링 세션이 시간이 지남에 따라 어떻게 변하는지 알아 두는 것이 좋습니다. 이 단원에서는 데이터베이스 미러링 세션의 여러 가지 데이터베이스 상태, 동기 및 비동기 로그 레코드 전송의 메커니즘, 장애 조치 순서에 대해 설명합니다.

설정 및 보안

주 서버, 미러 서버 및 선택적인 미러링 모니터 서버를 식별하고 나면 데이터베이스 미러링을 설정하는 작업은 기본적으로 세 단계로 구성됩니다.

데이터베이스를 백업한 다음 복구 없이 원하는 미러 서버로 복원해야 합니다.

참고: 데이터베이스를 백업하여 미러 서버로 복원하려면 주 데이터베이스가 전체 복구 모델에 포참되어야 합니다. 트랜잭션 로그에서 대량 로그 레코드를 전송해야 하는 경우에는 데이터베이스 미러링이 작동하지 않습니다. 미러 서버에는 주 데이터베이스와 마찬가지로 파일이 확장될 충분한 여유 공간이 있어야 합니다. 미러 서버에 데이터베이스 스냅숏을 만들려면 이를 위한 추가 여유 공간도 제공해야 합니다.

백업, 복사 및 복원에 상대적으로 오랜 시간이 걸리는 경우에는 원본 데이터베이스에서 트랜잭션 로그 백업을 수행하여 로그 크기를 제어 가능한 수준으로 유지해야 합니다. 그러나 트랜잭션 로그 레코드가 로그 백업에 의해 로그에서 잘린 경우 데이터베이스 미러링을 초기화하지 못할 수 있습니다. 따라서 데이터베이스 미러링을 초기화하기 전에 NORECOVERY를 사용하여 원하는 미러 데이터베이스로 이러한 트랜잭션 로그 백업을 순서대로 복원해야 합니다.

데이터베이스 미러링 세션과 관련된 서버는 서로를 신뢰해야 합니다. 도메인 같은 로컬 통신의 경우 신뢰한다는 것은 각 SQL Server 인스턴스 로그인이 다른 미러링 서버에 연결할 권한이 있어야 하며 해당 끝점을 수행해야 하는 것을 의미합니다. 이를 설정하려면 먼저 각 서버에서 CREATE LOGIN 명령을 사용한 다음 GRANT CONNECT ON ENDPOINT 명령을 사용합니다. SQL Server 온라인 설명서의 "Example of Setting Up Database Mirroring Using Windows Authentication"(영문)을 참조하십시오.

신뢰하지 않는 도메인을 통해 통신하는 경우에는 인증서를 사용해야 합니다. CREATE CERTIFICATE 문을 사용하여 자체 서명된 인증서를 만들면 대부분의 데이터베이스 미러링 인증서 요구 사항이 충족됩니다. 또한 CREATE CERTIFICATE 문에서 인증서가 ACTIVE FOR BEGIN_DIALOG로 표시되었는지 확인해야 합니다.
다음 단계는 데이터베이스 미러링 끝점을 설정하는 것입니다. 끝점을 설정하려면 SQL Server 인스턴스에 대해 시스템 관리자 권한이 있어야 합니다. 데이터베이스 미러링 끝점으로 정확하게 명시된 각 서버에서 끝점을 설정해야 합니다. 끝점을 설정하는 가장 간단한 방법은 데이터베이스 미러링 보안 구성 마법사를 사용하는 것입니다. 이 마법사는 [데이터베이스 속성] 대화 상자의 [미러링] 페이지에서 [보안 구성] 단추를 클릭하여 실행할 수 있습니다. [보안 구성] 대화 상자에서는 CREATE ENDPOINT 명령을 구성하고 실행하기 전에 컴퓨터 이름과 포트 번호를 묻고 선택에 따라 로그인을 요구하기도 합니다. Transact-SQL을 사용하여 CREATE ENDPOINT 명령을 실행할 수도 있습니다. SQL Server 온라인 설명서의 "방법: 미러링 끝점 만들기(Transact-SQL)"를 참조하십시오.

도메인에 데이터베이스 미러링을 설정할 때 모든 SQL Server 인스턴스가 같은 서비스 로그인과 암호를 사용하는 경우 각 서버에 로그인을 만들 필요가 없습니다. 마찬가지로 한 작업 그룹에서 모든 SQL Server 인스턴스가 같은 서비스 로그인과 암호를 사용하는 경우 해당 서버에 로그인을 만들 필요가 없습니다. 끝점을 설정할 때 데이터베이스 미러링 보안 구성 마법사에서 로그인을 비워두기만 하면 됩니다.

각 데이터베이스 끝점은 서버에서 고유한 포트를 지정해야 합니다. 개별 컴퓨터에서 SQL Server 인스턴스 작업을 수행할 경우에는 이러한 포트 번호가 모두 같을 수 있으며 데이터베이스 미러링 보안 구성 마법사에서는 자동으로 포트 5022를 해당 포트로 제안합니다. SQL Server 인스턴스가 같은 컴퓨터에 있는 경우에는 각 인스턴스가 서로 다른 포트를 사용해야 하며 포트 번호가 고유해야 합니다.

가용성 우선 미러링 세션에서 세 개의 서버를 사용한다고 가정합시다. 서버 A는 주 서버, 서버 B는 미러 서버, 서버 W는 미러링 모니터 서버가 됩니다. 서버 A에서 다음 명령을 실행하여 포트 5022에 끝점을 만듭니다.
코드 복사
```
CREATE ENDPOINT [Mirroring] 
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);
```
역할이 PARTNER로 지정되었으므로 이 서버는 지정된 데이터베이스 미러링 데이터베이스에 대해 주 또는 미러 서버의 역할을 맡을 수 있습니다. 서버 B에서 같은 명령을 실행합니다. 서버 B는 별도의 컴퓨터에 있는 SQL Server 인스턴스이므로 포트 번호가 동일합니다. 그런 다음 서버 W에 대해 다음 명령을 실행할 수 있습니다.
코드 복사
```
CREATE ENDPOINT [Mirroring] 
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);
```
서버 W의 경우 역할이 WITNESS로 지정되었습니다.

기본적으로 끝점은 시작이 되지 않습니다. 따라서 각 서버에서 다음 쿼리를 사용하여 각 끝점을 시작할 수 있습니다.
코드 복사
```
ALTER ENDPOINT [Mirroring] STATE = STARTED;
```
선택에 따라 CREATE ENDPOINT 명령에 STATE 옵션을 삽입할 수 있습니다. 이 프로세스는 각 서버에서 반복됩니다.

CREATE ENDPOINT를 사용하여 끝점을 만들 때 프로토콜 관련 인수를 사용하여 IP 주소별로 액세스를 제한할 수 있습니다. RESTRICT_IP를 ALL 옵션과 함께 사용하고 EXCEPT_IP를 원하는 특정 IP 주소 목록과 함께 사용하여 특정 IP 주소 집합에 대한 액세스를 제한할 수 있습니다. SQL Server 온라인 설명서의 "CREATE ENDPOINT"를 참조하십시오.

sys.database_mirroring_endpoints 카탈로그 뷰를 쿼리하여 서버에서 데이터베이스 미러링 끝점을 확인할 수 있습니다.
코드 복사
```
SELECT *
FROM sys.database_mirroring_endpoints;
```
데이터베이스 미러링을 시작하려면 파트너 및 미러링 모니터 서버를 지정합니다. 주어진 데이터베이스 미러링 세션을 시작하고 관리하려면 데이터베이스 소유자 권한이 있어야 합니다. 원하는 주 서버인 서버 A에서 다음 코드를 실행하여 SQL Server가 특정 데이터베이스에 주 역할을 부여하도록 지시하고 파트너(미러) 서버를 지정합니다.
코드 복사
```
-- 주 서버에서 파트너 서버를 지정합니다.
ALTER DATABASE [AdventureWorks] SET PARTNER =
N'TCP://B.corp.mycompany.com:5022';
```
파트너 이름은 파트너의 정규화된 컴퓨터 이름이어야 합니다. 정규화된 이름을 찾는 것이 어려울 수 있지만 데이터베이스 미러링 보안 구성 마법사에서 끝점을 설정할 때 정규화된 이름이 자동으로 검색됩니다.

각 서버의 정규화된 컴퓨터 이름은 명령 프롬프트에서 다음 명령을 실행하여 찾을 수도 있습니다.
코드 복사
```
IPCONFIG /ALL
```
"Host Name"과 "Primary DNS Suffix"를 연결합니다. 다음과 같은 내용이 표시되는 경우

Host Name . . . . . . . . . . . . : A
Primary Dns Suffix . . . . . . . : corp.mycompany.com

컴퓨터 이름은 A.corp.mycompany.com이 됩니다. 여기에 접두사로 'TCP://'를 사용하고 끝에 ':<포트 번호>'를 추가하면 파트너 이름이 만들어집니다.

미러 서버에서 같은 명령을 반복합니다. 그러나 이 경우에는 명명된 주 서버를 사용합니다.
코드 복사
```
-- 미러 서버에서 파트너 서버를 지정합니다.
ALTER DATABASE [AdventureWorks] SET PARTNER =
N'TCP://A.corp.mycompany.com:5022';
```
다음으로 주 서버에서 미러링 모니터 서버를 지정합니다.
코드 복사
```
-- 주 서버에서 미러링 모니터 서버를 지정합니다.
ALTER DATABASE [AdventureWorks] SET WITNESS =
N'TCP://W.corp.mycompany.com:5026';
```
초기 CREATE ENDPOINT 이후에는 미러링 모니터 서버에서 추가 명령을 실행할 필요가 없습니다.

마지막으로 주 서버에서 세션의 안전성 수준을 지정합니다.
코드 복사
```
-- 주 서버에서 안전성 수준을 지정합니다.
ALTER DATABASE [AdventureWorks] SET SAFETY FULL;
```
이 시점에서 미러링이 자동으로 시작되며 주 서버와 미러 서버가 동기화됩니다. ALTER DATABASE에 TIMEOUT 매개 변수를 사용하여 파트너 중단을 결정하는 시간 초과 값을 조정할 수 있습니다. 예를 들어 TIMEOUT 값을 20초(기본값은 10초)로 변경하려면 주 서버에서 다음 명령을 실행합니다.
코드 복사
```
-- 주 서버에서 다음 명령을 실행합니다.
ALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;
```
마지막으로 주 서버에서 REDO_QUEUE 옵션이 지정된 ALTER DATABASE를 실행하여 미러 서버에 있는 다시 실행 큐의 크기를 조정할 수 있습니다. 다음 쿼리는 미러 서버의 다시 실행 큐를 100MB로 설정합니다.
코드 복사
```
-- 주 서버에서 다음 명령을 실행합니다.
ALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;
```
파트너가 지정되면 미러링이 즉시 시작됩니다.

데이터베이스 미러링 카탈로그 뷰

데이터베이스 미러링 세션은 파트너 서버 간에 형성된 관계로 이루어지며 선택적으로 미러링 모니터 서버가 포함될 수 있습니다. 세션에 참여하는 각 서버는 세션에 대한 일부 메타데이터와 데이터베이스의 현재 상태에 대한 정보를 유지합니다. sys.database_mirroring 카탈로그 뷰를 쿼리하여 주 서버나 미러 서버에서 세션을 확인할 수 있습니다. 미러링 모니터 서버 메타데이터는 다른 카탈로그 뷰인 sys.database_mirroring_witnesses를 통해 반환됩니다. 두 카탈로그 뷰에서 볼 수 있는 모든 열에 대한 자세한 내용은 SQL Server 온라인 설명서의 "sys.database_mirroring" 및 "sys.database_mirrroing_witnesses"를 참조하십시오.

데이터베이스 미러링 세션의 작동 방식과 데이터베이스의 가능한 상태를 이해하는 좋은 방법은 카탈로그 뷰에서 데이터를 확인하는 것입니다. 안전성이 FULL로 설정되고 미러링 모니터 서버가 있는 가용성 우선 세션부터 살펴보겠습니다. 다음 쿼리는 주 또는 미러 서버에 대한 기본적인 데이터베이스 미러링 세션의 정보 설명을 반환합니다.

코드 복사

SELECT 
      DB_NAME(database_id) AS 'DatabaseName'
    , mirroring_role_desc 
    , mirroring_safety_level_desc
    , mirroring_state_desc
    , mirroring_safety_sequence
    , mirroring_role_sequence
    , mirroring_partner_instance
    , mirroring_witness_name
    , mirroring_witness_state_desc
    , mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;

다음은 미러링 모니터 서버에서 실행하는 위와 유사한 쿼리이며 미러링 모니터 서버에 대한 관련 설명 세션 정보를 반환합니다.

코드 복사

SELECT 
      Database_name
    , safety_level_desc
    , safety_sequence_number
    , role_sequence_number
    , is_suspended
    , is_suspended_sequence_number
    , principal_server_name
    , mirror_server_name
FROM sys.database_mirroring_witnesses;

이제 일반적인 데이터베이스 미러링 세션에서 두 쿼리의 출력을 비교해 보겠습니다. 안전성을 FULL로 설정하여 서버 A에서 서버 B로 미러링을 설정했다고 가정합니다. 다음 구성을 설정하는 샘플 코드는 뒷부분에 나오는 데이터베이스 미러링 구현에서 "설정 및 보안"을 참조하십시오. 서버 W가 미러링 모니터 서버이며 AdventureWorks 데이터베이스를 미러링합니다. 표 3은 두 파트너에 대한 위 쿼리의 가능한 출력을 보여 줍니다.

표 3: 두 파트너에 대한 샘플 가용성 우선 세션에서 sys.database_mirroring의 출력

파트너 메타데이터 열	주 서버 값: 서버 A	미러 서버 값: 서버 B
db_name(database_id)	AdventureWorks	AdventureWorks
mirroring_role_desc	PRINCIPAL	MIRROR
mirroring_safety_level_desc	FULL	FULL
mirroring_state_desc	SYNCHRONIZED	SYNCHRONIZED
mirroring_safety_sequence	1	1
mirroring_role_sequence	1	1
mirroring_partner_instance	TCP://B.corp.mycompany.com:5022	TCP://A. .corp.mycompany.com:5022
mirroring_witness_name	TCP://W.corp.mycompany.com:5022	TCP://W.corp.mycompany.com:5022
mirroring_witness_state_desc	CONNECTED	CONNECTED
mirroring_failover_lsn	95000000007300001	95000000007300001

데이터베이스 미러링 세션의 각 파트너는 파트너의 관점에서 모두 같은 메타데이터를 유지합니다. 각 파트너는 자체 데이터베이스 이름, 전체 세션의 안전성 설정, 데이터베이스의 미러링 상태 및 두 개의 시퀀스 카운터를 유지합니다.

mirroring_safety_sequence 카운터는 양쪽 파트너에서 유지되며 안전성 설정이 변경될 때마다 증가합니다.
mirroring_role_sequence 카운터는 양쪽 파트너와 미러링 모니터 서버에서 유지되며 장애 조치가 발생할 때마다 증가합니다.

양쪽 파트너 데이터베이스 상태와 미러링 모니터 서버 상태는 각 파트너 서버에서 유지됩니다.

mirroring_state_desc는 세션에서 파트너 데이터베이스의 상태를 보여 줍니다.
mirroring_witness_state_desc는 세션에서 미러링 모니터 서버의 상태를 보여 줍니다.

마지막으로 각 파트너에는 mirroring_failover_lsn이 포함되어 있습니다. LSN은 각 트랜잭션 로그 레코드를 고유하게 식별하는 로그 시퀀스 번호입니다. 미러링 파트너는 세션에 대해 플러시된 마지막 로그 레코드 집합에서 가장 높은 LSN에 1을 더한 값을 저장합니다. 위의 표에서는 주 데이터베이스의 작업량이 적었기 때문에 미러링 장애 조치 lsn이 주 서버와 미러링 모니터 서버에서 동일했습니다. 많은 데이터를 전송할 때는 미러가 약간 늦게 실행되기 때문에 주 서버의 값이 미러 서버의 값보다 앞서 있는 것을 볼 수 있습니다.

이제 미러링 모니터 서버에 있는 메타데이터를 비교해 보겠습니다. 다음 표는 미러링 모니터 서버 메타데이터에 있는 유사한 정보를 보여 줍니다.

표 4: 파트너 메타데이터와 관련된 미러링 모니터 서버에서의 sys.database_mirroring_witnesses 출력

미러링 모니터 서버 메타데이터 열	미러링 모니터 서버 값	해당 파트너 메타데이터 열
database_name	AdventureWorks	db_name(database_id)
safety_level_desc	FULL	mirroring_safety_level_desc
safety_sequence_number	1	mirroring_safety_sequence
role_sequence_number	1	mirroring_role_sequence
is_suspended	0
is_suspended_sequence_number	1
principal_server_name	TCP://A. .corp.mycompany.com:5022
mirror_server_name	TCP://B.corp.mycompany.com:5022

미러링 모니터 서버의 메타데이터에는 이름은 약간 다르지만 안전성 설명, 안전성 시퀀스 번호 및 역할 시퀀스 번호가 포함되어 있습니다. 또한 미러링 모니터 서버는 세션의 일시 중단 여부에 대한 데이터와 주 서버 및 미러 서버 이름을 유지합니다. 미러링 모니터 서버 카탈로그 뷰는 미러링 장애 조치 lsn을 보고하지 않으며 데이터베이스 상태에 대한 정보를 유지하지 않습니다.

데이터베이스 미러링에 필요한 모든 메타데이터(특히 미러링 장애 조치 lsn 및 파트너 서버 이름)는 미러링 파트너가 유지합니다. 미러링 모니터 서버는 가용성 우선 모드에서 미러링 모니터 서버 역할을 수행하는 데 필요한 데이터(특히 세션에서 역할 변경 횟수를 추적하는 역할 시퀀스 번호)만 유지합니다. 이 카운터는 주 서버가 역할을 변경할 시점을 결정하는 데 사용됩니다. 다음 단원에서 이와 관련된 시나리오를 설명합니다.

데이터베이스 미러링 상태 및 전환

각 서버의 데이터베이스 상태는 데이터베이스 미러링 세션 동안 유지되며, 각 파트너 서버에 기록되고, sys.database_mirroring 카탈로그 뷰에 의해 보고됩니다. mirroring_state 열은 상태 번호를 반환하고 mirroring_state_desc 열은 상태에 대한 설명 이름을 반환합니다. 데이터베이스 상태 번호와 설명 이름에 대한 전체 목록은 SQL Server 온라인 설명서의 "sys.database_mirroring"을 참조하십시오. 미러링 모니터 서버에 대한 상태 정보도 동일한 카탈로그 뷰에서 보고됩니다.

각 데이터베이스에 대해 보고된 상태 이외에 데이터베이스 미러링에 관련된 서버와 데이터베이스를 설명하는 데 유용한 세 가지 표현이 있습니다.

주 서버에서 트랜잭션을 처리 중이지만 로그 데이터가 미러로 보내지지 않을 경우 주 서버의 데이터가 노출되었다라고 합니다.
주 서버가 데이터베이스에 대한 사용자 연결과 트랜잭션 처리를 허용하지 않을 경우 데이터베이스를 서비스할 수 없다라고 합니다.
한 서버가 데이터베이스 미러링 세션에서 다른 서버에 연결할 수 없고 다른 서버도 해당 서버에 연결할 수 없는 경우 이 서버를 격리되었다라고 합니다.

주 데이터베이스가 노출되어 있더라도 사용자는 연결할 수 있으며 트랜잭션도 처리할 수 있습니다. 그러나 로그 레코드가 미러 데이터베이스에 보내지지 않으므로 주 서버에 오류가 발생하면 주 데이터베이스가 노출 상태로 전환된 시점 이후의 모든 주 서버 트랜잭션이 미러에 존재하지 않게 됩니다. 또한 주 서버의 트랜잭션 로그가 잘리지 않기 때문에 로그 파일이 무한대로 증가하게 됩니다.

미러링 모니터 서버가 설정되어 있는 경우 주 서버가 다른 서버와 쿼럼을 구성할 수 없으면 데이터베이스 서비스가 중지됩니다. 이렇게 되면 주 데이터베이스에서 사용자 연결과 트랜잭션이 허용되지 않고 모든 현재 사용자의 연결이 끊어집니다. 다시 쿼럼을 구성할 수 있게 되면 데이터베이스를 다시 서비스합니다.

서버는 작동하지만 서버와 데이터베이스 미러링 세션에 있는 다른 두 서버 사이의 통신 회선이 다운될 수 있습니다. 이 경우 서버가 격리되었다라고 합니다. 미러링 모니터 서버가 설정되어 있을 경우 주 서버가 격리되면 세션에 쿼럼을 구성할 수 있는 서버가 없기 때문에 데이터베이스를 더 이상 서비스할 수 없습니다.

이제 주 서버 및 데이터베이스에서 시작하여 데이터베이스 미러링 상태에 대해 중점적으로 설명합니다.

주 서버 데이터베이스 상태

안전성이 FULL일 경우 주 데이터베이스의 일반 작동 상태는 SYNCHRONIZED 상태입니다.
안전성이 OFF인 경우 주 데이터베이스의 일반 작동 상태는 SYNCHRONZING 상태에서 시작합니다. 미러 데이터베이스가 주 데이터베이스와 동기화되면 SYNCHRONIZED 상태로 전환되고 주 데이터베이스와 어느 정도 차이가 나는지에 상관없이 이 상태를 유지합니다.

안전성이 FULL이면 주 데이터베이스는 항상 SYNCHRONIZING 상태에서 시작하고 주 데이터베이스와 미러 데이터베이스의 트랜잭션 로그가 동기화되면 SYNCHRONIZED 상태로 전환됩니다.
안전성이 FULL이고 주 서버가 미러링 모니터 서버와 연결이 끊어졌지만 여전히 트랜잭션을 처리할 수 있으면 데이터베이스가 노출됩니다.

다음 표는 주 데이터베이스의 가능한 상태와 다른 상태로 전환시킬 수 있는 일부 이벤트를 보여 줍니다.

표 5: 미러링 모니터 서버가 설정된 경우 안전성 설정(FULL 또는 OFF)에 따른 주 데이터베이스 상태

안전성	주 데이터베이스 초기 상태	이벤트	결과 상태	쿼럼	노출 여부	DB 서비스 가능
FULL	SYNCHRONIZING	동기화 발생	SYNCHRONIZED	Y	N	Y
FULL	SYNCHRONIZED	세션 일시 중지	SUSPENDED	Y	Y	Y
FULL	SYNCHRONIZED	미러에서의 다시 실행 오류	SUSPENDED	Y	Y	Y
FULL	SYNCHRONIZED	미러 사용 불가능	DISCONNECTED	Y, 미러링 모니터 서버 있음 N, 미러링 모니터 서버 없음	Y -	Y N
OFF	SYNCHRONIZING	세션 일시 중지	SUSPENDED	?	Y	Y
OFF	SYNCHRONIZING	미러에서의 다시 실행 오류	SUSPENDED	-	Y	Y
OFF	SYNCHRONIZING	미러 사용 불가능	DISCONNECTED	Y, 미러링 모니터 서버 있음 N, 미러링 모니터 서버 없음	Y -	Y N

표 6 미러링 모니터 서버가 설정되어 있지 않은 경우 안전성 설정(FULL 및 OFF)에 따른 주 데이터베이스 상태

안전성	주 데이터베이스 초기 상태	이벤트	결과 상태	노출 여부	DB 서비스 가능
전체	SYNCHRONIZING	동기화 발생	SYNCHRONIZED	N	Y
FULL	SYNCHRONIZED	세션 일시 중지	SUSPENDED	Y	Y
FULL	SYNCHRONIZED	미러에서의 다시 실행 오류	SUSPENDED	Y	Y
FULL	SYNCHRONIZED	미러 사용 불가능	DISCONNECTED	Y	Y
OFF	SYNCHRONIZING	세션 일시 중지	SUSPENDED	Y	Y
OFF	SYNCHRONIZING	미러에서의 다시 실행 오류	SUSPENDED	Y	Y
OFF	SYNCHRONIZING	미러 사용 불가능	DISCONNECTED	Y	Y

안전성이 FULL인 경우 처음에 주 데이터베이스는 SYNCHRONIZING 상태가 되고 미러와 동기화되는 즉시 두 파트너 모두 SYNCHRONIZED 상태가 됩니다. 안전성이 OFF이면 주 데이터베이스는 SYNCHRONIZING 상태로 시작됩니다. 미러 데이터베이스가 주 데이터베이스와 동기화되면 SYNCHRONIZED 상태로 전환되고 주 데이터베이스와 어느 정도 차이가 나는지에 상관없이 이 상태를 유지합니다.

안전성 설정이 어떠하든 세션이 일시 중지되거나 미러에 다시 실행 오류가 발생하면 주 데이터베이스는 SUSPENDED 상태가 됩니다. 미러를 사용할 수 없게 되면 주 데이터베이스는 DISCONNECTED 상태가 됩니다.

DISCONNECTED 및 SUSPENDED 상태의 경우

미러링 모니터 서버가 설정되어 있고 주 서버가 미러링 모니터 서버 또는 미러 서버와 쿼럼을 구성할 수 있는 경우 주 데이터베이스는 노출된 것으로 간주됩니다. 이것은 주 데이터베이스가 활성화되어 사용자 연결과 트랜잭션 처리를 수행한다는 의미입니다. 그러나 로그 레코드가 미러 데이터베이스에 보내지지 않으므로 주 서버에 오류가 발생하면 주 데이터베이스가 노출 상태로 전환된 시점 이후의 모든 주 서버 트랜잭션이 미러에 존재하지 않게 됩니다. 또한 주 서버의 트랜잭션 로그가 잘리지 않기 때문에 로그 파일이 무한대로 증가하게 됩니다.
미러링 모니터 서버가 설정되어 있는 경우 주 서버가 다른 서버와 쿼럼을 구성할 수 없으면 데이터베이스를 서비스할 수 없습니다. 모든 사용자 연결이 끊어지고 새 트랜잭션이 처리되지 않습니다.
안전성이 OFF이면 트랜잭션 로그 레코드가 미러로 보내지지 않기 때문에 주 데이터베이스는 노출된 것으로 간주됩니다.

참고: Management Studio의 개체 탐색기는 서버 트리 그래프에서 데이터베이스 이름 옆에 주 데이터베이스 상태를 보고합니다. 주 데이터베이스의 SYNCHRONIZED 상태를 'Principal, Synchronizing'으로, DISCONNECTED 상태를 'Principal, Disconnected'로 보고합니다.

미러 서버 데이터베이스 상태

미러 데이터베이스는 주 데이터베이스와 같은 데이터베이스 상태를 가지지만 미러는 항상 복구되지 않은 상태에 있기 때문에 미러 역할을 수행하는 동안에는 데이터베이스를 서비스하지 못합니다. 다음 표에서는 미러 서버 및 데이터베이스의 데이터베이스 상태를 변경시킬 수 있는 가장 일반적인 이벤트를 보여 줍니다.

표 7: 안전성 설정(FULL 및 OFF)에 따른 미러 데이터베이스 미러링 상태

안전성	미러 서버 상태	이벤트	결과 상태
FULL	SYNCHRONIZING	동기화 발생	SYNCHRONIZED
FULL	SYNCHRONIZED	세션 일시 중지	SUSPENDED
FULL	SYNCHRONIZED	미러에서의 다시 실행 오류	SUSPENDED
FULL	SYNCHRONIZED	주 데이터베이스 사용 불가능	DISCONNECTED
OFF	SYNCHRONIZING	세션 일시 중지	SUSPENDED
OFF	SYNCHRONIZING	미러에서의 다시 실행 오류	SUSPENDED

주 서버와 마찬가지로 Management Studio의 개체 탐색기는 서버 트리의 데이터베이스 이름 옆에 일부 미러 데이터베이스 상태를 보고합니다. 미러 데이터베이스의 SYNCHRONIZED 상태를 'Mirror, Synchronizing'으로, DISCONNECTED 상태를 'Mirror, Disconnected'로 보고합니다.

미러링 모니터 서버 상태

미러링 모니터 서버는 sys.database_mirroring 카탈로그 뷰에서 CONNECTED, DISCONNECTED 및 UNKNOWN의 세 가지 상태로 표시됩니다.

표 8: 파트너 서버에 기록된 미러링 모니터 서버 상태

미러링 모니터 서버 상태	이벤트	결과 상태
CONNECTED	미러링 모니터 서버 사용 불가능	DISCONNECTED
	주 서버가 미러를 초기화할 수 없음	UNKNOWN

미러링 모니터 서버의 상태가 실제로 파트너 서버에 기록되고 미러링 모니터 서버에는 기록되지 않기 때문에 이러한 상태는 파트너에게 유리한 상황으로 설정됩니다. 따라서 미러링 모니터 서버의 상태가 DISCONNECTED이면 파트너가 미러링 모니터 서버와 연결이 끊어진 것을 의미합니다. 데이터베이스 미러링이 시작될 때 미러 데이터베이스가 주 데이터베이스를 사용하여 초기화되지 못하면 미러링 모니터 서버는 UNKNOWN 상태가 됩니다.

트랜잭션 로그 레코드 전송

주 및 미러 SQL Server가 메시지와 로그 레코드 블록을 전송할 때의 작업 순서는 안전성 설정에 따라 달라집니다. 먼저 동기 전송을 검사한 다음 비동기 전송을 검사합니다.

SQL Server가 트랜잭션 로그에 트랜잭션 이벤트를 기록하면 로그 레코드는 디스크에 기록되기 전에 로그 버퍼에 잠시 놓여집니다. 데이터베이스 미러링에서는 로그 버퍼를 디스크에 기록(플러시)할 때마다 주 서버가 미러 서버에 동일한 로그 레코드 블록을 보냅니다.

안전성이 FULL일 때 주 SQL Server는 로그 레코드 블록을 플러시하면서 동일한 블록을 미러 서버로 보내고 로그에 대한 로컬 I/O와 해당 로그에 대한 원격 미러 서버의 I/O를 모두 동일하게 처리합니다. 이러한 전송을 동기화라고 부르는데 이것은 I/O(플러시)가 완료되었다는 로컬 I/O(플러시)와 미러의 응답을 주 서버가 모두 받아야만 트랜잭션이 완료된 것으로 간주되기 때문입니다.

주 서버나 미러 서버는 로그 버퍼를 플러시할 때마다 메타데이터에 있는 버퍼의 가장 높은 로그 시퀀스 번호(LSN)에 1을 더한 값을 mirroring_failover_lsn으로 기록합니다. mirroring_failover_lsn은 두 파트너 데이터베이스가 초기에 동기화하고 장애 조치 후에 동기화할 수 있도록 트랜잭션 로그에서 최신 보장 지점을 협상하는 데 사용됩니다.

미러링 장애 조치 lsn은 주 서버가 미러에 로그 레코드를 보낼 때 일반적으로 주 서버의 lsn이 앞서 있게 됩니다. 로그 레코드를 플러시할 때 미러는 mirroring_failover_lsn을 기록하고 주 서버에 응답하지만 주 서버가 미러로부터 승인을 받는 시점에 주 서버는 새 로그 레코드 집합을 플러시했을 수 있습니다.

표 9는 안전성이 FULL인 경우 주 서버와 미러 서버 사이의 이벤트 시퀀스 샘플을 보여 줍니다.

표 9: 안전성이 FULL(동기 전송)인 경우 이벤트 시퀀스 예

서버 A	서버 B
주 서버, SYNCHRONIZED	미러 서버, SYNCHRONIZED
다중 문 트랜잭션이 데이터 수정 내용을 포함하기 시작함
주 데이터베이스의 트랜잭션 로그 레코드가 트랜잭션 로그 버퍼에 삽입됨
트랜잭션 로그 버퍼가 디스크에 기록됨(플러시), 로그 레코드 블록이 미러 서버로 전송됨, 주 서버가 해당 로그 블록의 mirroring_failover_lsn을 기록함, 주 서버가 미러의 확인을 기다림
	미러 서버가 로그 레코드 블록을 트랜잭션 로그 버퍼에 받음
	미러 서버가 로그 버퍼를 디스크에 기록함, mirroring_failover_lsn을 기록함, 로그 블록이 플러시되었음을 주 서버에 알림
미러에서 로그 레코드 블록을 기록했다는 알림을 주 서버가 받음	미러 서버가 REDO 큐에서 계속 트랜잭션 로그 레코드를 재생함
트랜잭션에 대한 COMMIT이 트랜잭션 로그 버퍼에 입력됨
트랜잭션 로그 버퍼가 디스크에 기록됨(플러시), COMMIT이 들어 있는 로그 레코드 블록이 미러 서버로 전송됨, 주 서버가 해당 블록의 mirroring_failover_lsn을 기록함, 주 서버가 미러의 확인을 기다림
	미러 서버가 로그 레코드 블록을 트랜잭션 로그 버퍼에 받음
	미러 서버가 로그 버퍼를 디스크에 기록함, mirroring_failover_lsn을 기록함, 로그 블록이 플러시되었음을 주 서버에 알림
미러에서 로그 레코드 블록을 기록했다는 알림을 주 서버가 받음, 트랜잭션이 커밋된 것으로 간주됨	미러 서버가 REDO 큐에서 COMMIT을 포함한 트랜잭션 로그 레코드를 재생하여 데이터 페이지를 변경함
새 트랜잭션이 주 서버의 로그 버퍼에 기록됨

위 시퀀스에서 중요한 점은 안전성이 FULL인 경우 주 서버가 로그 버퍼를 플러시하는 동시에 버퍼에서 미러 서버로 로그 레코드의 복사본을 보낸다는 것입니다. 그런 다음 자체 I/O 및 미러 서버의 I/O가 완료되면 트랜잭션이 완료되었다고 간주합니다. 주 서버가 미러 서버에서 응답을 받으면 주 서버는 다음 플러시로 진행할 수 있습니다.

안전성이 FULL인 경우 주 서버와 미러 서버 사이의 긴밀한 협력에도 불구하고 데이터베이스 미러링은 분산 트랜잭션이 아니며 2단계 커밋을 사용하지 않습니다.

데이터베이스 미러링에서는 두 서버에 걸쳐 한 트랜잭션이 분산되는 것이 아니라 두 서버에서 두 개의 트랜잭션이 따로 재생되는 것입니다.
데이터베이스 미러링은 분산 트랜잭션에서 파트너 서버를 리소스 관리자로 사용하지 않습니다.
데이터베이스 미러링 트랜잭션은 준비 및 커밋 단계를 거치지 않습니다.
가장 중요한 것은 분산 트랜잭션과는 달리 미러 서버에서 커밋하지 못한다고 해서 주 서버에서 트랜잭션이 롤백되는 것은 아니라는 점입니다.

안전성이 OFF이면 주 서버가 미러 서버의 승인을 기다리지 않으므로 표 10에서 볼 수 있는 것처럼 주 서버에서 커밋된 트랜잭션 수가 미러 서버보다 많을 수 있습니다.

표 10: 안전성이 OFF인 경우(비동기 전송) 이벤트 시퀀스 예

서버 A	서버 B
주 서버, SYNCHRONIZING	미러 서버, SYNCHRONIZING
다중 문 트랜잭션이 데이터 수정 내용을 포함하기 시작함
데이터 수정을 위한 트랜잭션 로그 레코드가 트랜잭션 로그 버퍼에 기록됨
트랜잭션 로그 버퍼가 디스크에 기록됨(플러시), 로그 레코드 블록이 미러 서버로 전송됨, 주 서버가 해당 블록의 mirroring_failover_lsn을 기록함
트랜잭션에 대한 COMMIT이 다른 트랜잭션 작업과 함께 트랜잭션 로그 버퍼에 입력됨	미러 서버가 로그 레코드 블록을 트랜잭션 로그 버퍼에 받음
트랜잭션 로그 버퍼가 디스크에 플러시됨, COMMIT이 들어 있는 로그 블록이 미러 서버로 전송됨	미러 서버가 로그 버퍼를 디스크에 기록함, mirroring_failover_lsn을 기록함, 로그 블록이 플러시되었음을 주 서버에 알림
트랜잭션이 커밋된 것으로 간주됨	미러 서버가 REDO 큐에서 계속 트랜잭션 로그 레코드를 재생함
	미러 서버가 로그 레코드 블록을 트랜잭션 로그 버퍼에 받음
	미러 서버가 로그 블록을 디스크에 기록하여 플러시함, mirroring_failover_lsn을 기록함, 로그 블록이 플러시되었음을 주 서버에 알림

데이터베이스 미러링 역할 변경

데이터베이스 미러링 장애 조치는 데이터베이스 미러링 서버 또는 응용 프로그램의 관점에서 처리될 수 있는 문제입니다. 데이터베이스 미러링 서버의 관점에서 볼 때 장애 조치는 미러 서버를 주 서버로 변환하고 새로 복구한 데이터베이스를 세션의 주 데이터베이스로 사용하는 것입니다. 장애 조치는 자동, 수동 또는 강제 방식으로 처리될 수 있습니다.

자동 - 가용성 우선 모드에서만 발생합니다(안전성이 FULL이고 미러링 모니터 서버가 세션에 포함됨).
수동 - 가용성 우선 또는 보호 우선 운영 모드(안전성이 FULL)이고 파트너 데이터베이스가 모두 SYNCHRONIZED인 경우 발생합니다.
강제 서비스(데이터 손실 허용) - 주로 성능 우선(안전성이 OFF) 모드에서 미러 데이터베이스를 즉시 수동으로 복구하는 데 사용됩니다.

안전성이 FULL일 때 서버의 역할을 반대로 바꾸는 가장 좋은 방법은 강제 서비스가 아닌 수동 장애 조치를 사용하는 것입니다.

자동 장애 조치

자동 장애 조치는 가용성 우선 운영 모드(안전성이 FULL이고 미러링 모니터 서버 사용)에서의 데이터베이스 미러링 기능입니다. 대부분의 경우 SQL Server는 몇 초 내에 자동 데이터베이스 미러링 장애 조치를 수행할 수 있습니다. 데이터베이스 미러링 세션에 연관된 SQL Server는 모두 서로의 존재를 테스트하기 때문에 부분적으로 이 작업을 수행할 수 있습니다. 이 프로세스는 일반적인 IP 주소 ping보다 훨씬 많은 작업을 포함하기는 하지만 'ping'이라고 부릅니다. 미러 서버와 미러링 모니터 서버는 실제 서버가 있는지, SQL Server 인스턴스가 있는지, 주 데이터베이스가 사용 가능한 상태인지 확인하기 위해 주 서버에 연결합니다. 마찬가지로, 주 서버와 미러링 모니터 서버도 실제 서버와 SQL Server 인스턴스가 있는지 확인하고 미러 데이터베이스가 복구 중 상태인지 여부를 알아보기 위해 미러 서버에 각각 ping을 수행합니다.

데이터베이스 미러링 세션이 안전성은 FULL이고 미러링 모니터 서버를 사용하도록 설정되었다고 가정합시다. 미러 서버인 서버 B는 주 서버 A를 사용할 수 없다는 것을 ping을 통해 확인합니다. 서버 B는 미러링 모니터 서버와 통신하여 미러링 모니터 서버도 서버 A를 볼 수 없다는 확인을 받습니다. 그러면 서버 B는 미러링 모니터 서버와 쿼럼을 구성하고 스스로 주 서버 역할로 승격합니다. 데이터베이스는 연결이 끊어지고 새로운 주 데이터베이스의 트랜잭션 로그는 잘라낼 수 없지만 서버 B는 데이터베이스를 복구하고 이제 주 서버 역할을 하게 되었음을 미러링 모니터 서버에 알립니다.

서버 B의 새로운 주 데이터베이스는 트랜잭션 로그 작업을 계속 재생하지만 지속적으로 다시 실행 상태에 있었기 때문에 대부분의 경우 수행할 작업이 거의 남아 있지 않습니다. 모든 SQL Server 버전의 데이터베이스 미러링에서 새로운 주 데이터베이스는 다시 실행 상태를 완료하는 즉시 사용할 수 있게 됩니다. 데이터베이스가 실행 취소 상태가 되면 사용자를 연결할 수 있게 됩니다. 남아 있는 실행 취소 단계가 더 오래 걸릴 수도 있겠지만 다시 실행 상태는 일반적으로 몇 초 이내에 완료됩니다. 데이터베이스 미러링에서 새로운 주 데이터베이스는 다시 실행 프로세스가 완료되는 즉시 사용자 연결을 서비스하는 데 사용할 수 있습니다. 새로운 주 서버 B의 데이터베이스는 DISCONNECTED 상태이고 노출되어 있지만 다시 실행 단계가 완료되는 즉시 데이터베이스를 서비스할 수 있습니다.

일반적으로 데이터베이스 미러링 자동 장애 조치에 걸리는 시간보다 기존의 주 서버에서 새로운 주 서버로 전체 응용 프로그램을 리디렉션하는 데 더 많은 시간이 걸립니다. 응용 프로그램이 연결을 감지하고 다시 시도해야 하기 때문에 프로세스 시간이 약간 길어질 수 있습니다. 또한 SQL Server 인증을 사용한 새 로그인이 서버에 추가된 경우에는 시스템 저장 프로시저인 sp_change_users_login을 사용하여 이러한 로그인을 새로운 주 서버에 매핑해야 합니다. SQL 에이전트 작업 같은 이전 주 서버의 중요한 개체가 새로운 주 서버에 복사되지 않은 경우에는 전체 응용 프로그램 장애 조치가 지연될 수도 있습니다. 자세한 내용은 뒷부분에 나오는 구현 절에서 "장애 조치를 위한 미러 서버 준비"를 참조하십시오.

이제 기존의 주 서버가 온라인 상태가 되었다고 가정합시다. 수동 장애 조치 또는 기존의 주 서버가 빠르게 복구되는 자동 장애 조치에서처럼 두 서버의 역할이 바뀌는 경우에는 두 서버 간에 반드시 협상 프로세스가 발생하게 됩니다. 미러링을 다시 시작하려면 두 파트너 서버가 서로 동기화할 수 있는 방법을 찾아야 합니다. 미러링 장애 조치 lsn은 이 프로세스에서 중요한 역할을 수행합니다.

서버 A(새 미러)가 시간적으로 이전이지만 어느 정도인지는 확실하지 않습니다. 서버 A는 서버 B(새로운 주 서버)에 서버 B로부터 받은 마지막 미러링 장애 조치 lsn을 보고합니다. 반면에 서버 B는 작업을 커밋하였으므로 보다 최근 상태의 미러링 장애 조치 lsn을 가집니다. 두 서버는 서버 B에 정확한 장애 조치 lsn이 있고 서버 A가 이와 동기화되어야 한다는 것에 동의합니다. 서버 B는 서버 A가 동기화되기 위해 재생할 수 있는 충분한 수의 트랜잭션 레코드를 서버 A로 전송합니다.

수동 장애 조치

수동 장애 조치는 두 파트너 서버가 정해진 순서대로 오류 없이 자신들의 역할을 바꾸도록 하는 방법입니다. 안전성이 FULL로 설정되고 주 데이터베이스와 미러 데이터베이스가 SYNCHRONIZED 상태에 있어야 합니다.

다음과 같이 주 서버에서 ALTER DATABASE 명령을 호출하여 수동 장애 조치를 수행합니다.

코드 복사

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;

또는 Management Studio의 [데이터베이스 속성/미러링] 대화 상자에서 [장애 조치] 단추를 클릭합니다. 수동 장애 조치를 수행하면 현재 사용자의 연결이 끊어지고 기존의 주 데이터베이스에서 완료되지 않은 트랜잭션이 롤백됩니다. 다시 실행 큐에서 커밋된 모든 트랜잭션을 완료하고 커밋되지 않은 트랜잭션을 실행 취소 단계에서 롤백하여 미러 데이터베이스를 복구합니다. 기존 미러에는 주 데이터베이스 역할이 주어지고 기존의 주 데이터베이스에는 새롭게 미러 역할이 주어집니다. 두 서버는 각자의 미러링 장애 조치 lsn을 기반으로 미러링의 새로운 시작점을 협상하고 서로 바뀐 역할에 맞게 처리합니다.

미러링을 초기화하기 전에 먼저 미러 서버를 업그레이드하는 경우 서버 운영 체제 또는 SQL Server 인스턴스로 '롤링 업그레이드'를 수행하는 한 가지 방법으로 수동 장애 조치를 사용할 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서의 수동 장애 조치(Failover)를 참조하십시오.

강제 서비스

다음과 같이 ALTER DATABASE 명령을 호출하여 미러에서 강제 서비스를 수행할 수 있습니다.

코드 복사

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

일반적으로 이 방법은 안전성이 OFF이고 주 서버가 더 이상 작동하지 않는 경우에만 유용합니다. 안전성이 FULL일 때도 이 명령을 사용할 수 있지만 복구된 미러 서버가 쿼럼을 구성할 수 없는 경우에는 데이터베이스를 서비스할 수 없습니다. 따라서 안전성이 OFF(성능 우선 모드)인 경우에만 이 명령을 사용하는 것이 좋습니다. 비동기 데이터 전송에서는 미러를 주 서버의 커밋된 트랜잭션과 완벽하게 같도록 유지할 수 없기 때문에 일부 데이터가 손실될 수 있습니다.

페이지 위쪽

데이터베이스 미러링 가용성 시나리오

이 단원에서는 다음 두 가지 유형의 이벤트를 기반으로 데이터베이스 미러링 시나리오에서 예상되는 가용성 결과를 살펴봅니다.

하나 이상의 서버 또는 데이터베이스가 다운된 경우
서버 사이에 하나 이상의 통신 회선이 끊어진 경우

파트너 데이터베이스 중 하나 또는 SQL Server 인스턴스 중 하나를 사용할 수 없게 되면 서버 손실이 발생할 수 있습니다. 또는, 서버 자체는 계속 작동하지만 데이터베이스 미러링 파트너 서버 사이의 통신 회선이 중단될 수 있습니다.

다음 시나리오에서는 두 구성 요소의 동시 실패를 한 구성 요소가 실패하고 이어서 다른 구성 요소가 실패한 것으로 간주합니다. 예를 들어 서버 A와 B가 동시에 실패한 것으로 나타나는 경우 미러링 시스템은 해당 이벤트를 서버 A에 다음에 서버 B가 실패했거나 이와 반대인 것으로 취급합니다.

다음 규칙을 사용하여 사용 불가능 이벤트가 발생했을 때 예상되는 결과를 확인할 수 있습니다.

미러링 모니터 서버가 설정되어 있으면 주 서버는 데이터베이스 서비스를 유지하기 위해 하나 이상의 다른 서버와 쿼럼을 구성해야 합니다.

주 서버가 쿼럼을 구성할 수 없으면 더 이상 데이터베이스를 서비스할 수 없습니다.
안전성이 FULL일 때 미러와 미러링 모니터 서버가 모두 주 서버를 볼 수 없으면 미러 서버는 미러링 모니터 서버와 쿼럼을 구성하고 역할을 변경하여 새로운 주 서버가 될 수 있습니다. 이 경우 주 서버가 다운되었을 때 미러링 세션이 동기화된 것으로 가정합니다.

이 방법은 자동 장애 조치입니다.
안전성이 FULL일 때 주 서버가 미러링 모니터 서버와 쿼럼을 구성한 상태에서 작업을 수행하지만 미러와는 연결이 끊긴 경우, 주 서버에 오류가 발생하면 미러가 미러링 모니터 서버와 쿼럼을 구성하여 새로운 주 서버의 역할을 수행할 수 없습니다.

이렇게 함으로써 세션에 의해 작업이 손실되는 것을 방지합니다.
안전성이 FULL일 때 오류가 발생한 주 서버가 다운 또는 격리된 후에 세션에 다시 참여하고 기존의 미러 서버가 미러링 모니터 서버와 쿼럼을 구성하여 새로운 주 서버의 역할을 맡은 경우, 기존의 주 서버는 세션에서 새로운 미러의 역할을 맡게 됩니다.

장애 조치 이벤트 동안 미러와 미러링 모니터 서버는 미러링 역할 시퀀스 카운터를 증가시켰습니다. 기존 주 서버의 미러링 역할 시퀀스 카운터가 다른 파트너 서버 및 미러링 모니터 서버의 시퀀스 카운터보다 작기 때문에 이러한 두 서버는 기존의 주 서버가 세션에 다시 참여하기 전에 쿼럼을 구성했으며 새로운 주 서버에서는 새 작업이 발생했을 수 있습니다. 기존의 주 서버는 세션에서 미러 역할을 맡습니다.
미러링 모니터 서버가 설정된 경우 주 서버가 데이터베이스를 서비스하려면 쿼럼이 있어야 합니다. 미러링 모니터 서버가 설정되지 않은 경우 즉, sys.database_mirroring 열의 “mirroring_witness_name”의 상태가 NULL인 경우에는 쿼럼이 없어도 주 서버가 데이터베이스를 서비스할 수 있습니다.

미러링 모니터 서버가 없다는 것은 자동 장애 조치가 발생할 수 없음을 의미합니다. 자동 장애 조치가 발생하지 않으면 "교신 두절(Split Brain)" 문제가 발생하지 않으며, 주 서버는 쿼럼을 구성하기 위해 다른 서버와 연결하지 않아도 됩니다.

서버 손실이 있는 가용성 우선 시나리오

가용성 우선 운영 모드에서 데이터베이스 미러링의 목적은 데이터베이스 가용성을 최대한 유지하는 것입니다. 이 모드에서 데이터베이스 미러링은 주 데이터베이스를 사용할 수 없게 될 경우 미러 데이터베이스를 신속하게 서비스하게 됩니다. 다음 시나리오 집합에서는 세 개의 독립된 서버가 있는 가용성 우선 구성을 사용하여 시작합니다.

그림 1에서 볼 수 있듯이 다음 가용성 우선 시나리오에서 서버 A는 주 서버, 서버 B는 미러 서버, 서버 W는 미러링 모니터 서버로 시작합니다.

그림 1

그림 1: 샘플 데이터베이스 미러링 세션이 가용성 우선 운영 모드로 시작합니다.

실제로 세 개의 서버는 모두 같은 사이트에 있으면서 로컬 네트워크를 통해 연결되거나, WAN을 통해 연결된 독립적인 사이트에 있을 수 있습니다. 서버 A와 서버 B는 역할을 변경할 수 있지만 서버 W는 항상 미러링 모니터 서버를 유지합니다.

이제 서버 중 하나가 다운되는 경우 어떤 일이 발생하는지 살펴봅시다.

시나리오 HASL1.1: 주 서버 손실

다음 시나리오에서는 가용성 우선 시나리오에서 주 서버가 손실될 때 어떤 일이 발생하는지 살펴봅니다. 그림 2는 다양한 역할과 이러한 역할이 파트너 사이에서 변경되는 방법을 보여 줍니다.

그림 2

그림 2: 가용성 우선 모드에서 주 서버 A가 실패하면 장애 조치가 발생합니다.

주 서버 A가 손실되면 미러 서버와 미러링 모니터 서버가 쿼럼을 구성하고 자동 장애 조치가 발생합니다. 원래 주 서버를 복구하면 원래 주 서버는 미러 역할을 맡게 됩니다.

참고:가용성 우선 모드에서 장애 조치를 발생시키는 오류에는 여러 가지가 있을 수 있습니다. 실제 서버가 다운되거나, 주 서버의 SQL Server 인스턴스가 중지 또는 실패하거나, 서버의 주 데이터베이스가 사용 불가능하거나 주의 대상이 되는 경우가 있을 수 있습니다. 다음 시나리오에서 주 서버가 손실되면 이러한 이벤트가 그 원인일 수 있습니다.

서버 B와 W가 쿼럼을 구성할 수 있고 두 서버 모두 서버 A를 볼 수 없기 때문에 서버 B가 새로운 주 서버로 승격할 수 있습니다. 그러나 미러 서버가 없으면 미러링 세션은 노출된 것으로 간주됩니다.

서버 A를 복구하면 서버 A가 새로운 주 서버가 되고 미러링 세션은 더 이상 노출되지 않습니다.

단일 서버가 실패하는 경우는 드뭅니다. 하물며 두 서버가 실패하는 경우는 더욱 발생하기 어렵습니다. 그러나 드문 경우라도 그 결과를 알아두는 것이 좋습니다.

두 서버가 동시에 또는 거의 동시에 실패할 수 있지만 데이터베이스 미러링 관점에서는 결과적으로 한 서버가 실패한 다음 다른 서버가 실패하는 것과 같습니다. 따라서 이러한 시나리오에서는 서버가 순차적으로 실패할 경우 어떤 결과가 발생하는지만 고려합니다.

다음 두 시나리오에서는 주 서버 A의 실패에 이어 두 개의 대체 서버가 실패할 경우 어떤 일이 발생하는지 살펴봅니다.

새로운 주 서버 B의 실패
미러링 모니터 서버 W의 실패

시나리오 HASL1.2: 주 서버 손실에 이어 새로운 주 서버 손실

앞의 시나리오에서 본 것처럼 가용성 우선 모드에서는 주 서버가 먼저 손실되는 경우 장애 조치가 발생합니다. 그림 3은 다음으로 새로운 주 서버가 실패하는 경우 서버 복원에 관계없이 새로운 주 서버(서버 B)가 주 서버 역할을 유지하는 과정을 보여 줍니다.

그림 3

그림 3: 주 서버 손실에 이어 새로운 주 서버가 손실됨에 따라 역할이 변경됩니다.

서버 A가 실패한 후 서버 B가 새로운 주 서버가 되지만 데이터를 미러 서버로 전송할 수 없으므로 주 서버는 데이터베이스를 여전히 서비스할 수 있을지라도 노출됩니다. 서버 A 실패에 이어 서버 B가 실패하면 서버 B가 다운되기 때문에 미러링이 수행되지 않습니다.

서버 A를 먼저 복구한 경우 서버 A는 미러링 모니터 서버가 새로운 쿼럼을 구성했기 때문에 미러링 모니터 서버 W에서 mirroring_role_sequence 번호를 감지합니다. 서버 A는 미러 역할을 맡고 서버 B가 복구되기를 기다립니다. 서버 B는 복구된 즉시 서버 A로 미러링 프로세스를 시작합니다. 서버 B를 먼저 복구하는 경우에는 HASL1.1에서 보여준 원래 시나리오로 돌아갑니다.

참고: 서버 A의 손실에 이어 서버 B가 손실된 후 서버 W가 손실되면 세 서버가 모두 다운되고 서버 A와 서버 B의 뒤바뀐 역할은 서버 복원 순서에 관계없이 유지됩니다.

시나리오 HASL1.3. 주 서버 손실에 이어 미러링 모니터 서버 손실

주 서버가 손실되면 장애 조치가 발생합니다. 그런 다음 그림 4처럼 미러링 모니터 서버가 실패할 수 있습니다.

그림 4

그림 4: 초기 주 서버의 손실에 이어 미러링 모니터 서버가 손실되면 새로운 주 서버가 데이터베이스를 서비스할 수 없습니다.

주 서버 A가 손실된 후에 미러링 모니터 서버 W가 손실되면 새로운 주 서버 B는 여전히 주 서버이지만 격리되어 있어서 쿼럼을 구성할 수 없고 데이터베이스를 서비스할 수 없습니다.

먼저 서버 A를 복구할 경우 서버 B의 mirroring_role_sequence 번호는 장애 조치가 발생했기 때문에 서버 A의 번호보다 1이 커집니다. 이를 통해 서버 A는 자신이 맡았던 주 서버 역할을 이제 서버 B가 맡고 있음을 알 수 있습니다. 서버 A는 서버 B와 쿼럼을 구성하여 미러 서버가 되며 두 서버는 모두 동기화됩니다. 서버 W가 복구될 때까지 자동 장애 조치는 발생할 수 없습니다.

참고: 서버 A의 손실에 이어 서버 W가 손실된 후 서버 B가 손실되면 서버 A와 서버 B의 새로운 역할은 서버 복원 순서에 관계없이 유지됩니다.

시나리오 HASL2.1 미러 서버 손실

미러 서버가 먼저 손실된 경우에는 미러 서버로 데이터를 전송할 수 없기 때문에 주 서버가 노출된 것으로 간주됩니다. 그림 5는 미러 서버인 서버 B가 손실될 경우의 역할 변경을 보여 줍니다.

그림 5

그림 5: 가용성 우선 모드에서 미러 서버 B가 실패하는 경우 장애 조치가 발생하지 않습니다.

자동 장애 조치가 발생하지 않으며 파트너는 역할을 교환하지 않습니다. 서버 B가 복원되면 세 서버 모두 원래 역할과 상태로 돌아갑니다.

다음 표는 미러 서버 B가 손실되고 복구되는 동안 데이터베이스 상태와 쿼럼을 보여 줍니다.

데이터가 중복 데이터베이스에 저장되지 않기 때문에 미러 없이 세션이 노출됩니다.

서버 B를 복원할 수 있게 되면 서버 B의 미러 역할이 재개되며 두 파트너가 동기화되면 미러링 세션은 더 이상 노출된 것으로 간주되지 않습니다.

다음 두 시나리오에서는 미러 서버 B 실패에 이어 주 서버 A 또는 미러링 모니터 서버 W가 실패할 경우 어떤 일이 발생하는지 살펴봅니다.

시나리오 HASL2.2: 미러 서버 손실에 이어 주 서버 손실

미러 서버에 이어 주 서버가 손실된 경우 파트너 서버의 역할은 변경되지 않습니다. 그림 6은 다양한 경로를 통해 서버를 복구할 때 역할이 어떻게 변경되는지를 보여 줍니다.

그림 6

그림 6: 미러 서버에 이어 주 서버가 손실되는 경우 미러링 모니터 서버가 격리됩니다.

서버 B에 이어 서버 A가 손실되면 상태는 다이어그램 오른쪽 위에 표시된 상태가 됩니다.

먼저 서버 B를 복구하면 서버 B는 미러링 모니터 서버 W를 통해 서버 A가 계속 주 서버이고 장애 조치가 발생하지 않았음을 감지합니다. mirroring_failover_lsn은 증가하지 않았습니다. 결과적으로 서버 B는 미러 서버를 유지합니다. 그런 다음 서버 W를 복구하면 세션이 원래 상태로 복원됩니다.

참고: 서버 B에 이어 서버 A가 손실된 후 서버 W가 손실되면 서버를 어떤 순서로 복구하든 결과는 같습니다.

시나리오 HASL2.3: 미러 서버 손실에 이어 미러링 모니터 서버 손실

미러 서버 손실에 이어 미러링 모니터 서버가 손실되면 주 서버가 격리되고 다른 서버와 쿼럼을 구성할 수 없습니다. 따라서 그림 7의 오른쪽 위에서 볼 수 있듯이 데이터베이스를 서비스하지 못하게 됩니다.

그림 7

그림 7: 미러 서버 손실에 이어 미러링 모니터 서버가 손실되면 주 서버가 데이터베이스를 서비스할 수 없게 됩니다.

미러 서버에 이어 미러링 모니터 서버가 중단되면 주 서버 A는 주 서버 역할을 유지하지만 다른 서버와 쿼럼을 구성할 수 없고 안전성이 FULL이기 때문에 데이터베이스를 서비스할 수 없고 모든 사용자의 연결이 끊어집니다.

먼저 서버 B가 복원되면 미러링이 재개되지만 미러링 모니터 서버가 없어서 자동 장애 조치가 불가능합니다.

먼저 서버 W가 복원되는 경우 시나리오는 그림 5와 같습니다.

참고: 서버 B에 이어 서버 W가 손실된 후 서버 A가 손실되면 서버를 어떤 순서로 복구하든 최종 결과는 같습니다.

시나리오 HASL3.1: 미러링 모니터 서버 손실

미러링 모니터 서버가 실패하면 미러링은 계속되지만 자동 장애 조치는 불가능합니다. 서버를 하나 더 손실하면 쿼럼이 없어지며 주 데이터베이스가 더 이상 데이터베이스를 서비스할 수 없게 됩니다.

그림 8

그림 8: 가용성 우선 모드에서 먼저 미러링 모니터 서버 W가 실패하면 미러링이 계속됩니다.

서버 W를 복원하면 파트너 서버인 서버 A와 서버 B는 원래 역할을 유지합니다.

다음 표는 미러링 모니터 서버가 실패하여 복원되는 동안 데이터베이스 상태와 쿼럼이 변경되는 내용을 보여 줍니다.

다음 두 시나리오에서는 미러링 모니터 서버 W 실패에 이어 주 서버 A 또는 미러 서버 B가 실패할 경우 어떤 일이 발생하는지 살펴봅니다.

시나리오 HASL3.2: 미러링 모니터 서버 손실에 이어 주 서버 손실

먼저 미러링 모니터 서버가 실패하면 미러링은 계속되지만 자동 장애 조치는 불가능합니다. 나머지 두 서버 중 하나만 실패해도 쿼럼이 불가능하고 나머지 서버는 격리됩니다.

그림 9

그림 9: 초기 미러링 모니터 서버 손실에 이어 주 서버가 손실되면 파트너 역할은 동일하게 유지됩니다.

먼저 서버 W를 복구할 경우 서버 B는 미러링 모니터 서버를 통해 마지막으로 양호했던 주 서버가 서버 A였음을 감지하므로 서버 B는 미러 서버를 유지합니다. 마지막으로 서버 A를 복구하면 서버 A는 주 서버 역할을 유지합니다.

참고: 서버 W에 이어 서버 A가 손실된 후 서버 B가 손실되면 서버를 어떤 순서로 복구하든 최종 결과에는 영향을 주지 않습니다.

시나리오 HASL3.3: 미러링 모니터 서버 손실에 이어 미러 서버 손실

미러링 모니터 서버가 실패한 다음 미러 서버가 실패하면 주 서버는 격리됩니다. 그림 10에서 볼 수 있는 것처럼 안전성이 FULL이고 주 서버가 쿼럼을 구성할 수 없으면 주 서버는 더 이상 데이터베이스를 서비스할 수 없습니다.

그림 10

그림 10: 미러링 모니터 서버가 실패하고 이어서 미러 서버가 실패하면 주 서버는 데이터베이스 서비스를 중단해야 합니다.

참고: 서버 W에 이어 서버 B가 손실된 후 서버 A가 손실되면 서버를 어떤 순서로 복구하든 최종 결과에는 영향을 주지 않습니다.

요약: 서버 손실이 있는 가용성 우선 시나리오

이들 시나리오에서 많은 결론을 이끌어낼 수 있습니다. 가용성 우선 모드에서는 다음과 같이 작업이 이루어집니다.

주 서버를 먼저 사용할 수 없게 되면 자동 장애 조치가 발생하고 이전 미러 서버가 주 서버 역할을 맡게 되어 사용자는 데이터베이스를 사용할 수 있게 됩니다. 이후의 서버 실패와 복원은 새로운 주 서버로 이루어진 전체 미러링 구성에 영향을 주지 않습니다. 미러링은 반대 방향으로 계속됩니다.
미러 서버를 먼저 사용할 수 없게 되면 자동 장애 조치가 발생하지 않습니다. 이후의 서버 비가용성과 복원 순서는 미러링 파트너 역할에 영향을 주지 않습니다.
미러링 모니터 서버를 먼저 사용할 수 없게 되면 자동 장애 조치가 불가능하며 파트너 서버는 원래 역할을 유지합니다. 이후의 서버 비가용성과 복원은 파트너 역할에 영향을 주지 않습니다.

다음 표는 한 개 또는 두 개의 서버가 손실되는 가용성 우선 시나리오에 대한 결과를 요약한 것입니다. 이 표에서는 안전성이 FULL로 설정되어 있고 미러링 세션 서버가 다음 조건을 갖는다고 가정합니다.

A: 주 서버, SYNCHRONIZED

B: 미러 서버, SYNCHRONIZED

W: 미러링 모니터 서버, CONNECTED

표에서는 장애 조치 시나리오가 회색으로 강조 표시되어 있습니다.

표 11: 파트너 서버 역할과 데이터베이스 상태를 보여 주는 단일 및 이중 서버 실패 요약

Table2

통신 손실이 있는 가용성 우선 시나리오

가용성 우선 운영 모드에는 세 개의 SQL Sever 인스턴스가 필요합니다. 서버가 서로 상당히 떨어진 둘 또는 세 개의 독립된 사이트에 있을 경우 이들 사이에 통신 문제가 발생하기 쉽습니다. 즉, 서버는 사용 가능하지만 통신 회선이 중단되는 경우가 있을 수 있습니다. 이러한 시나리오는 이전 시나리오보다 약간 더 복잡하지만 적용되는 원칙은 동일합니다.

통신이 손실된 가용성 우선 운영 모드 시나리오는 다음 두 경우로 나누어서 설명할 수 있습니다. 첫 번째 경우는 세 개의 SQL Server 인스턴스가 각각 독립된 사이트에 있어서 세 개의 독립된 통신 회선을 사용합니다. 두 번째 경우는 두 개의 독립된 사이트에 서버가 있어서 하나의 통신 회선을 사용하여 한 쌍의 서버를 떨어져 있는 나머지 서버 하나와 연결합니다.

먼저 첫 번째 경우에는 데이터베이스 미러링 세션에 있는 모든 서버 사이에 세 개의 독립된 통신 회선이 있다고 가정합니다. 예를 들어 주 서버, 미러 서버 및 미러링 모니터 서버가 세 개의 독립된 사이트에 있을 수 있습니다. 또는 세 개의 서버가 한 사이트에 있지만 개인 네트워크로 연결되어 있을 수도 있습니다.

초기 조건은 서버 A에 주 데이터베이스가 있고 미러링된 데이터베이스가 있는 파트너인 서버 B가 서버 A와 동기화되었다고 가정합니다. 안전성은 FULL로 설정되어 있고 미러링 모니터 서버(서버 W)는 데이터베이스 미러링 세션에 속해 있습니다. 그림 11은 초기 구성을 보여 줍니다.

그림 11

그림 11: 독립된 세 개 서버의 초기 가용성 우선 구성에 세 개의 독립된 통신 회선이 있는 경우

참고: 다음 페이지의 다이어그램에 대한 설명은 위의 "서버 손실이 있는 가용성 우선 모드"를 참조하십시오.

그림 11을 보면 A/B, A/W 및 B/W라는 세 개의 다른 회선이 있으며 이들 중 어느 것이든 먼저 끊어질 수 있습니다. 이들 통신 회선 중 하나가 다운되더라도 세 개의 서버가 모두 계속 작동합니다. 표 12에서 볼 수 있듯이 유일하게 주 서버와 미러 서버 사이의 회선이 끊어지면 영향을 받습니다.

표 12: 단일 통신 회선 끊김에 대한 요약

초기 조건	이벤트	쿼럼	결과	조건
A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: 미러링 모니터 서버, CONNECTED	A/B 회선 끊김	A 및 W	서버 A의 데이터베이스 사용 가능, 노출됨	A: 주 서버, DISCONNECTED B: 미러 서버, DISCONNECTED W: 미러링 모니터 서버, CONNECTED
	A/W	A 및 B	서버 A의 데이터베이스 사용 가능	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: 미러링 모니터 서버, CONNECTED
	B/W	A 및 B	서버 A의 데이터베이스 사용 가능	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: 미러링 모니터 서버, CONNECTED

초기 조건

이벤트

쿼럼

결과

조건

A: 주 서버,
SYNCHRONIZED

B: 미러 서버,
SYNCHRONIZED

W: 미러링 모니터 서버,
CONNECTED

A/B 회선 끊김

A 및 W

서버 A의 데이터베이스 사용 가능, 노출됨

A: 주 서버,
DISCONNECTED

B: 미러 서버,
DISCONNECTED

W: 미러링 모니터 서버,
CONNECTED

A/W

A 및 B

서버 A의 데이터베이스 사용 가능

A: 주 서버,
SYNCHRONIZED

B: 미러 서버,
SYNCHRONIZED

W: 미러링 모니터 서버,
CONNECTED

B/W

A 및 B

서버 A의 데이터베이스 사용 가능

A: 주 서버,
SYNCHRONIZED

B: 미러 서버,
SYNCHRONIZED

W: 미러링 모니터 서버,
CONNECTED

주 서버/미러 서버 연결이 끊어질 경우에만 영향을 받습니다. 주/미러링 모니터 서버 또는 미러/미러링 모니터 서버의 연결이 끊어질 경우에는 데이터베이스 미러링 세션의 동작이 영향을 받지 않습니다.

표 HACL1의 내용을 요약하면 다음과 같습니다.

단일 통신 회선 끊김 중에서 주/미러 서버 끊김만 데이터베이스 미러링에 영향을 줍니다. 로그 레코드가 미러 서버로 전송되지 않기 때문에 주 서버는 노출된 상태로 실행됩니다.

이제 두 번째 회선이 끊기는 경우 어떤 일이 발생하는지 살펴봅니다. 두 회선이 동시에 또는 순서대로 끊길 수 있습니다.

두 회선이 동시에 끊기는 경우에도 최종 결과는 한 회선이 끊긴 다음 다른 회선이 끊기는 것과 동일합니다. 그러나 정확한 순서는 사전에 예측할 수 없으며 이후의 동작을 통해서만 해당 동시 끊김에 적용되는 순서를 알 수 있습니다.

따라서 여기에서는 순차적인 회선 끊김만 고려합니다. 표 13은 이 단원의 제목이 나타내는 가용성 우선 모드에서 통신 회선이 끊긴 경우에 대한 기본 시나리오를 보여 줍니다.

표 13: 대부분의 경우 두 회선의 통신 회선 끊김은 한 서버가 다운되는 서버 다운 시나리오와 동일합니다.

시나리오	첫 번째 회선 끊김	시나리오	두 번째 회선 끊김	결과	나머지 서버에 대해 적용되는 동일한 시나리오	참조 시나리오
HACL1.1	A 및 W	HACL1.2	A/W	서버 A 격리됨	서버 A 다운	(없음)
		HACL1.3	B/W	서버 B 격리됨	서버 B 다운	HASL2.1
HASL2.1	A/W	HASL2.1	A/B	서버 A 격리됨	서버 A 다운	HASL1.1
		HASL2.2	B/W	서버 W 격리됨	서버 W 다운	HASL3.1
HACL3.1	B/W	HACL3.1	A/W	서버 W 격리됨	서버 W 다운	HASL3.1
		HACL3.2	A/B	서버 B 격리됨	서버 B 다운	HASL2.1

표 HACL2의 경우 모든 순차적인 두 회선 통신 끊김이 앞 단원의 단일 서버 다운 시나리오와 동일하므로 여기에서는 반복해서 분석하지 않습니다.

중요한 사항은 다음과 같습니다.

두 개의 통신 회선이 끊기는 시나리오에서는 주/미러링 모니터 서버 회선이 끊기고 이어서 주/미러 서버 회선이 끊기는 경우에만 장애 조치가 발생합니다.

주/미러 서버 회선이 끊기고 이어서 주/미러링 모니터 서버 회선이 끊기면 주 서버가 격리되었어도 장애 조치가 발생하지 않으며 미러 및 미러링 모니터 서버는 주 서버를 볼 수 없습니다.

시나리오 HACL1.2를 보다 자세하게 살펴봅시다.

시나리오 HACL1.2: 주/미러 서버 회선이 끊기고 이어서 주/미러링 모니터 서버 회선이 끊김

주/미러 서버 회선이 끊기고 이어서 주 서버와 미러링 모니터 서버 사이의 회선이 끊기면 주 서버가 격리됩니다. 주 서버는 다른 서버를 볼 수 없으며 쿼럼이 손실됩니다. 한편 미러 서버와 미러링 모니터 서버는 주 서버가 여전히 가동되는지 여부를 알지 못하므로 서버 B가 주 서버의 역할을 맡고 자동 장애 조치가 발생합니다. 그림 12는 이러한 이벤트를 보여 줍니다.

그림 12

그림 12: 가용성 우선 모드에서 주/미러 서버 회선이 끊기고 이어서 주/미러링 모니터 서버 회선이 끊기면 장애 조치가 발생하지 않습니다.

주/미러 서버 회선이 끊기고 이어서 주/미러링 모니터 서버 회선이 끊기면 서버 A는 격리되고 데이터베이스를 서비스할 수 없습니다. 서버 A가 서버 B에 없는 작업을 수행했을 수 있기 때문에 서버 B와 W는 쿼럼을 구성하지 않습니다.

주/미러링 모니터 서버(A/W) 회선 끊김이 먼저 복구되면 서버 A는 DISCONNECTED 상태에서 주 서버 역할을 재개합니다. 그러나 주 서버와 미러 서버 사이의 회선이 아직 복구되지 않았기 때문에 미러링은 발생하지 않습니다.

주/미러 서버(A/B) 회선 끊김이 먼저 복구되면 미러링 모니터 서버가 없어도 서버 A는 서버 B에 대한 미러링을 재개하므로 세션이 노출됩니다. 그러나 주/미러링 모니터 서버 회선이 최종적으로 복구될 때까지는 자동 장애 조치가 불가능합니다.

요약: 통신 회선 손실이 있는 가용성 우선 시나리오: 세 개의 사이트

다음 표는 세 개의 독립된 서버가 있을 때 한 개 또는 두 개의 회선이 끊길 경우의 동작을 요약한 것입니다. 이 표의 초기 조건은 안전성 수준이 FULL로 설정되고 서버는 다음과 같은 상태에 있습니다.

A: 주 서버, SYNCHRONIZED

B: 미러 서버, SYNCHRONIZED

W: 미러링 모니터 서버, CONNECTED

장애 조치 시나리오 경로는 회색으로 강조 표시되어 있습니다.

표 14: 가용성 우선 모드에서 안전성이 FULL이고 세 개의 독립된 서버가 있는 경우 한 개 회선 및 두 개 회선 끊김에 대한 요약

Table3

시나리오 HACL4: 미러 사이트에 미러링 모니터 서버가 있는 두 사이트

서버 집합 사이에 통신 회선이 하나만 있으면 미러링 모니터 서버를 배치할 곳을 선택해야 합니다. 먼저 미러 데이터베이스 서버에 미러링 모니터 서버를 배치한다고 가정합니다. 그림 13과 같이 두 서버 집합 사이에 통신 회선이 하나만 있는데 이 회선이 중단될 수 있습니다.

그림 13

그림 13: 주 서버 및 미러/미러링 모니터 사이트 사이의 통신 회선이 중단되었습니다.

서버 A는 미러링 모니터 서버 W 또는 미러 데이터베이스의 서버 B를 볼 수 없으므로 쿼럼을 구성할 수 없습니다. 서버 B와 서버 W는 쿼럼을 구성할 수 있지만 둘 다 서버 A에 있는 주 서버를 볼 수 없습니다. 회선이 끊긴 결과는 그림 14와 같습니다.

그림 14

그림 14: 통신이 중단되고 미러링 모니터 서버가 미러 사이트에 있을 경우 장애 조치가 발생합니다.

서버 A는 미러링 모니터 서버 W 또는 이전 미러 파트너 서버 B를 볼 수 없기 때문에 연결이 끊긴 상태가 되며 데이터베이스를 사용할 수 없게 됩니다.

서버 B와 서버 W는 쿼럼을 구성할 수 있습니다. 서버 B는 서버 A를 볼 수 없으며, 서버 W와 서버 B가 주 서버가 되어 데이터베이스를 온라인 상태로 만들려고 시도합니다. 서버 W는 서버 A를 볼 수 없기 때문에 서버 B에 동의합니다. 서버 B는 이제 쿼럼을 갖게 되고 이 세션에서 주 서버 역할을 맡아서 데이터베이스를 복구합니다.

통신 회선을 복원하면 서버 A는 서버 B가 주 서버인 것을 확인하고 미러링 모니터 서버 W가 서버 B를 주 서버로 여기고 있음을 감지합니다. 그러면 서버 A는 역할을 미러 서버로 변경하고 새로운 주 서버와 동기화를 시도합니다. 동기화가 완료된 후의 결과 구성은 그림 15와 같습니다.

그림 15

그림 15: 이 시나리오의 복원된 버전은 역방향으로 미러링을 수행합니다.

요약: 미러링 모니터 서버가 미러 서버와 함께 원격 사이트에 존재하는 경우 사이트 간의 통신 회선이 중단되면 자동 장애 조치가 수행됩니다.

시나리오 HACL5: 주 사이트에 미러링 모니터 서버가 있는 두 사이트

이 가용성 우선 시나리오에서는 그림 16과 같이 미러링 모니터 서버를 주 데이터베이스 서버와 같은 사이트에 배치하였는데 두 사이트 사이의 통신이 중단되었다고 가정합니다.

그림 16

그림 16: 주/미러링 모니터 서버 및 미러 서버 사이의 통신이 중단되었습니다.

이 경우 미러 데이터베이스가 있는 서버 B는 주 서버와 미러링 모니터 서버로부터 격리됩니다. 서버 A와 서버 W는 쿼럼을 계속 구성하므로 서버 A의 데이터베이스가 주 데이터베이스로 유지됩니다. 그러나 서버 A는 서버 B를 볼 수 없고 데이터를 전송할 수 없기 때문에 서버 A의 데이터베이스는 연결이 끊긴 상태가 됩니다. 서버 B 또한 서버 A를 볼 수 없으므로 연결이 끊긴 상태가 됩니다. 결과 구성은 그림 17과 같습니다.

그림 17

그림 17: 이 시나리오에서 통신이 손실되면 두 파트너가 연결이 끊긴 상태가 됩니다.

서버 A는 트랜잭션을 계속 받지만 트랜잭션 로그를 잘라내지 못합니다. 회선을 신속하게 복원하면 미러링 세션을 다시 동기화하여 원래 운영 상태로 돌아갈 수 있습니다.

요약: 주 서버와 같은 사이트에 미러링 모니터 서버가 있고 원격 사이트에 미러 서버가 있으면 사이트 사이의 통신 중단이 발생해도 자동 장애 조치가 발생하지 않습니다.

요약: 통신 회선이 끊긴 경우의 가용성 우선 시나리오

세 개의 독립된 서버가 있는 가용성 우선 구성에서 세 개의 독립된 통신 회선이 있는 경우

주/미러 서버 통신 손실이 발생하면 자동 장애 조치가 발생하지 않습니다.
주/미러링 모니터 서버 통신 손실이 먼저 발생하고 이어서 주/미러 서버 통신이 끊기면 자동 장애 조치가 발생합니다. 회선을 복원하면 역방향의 미러링이 유지됩니다.
미러/미러링 모니터 서버 통신 손실이 발생하면 자동 장애 조치가 발생하지 않습니다.

한 통신 회선만 있는 가용성 우선 구성에서 미러링 모니터 서버가 주 서버 또는 미러 서버와 같은 사이트에 있는 경우

미러링 모니터 서버가 미러 서버와 함께 원격 사이트에 있는 경우 사이트 간의 통신 회선이 중단되면 자동 장애 조치가 발생합니다.
미러링 모니터 서버가 주 서버와 같은 사이트에 있고 미러 서버는 원격 사이트에 있는 경우 사이트 간의 통신이 중단되면 자동 장애 조치가 발생하지 않습니다.

보호 우선 시나리오

보호 우선 운영 모드는 안전성은 FULL로 설정되었지만 미러링 모니터 서버 없이 작동합니다. 주 데이터베이스가 있는 서버와 미러 데이터베이스가 있는 서버만 관련되기 때문에 통신 회선이 하나만 있습니다. 그래서 시나리오 또한 많지 않습니다.

사례 1. 보호 우선 운영 모드에서는 두 SQL Server 인스턴스 즉, 주 서버와 미러 서버만 관련됩니다. 미러링 모니터 서버가 없기 때문에 자동 장애 조치가 불가능합니다. 서버 사이에 통신 회선이 하나만 있어서 이 회선이 중단될 경우 그림 18과 같은 구성이 만들어질 수 있습니다.

그림 18

그림 18. 보호 우선 시나리오에서 통신이 중단되면 두 파트너 모두 연결이 끊긴 상태가 되지만 주 서버는 계속 데이터베이스를 서비스합니다.

미러링 모니터 서버가 설정되어 있지 않기 때문에 주 서버는 미러 서버와 쿼럼을 구성할 필요가 없고 일반적인 방법으로 데이터베이스를 서비스합니다.

사례 2. 보호 우선 시나리오에서 미러 데이터베이스를 사용할 수 없게 되면 그림 19처럼 주 서버는 위 시나리오와 동일하게 작동합니다.

그림 19

그림 19: 보호 우선 시나리오에서 미러 서버를 사용할 수 없게 되더라도 주 데이터베이스는 영향을 받지 않습니다.

사례 3. 보호 우선 시나리오에서 주 데이터베이스를 사용할 수 없게 되면 미러 데이터베이스는 미러 서버에 유지되지만 그림 20에서 볼 수 있듯이 연결이 끊긴 상태가 됩니다.

그림 20

그림 20: 보호 우선 모드에서 주 서버를 사용할 수 없게 되면 미러 데이터베이스는 연결이 끊긴 상태가 됩니다.

보호 우선 운영 모드에서는 미러링 모니터 서버가 설정되어 있지 않기 때문에 중단이 발생해도 주 데이터베이스는 사용 가능 상태를 유지하게 되며 미러 데이터베이스는 복구 중 상태로 유지됩니다.

성능 우선 시나리오

성능 우선 운영 모드는 안전성이 OFF인 상태에서 작동합니다. 미러링 모니터 서버는 아무런 역할도 수행하지 않습니다. 주 데이터베이스가 있는 서버와 미러 데이터베이스가 있는 서버만 관련되기 때문에 통신 회선이 하나만 있습니다.

사례 1. 성능 우선 운영 모드의 경우 두 SQL Server 인스턴스가 관련됩니다. 하나에는 주 데이터베이스가 있고 다른 하나에는 미러 데이터베이스가 포함되어 있습니다. 서버 사이에 통신 회선이 하나만 있어서 중단될 경우 그림 21과 같은 구성이 만들어질 수 있습니다.

그림 21

그림 21: 성능 우선 시나리오에서 통신이 중단되면 두 파트너 모두 연결이 끊어지지만 주 데이터베이스는 사용할 수 있습니다.

미러링 모니터 서버가 설정되지 않았기 때문에 서버 A에는 데이터베이스의 가용성을 유지하기 위한 쿼럼이 필요하지 않습니다. 따라서 연결 끊어지더라도 주 서버는 사용자 작업을 계속 받아들입니다. 통신을 복원하면 미러 데이터베이스가 동기화를 시도하지만 동기화가 되지 않을 수 있으며, 누락된 모든 트랜잭션을 검색할 수 없는 경우 다시 실행 오류가 발생할 수도 있습니다.

사례 2. 성능 우선 시나리오에서 미러 데이터베이스를 사용할 수 없게 되면 주 서버의 결과는 그림 22와 같습니다.

그림 22

그림 22: 성능 우선 시나리오에서 미러 서버를 사용할 수 없는 경우 주 데이터베이스는 영향을 받지 않습니다.

안전성이 OFF이므로 주 데이터베이스는 계속 사용할 수 있습니다.

사례 3. 보호 우선 시나리오에서 주 데이터베이스를 사용할 수 없게 되면 그림 23처럼 미러 데이터베이스는 미러로 남아 있지만 연결이 끊어집니다.

그림 23

그림 23: 주 서버를 사용할 수 없게 되면 서버 B는 영향을 받지 않지만 연결이 끊긴 상태가 됩니다.

성능 우선 운영 모드에서는 보호 우선 모드와 마찬가지로 자동 장애 조치가 불가능합니다. 미러링 모니터 서버가 설정되지 않았기 때문에 미러 서버를 사용할 수 없게 되면 주 서버는 데이터베이스를 사용할 수 있도록 유지합니다. 또한 안전성이 OFF이므로 트랜잭션이 미러에 반드시 도달한다고 볼 수 없습니다. 미러에 강제로 장애 조치하는 경우 일부 트랜잭션이 손실될 수 있습니다.

안전성을 OFF로 설정하고 미러링 모니터 서버를 설정한 상태로 실행하는 것은 좋지 않습니다. 안전성이 FULL이 아니기 때문에 미러링 모니터 서버는 자동 장애 조치를 제공할 수 없습니다. 또한 미러링 모니터 서버와 미러 서버를 사용할 수 없게 되면 주 서버는 쿼럼을 상실하게 되므로 데이터이베스의 사본을 오프라인으로 만듭니다.

페이지 위쪽

데이터베이스 미러링 구현

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

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

SQL Server 2005 Management Studio의 개체 탐색기에서 주 또는 미러 데이터베이스를 검사하여 각 데이터베이스 미러링 파트너의 상태를 알아낼 수 있습니다. 주 서버가 미러 서버와 동기화되면 개체 탐색기는 주 데이터베이스 이름 옆에 (Principal, Synchronized) 메시지를 추가하고 미러 서버 이름 옆에 (Mirror, Synchronized) 메시지를 추가합니다. 또한 주 서버에서 호출할 때 [데이터베이스 속성] 대화 상자에 있는 [미러링] 페이지의 [상태] 상자를 보고 데이터베이스 미러링 세션의 상태를 확인할 수 있습니다. 미러 데이터베이스에서는 데이터베이스 속성 대화 상자가 열리지 않습니다.

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

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

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

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

주 서버의 경우 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 및 Receives/sec 카운터는 각 파트너에 대해 서버와의 통신 속도를 알 수 있도록 개별 전송 및 수신 작업 수를 보여 줍니다. Bytes Sent/sec 및 Bytes Received/sec 카운터는 이러한 전송과 수신에 대해 각 파트너 서버에서 전송하고 수신한 총 바이트 수를 보여 줍니다.

다시 실행 및 동기화에 걸리는 시간 예측

Redo Queue 및 Redo Bytes/sec의 값을 사용하면 미러 데이터베이스가 다시 실행을 완료하여 사용 가능해지는 데 걸리는 시간 즉, 장애 조치가 발생하는 데 걸리는 시간을 예측할 수 있습니다. 예측에는 다음과 같은 간단한 수식을 사용합니다.

다시 실행에 대한 예상 시간(초) =
(Redo Queue)/(Redo Bytes/sec)

마찬가지로 Log Send Queue 및 Log Bytes Received/sec 카운터를 사용하면 주 서버의 작업이 앞서 있는 상태에서 다운된 경우 미러 서버가 주 서버와 동기화되는 데 걸리는 시간을 예측할 수 있습니다. 예상 시간은 다음 수식을 통해 구합니다.

동기화에 걸리는 예상 시간(초) =
(Log Send Queue)/( Log Bytes Received /sec)

프로파일러 이벤트

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

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

오류는 설치 및 런타임 중에 가장 발생하기 쉽습니다.

설치 문제 해결

데이터베이스 미러링을 설치했지만 시작되지 않는 경우에는 설치 동안 수행한 단계를 다시 추적해 봅니다.

미러 서버가 제때에 주 서버와 충분히 동기화되는지 확인합니다. 미러링을 시작할 때 다음 메시지가 나타나는 경우

데이터베이스 "AdventureWorks"의 원격 복사본이 데이터베이스 로그의 로컬 복사본에 있는 지정 시간으로 롤포워드되지 않았습니다. (Microsoft SQL Server, 오류: 1412)

미러가 동기화되지 않았음을 알 수 있습니다. 주 서버로부터 로그 레코드를 받을 수 있는 지점까지 미러를 동기화하려면 주 서버에서 미러 서버로 트랜잭션 로그 백업을 적용해야 합니다(NORECOVERY 사용).
각 서버의 SQL Server Windows 서비스 계정이 상대방 서버에서 신뢰되는지 확인합니다. 서버가 신뢰되지 않는 도메인에 있는 경우 인증서가 올바른지 확인합니다.
sys.database_mirroring_endpoints 카탈로그 뷰를 쿼리하여 끝점이 정의되고 시작되었는지 확인합니다.
코드 복사
```
SELECT * FROM sys.database_mirroring_endpoints;
```
또한 정규화된 컴퓨터 이름과 포트 번호가 올바른지 확인합니다. 단일 실제 서버에 있는 여러 인스턴스들 간에 미러링을 수행하는 경우에는 포트 번호가 고유해야 합니다. 각 SQL Server 서비스 로그인은 끝점에 대한 CONNECT 권한이 있어야 합니다.

마지막으로 서버에 대한 각 끝점 역할이 의도한 역할에 맞게 적절히 정의되었는지 확인합니다.
ALTER DATABASE 명령에서 올바른 파트너 이름을 사용했는지 확인합니다. 주 서버와 미러 서버의 sys.database_mirroring 카탈로그 뷰에서 파트너 이름을 확인할 수 있습니다. 가용성 우선 모드인 경우 sys.database_mirroring_witnesses 미러링 모니터 서버에서도 이를 확인할 수 있습니다.

런타임 오류 문제 해결

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

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

코드 복사

ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

문제는 미러 데이터베이스를 복구하게 되면 미러 서버가 주 서버 역할을 수행하게 되지만 쿼럼을 구성할 수 없으므로 데이터베이스를 서비스할 수 없다는 것입니다. 이 경우 안전성을 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 구성(예: AWE, 최대 병렬 처리 수준)을 갖고 있어야 합니다. 그러나 가장 기본적인 사항은 로그인과 해당 권한입니다. 주 서버의 모든 활성 SQL Server 로그인은 미러 서버에도 있어야 합니다. 그렇지 않으면 장애 조치 발생 시 응용 프로그램이 미러 서버를 새로운 주 서버로 사용할 수 없게 됩니다. SQL Server Integration Services에는 한 서버에서 다른 서버로 로그인과 암호를 복사하는 데 사용할 수 있는 로그인 전송 작업이 있기는 하지만 로그인에 대한 데이터베이스 권한은 따로 설정해야 합니다. 다른 도메인에 있는 서버로 로그인을 전송할 때 SID가 일치하지 않으면 이를 일치시켜야 합니다.

주 SQL Server에는 대기 서버로 마이그레이션해야 할 여러 가지 지원 개체가 있을 수 있습니다. 예를 들어, SQL 에이전트 작업 및 경고, SQL Server Integration Services 패키지, 지원 데이터베이스, 링크된 서버 정의, 백업 장치, 유지 관리 계획, SQL 메일 또는 데이터베이스 메일 설정, DTC(Distributed Transaction Coordinator) 설정 등이 있습니다.

SQL 에이전트 작업을 대기 서버로 전송한 경우에는 대부분의 해당 작업을 사용하지 않도록 설정해야 합니다. 장애 조치 발생 시에 이러한 작업을 사용해야 합니다.

장애 조치 후에 응용 프로그램이 SQL Server 인증을 사용할 경우에는 새로운 주 SQL Server의 로그인을 확인할 때 새로운 주 데이터베이스 사용자를 사용해야 합니다. 이 작업에는 저장 프로시저 sp_change_users_login을 사용하는 것이 좋습니다.

다중 데이터베이스 문제

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

가용성 우선 모드를 사용하려는 경우 가장 좋은 방법은 응용 프로그램 하나를 데이터베이스 하나와 짝을 이루도록 하는 것입니다. 그러면 자동 장애 조치가 발생할 경우 응용 프로그램은 더 이상 주 서버에 있는 데이터베이스를 필요로 하지 않습니다. 단일 서버에 여러 데이터베이스가 있고 가용성 우선 모드로 작동할 경우 어떤 일이 발생할지 고려해 보아야 합니다. 실제 서버 중단, SQL Server 인스턴스 오류 또는 통신 오류가 발생할 경우 모든 데이터베이스는 대기 서버로 자동으로 장애 조치되며 미러 데이터베이스는 새로운 주 데이터베이스가 됩니다. 미러링 모니터 서버를 볼 수 있는 경우 응용 프로그램은 새로운 주 데이터베이스에 연결할 수 있습니다. 그러나 데이터베이스 중 하나에서 디스크 오류로 손상된 페이지가 발생한 경우 해당 데이터베이스에만 장애 조치가 이루어진다고 볼 수 없습니다. 이 경우 응용 프로그램을 모두 올바른 데이터베이스에 연결하는 것이 불가능할 수 있습니다.

따라서 여러 데이터베이스를 사용하는 응용 프로그램은 가용성 우선 모드의 데이터베이스 미러링에 적합하지 않습니다. 자동 장애 조치는 사용하지 않더라도 다른 데이터베이스 서버와 동기화를 유지하는 성능 우선 방법을 사용하기 위해 안전성을 OFF로 설정할 수 있습니다.

페이지 위쪽

데이터베이스 미러링 및 고가용성 기술

이제 SQL Server 2005에는 적어도 네 가지의 고가용성 기술이 있으며 일부 중복되기는 하지만 각 기술마다 상대적인 장점과 단점이 있습니다. 이러한 기술은 다음과 같습니다.

데이터베이스 미러링 - 설명을 위해 안전성이 FULL이고 미러링 모니터 서버가 있는 가용성 우선 운영 모드를 고려합니다.
장애 조치 클러스터링 - 가장 일반적인 구성은 SQL Server 인스턴스 하나를 사용하는 두 개 노드의 Windows 장애 조치 클러스터입니다.
로그 전달 - 별도의 모니터링이 있는 SQL Server 기본 제공 로그 전달을 가정합니다.
트랜잭션 복제 - 게시자 서버가 실패하는 경우 대기 서버의 역할을 하는 별도의 배포 서버와 하나의 가입자가 있는 구성을 고려합니다.

이 단원에서는 이러한 네 가지 기술의 기본 기능을 비교하고 데이터베이스 미러링이 더 나은 솔루션을 보완하거나 입증할 수 있는 영역을 자세히 살펴봅니다.

다음 표는 네 가지 기술의 여러 가지 가용성 기능을 보여 줍니다.

표 15: SQL Server 2005 고가용성 기술 비교

Table4

위의 표는 네 가지 고가용성 기술의 여러 가지 특성을 요약한 것입니다. 다음 단원에서는 이러한 기술들을 보다 자세하게 비교합니다.

데이터베이스 미러링 및 클러스터링

데이터베이스 미러링과 장애 조치 클러스터링 사이의 가장 중요한 차이는 각 기술이 제공하는 중복의 수준입니다. 데이터베이스 미러링은 데이터베이스 수준의 보호를 제공하는 반면, 클러스터링은 서버 인스턴스 수준의 보호를 제공합니다. 다른 중요한 차이점은 데이터베이스 미러링에서는 주 서버와 미러 서버가 서로 다른 이름을 가진 별개의 SQL Server 인스턴스인 반면, 클러스터의 SQL Server 인스턴스는 클러스터의 어떤 노드가 인스턴스를 호스팅하는지에 관계없이 항상 동일하게 유지되는 하나의 가상 서버 이름과 IP 주소를 갖는다는 것입니다.

서버 수준에서 데이터베이스를 보호해야 하는 경우(예를 들어, 응용 프로그램이 같은 데이터베이스 서버에서 동시에 많은 데이터베이스에 액세스해야 하는 경우) 장애 조치 클러스터링이 더 적절한 선택일 수 있습니다. 그러나 한 번에 한 데이터베이스에 가용성을 제공하려는 경우에는 데이터베이스 미러링이 더 많은 장점을 제공합니다.

클러스터링과 달리 데이터베이스 미러링은 전용 하드웨어가 필요하지 않으며 공유 저장 공간에 잠재적인 오류 지점이 없습니다. 데이터베이스 미러링은 다른 고가용성 기술보다 훨씬 빨리 대기 데이터베이스를 서비스할 수 있으며 클라이언트 쪽 장애 조치의 경우 ADO.NET 및 SQL Native Access Client의 새로운 기능과 잘 작동합니다.

클러스터 내에서 데이터베이스 미러링을 사용할 수는 없지만 클러스터 인스턴스 데이터베이스의 최신 대기 서버를 만들 때 데이터베이스 미러링을 사용할 수 있습니다. 이렇게 하면 클러스터 장애 조치가 데이터베이스 미러링의 시간 초과 값보다 길기 때문에 미리 경고를 받을 수 있으므로 가용성 우선 모드 미러링 세션은 클러스터 장애 조치를 주 서버의 실패로 간주하고 반응합니다. 그러면 결과적으로 클러스터 노드가 미러링 상태가 됩니다.

데이터베이스 미러링 및 트랜잭션 복제

데이터베이스 미러링 및 트랜잭션 복제는 모두 원본 서버의 트랜잭션 로그 읽기를 기반으로 하지만 그 이후의 단계는 상당히 달라집니다. 트랜잭션 복제에 대한 자세한 내용은 SQL Server 온라인 설명서의 관련 항목을 참조하십시오. 트랜잭션 복제는 게시자 데이터베이스의 사용자 트랜잭션을 몇 초 만에 가입자에 전달할 수 있기 때문에 고가용성을 위해 주로 사용됩니다. 데이터베이스 미러링은 복제만큼 또는 복제보다 더 빠르다는 장점이 있지만 사용자 테이블과 관련된 트랜잭션뿐만 아니라 데이터베이스의 모든 트랜잭션을 전달합니다.

트랜잭션 복제는 보고를 위해 여러 게시자로 데이터를 확장하기에 적절한 기술입니다. 트랜잭션 복제 가입자 데이터베이스는 일반적으로 읽기 전용으로 간주되므로 거의 실시간 데이터 액세스가 필요할 때 이상적입니다.

데이터베이스 미러링은 트랜잭션 복제와 호환되며 게시자 데이터베이스의 최신 대기 데이터베이스를 유지하는 방법으로 가장 유용합니다. 복제 게시자를 보호하는 다른 방법(예: 로그 전달)들은 게시자에 대한 대기 서버를 게시자 자체의 가입자보다 더 최신 상태로 유지할 수 없습니다. 다시 말해 트랜잭션 복제가 트랜잭션 로그 백업 계획보다 훨씬 빠르게 가입자에게 트랜잭션을 전달할 수 있습니다. 데이터베이스 미러링은 아주 빠르므로 게시자 데이터베이스의 최신 대기 서버를 유지하는 데 훨씬 적합합니다.

그러나 게시자가 실패하는 경우 복구된 대기 데이터베이스를 직접 게시자로 다시 설정하고 이를 배포 서버에 다시 연결해야 합니다. 이러한 작업은 로그 전달을 사용하여 게시자 서버를 대기 서버로 유지 관리할 경우 수행해야 하는 작업과 같습니다.

데이터베이스 미러링 및 로그 전달

데이터베이스 미러링 및 로그 전달은 모두 SQL Server 데이터베이스의 복원 및 복구 기능에 의존합니다. 데이터베이스 미러링의 미러 데이터베이스는 항상 복구 중 상태에 있으며 주 서버의 트랜잭션을 계속해서 재생합니다. 로그 전달 보조 데이터베이스는 해당 데이터베이스에 적용된 트랜잭션을 트랜잭션 로그 백업에서 주기적으로 재생합니다. 대량 로그 데이터가 트랜잭션 로그 백업에 추가되기 때문에 로그 전달은 대량 로그 복구 모델에서 작동할 수 있습니다. 반면에 데이터베이스 미러링은 주 서버에서 미러 서버로 로그 레코드를 직접 전송하며 대량 로그 데이터를 전달할 수 없습니다.

대부분의 경우 데이터베이스 미러링은 고가용성의 자동 장애 조치와 함께 로그 전달과 같은 종류의 데이터 중복을 제공할 수 있습니다. 그러나 응용 프로그램이 한 서버에 있는 여러 데이터베이스에 의존하는 경우에는 로그 전달도 데이터 미러링과 동일하게 유효합니다. 앞 단원의 "다중 데이터베이스 고려 사항"을 참조하십시오.

또한 로그 전달을 통해 가용성을 보완할 수 있는 데이터베이스 미러링 시나리오가 있습니다. 예를 들어, 내부에서는 가용성 우선 데이터베이스 미러링 구성을 가지고 있고 재해 복구를 위해 주 서버를 원격 사이트에 로그 전달하는 경우가 있을 수 있습니다. 그림 24는 이러한 구성을 보여 줍니다.

그림 24

그림 24: 원격 위치로 주 데이터베이스를 로그 전달할 수 있습니다.

이 방법의 장점은 전체 사이트의 손실이 발생하는 경우 보조 사이트에서 데이터를 사용할 수 있다는 것입니다. 그러나 데이터베이스 미러링 장애 조치가 발생할 경우 서버 B에서 원격 대기 서버로의 로그 전달은 일반적으로 다시 초기화해야 합니다.

데이터베이스 미러링을 보완하기 위해 로그 전달을 사용하는 또 다른 시나리오에서는 재해 복구를 위해 데이터베이스 미러링 세션을 사용하는 주 서버의 로컬 대기 서버로서 로그 전달이 사용됩니다. 이 경우에는 원격 사이트에 원격 대기 서버로서 미러 서버가 존재하며 미러링 세션은 성능 우선 모드를 사용합니다.

그림 25

그림 25: 모든 트랜잭션을 유지하는 방법으로 주 데이터베이스를 로그 전달할 수 있습니다.

성능 우선 모드에서 주 서버가 실패하여 미러 서버가 강제 서비스 복구를 통해 복구된 경우 데이터가 손실될 수 있습니다. 이전 주 서버를 로그 전달하고 이전 주 서버의 트랜잭션 로그 파일이 손상되지 않은 경우 주 서버의 '비상 로그' 백업을 만들어 트랜잭션 로그로부터 로그 레코드의 마지막 집합을 얻을 수 있습니다. 대기 로그 전달 데이터베이스에 다른 모든 트랜잭션 로그 백업이 적용된 경우 대기 서버에 비상 로그 백업을 적용하면 이전 주 서버의 데이터가 손실되지 않습니다. 그런 다음 로그 전달 대기 서버의 데이터를 원격 데이터베이스와 비교하여 누락된 데이터를 원격 서버로 복사할 수 있습니다.

어떤 경우이든 로그 전달을 데이터베이스 미러링과 비교할 때는 주 데이터베이스의 데이터베이스와 트랜잭션 로그 백업을 유지하는 것이 중요함을 알 수 있습니다. 이러한 로그 백업을 로그 전달 서버에 적용하면 데이터베이스 미러링 구성을 보완할 수 있습니다.

페이지 위쪽

결론

데이터베이스 미러링은 데이터베이스 중복을 위해 고가용성 및 고성능의 솔루션을 제공할 수 있는 새로운 SQL Server 2005 기술입니다. 데이터베이스 미러링에서는 주 서버의 트랜잭션 로그 버퍼가 디스크에 기록(플러시)될 때마다 트랜잭션 로그 레코드가 주 서버에서 미러 데이터베이스로 직접 전송됩니다. 이 기술을 통해 미러 데이터베이스를 주 데이터베이스와 거의 동일한 상태로 유지할 수 있으며 커밋된 데이터가 손실되지 않도록 할 수 있습니다. 가용성 우선 운영 모드에서는 주 서버가 실패하는 경우 미러 서버가 자동으로 새로운 주 서버가 되어 데이터베이스를 복구합니다. 새로운 ADO.NET 또는 SQL Native Access Client 드라이버를 통해 응용 프로그램은 클라이언트 서버에서도 자동 장애 조치를 수행할 수 있습니다. 데이터베이스 미러링은 SQL Server 2005에서 지원하는 고가용성 기술 중에서 새로운 중요 기술로 부각되었습니다.

For More Information

SQL Server TechNet 사이트: http://www.microsoft.com/technet/prodtechnol/sql

SQL Server 개발자 센터: http://msdn.microsoft.com/sql

Microsoft SQL Server 사이트: http://www.microsoft.com/sql/

Database Mirroring FAQ: http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx (영문)

페이지 위쪽

'wow db Log > ms-sql' 카테고리의 다른 글

[MSSQL2008] 701 오류 (리소스 풀 'internal'에 시스템 메모리가 부족하여 이 쿼리를 실행할 수 없습니다.) (0)	2010.04.27
MS-SQL 보안점검 사항 (0)	2010.01.19
[MSSQL] Full Text Search 윈도우 서버에 따른 설정 고려사항 (0)	2009.12.16
[펌] 성능 저하 없이 미러링할 수 있는 데이터베이스의 수는 최대 몇 개? (0)	2009.12.08
[세미나후기] SQL Server 2008 향상된 Query Optimizing (0)	2009.12.07

[MSSQL] SQL Server 2005의 데이터베이스 미러링

이 페이지에서

중요:

소개

데이터베이스 미러링 개요

운영 모드

트랜잭션 안전성

쿼럼 및 미러링 모니터 서버

가용성 우선 운영 모드

보호 우선 운영 모드

성능 우선 운영 모드

데이터베이스 스냅숏 및 미러 데이터베이스

클라이언트 쪽 리디렉션

데이터베이스 미러링 및 SQL Server 2005 Edition

데이터베이스 미러링 다이내믹스

설정 및 보안

데이터베이스 미러링 카탈로그 뷰

데이터베이스 미러링 상태 및 전환

주 서버 데이터베이스 상태

미러 서버 데이터베이스 상태

미러링 모니터 서버 상태

트랜잭션 로그 레코드 전송

데이터베이스 미러링 역할 변경

자동 장애 조치

수동 장애 조치

강제 서비스

데이터베이스 미러링 가용성 시나리오

서버 손실이 있는 가용성 우선 시나리오

시나리오 HASL1.1: 주 서버 손실

시나리오 HASL1.2: 주 서버 손실에 이어 새로운 주 서버 손실

시나리오 HASL1.3. 주 서버 손실에 이어 미러링 모니터 서버 손실

시나리오 HASL2.1 미러 서버 손실

시나리오 HASL2.2: 미러 서버 손실에 이어 주 서버 손실

시나리오 HASL2.3: 미러 서버 손실에 이어 미러링 모니터 서버 손실

시나리오 HASL3.1: 미러링 모니터 서버 손실

시나리오 HASL3.2: 미러링 모니터 서버 손실에 이어 주 서버 손실

시나리오 HASL3.3: 미러링 모니터 서버 손실에 이어 미러 서버 손실

요약: 서버 손실이 있는 가용성 우선 시나리오

통신 손실이 있는 가용성 우선 시나리오

시나리오 HACL1.2: 주/미러 서버 회선이 끊기고 이어서 주/미러링 모니터 서버 회선이 끊김

요약: 통신 회선 손실이 있는 가용성 우선 시나리오: 세 개의 사이트

시나리오 HACL4: 미러 사이트에 미러링 모니터 서버가 있는 두 사이트

시나리오 HACL5: 주 사이트에 미러링 모니터 서버가 있는 두 사이트

요약: 통신 회선이 끊긴 경우의 가용성 우선 시나리오

보호 우선 시나리오

성능 우선 시나리오

데이터베이스 미러링 구현

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

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

다시 실행 및 동기화에 걸리는 시간 예측

프로파일러 이벤트

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

설치 문제 해결

런타임 오류 문제 해결

안전성 및 성능 비교

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

장애 조치를 위한 미러 서버 준비

다중 데이터베이스 문제

데이터베이스 미러링 및 고가용성 기술

데이터베이스 미러링 및 클러스터링

데이터베이스 미러링 및 트랜잭션 복제

데이터베이스 미러링 및 로그 전달

결론

For More Information

'wow db Log > ms-sql' 카테고리의 다른 글

'wow db Log/ms-sql' Related Articles

티스토리툴바