위키원
"미러사이트"의 두 판 사이의 차이
잔글 |
잔글 (→구성) |
||
| 37번째 줄: | 37번째 줄: | ||
#'''감시 서버를 포함하지 않은 동기 미러링''' : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.<ref name="디비가이드넷></ref> | #'''감시 서버를 포함하지 않은 동기 미러링''' : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.<ref name="디비가이드넷></ref> | ||
| − | + | ===미러 서버 구성하기=== | |
| − | |||
주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.<ref name="디비가이드넷></ref> | 주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.<ref name="디비가이드넷></ref> | ||
| − | + | ===미러 데이터베이스 구성하기=== | |
| − | |||
미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.<ref name="디비가이드넷></ref> | 미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.<ref name="디비가이드넷></ref> | ||
| − | + | ===미러링 구성을 위한 끝점 구성하기=== | |
| − | |||
*'''미러 서버에 파트너 끝점 구성하기''' | *'''미러 서버에 파트너 끝점 구성하기''' | ||
:주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 Mirror_EndP라는 파트너 끝점을 만든다. STATE 파라미터를 STARTED로 지정하게 되면 바로 활성화된다. TCP 포트 5022는 미러링에서 기본적으로 사용하는 포트 번호이다. | :주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 Mirror_EndP라는 파트너 끝점을 만든다. STATE 파라미터를 STARTED로 지정하게 되면 바로 활성화된다. TCP 포트 5022는 미러링에서 기본적으로 사용하는 포트 번호이다. | ||
| 72번째 줄: | 69번째 줄: | ||
<ref name="디비가이드넷></ref> | <ref name="디비가이드넷></ref> | ||
| − | + | ===미러 세션 설정하기=== | |
위에서 미러 서버와 데이터베이스 준비되고 각 서버에 Endpoint가 생성이 되면 다음과 같이 미러 세션을 설정한다. | 위에서 미러 서버와 데이터베이스 준비되고 각 서버에 Endpoint가 생성이 되면 다음과 같이 미러 세션을 설정한다. | ||
| 86번째 줄: | 83번째 줄: | ||
<ref name="디비가이드넷></ref> | <ref name="디비가이드넷></ref> | ||
| − | + | ===감시 서버 구성하기=== | |
자동 장애 조치를 구성하려면 목적 서버를 구성해야 한다. 목적 서버는 주 서버 및 미러 서버와는 다른 서버에 구성이 되어야 한다. 그렇지만 하나의 목적 서버는 여러 개의 미러 세션을 담당할 수 있다. | 자동 장애 조치를 구성하려면 목적 서버를 구성해야 한다. 목적 서버는 주 서버 및 미러 서버와는 다른 서버에 구성이 되어야 한다. 그렇지만 하나의 목적 서버는 여러 개의 미러 세션을 담당할 수 있다. | ||
| 93번째 줄: | 90번째 줄: | ||
<ref name="디비가이드넷></ref> | <ref name="디비가이드넷></ref> | ||
| − | + | ===감시 서버 제거하기=== | |
미러 서버가 제거되어도 미러링 세션은 유지된다. 다만, 자동 장애 조치는 불가능하다. 감시 서버를 제거하는 방법은 다음과 같다. | 미러 서버가 제거되어도 미러링 세션은 유지된다. 다만, 자동 장애 조치는 불가능하다. 감시 서버를 제거하는 방법은 다음과 같다. | ||
2020년 8월 10일 (월) 23:24 판
미러사이트(mirror site)란 다른 사이트의 정보를 마치 거울(mirror)처럼 그대로 복사하여 동일한 정보를 제공하는 웹사이트를 말한다. 동일한 내용을 전 세계 여러 지역에 분산하여 서비스함으로써 네트워크 부하를 분산할 수 있고, 시스템 장애 시 신속히 대응할 수 있는 장점이 있다. 다만, 동일한 시스템을 여러 곳에 중복하여 구축·운영해야 하므로 관리 및 비용 부담이 큰 단점이 있다. 유사한 개념으로 CDN이 있다.
목차
개요
다른 웹사이트의 콘텐츠를 그대로 복사하여 갖고 있는 사이트를 말한다. 이런 식으로 웹사이트의 파일을 동기화하는 것을 미러링이라고 부른다. 미러링의 목적은 데이터의 안정적 보존 및 본 서버에 문제가 생겼을 경우에 대한 대비이다. 미러링을 함으로써 엔하위키 미러, 나무위키 미러처럼 본 서버의 접속자를 분산하거나 해당 웹페이지를 빠르고 가볍게 접속할 수 있다. 본래 트래픽 감당과 빠른 접속을 위해 코드나 디자인이 간결하게 만들어지는 것이 특징이며, 그 기반을 둔 사이트를 본관이라고 지칭하기도 한다. 시스템에 의해 전자동으로 저장되는지, 사람이 직접 저장하는지에 따라 미러링과 아카이브로 나뉘기도 한다. 사람이 수동으로 하는 아카이브로 박제하는 것은 위법이 아니다. 다만 본관 사이트의 허가를 받지 않은 무단 불법 미러링은 위법이라고 판결이 났다. 대표적인 예시로서 엔하위키 미러가 있다. 주요 소프트웨어 개발사들은 대체로 사용자들의 다운로드 편의를 제공하기 위해 전 세계적으로 여러 개의 미러사이트들을 운영한다. 미러사이트는 원래 사이트의 정확한 복제품이어야 하므로 원래 사이트의 내용을 확실히 반영시키기 위해 보통 주기적으로 갱신된다. 미러사이트들은 원래 사이트가 지리적으로 어느 정도의 거리가 있을 때, 보다 빨리 액세스하기 위해 사용된다. 어떤 경우에는 원래 사이트가 인터넷에 고속으로 접속되어 있지 않은 경우, 고속으로 접속되어 있는 대형 사이트에 미러사이트를 만든다면, 아마도 보다 많은 방문객을 유지할 수 있을 것이다.[1][2]
특징
작동하는 방법에는 여러 가지가 있다. 가장 일반적으로 미러는 스냅 샷과 같이 원본 사이트의 정적 복사본으로, 소유자가 콘텐츠를 최신 상태로 유지하려면 미러를 자주 업데이트해야한다. 원래 사이트의 변경 사항으로 최신 상태를 유지하는 라이브 미러를 설정할 수도 있다. 미러사이트의 용도에 따라 미러는 전체 웹 사이트를 복사하거나 파일 아카이브 역할을 할 수 있다. 미러사이트를 설정하는 일반적인 이유 중 하나는 서버에 과부하가 걸리는 갑작스러운 트래픽 유입에 대처하기 위한 것이다. 방문자에게 미러사이트 또는 여러 사이트를 제공함으로써 사이트 소유자는 사람들이 사이트를 볼 수 있도록 사이트를 계속 운영 할 수 있다. 서버 문제나 트래픽 유입으로 인해 사이트가 다운 될 때 유용하다. 미러사이트는 백업으로도 사용되므로 서버가 어떤 식 으로든 손상되거나 손상된 경우 전체 파일 세트가 다른 곳에서 호스팅되도록 한다. 소프트웨어 다운로드는 종종 서버를 압도하지 않고 사용자 편의를 위해 미러사이트에서 호스팅된다. 예를 들어 독일에있는 다운로드 사이트는 일본 사용자를 위해 일본에 미러사이트를 제공하여 파일을 더 빨리 다운로드 할 수 있다. 또한 여러 서버에 소프트웨어를 배포하면 하나 이상의 사이트가 다운 되더라도 사용자가 항상 소프트웨어에 액세스 할 수 있다. 고전적으로 미러사이트는 검열과 싸우기 위해 사용되었다. 예를 들어, 사이트가 종료 된 경우를 대비하여 논란이 많은 사이트가 원격 위치에 미러링 될 수 있다. 또는 검열 소프트웨어에 의해 금지 된 사이트는 사람들이 여전히 액세스 할 수 있도록 미러를 호스팅 할 수 있다. 미러는 원본 사이트가 중단되거나 근본적으로 재 설계 될 때 견딜 수있는 일종의 살아있는 아카이브인 빈티지 컨텐츠의 저장소 역할을 할 수도 있다. 이전 화신에서 사이트를 보거나 날짜가 있지만 여전히 관심이있는 정보에 액세스하려는 사용자에게 유용할 수 있다.[3]
미러링
특정 사이트의 콘텐츠(글, 웹페이지, 이미지 파일, html 소스 등)을 특정 주기를 간격으로 자동으로 복제해 저장해 놓는 기능이다. 특정 사이트를 미러링 하는 사이트를 미러사이트라고 부른다. 네이버나 다음 등 한국의 대형 포털 사이트에서는 언론사가 제공한 뉴스를 각각의 포털 사이트 내에서 독자들이 읽게 하는데, 이걸 인링크라고 한다. 이 인링크가 내용을 복사하는데 댓글로 여론조작을 하는 등의 부작용이 있다. robots.txt가 작동하는 사이트는 미러링이 쉽지 않다(아카이브라면 가능하다). 구글 웹 캐시 기능이나 archive.is나 웨이백 머신 등의 아카이브도 미러링과 비슷한 맥락이다. 문제는 이게 시스템에 의해 전자동으로 저장되는지, 사람이 직접 저장해야 되는지에 따라 미러링과 아카이브로 나뉘기도 한다는 점이다. 다만 본관 사이트의 허가를 받지 않은 무단 불법 미러링은 위법이라고 판결이 났다. 실제로 일베저장소의 불법 미러링 사이트가 등장하여 게시물을 삭제하려면 100달러를 내야 한다고 한다. 비슷한 불법 미러링 사이트로 세이브메갈도 있었지만 해킹으로 인해 폐쇄되었다. 물론 이는 시스템에 자동 저장되는 경우 한정이고, 사람이 수동으로 하는 아카이브로 박제하는 것이 위법인건 아니다. 합법적 미러사이트를 만들어 두었을 때의 장점은 트래픽 초과등으로 본관이 터졌을 때 대체할 사이트를 만들어 놓을 수 있다는 것, 본관이 해킹이나 모종의 이유로 데이터에 이상이 생겼을 때를 대비하여 실시간으로 미러사이트가 백업을 할 수 있다는 점이다. 또한 본관 사이트에 집중되었던 트래픽을 분산시킬 수 있다. 엔하위키 및 리그베다 위키에서 트래픽 문제로 검색 엔진의 크롤링을 허용하지 않아서 그런 것도 있다. 다음이나 네이버, 구글 같은 검색 엔진에서 뭘 찾으면 엔하위키 또는 리그베다 위키가 아닌 엔하위키 미러가 나왔으니 당연히 접속자 수가 더 많을 수밖에 없다. 이러한 미러링은 자신에게 요청되었던 모든 것에 대한 복사본을 유지하는 캐시나 프록시 서버와는 달리, 대체로 특정 원격 서버에 있는 전체 디렉토리나 파일들에 대해 이루어진다. 예를 들면, 주요 소프트웨어 개발사들은 대체로 사용자들의 다운로드 편의를 제공하기 위해 전세계적으로 여러 개의 미러사이트들을 운영한다. 이러한 기법은 하드웨어 또는 소프트웨어에 의해 구현될 수 있다. 미러링은 RAID 시스템의 보편적인 특징이다. 노벨 네트웨어와 같은 일부 운영체계들은 디스크 미러링을 소프트웨어적으로 지원한다. 이러한 기술이 자기테이프 저장 시스템에 적용되었을 때에는 그것을 미러링이라고 하지 않고 "트위닝"(twinning)이라고 불리운다. 미러링에 비해 좀더 낮은 가격으로 데이터 손실을 최소화할 수 있는 대안은, 디스크를 자기 테이프에 정기적으로 백업하는 것이다. 웹 사이트가 아닌 로컬 컴퓨터의 데이터를 실시간으로 백업하는 것은 '디스크 미러링'이라 불린다. 불법이라면 구글같은 경우에는 DMCA 테이크 다운이 걸려야 한다. 크롤링해서 데이터를 개인 하드에 소장하는 것까지는 합법이다. 배포하면 그 순간부터 합법과 불법이 갈린다. 특히 박제 목적의 경우에는 임시조치가 내려질 수도 있다.[4]
- 서버역할
대기 서버에 완벽한 데이터베이스 복사본을 이용하여 데이터베이스의 이중화를 유지한다. 또한 클러스터링에 비해 약 3초 미만의 시간 내에 서비스가 이어진다. 그리고, 특별한 장비의 요구 사항이 없다. 그렇기 때문에 네트워크에 연결되어 있는 일반적인 저 사양의 장비로 훌륭하게 데이터가 용성을 구현할 수 있다. 또한 구현도 쉽다. 그리고, 문제가 발생하면 자동으로 서버의 역할을 교대하여 서비스를 유지한다. 이럴 때 데이터베이스 서버에 연결된 클라이언트 측에서는 어떤 서버를 사용하는지 모르는 상태에서 서버의 변경이 가능하다. 자동적인 데이터베이스 미러링을 구현하기 위해서는 다음과 같은 역할을 가진 서버가 있어야 한다.
역할 설명 Principal Server(주 서버) 데이터베이스를 가지고 서비스를 운영하는 서버 Mirror Server(미러서버) 주 서버의 데이터베이스의 복사본을 유지하는 서버 Witness Server(감시서버) 서버간의 연결과 주 서버의 문제 발생시 자동적으로 문제점을 해결하는 서버
구성
데이터베이스 미러링은 상황에 맞게 3가지 구성 방법이 있다.
- 감시 서버를 포함한 동기화 미러링(Synchronous mirroring) : 데이터의 손실이 없고 자동으로 장애 조치를 지원한다. 주 서버에서 일어난 트랜잭션이 미러 서버에 기록이 정확하게 이루어져야만 주 서버에 커밋이 된다. 데이터의 손실이 없는 장점에 비해 성능에 영향을 줄 수 있다.
- 감시 서버를 포함한 비동기화 미러링 방식(Asynchronous mirroring) : 동기화 미러링 방식과는 달리 주 서버에서 트랜잭션이 바로 커밋 된다. 이런 이유로 동기화 방식에 비해 성능이 좋다. 이 방식은 주 서버와 미러 서버 간의 거리가 멀리 떨어지거나 서버 간의 지연이 있는 경우 고려할 수 있는 방식이다.
- 감시 서버를 포함하지 않은 동기 미러링 : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.[5]
미러 서버 구성하기
주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.[5]
미러 데이터베이스 구성하기
미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.[5]
미러링 구성을 위한 끝점 구성하기
- 미러 서버에 파트너 끝점 구성하기
- 주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 Mirror_EndP라는 파트너 끝점을 만든다. STATE 파라미터를 STARTED로 지정하게 되면 바로 활성화된다. TCP 포트 5022는 미러링에서 기본적으로 사용하는 포트 번호이다.
CREATE ENDPOINT Mirror_EndP STATE=STARTED AS TCP(LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=PARTNER)
- 주 서버에 파트너 끝점 구성하기
- 미러 서버에서 보여준 것처럼, 주 서버는 미러링 서비스를 제공하는 SQL 서버 인스턴스와 통신을 할 파트너 끝점이 필요하다.
CREATE ENDPOINT Mirror_EndP STATE=STARTED AS TCP (LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=WITNESS)
- 목격자 서버에 목격자 끝점 구성하기
- 시나리오에 미러링 끝점이 포함되어 있으면 목격자 서비스를 제공하는 SQL 서버 인스턴스 상에 끝점이 필요하다.
CREATE ENDPOINT Mirror_EndP STATE=STARTED AS TCP (LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=WITNESS)
미러 세션 설정하기
위에서 미러 서버와 데이터베이스 준비되고 각 서버에 Endpoint가 생성이 되면 다음과 같이 미러 세션을 설정한다.
- 미러 서버에서 파트너십 생성하기
- 우선 미러 서버에서 ALTER DATBASE 명령어를 수행한다.
ALTER DATABASE AdventureWorks SET PARTNER =‘ TCP://Seoul:5022’
- 주 서버에서 파트너십 생성하기
ALTER DATABASE AdventureWorks SET PARTNER =‘ TCP://Busan:5022’
감시 서버 구성하기
자동 장애 조치를 구성하려면 목적 서버를 구성해야 한다. 목적 서버는 주 서버 및 미러 서버와는 다른 서버에 구성이 되어야 한다. 그렇지만 하나의 목적 서버는 여러 개의 미러 세션을 담당할 수 있다.
ALTER DATABASE AdventureWorks SET WITNESS =‘ TCP://DAEGU:5022’
감시 서버 제거하기
미러 서버가 제거되어도 미러링 세션은 유지된다. 다만, 자동 장애 조치는 불가능하다. 감시 서버를 제거하는 방법은 다음과 같다.
ALTER DATABASE AdventureWorks SET WITNESS OFF
비교
고가용성 기술로서 미러링, 장애 조치 클러스터링, 로그 전달, 트랜잭션 복제, 이 네 가지가 존재하고 일부 중복되기는 하지만 각 기술마다 상대적인 장점과 단점이 있다. 이러한 네 가지 기술의 기본 기능을 비교하고 데이터베이스 미러링이 더 나은 솔루션을 보완하거나 입증할 수 있는 영역을 자세히 살펴 보겠다. 다음 표는 네 가지 기술의 여러 가지 가용성 기능을 보여준다.
카테고리 가용성 특징 데이터베이스 미러링 장애 조치 클리스터링 로그 전달 트랜잭션 복제장애 조치 장애 조치 특성 대기 유형 Hot Hot Warm Hot 자동 역할 변경 예 예 사용자 정의 코딩 필요 사용자 정의 코딩 필요 장애 조치가 커밋된 작업을 보존 예 예 아니오 아니오 장애 조치 유형 자동 및 수동 자동 및 수동 변수 변수 장애 조치 동안 10초 미만 30초 + 데이터베이스 데이터베이스 복구 다운 시간 Physical 구성 중복 저장 위치 예 아니오(공유 디스크) 예 예 하드웨어 요구 사항 표준 서버 클러스터 인증 서버 및 저장 표준 서버 표준 서버 실제 거리 제한 없음 100 마일 없음 없음 추가 서버 역할 Witness 없음 모니터 Distributor 관리 복잡도 낮음 높음 낮음 중간 대기 서버 액세스 가능 데이터베이스 스냅샷을 통해 가능한 성능 영향 아니오 R/O, 복원과 호환되지 않음 읽기 전용 작업의 경우 예 여러 보조 아니오 아니오 예 예 보조에서 로드 지연 아니오 아니오 예 아니오 가용성 범위 데이터베이스 서버 인스턴스 데이터베이스 데이터베이스 클라이언트 액세스 클라이언트 리디렉션 ADO.NET 및 SQL Native Client에서 지원 필요 없음, 가상 IP 사용자 정의 코딩 필요 사용자 정의 코딩 필요
위의 표는 네 가지 가용성 기술의 여러 가지 특성을 요약한 것이다. 다음 절에서는 몇 가지 자세한 비교를 제공한다.[6]
- 데이터베이스 미러링 및 클러스터링
데이터베이스 미러링과 장애 조치 클러스터링 사이의 가장 중요한 차이는 각각이 제공하는 중복의 수준이다. 데이터베이스 미러링은 데이터베이스 수준의 보호를 제공하는 반면, 클러스터링은 서버 인스턴스 수준의 보호를 제공한다. 다른 중요한 차이점은 데이터베이스 미러링에서 주 서버와 미러 서버가 서로 다른 이름을 가진 별개의 SQL Server 인스턴스인 반면, 클러 스터의 SQL Server 인스턴스는 클러스터의 어떤 노드가 인스턴스를 호스팅하는지에 관계 없이 동일하게 유지되는 하나의 가상 서버 이름과 IP 주소를 얻는다는 것이다. 서버 수준에서 데이터베이스를 보호해야 하는 경우(예를 들어, 응용 프로그램이 같은 데이터베이스 서버에서 동시에 많은 데이터베이스에 액세스해야 하는 경우), 장애 조치 클러스터링이 더 적절한 선택일 수 있다. 그러나 한 번에 한 데이터베이스에 대한 가용성을 제공하도록 연결된 경우 데이터베이스 미러링은 여러 가지 장점을 갖고 있다. 클러스터링과 달리 데이터베이스 미러링은 전용 하드웨어가 필요하지 않으며 공유 저장 공간이 있는 잠재적인 오류 지점이 없다. 데이터베이스 미러링은 다른 고가용성 기술보다 훨씬 빨리 대기 데이터베이스를 서비스로 가져오며 클라이언트쪽 장애 조치의 경우 ADO.NET 및 SQL Native Access Client의 새로운 기능에서 잘 작동한다. 클러스터 내에서 데이터베이스 미러링을 사용할 수 없지만 클러스터 인스턴스 데이터베이스의 hot 대기 서버를 만드는 방법으로 데이터베이스 미러링 사용을 고려할 수 있다. 이렇게 하면 클러스터 장애 조치가 데이터베이스 미러링의 시간 초과 값보다 길기 때문에 발생할 때 클러스터 장애 조치에 반응합니다. 클러스터 노드가 미러링 상태가 된다.[6]
- 데이터베이스 미러링 및 트랜잭션 복제
데이터베이스 미러링 및 트랜잭션 복제는 모두 원본 서버의 트랜잭션 로그 읽기를 기준으로 하지만 기술은 상당히 다르다. 트랜잭션 복제에 대한 자세한 내용은 SQL Server 온라인 설명서의 관련 항목을 참조하면 된다. 트랜잭션 복제는 게시자 데이터 베이스의 사용자 트랜잭션을 몇 초 만에 가입자에 전달할 수 있기 때문에 고가용성에 주로 사용된다. 데이터베이스 미러링은 복제만큼 또는 복제보다 더 빠르다는 장점이 있지만 사용자 테이블과 관련된 트랜잭션만이 아니라 모든 데이터베이스의 트랜잭션을 전달한다. 트랜잭션 복제는 보고를 위해 여러 게시자에게 데이터를 확장하는 적절한 기술이다. 데이터베이스 미러링은 트랜잭션 복제와 호환되며 게시자 데이터베이스의 hot 대기를 유지하는 방법으로 가장 유용하다. 로그 전달 같은 복제 게시자를 보호하는 다른 방법은 게시자 자체 가입자에 앞서 게시자를 위해 대기 서버를 유지할 수 없다. 즉, 트랜잭션 복제는 트랜잭션 로그 백업 스키마보다 훨씬 빠르게 가입자에게 트랜잭션을 전달할 수 있다. 데이터베이스 모니터링이 아주 빠르므로 게시자 데이터베이스의 hot 대기를 유지하는 데 훨씬 적합하다. 그러나 게시자가 실패하는 경우 복구된 대기 데이터베이스를 게시자로 수동으로 다시 설정하고 배포 서버에 다시 연결해야 한다. 따라서 게시자 서버를 대기 서버로 유지하기 위해 로그 전달을 사용하는 경우 현재 수행해야 한다.[6]
- 데이터베이스 미러링 및 로그 전달
데이터베이스 미러링 및 로그 전달은 SQL Server 데이터베이스의 복원과 복구 기능에 의존한다. 데이터베이스 미러링 미러 데이터베이스는 계속 복구 중 상태에 있으며, 주 서버에서 트랜잭션을 계속해서 재생한다. 로그 전달 보조 서버는 트랜잭션 로그 백업에서 주기적으로 적용된 트랜잭션을 재생한다. 대량 로그 데이터가 트랜잭션 로그 백업에 추가하기 때문에 로그 전달은 대량 로그 복구모델에서 작동할 수 있다. 반면에 데이터베이스 미러링은 주 서버에서 미러 서버로 로그 레코드를 직접 전송하며 대량 로그 데이터를 전달할 수 없다. 많은 경우 데이터베이스 미러링은 고가용? 데이터 중복을 제공할 수 있다. 그러나 응용 프로그램이 한 서버의 여러 데이터베이스에 의존하는 경우 로그 전달은 동일하게 유효한 방법일 수 있다. 앞 절의 “다중 데이터베이스 고려 사항”을 참조하는 게 좋다. 또한 로그 전달이 가용성을 보충할 수 있는 데이터베이스 미러링 시나리오가 있다. 예를 들어, 고가용성 데이터베이스 미러링 구성을 가질 수 있으며 재해 복구 목적을 위해 주 서버를 원격 사이트에 로그 전달할 수 있는 방법을 보여준다. 여기의 장점은 전체 사이트의 손실이 발생하는 경우 보조 사이트에서 데이터를 사용할 수 있다. 그러나 데이터베이스 미러링 장애 조치의 경우 서버 B에서 원격 대기 서버로의 로그 전달은 일반적으로 다시 초기화해야 한다. 데이터베이스 미러링을 보완하기 위해 로그 전달을 사용하는 또 다른 시나리오는 데이터베이스 미러링 세션이 재해 복구에 사용되는 주 서버에 대한 로컬 대기 서버로 사용되는 것이다. 이 경우 미러링 세션은 원격 사이트의 미러 서버가 원격 대기 서버인 고성능 모드에 있다. 고성능 모드에서 주 서버가 실패하고 미러 서버가 강제 서비스 복구를 사용하여 복구된 경우 데이터 손실 가능성이 있다. 이전 주 서버를 로그 전달하고 이전 주 서버의 트랜잭션 로그 파일이 손상되지 않은 경우 주 서버의‘tail of the log’ 백업을 만들어 트랜잭션 로그에서 로그 레코드의 마지막 세트를 얻을 수 있다. 대기 로그 전달 데이터베이스에 다른 모든 트랜잭션 로그 백업이 적용된 경우 대기 서버에 로그 백업의 끝을 적용할 수 있으며 이전 주 서버의 데이터가 손실되지 않는다.[6]
결론
데이터베이스 미러링은 데이터베이스 중복을 위한 고가용성과 고성능 솔루션을 전달할 수 있는 새로운 SQL Server 2005 기술이다. 데이터베이스 미러링에서 주 서버의 트랜잭션 로그 버퍼가 디스크에 기록될 때마다 트랜잭션 로그 레코드는 주 서버에서 미러 데이터베이스로 직접 전송된다. 이 기술은 주 서버와 거의 최신 상태로 미러 데이터베이스를 유지할 수 있으며 커밋된 데이터는 손실되지 않는다. 고가용성 작동 모드에서는 주 서버가 실패하는 경우 미러 서버는 자동으로 새로 운 주 서버가 되고 데이터베이스를 복구한다. 새로운 ADO.NET 또는 SQL Native Access Client 드라이버를 사용하여 응용 프로그램은 클라이언트 서버에서도 자동 장애 조치를 수행할 수 있다. 데이터베이스 미러링은 SQL Server 2005에서 지원하는 고가용성 기술에서 중요한 새 옵션이 되고 있다.[6]
각주
- ↑ 미러 사이트 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%20%EC%82%AC%EC%9D%B4%ED%8A%B8
- ↑ 〈mirror site ; 미러사이트〉, 《텀즈》, 1999-11-04
- ↑ 〈미러 사이트 란 무엇입니까?〉, 《네트인백》
- ↑ 미러링 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%EB%A7%81
- ↑ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7 〈데이터베이스 미러링〉, 《디비가이드넷》
- ↑ 6.0 6.1 6.2 6.3 6.4 〈데이터베이스 미러링 및 고가용성 기술〉, 《디비가이드넷》
참고자료
- 미러 사이트 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%20%EC%82%AC%EC%9D%B4%ED%8A%B8
- 미러링 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%EB%A7%81
- 〈미러 사이트 란 무엇입니까?〉, 《네트인백》
- 〈데이터베이스 미러링〉, 《디비가이드넷》
- 〈데이터베이스 미러링 및 고가용성 기술〉, 《디비가이드넷》
- 〈mirror site ; 미러사이트〉, 《텀즈》, 1999-11-04
같이 보기
