Microsoft SQL Server 2005/2008
향상된 가용성 기능 (미러링)
1. MIRRORING
1.1 미러링 개요.
데이터베이스 미러링은 SQL Server 데이터베이스 엔진의 서로 다른 서버 인스턴스에 있어야 하는 두 개의 단일 데이터베이스 복사본을 유지 관리하는 것을 일컫는다.
일반적으로 두 서버는 서로 다른 위치의 컴퓨터에 있으며 한 서버는 클라이언트에 데이터베이스를 제공하는(주 서버) 다른 서버는 세션의 구성 및 상태에 따라 상시 또는 웜 대기 서버(미러 서버) 역할을 한다.
데이터베이스의 미러링 세션을 동기화하면 데이터베이스 미러링은 커밋된 트랜잭션에서 데이터 손실 없이 신속한 장애 조치(Failover)를 지원하는 상시 대기 서버를 제공한다.
세션이 동기화되지 않은 경우에는 미러 서버는 일반적으로 웜 대기 서버로 사용할 수 있으며 데이터가 손실될 수 있다.
논리적 수준에서 작동하는 복제와 달리 미러링은 물리적 로그 레코드 수준에서 작동한다.
1.2 미러링 이점.
1.데이터 보호가 향상.
데이터베이스 미러링은 운영 모드가 보호 우선 모드인지 성능 우선 모드인지에 따라 완벽하거나 완벽에 가까운 데이터 중복을 제공한다.
1) 보호 우선 모드
보호 우선 모드에서는 장애 발생시 장애조치(Failover)에 의해 데이터베이스의 대기 복사본이 신속하게 온라인 상태가 된다.(데이터 손실 없음).
2) 우선 모드
비동기 작업(성능 우선 모드)에서는 미러 서버가 로그를 디스크에 쓸 때까지 기다리지 않고 트랜잭션이 커밋되므로 성능이 극대화된다.
SQL Server 2008 Enterprise 이상 버전에서 실행 중인 데이터베이스 미러링 파트너는 데이터 페이지를 읽지 못하게 하는 특정 오류 유형을 자동으로 해결하려고 시도합니다. 페이지를 읽지 못하는 파트너는 다른 파트너로부터 새 복사본을 요청합니다. 이 요청이 성공하면 읽을 수 없는 페이지는 새 복사본으로 대체되고 일반적으로 오류가 해결됩니다.
비동기 데이터베이스 미러링은 SQL Server 2005 Enterprise Edition 서비스 팩 1(SP1) 이상 버전에서만 지원됩니다. |
3. 업그레이드 중에 프로덕션 데이터베이스의 가용성이 증가합니다
2. 데이터베이스 미러링 운영 모드.
2.1 비동기 모드
비동기 작업을 통해 주 서버는 최소 트랜잭션 대기 시간으로 실행될 수 있지만 데이터가 손실될 수 있는 위험이 있다. 미러 서버는 주 서버가 보낸 로그 레코드를 유지하려고 합니다. 미러서버는 주 서버보다 약간 뒤처질 수 있다. 그러나 두 데이터베이스의 시간 간격은 일반적으로 크지 않다. 그러나 주 서버에 작업이 크거나 미러 서버 시스템이 과부화된 경우 이 시간 간격은 상당히 커질 수 있다.
2.2 동기 모드
자동 장애 조치(Failover) 있는 보호 우선 모드를 사용하려면 미러링 모니터 서버라는 세 번째 서버 인스턴스가 필요하다.
미러링 모니터 서버는 두 파트너와는 달리 데이터베이스를 제공하지 않는다.. 미러링 모니터 서버는 주 서버가 작동하는지 여부만 확인하여 자동 장애 조치(Failover)를 지원한다. 미러 서버는 미러 서버 및 미러링 모니터 서버가 주 서버와 연결이 끊어진 후에도 서로 연결되어 있는 경우에만 자동 장애 조치(Failover)를 시작한다.
3. 데이터베이스 미러링 작동 방법
3. 1 미러링 작동 방법
주 서버와 미러 서버는 데이터베이스 미러링 세션 내에서 파트너로 통신하고 협력한다. 언제든지 한 파트너는 주 역할을 수행하고 다른 파트너는 미러 역할을 수행한다.
데이터베이스 미러링은 주 데이터베이스에서 발생한 모든 삽입, 업데이트 및 삭제 작업을 가능한 한 빨리 미러 데이터베이스에 대해서도 실행한다. 모든 활성 트랜잭션 로그 레코드를 미러 서버로 보내고, 미러 서버에서 가능한 한 빨리 로그 레코드를 순서대로 미러 데이터베이스에 적용한다.
SQL Server 2008에서는 들어오는 로그 레코드를 수신할 때 미러 서버가 로그 레코드를 디스크에 비동기식으로 씁니다. 이와 동시에 미러 서버는 디스크에 이미 기록된 로그 레코드를 처리합니다.
4. 미러링 세션
미러링이 시작되면 각 파트너는 해당 데이터베이스와 다른 파트너 및 미러링 모니터(있는 경우)에 대한 데이터베이스의 상태 정보를 유지 관리하기 위하여 미러링 세션을 유지한다.
미러링 세션을 시작할 때 미러 서버는 미러 데이터베이스에서 가장 최근에 적용된 트랜잭션 로그의 LSN(로그 시퀀스 번호)을 식별하고 주 서버에 모든 후속 트랜잭션(있는 경우)에 대한 트랜잭션 로그를 요청한다. 이에 대한 응답으로 주 서버는 미리 데이터베이스로 복원되었거나 미러 서버로 전송된 마지막 로그 이후 누적된 모든 활성 로그 레코드를 미러 서버로 보낸다.
Send Queue : 주 데이터베이스의 로그 디스크에 누적된 보내지 않은 로그.
Redo Queue : 미러 로그를 즉시 디스크에 쓰고 미러 데이터베이스에 적용될 떄 까지 보관되는 로그.
Redo Queue에서 대기 중인 복원되지 않은 로그의 양은 미러 데이터베이스로 장애 조치(Failover)하는 데 필요한 시간을 나타낸다.
4.1 동시 세션
모든 데이터베이스 미러링 세션에서 서버 인스턴스가 파트너나 미러링 모니터 서버로만 사용되는 경우가 많다. 그러나 각 세션은 다른 세션과 독립적이므로 서버 인스턴스가 일부 세션에서는 파트너 역할을 하고 다른 세션에서는 미러링 모니터 서버 역할을 할 수 있다.
서버 인스턴스 | 데이터베이스 A | 데이터베이스 B | 데이터베이스 C | 데이터베이스 D |
SSInstance_1 | 미러링 모니터 | 파트너 | 파트너 | 파트너 |
SSInstance_2 | 파트너 | 미러링 모니터 | 파트너 | 파트너 |
SSInstance_3 | 파트너 | 파트너 | 미러링 모니터 | 미러링 모니터 |
서버 인스턴스가 파트너 및 미러링 모니터 두 가지 모두로 작동하도록 설정하는 경우 데이터베이스 미러링 끝점이 두 역할을 모두 지원해야 한다.
4.2 세션에 대해 생성되는 스레드
1) 미러링 통신을 위한 하나의 전역 스레드(Service Broker에 의해 시작)
2) 서버 인스턴스가 미러링 파트너 역할을 하는 경우(주 서버이든 미러 서버이든 관계없음):미러된 데이터베이스당 이벤트 처리용 스레드
3)이벤트 스레드 차단 방지를 위해 미러된 데이터베이스당 비동기 태스크(예: 로그 전송 또는 로그 작성)용 스레드
4) 인스턴스가 미러 서버 역할을 수행할 때마다: 대기 중인 로그 제출, 페이지 미리 읽기 수행, 잠금 다시 획득 등을 위한 다시 실행 관리자 스레드
5) SQL Server Standard의 경우 미러 데이터베이스당 실행 스레드 하나, SQL Server Enterprise의 경우 CPU 4개마다 미러 데이터베이스당 실행 스레드 하나. 이러한 스레드는 실제 로그 실행 작업을 한다.
6) 인스턴스가 미러링 모니터 역할을 수행하고 있는 모든 미러링 세션에 대한 미러링 모니터 메시지를 처리하기 위한 전역 스레드
4.3 세션을 일시 중지할 경우 주서버에 미치는 영향.
데이터베이스 소유자는 언제든지 세션을 일시 중지할 수 있다.
일시 중지된 세션은 미러링을 제거하기 전까지 세션 상태를 유지한다. 세션이 일시 중지되면 주 서버에서 새 로그 레코드를 미러 서버로 보내지 않는다. 이러한 레코드는 모두 활성 상태로 유지되며 주 데이터베이스의 트랜잭션 로그에 누적된다. 미러링 세션이 일시 중지된 동안에는 트랜잭션 로그를 자를 수 없다. 따라서 데이터베이스 미러링 세션을 너무 오래 일시 중지하면 로그가 가득 찰 수 있다.
5. 미러링 구성 방법
새 미러 데이터베이스를 만들려면 최소한 주 데이터베이스의 전체 백업과 후속 로그 백업이 필요하며 WITH NORECOVERY를 사용하여 두 백업을 모두 미러 서버 인스턴스로 복원해야 한다.
미러링이 작동하려면 미러 데이터베이스가 RESTORING 상태여야 한다. 또한 필수 로그 백업 후에 추가 로그 백업이 수행된 경우 미러링을 시작하려면 추가 로그 백업도 항상 WITH NORECOVERY를 사용하여 모두 수동으로 적용해야 한다.
1) 테스트 DB를 생성하여 (DB : MirrorTest) 데이터를 입력한다. (Tbl : MirrorTbl)
2) 주서버의 MirrorTest 를 백업하여 미러서버에 복원한다. 이때 복원상태는 NORECOVERY로 한다.
3) 주 서버에서 미러링을 설정한다.
4) 미러링을 시작하여 세션 동기화를 시킨다.
5) 주 서버에서 데이터를 변경하여 미러서버로 전달되는지 확인한다. 미러서버는 복구 상태이기 때문에 스냅샷을 이용하여 변경된 내용을 확인할 수 있다.
6) 스냅샷을 이용하여 동기화 되었는지 확인한다.
6. SQL 2008 향상된 미러 기능.
6.1 미러 서버의 들어오는 로그 스트림 미리 쓰기.
SQL Server 2008에서는 들어오는 로그 레코드를 수신할 때 미러 서버가 로그 레코드를 디스크에 비동기식으로 씁니다. 이와 동시에 미러 서버는 디스크에 이미 기록된 로그 레코드를 처리합니다.
SQL Server에서는 미리 쓰기 로그(WAL) 기능을 사용하여 관련된 로그 레코드가 디스크에 기록되기 전에는 어떠한 데이터 수정 내용도 디스크에 기록되지 않도록 합니다. 따라서 트랜잭션의 ACID (원자성, 일관성, 격리성 및 내구성) 속성이 유지 관리됩니다.
WAL : SQL Server는 데이터를 검색해야 할 때 데이터 페이지를 읽어 오는 버퍼 캐시를 유지 관리한다. 데이터 수정은 디스크에 직접 수행되지 않고 버퍼 캐시의 페이지 복사본에서 수행된다. 수정된 내용은 데이터베이스에 검사점이 발생할 때까지 디스크에 기록되지 않거나 버퍼가 새 페이지를 보유하는 데 사용될 수 있도록 디스크에 기록(플러쉬)된다.
캐시에서 수정되었으나 아직 디스크에 기록되지 않은 페이지를 커밋되지 않은 페이지라고 한다. 버퍼에 있는 페이지가 수정될 때 로그 캐시에는 수정 내용을 기록하는 로그 레코드가 작성된다. 이 로그 레코드는 관련된 커밋되지 않은 페이지가 버퍼 캐시에서 디스크로 플러시되기 전에 디스크에 기록되어야 한다. 로그 레코드가 기록되기 전에 커밋되지 않은 페이지가 플러시되면 로그 레코드가 디스크에 기록되기 전에 서버 장애가 발생하는 경우에는 롤백될 수 없는 수정된 내용이 디스크에 작성된다. SQL Server에는 관련 로그 레코드가 기록되기 전에 커밋되지 않은 페이지가 플러시되지 않도록 하는 논리가 있다. 로그 레코드는 트랜잭션이 커밋될 때 디스크에 기록됩니다.
6.2 로그 송신 버퍼의 향상된 사용
SQL Server 2005에서는 주 서버의 모든 로그 플러시 작업에서 로그 레코드를 위해 전체 데이터베이스 미러링 로그 송신 버퍼가 예약된다.
그러나 SQL Server 2008에서는 최근에 사용한 로그 캐시의 여유 공간이 충분하면 다음 로그 플러시 작업의 로그 레코드가 이 로그 캐시에 추가됩니다. 그렇지 않으면 새 로그 캐시가 할당된다.
6.3 트랜잭션 로그 레코드 스트림의 압축
SQL Server 2008부터 주 서버는 트랜잭션 로그 레코드의 스트림을 미러 서버에 보내기 전에 압축한다. 이러한 로그 압축은 모든 미러링 세션에서 발생한다. 데이터베이스 미러링 세션은 동기 또는 비동기 작업으로 실행된다. 모든 데이터베이스 미러링 세션은 주 서버와 미러 서버를 각각 하나씩만 지원합니다.
1) SQL Server 2008에서는 테이블 및 인덱스 모두에 대해 행 압축과 페이지 압축이 모두 지원됩니다.
(1) 힙으로 저장되는 전체 테이블
(2) 러스터형 인덱스로 저장되는 전체 테이블
(3) 전체 비클러스터형 인덱스
(4) 전체 인덱싱된 뷰
2) 분할된 테이블과 인덱스의 경우 파티션별로 압축 옵션을 구성할 수 있고 개체의 다양한 파티션에 동일한 압축 설정을 구성할 필요가 없다.
3) 테이블의 압축 설정은 비클러스터형 인덱스에 자동으로 적용되지 않는다. 즉, 각 인덱스를 개별적으로 설정해야 한다. 시스템 테이블에는 압축을 사용할 수 없다.
4) 테이블과 인덱스는 CREATE TABLE 및 CREATE INDEX 문을 사용하여 만들 때 압축할 수 있다.
6.4. 적어도 12.5% 압축률을 얻을 수 있는 스트림 데이터 압축.
BOL : ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.ko/s10de_1devconc/html/5f33e686-e115-4687-bd39-a00c48646513.htm
6.5 실행 취소 단계에서의 페이지 미리 읽기
장애 조치 후 새 미러 서버에서는 디스크에 로컬로 기록되었지만 로그 레코드가 이전 미러 서버(새 주 서버)에 전달되지 않았을 가능성이 있는 변경된 모든 페이지를 실행 취소해야 한다. 이러한 변경된 페이지를 실행 취소하려면 미러 서버는 먼저 해당 페이지를 새 주 서버에서 요청하고 받아야 한다. SQL Server 2008에서는 이 실행 취소 단계 부분의 성능이 향상되었다.
1) 실행 취소 단계 초기에 미러 서버는 주 서버에 미리 읽기 힌트를 전송하여 나중에 요청될 페이지를 알린다.
2) 주 서버에서는 페이지에 대한 미리 읽기 힌트를 수신한 후 해당 페이지를 송신 버퍼에 배치한다. 이렇게 하면 해당되는 페이지 요청을 받았을 때 주 서버에서 즉시 응답할 수 있다.
6.6 손상된 페이지의 자동 복구
SQL Server 2008 이상 버전에서 실행 중인 데이터베이스 미러링 파트너는 데이터 페이지를 읽지 못하게 하는 특정 오류 유형을 자동으로 해결하려고 시도한다. 페이지를 읽지 못하는 파트너는 다른 파트너로부터 새 복사본을 요청합니다. 이 요청이 성공하면 읽을 수 없는 페이지는 새 복사본으로 대체되고 일반적으로 오류가 해결됩니다.
'SQL Server > SQL Server Tip' 카테고리의 다른 글
SET 문 종류 (0) | 2015.07.17 |
---|---|
미러링 구현시 Failover 프로그램 코딩 (0) | 2015.07.17 |
SQL Server Agent 테이블 (0) | 2015.07.17 |
초보자를 위한 복제 4탄 – 스크립트 생성 방법 및 재구성 (1) | 2015.07.17 |
초보자를 위한 복제3탄 – 구독 설정 (0) | 2015.07.16 |