들어가는 글

데이터 손실을
최소화하는 빠른 장애 조치는 전통적으로 하드웨어 비용이 높고 소프트웨어 복잡성이 커집니다. 그러나 데이터 베이스 미러링은 커밋된 데이터 손실이
없이 빠르게 장애 조치할 수 있으며, 전용 하드웨어가 필요하지 않고 설치와 관리가 쉽습니다.

데이터베이스 미러링 개요

모든 SQL
Server 데이터베이스에서 실제 데이터 페이지를 변경하기 전에 트랜잭션 로그에 데이터 변경이 기록됩니다. 트랜잭 션 로그 레코드는 먼저
메모리의 데이터베이스 로그 버퍼에 저장되었다가 가능한 빨리 디스크에 플러시(또는‘하드엔디드’) 됩니다. 데이터베이스 미러링에서 주 서버가 주
데이터베이스의 로그 버퍼를 디스크에 쓰는 것과 동시에 로그 레코드 블록을 미러 인스턴스로 보냅니다.

미러 서버가 로그 레코드 블록을
받으면 먼저 로그 레코드를 미러 데이터베이스의 로그 버퍼에 저장한 다음 가능한 빨리 디스 크에 저장하여 보호합니다. 이러한 트랜잭션 로그
레코드는 나중에 미러에서 재생됩니다. 미러 데이터베이스는 주 트랜잭션 로그 레코드를 재생하기 때문에 주 데이터베이스에 데이터베이스 변경을
복제합니다.

주 서버와 미러 서버는 각각 데이터베이스 미러링 세션의 파트너로 간주됩니다. 데이터베이스 미러링 세션은 한 파트너에서
다른 파트너로 데이터베이스를 미러링할 때 파트너 서버 사이의 관계로 구성됩니다. 해당 파트너 서버는 한 데이터베이스에는 주 서버 역할을 갖고
다른 데이터베이스에서는 미러 서버 역할을 가질 수 있습니다.

두 파트너 서버(주 서버 및 미러 서버) 이외에 데이터베이스 미러링
세션은 감시라고 하는 옵션인 세 번째 서버를 가질 수 있습 니다. 감시 서버의 역할은 자동 장애 조치를 수행하는 것입니다. 고가용성을 위해
데이터베이스 미러링을 사용하면 갑자기 주 서버에 장애가 발생하고, 미러 서버가 감시 서버에서 확인을 받은 경우 자동으로 주 서버의 역할을 맡고
몇 초 내에 데이터베이 스를 사용할 수 있도록 만들 수 있습니다.

데이터베이스 미러링에 대해 유의할 몇 가지 중요한 사항은 다음과
같습니다.

? 주 데이터베이스는 FULL 복구 모델에 있어야 합니다. 대량 로그 작업의 로그 레코드는 미러
데이터베이스로 보낼 수 없습니다.

?미러 데이터베이스는 NORECOVERY를
사용하여 주 데이터베이스의 복원에서, 이어서 순차적으로 주 트랜잭션 로그 백업 의 복원으로부터 초기화해야 합니다.

?미러 데이터베이스 이름은 주 데이터베이스 이름과 같아야 합니다.

? 미러 데이터베이스가 복구 중인 상태에 있기 때문에 직접 액세스할 수 없습니다. 미러에 데이터베이스
스냅샷을 만들어 특정 시간에 미러 데이터베이스를 간접적으로 읽을 수 있습니다. 이 백서 뒷부분의‘데이터베이스 미러링 및 데이터베이스 스냅 샷’을
참조하십시오.

주: 데이터베이스 미러링과 관련된 용어에 대한 자세한 내용은 SQL Server 2005 온라인
설명서의“Overview of Database Mirroring”을 참조하십시오.

동기 전송은 미러 데이터베이스의 트랜잭션 로그에 있는 모든 트랜잭션이 주 데이터베이스의 트랜잭션 로그와 동기화될 수 있도록 하므로
트랜잭션은 안전하게 전송된 것으로 간주됩니다. 다음을 사용하여 안전성을 FULL로 설정합니다.

ALTER
DATABASE [] SET SAFETY FULL;

안전성이 OFF로 설정되면 주 서버와 미러 사이의
통신이 동기화됩니다. 주 서버는 미러가 트랜잭션 레코드의 블록을 저장한 미러에서 승인되는 것을 기다리지 않습니다. 미러는 가능한 빨리 트랜잭션을
기록함으로써 주 서버와 동일한 상태를 유지하려 고 하지만 주 서버에 갑자기 장애가 발생하여 미러가 서비스하도록 하는 경우 일부 트랜잭션이 손실될
수 있습니다. SQL Server 온라인 설명서의‘Forced Service’항목을 참조하십시오.

감시 서버는 쿼럼 구성에서 주 서버나 미러를 지원합니다. 감시 서버가 있는 경우 주 데이터베이스나 미러 데이터베이스 중
하나가 손실되면 두 서버가 쿼럼을 구성하게 됩니다. 주 서버가 미러 서버에 연결할 수 없지만 감시 서버와 쿼럼을 구성할 수 있는 경우
데이터베이스의 서비스는 유지할 수 있습니다. 마찬가지로, 미러와 감시 서버가 주 서버에 연결할 수 없고 미러 서버가 감시 서버와 쿼럼을 구성할
수 없는 경우 미러가 새로운 주 서버의 역할을 맡을 수 있습니다.

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

서버 간에 빠르고 매우 안정적인 통신 경로를 갖는 고가용성 모드를 사용하는 것이 가장 좋으며 단일
데이터베이스에 대한 자동 장애 조치가 필요합니다. 안전성이 FULL이면 주 서버는 잠시 동안 미러 서버로부터 응답을 기다려야 하므로 미러 서버의
기능이 주 서버의 성능에 영향을 줄 수 있습니다. 단일 데이터베이스 오류로 인해 자동 장애 조치되기 때문에 여러 데이터베이 스 응용 프로그램이
있는 경우 다른 작동 모드를 고려할 수 있습니다. 이 문서 뒷부분에 있는 구현 절의“다중 데이터베이스 문제”를
참조하십시오.

고가용성 모드에서 데이터베이스 미러링은 자체 미러링입니다. 주 데이터베이스를 갑자기 사용할 수 없게 되거나 주 서버가
다운되는 경우 감시 서버와 미러 서버는 쿼럼을 구성하며 미러 SQL Server는 자동 장애 조치를 수행합니다. 이 지점에서 미러 서버
인스턴스는 새로운 주 서버로 역할이 변경되고 데이터베이스를 복구합니다. 미러가 주 서버의 트랜잭션 로그를 재생하고 주 서버와 동기화했기 때문에
미러 서버를 신속하게 사용할 수 있습니다.

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

안전성이 FULL이면 주 서버와 미러의 쿼럼이
갑자기 상실될 경우 데이터베이스 서비스를 중단해야 합니다. 감시 서버를 일시 적으로 제거해야 할 때는 고가용성의 경우 전환 상태로 데이터베이스
미러링 구성을 제외하므로 높은 수준의 보호 모드는 사용하지 않는 것이 좋습니다.

고성능 모드에서는 감시 서버는 아무
역할도 하지 않으며 쿼럼이 필요하지 않습니다. 따라서 자동 및 수동 장애 조치는 고성능 모드에 사용되지 않습니다. 허용되는 유일한 장애 조치
유형은 수동 작업이라고도 하는 forced service 장애 조치입니다.

ALTER
DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

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

마치 다른 데이터베이스에 있는 것처럼 데이터베이스 스냅샷에 액세스합니다. 데이터베이스 스냅샷을 쿼리하면
데이터베이스 스냅샷 파일에서 스냅샷을 만든 후에 변경된 데이터베이스 데이터의 원본 버전을 읽고 원본 데이터베이스에서 변경되지 않은 데이터를
읽습니다. 결과적으로 스냅샷을 만든 시점에 최신 데이터베이스 데이터를 볼 수 있습니다. 자세한 내용은 SQL Server 온라인
설명서의“Using Database Snapshots with Database Mirroring”을 참조하십시오.

데이터베이스
스냅샷은 미러 서버에 약간의 오버헤드가 요구되기 때문에 데이터베이스 미러링 성능에 어떤 영향을 미칠 수 있는지에 주의해야 합니다. 한
데이터베이스로만 미러링할 수 있으므로 많은 읽기 전용 보고 서버로 확장해야 하는 경우 트랜 잭션 복제가 더 나은 선택이 될 것입니다. 자세한
내용은 뒷부분의“데이터베이스 미러링 및 복제”를 참조하십시오.

연결
문자열을 작성하는 방법은 많지만 여기에서 제시하는 한 예는 서버 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 자동 리디렉션을 사용하지 않을 경우 응용 프로그램을 장애 조치할 수
있는 다른 기술을 사용할 수 있습니다. 예를 들어, 네트워크 로드 균형 조정을 사용하여 한 서버에서 다른 서버로 연결을 수동으로 리디렉션할 수
있지만 클라이언트는 가상 서버 이름에 연결합니다. 또한 자체 리디렉션 코드를 작성하고 로직을 다시 시도할 수 있습니다.

그러나
데이터베이스 미러링을 사용하여 클라이언트 리디렉션을 통합하는 이러한 모든 기술에는 중요한 제한이 있습니다. 데이터베이스 미러링은 서버 수준이
아니라 데이터베이스 수준에서만 발생합니다. 응용 프로그램이 서버의 여러 데이터베이 스 쿼리에 의존하거나 여러 부분의 개체 이름을 사용하여 여러
데이터베이스에 쿼리하는 경우 주의하십시오. 한 서버에 여러 데이터베이스가 있고 대기 서버에 미러링되면 여러 데이터베이스 중 하나가 대기 서버로
장애 조치될 수 있지만 다른 데이터 베이스는 원래 서버에 남아 있습니다. 이 경우 쿼리하는 데이터베이스 당 하나의 연결이 필요할 수 있으므로 한
데이터베이스만 주 서버이고 나머지는 미러인 대기 서버에서 데이터베이스간 쿼리를 시도하지 마십시오.

?
안전성이 OFF인 고성능 모드(비동기 데이터 전송);
? 데이터베이스 스냅샷;
? 미러 데이터베이스에서 트랜잭션 로그를 재생하는데
여러 스레드 사용(병렬 REDO).

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