"미러링"의 두 판 사이의 차이
(→종류) |
leejia1222 (토론 | 기여) |
||
(다른 사용자 한 명의 중간 판 하나는 보이지 않습니다) | |||
29번째 줄: | 29번째 줄: | ||
|} | |} | ||
<ref name="데이터베이스 미러링">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》</ref> | <ref name="데이터베이스 미러링">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》</ref> | ||
+ | |||
+ | ==구성== | ||
+ | 데이터베이스 미러링은 상황에 맞게 3가지 구성 방법이 있다. | ||
+ | |||
+ | #'''감시 서버를 포함한 동기화 미러링'''(Synchronous mirroring) : 데이터의 손실이 없고 자동으로 장애 조치를 지원한다. 주 서버에서 일어난 [[트랜잭션]]이 미러 서버에 기록이 정확하게 이루어져야만 주 서버에 커밋이 된다. 데이터의 손실이 없는 장점에 비해 성능에 영향을 줄 수 있다. | ||
+ | #'''감시 서버를 포함한 비동기화 미러링 방식'''(Asynchronous mirroring) : 동기화 미러링 방식과는 달리 주 서버에서 트랜잭션이 바로 커밋 된다. 이런 이유로 동기화 방식에 비해 성능이 좋다. 이 방식은 주 서버와 미러 서버 간의 거리가 멀리 떨어지거나 서버 간의 지연이 있는 경우 고려할 수 있는 방식이다. | ||
+ | #'''감시 서버를 포함하지 않은 동기 미러링''' : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.<ref name="데이터베이스 미러링">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》</ref> | ||
+ | |||
+ | ===미러 서버 구성하기=== | ||
+ | 주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.<ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ===미러 데이터베이스 구성하기=== | ||
+ | 미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.<ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ===미러링 구성을 위한 끝점 구성하기=== | ||
+ | *'''미러 서버에 파트너 끝점 구성하기''' | ||
+ | :주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 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) | ||
+ | <ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ===미러 세션 설정하기=== | ||
+ | 위에서 미러 서버와 데이터베이스 준비되고 각 서버에 Endpoint가 생성이 되면 다음과 같이 미러 세션을 설정한다. | ||
+ | |||
+ | *'''미러 서버에서 파트너십 생성하기''' | ||
+ | :우선 미러 서버에서 ALTER DATBASE 명령어를 수행한다. | ||
+ | |||
+ | ALTER DATABASE AdventureWorks | ||
+ | SET PARTNER =‘ TCP://Seoul:5022’ | ||
+ | |||
+ | *'''주 서버에서 파트너십 생성하기''' | ||
+ | ALTER DATABASE AdventureWorks | ||
+ | SET PARTNER =‘ TCP://Busan:5022’ | ||
+ | <ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ===감시 서버 구성하기=== | ||
+ | 자동 장애 조치를 구성하려면 목적 서버를 구성해야 한다. 목적 서버는 주 서버 및 미러 서버와는 다른 서버에 구성이 되어야 한다. 그렇지만 하나의 목적 서버는 여러 개의 미러 세션을 담당할 수 있다. | ||
+ | |||
+ | ALTER DATABASE AdventureWorks | ||
+ | SET WITNESS =‘ TCP://DAEGU:5022’ | ||
+ | <ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ===감시 서버 제거하기=== | ||
+ | 미러 서버가 제거되어도 미러링 세션은 유지된다. 다만, 자동 장애 조치는 불가능하다. 감시 서버를 제거하는 방법은 다음과 같다. | ||
+ | |||
+ | ALTER DATABASE AdventureWorks | ||
+ | SET WITNESS OFF | ||
+ | <ref name="데이터베이스 미러링"></ref> | ||
+ | |||
+ | ==비교== | ||
+ | 고가용성 기술로서 미러링, 장애 조치 클러스터링, 로그 전달, 트랜잭션 복제, 이 네 가지가 존재하고 일부 중복되기는 하지만 각 기술마다 상대적인 장점과 단점이 있다. 이러한 네 가지 기술의 기본 기능을 비교하고 데이터베이스 미러링이 더 나은 솔루션을 보완하거나 입증할 수 있는 영역을 자세히 살펴보겠다. 다음 표는 네 가지 기술의 여러 가지 가용성 기능을 보여준다. | ||
+ | |||
+ | :{|class=wikitable width=1100 | ||
+ | |+<big></big> | ||
+ | !align=center|카테고리 | ||
+ | !align=center|가용성 특징 | ||
+ | !align=center|데이터베이스 미러링 | ||
+ | !align=center|장애 조치 클리스터링 | ||
+ | !align=center|로그 전달 | ||
+ | !align=center|트랜잭션 복제 장애 조치 | ||
+ | |- | ||
+ | |align=center|'''장애 조치 특성''' | ||
+ | |align=center|대기 유형 | ||
+ | |align=center|Hot | ||
+ | |align=center|Hot | ||
+ | |align=center|Warm | ||
+ | |align=center|Hot | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|자동 역할 변경 | ||
+ | |align=center|예 | ||
+ | |align=center|예 | ||
+ | |align=center|사용자 정의 코딩 필요 | ||
+ | |align=center|사용자 정의 코딩 필요 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|장애 조치가 커밋 된 작업을 보존 | ||
+ | |align=center|예 | ||
+ | |align=center|예 | ||
+ | |align=center|아니오 | ||
+ | |align=center|아니오 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|장애 조치 유형 | ||
+ | |align=center|자동 및 수동 | ||
+ | |align=center|자동 및 수동 | ||
+ | |align=center|변수 | ||
+ | |align=center|변수 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|장애 조치 동안 | ||
+ | |align=center|10초 미만 | ||
+ | |align=center|30초 + | ||
+ | |align=center| | ||
+ | |align=center| | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|데이터베이스 | ||
+ | |align=center| | ||
+ | |align=center|데이터베이스 복구 | ||
+ | |align=center| | ||
+ | |align=center| | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|다운 시간 | ||
+ | |align=center| | ||
+ | |align=center| | ||
+ | |align=center| | ||
+ | |align=center| | ||
+ | |- | ||
+ | |align=center|'''Physical 구성''' | ||
+ | |align=center|중복 저장 위치 | ||
+ | |align=center|예 | ||
+ | |align=center|아니오(공유 디스크) | ||
+ | |align=center|예 | ||
+ | |align=center|예 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|하드웨어 요구 사항 | ||
+ | |align=center|표준 서버 | ||
+ | |align=center|클러스터 인증 서버 및 저장 | ||
+ | |align=center|표준 서버 | ||
+ | |align=center|표준 서버 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|실제 거리 제한 | ||
+ | |align=center|없음 | ||
+ | |align=center|100 마일 | ||
+ | |align=center|없음 | ||
+ | |align=center|없음 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|추가 서버 역할 | ||
+ | |align=center|Witness | ||
+ | |align=center|없음 | ||
+ | |align=center|모니터 | ||
+ | |align=center|Distributor | ||
+ | |- | ||
+ | |align=center|'''관리''' | ||
+ | |align=center|복잡도 | ||
+ | |align=center|낮음 | ||
+ | |align=center|높음 | ||
+ | |align=center|낮음 | ||
+ | |align=center|중간 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|대기 서버 액세스 가능 | ||
+ | |align=center|데이터베이스 스냅샷을 통해 가능한 성능 영향 | ||
+ | |align=center|아니오 | ||
+ | |align=center|R/O, 복원과 호환되지 않음 | ||
+ | |align=center|읽기 전용 작업의 경우 예 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|여러 보조 | ||
+ | |align=center|아니오 | ||
+ | |align=center|아니오 | ||
+ | |align=center|예 | ||
+ | |align=center|예 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|보조에서 로드 지연 | ||
+ | |align=center|아니오 | ||
+ | |align=center|아니오 | ||
+ | |align=center|예 | ||
+ | |align=center|아니오 | ||
+ | |- | ||
+ | |align=center| | ||
+ | |align=center|가용성 범위 | ||
+ | |align=center|데이터베이스 | ||
+ | |align=center|서버 인스턴스 | ||
+ | |align=center|데이터베이스 | ||
+ | |align=center|데이터베이스 | ||
+ | |- | ||
+ | |align=center|'''클라이언트 액세스''' | ||
+ | |align=center|클라이언트 리디렉션 | ||
+ | |align=center|ADO.NET 및 SQL Native Client에서 지원 | ||
+ | |align=center|필요 없음, 가상 IP | ||
+ | |align=center|사용자 정의 코딩 필요 | ||
+ | |align=center|사용자 정의 코딩 필요 | ||
+ | |} | ||
+ | |||
+ | 위의 표는 네 가지 가용성 기술의 여러 가지 특성을 요약한 것이다. 다음 절에서는 몇 가지 자세한 비교를 제공한다.<ref name="고가용성 기술">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=144620&boardConfigUid=9&categoryUid=216&boardIdx=68&boardStep=1 데이터베이스 미러링 및 고가용성 기술]〉, 《디비가이드넷》</ref> | ||
+ | |||
+ | ===데이터베이스 미러링 및 클러스터링=== | ||
+ | 데이터베이스 미러링과 장애 조치 클러스터링 사이의 가장 중요한 차이는 각각이 제공하는 중복의 수준이다. 데이터베이스 미러링은 데이터베이스 수준의 보호를 제공하는 반면, 클러스터링은 서버 인스턴스 수준의 보호를 제공한다. 다른 중요한 차이점은 데이터베이스 미러링에서 주 서버와 미러 서버가 서로 다른 이름을 가진 별개의 SQL 서버 인스턴스인 반면, 클러스터의 SQL 서버 인스턴스는 클러스터의 어떤 노드가 인스턴스를 호스팅 하는지에 관계없이 동일하게 유지되는 하나의 가상 서버 이름과 IP 주소를 얻는다는 것이다. 서버 수준에서 데이터베이스를 보호해야 하는 경우(예를 들어, 응용 프로그램이 같은 데이터베이스 서버에서 동시에 많은 데이터베이스에 액세스해야 하는 경우), 장애 조치 클러스터링이 더 적절한 선택일 수 있다. 그러나 한 번에 한 데이터베이스에 대한 가용성을 제공하도록 연결된 경우 데이터베이스 미러링은 여러 가지 장점을 갖고 있다. 클러스터링과 달리 데이터베이스 미러링은 전용 하드웨어가 필요하지 않으며 공유 저장 공간이 있는 잠재적인 오류 지점이 없다. 데이터베이스 미러링은 다른 고가용성 기술보다 훨씬 빨리 대기 데이터베이스를 서비스로 가져오며 클라이언트 쪽 장애 조치의 경우 ADO.NET 및 SQL 네이티브 액세스 클라이언트의 새로운 기능에서 잘 작동한다. 클러스터 내에서 데이터베이스 미러링을 사용할 수 없지만 클러스터 인스턴스 데이터베이스의 핫 대기 서버를 만드는 방법으로 데이터베이스 미러링 사용을 고려할 수 있다. 이렇게 하면 클러스터 장애 조치가 데이터베이스 미러링의 시간 초과 값보다 길기 때문에 발생할 때 클러스터 장애 조치에 반응합니다. 클러스터 노드가 미러링 상태가 된다.<ref name="고가용성 기술"></ref> | ||
+ | |||
+ | ===데이터베이스 미러링 및 트랜잭션 복제=== | ||
+ | 데이터베이스 미러링 및 트랜잭션 복제는 모두 원본 서버의 트랜잭션 로그 읽기를 기준으로 하지만 기술은 상당히 다르다. 트랜잭션 복제에 대한 자세한 내용은 SQL 서버 온라인 설명서의 관련 항목을 참조하면 된다. 트랜잭션 복제는 게시자 데이터 베이스의 사용자 트랜잭션을 몇 초 만에 가입자에 전달할 수 있기 때문에 고가용성에 주로 사용된다. 데이터베이스 미러링은 복제만큼 또는 복제보다 더 빠르다는 장점이 있지만 사용자 테이블과 관련된 트랜잭션만이 아니라 모든 데이터베이스의 트랜잭션을 전달한다. 트랜잭션 복제는 보고를 위해 여러 게시자에게 데이터를 확장하는 적절한 기술이다. 데이터베이스 미러링은 트랜잭션 복제와 호환되며 게시자 데이터베이스의 핫 대기를 유지하는 방법으로 가장 유용하다. 로그 전달 같은 복제 게시자를 보호하는 다른 방법은 게시자 자체 가입자에 앞서 게시자를 위해 대기 서버를 유지할 수 없다. 즉, 트랜잭션 복제는 트랜잭션 로그 백업 스키마보다 훨씬 빠르게 가입자에게 트랜잭션을 전달할 수 있다. 데이터베이스 모니터링이 아주 빠르므로 게시자 데이터베이스의 hot 대기를 유지하는 데 훨씬 적합하다. 그러나 게시자가 실패하는 경우 복구된 대기 데이터베이스를 게시자로 수동으로 다시 설정하고 배포 서버에 다시 연결해야 한다. 따라서 게시자 서버를 대기 서버로 유지하기 위해 로그 전달을 사용하는 경우 현재 수행해야 한다.<ref name="고가용성 기술"></ref> | ||
+ | |||
+ | ===데이터베이스 미러링 및 로그 전달=== | ||
+ | 데이터베이스 미러링 및 로그 전달은 SQL 서버 데이터베이스의 복원과 복구 기능에 의존한다. 데이터베이스 미러링 미러 데이터베이스는 계속 복구 중 상태에 있으며, 주 서버에서 트랜잭션을 계속해서 재생한다. 로그 전달 보조 서버는 트랜잭션 로그 백업에서 주기적으로 적용된 트랜잭션을 재생한다. 대량 로그 데이터가 트랜잭션 로그 백업에 추가하기 때문에 로그 전달은 대량 로그 복구 모델에서 작동할 수 있다. 반면에 데이터베이스 미러링은 주 서버에서 미러 서버로 로그 레코드를 직접 전송하며 대량 로그 데이터를 전달할 수 없다. 많은 경우 데이터베이스 미러링은 고가용? 데이터 중복을 제공할 수 있다. 그러나 응용 프로그램이 한 서버의 여러 데이터베이스에 의존하는 경우 로그 전달은 동일하게 유효한 방법일 수 있다. 앞 절의 “다중 데이터베이스 고려 사항”을 참조하는 게 좋다. 또한 로그 전달이 가용성을 보충할 수 있는 데이터베이스 미러링 시나리오가 있다. 예를 들어, 고가용성 데이터베이스 미러링 구성을 가질 수 있으며 재해 복구 목적을 위해 주 서버를 원격 사이트에 로그 전달할 수 있는 방법을 보여준다. 여기의 장점은 전체 사이트의 손실이 발생하는 경우 보조 사이트에서 데이터를 사용할 수 있다. 그러나 데이터베이스 미러링 장애 조치의 경우 서버 B에서 원격 대기 서버로의 로그 전달은 일반적으로 다시 초기화해야 한다. 데이터베이스 미러링을 보완하기 위해 로그 전달을 사용하는 또 다른 시나리오는 데이터베이스 미러링 세션이 재해 복구에 사용되는 주 서버에 대한 로컬 대기 서버로 사용되는 것이다. 이 경우 미러링 세션은 원격 사이트의 미러 서버가 원격 대기 서버인 고성능 모드에 있다. 고성능 모드에서 주 서버가 실패하고 미러 서버가 강제 서비스 복구를 사용하여 복구된 경우 데이터 손실 가능성이 있다. 이전 주 서버를 로그 전달하고 이전 주 서버의 트랜잭션 로그 파일이 손상되지 않은 경우 주 서버의‘tail of the log’ 백업을 만들어 트랜잭션 로그에서 로그 레코드의 마지막 세트를 얻을 수 있다. 대기 로그 전달 데이터베이스에 다른 모든 트랜잭션 로그 백업이 적용된 경우 대기 서버에 로그 백업의 끝을 적용할 수 있으며 이전 주 서버의 데이터가 손실되지 않는다.<ref name="고가용성 기술"></ref> | ||
+ | |||
+ | ==결론== | ||
+ | 데이터베이스 미러링은 데이터베이스 중복을 위한 고가용성과 고성능 솔루션을 전달할 수 있는 새로운 SQL 서버 2005 기술이다. 데이터베이스 미러링에서 주 서버의 트랜잭션 로그 버퍼가 디스크에 기록될 때마다 트랜잭션 로그 레코드는 주 서버에서 미러 데이터베이스로 직접 전송된다. 이 기술은 주 서버와 거의 최신 상태로 미러 데이터베이스를 유지할 수 있으며 커밋 된 데이터는 손실되지 않는다. 고가용성 작동 모드에서는 주 서버가 실패하는 경우 미러 서버는 자동으로 새로운 주 서버가 되고 데이터베이스를 복구한다. 새로운 ADO.NET 또는 SQL 네이티브 액세스 클라이언트 드라이버를 사용하여 응용 프로그램은 클라이언트 서버에서도 자동 장애 조치를 수행할 수 있다. 데이터베이스 미러링은 SQL 서버 2005에서 지원하는 고가용성 기술에서 중요한 새 옵션이 되고 있다.<ref name="고가용성 기술"></ref> | ||
{{각주}} | {{각주}} | ||
36번째 줄: | 249번째 줄: | ||
*〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》 | *〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》 | ||
*NAVER CLOUD PLATFORM, 〈[https://medium.com/naver-cloud-platform/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-packet-%EB%A5%BC-%EC%A0%9C%EC%96%B4%ED%95%98%EB%8A%94-%EA%B8%B0%EC%88%A0-mirroring-inline-proxy-b45fbb441cca 네트워크(Packet)을 제어하는 기술 (Mirroring / Inline / Proxy)]〉, 《미디엄》, 2019-09-30 | *NAVER CLOUD PLATFORM, 〈[https://medium.com/naver-cloud-platform/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-packet-%EB%A5%BC-%EC%A0%9C%EC%96%B4%ED%95%98%EB%8A%94-%EA%B8%B0%EC%88%A0-mirroring-inline-proxy-b45fbb441cca 네트워크(Packet)을 제어하는 기술 (Mirroring / Inline / Proxy)]〉, 《미디엄》, 2019-09-30 | ||
+ | |||
+ | ==같이 보기== | ||
+ | *[[미러사이트]] | ||
{{하드웨어|검토 필요}} | {{하드웨어|검토 필요}} |
2020년 8월 12일 (수) 13:34 기준 최신판
미러링(mirroring)이란 특정 사이트의 콘텐츠(글, 웹페이지, 이미지 파일, html 소스 등)을 특정 주기를 간격으로 자동으로 복제해 저장해 놓는 기능이다. 특정 사이트를 미러링 하는 사이트를 미러사이트라고 부른다.
목차
개요[편집]
네이버나 다음 등 한국의 대형 포털 사이트에서는 언론사가 제공한 뉴스를 각각의 포털 사이트 내에서 독자들이 읽게 하는데, 이걸 인링크라고 한다. 이 인링크가 내용을 복사하는데 댓글로 여론조작을 하는 등의 부작용이 있다. robots.txt가 작동하는 사이트는 미러링이 쉽지 않다(아카이브라면 가능하다). 구글 웹 캐시 기능이나 archive.is나 웨이백 머신 등의 아카이브도 미러링과 비슷한 맥락이다. 문제는 이게 시스템에 의해 전자동으로 저장되는지, 사람이 직접 저장해야 되는지에 따라 미러링과 아카이브로 나뉘기도 한다는 점이다. 다만 본관 사이트의 허가를 받지 않은 무단 불법 미러링은 위법이라고 판결이 났다. 실제로 일베저장소의 불법 미러링 사이트가 등장하여 게시물을 삭제하려면 100달러를 내야 한다고 한다. 비슷한 불법 미러링 사이트로 세이브 메갈도 있었지만 해킹으로 인해 폐쇄되었다. 물론 이는 시스템에 자동 저장되는 경우 한정이고, 사람이 수동으로 하는 아카이브로 박제하는 것이 위법인 건 아니다. 합법적 미러사이트를 만들어 두었을 때의 장점은 트래픽 초과 등으로 본관이 터졌을 때 대체할 사이트를 만들어 놓을 수 있다는 점이다. 본관이 해킹이나 모종의 이유로 데이터에 이상이 생겼을 때를 대비하여 실시간으로 미러사이트가 백업을 하는 것이 가능하다. 또한 본관 사이트에 집중되었던 트래픽을 분산시킬 수 있다. 엔하위키 및 리그베다 위키에서 트래픽 문제로 검색 엔진의 크롤링을 허용하지 않아서 그런 것도 있다. 다음이나 네이버, 구글 같은 검색 엔진에서 뭘 찾으면 엔하위키 또는 리그베다 위키가 아닌 엔하위키 미러가 나왔으니 당연히 접속자 수가 더 많을 수밖에 없다. 이러한 미러링은 자신에게 요청되었던 모든 것에 대한 복사본을 유지하는 캐시나 프록시 서버와는 달리, 대체로 특정 원격 서버에 있는 전체 디렉터리나 파일들에 대해 이루어진다. 예를 들면, 주요 소프트웨어 개발사들은 대체로 사용자들의 다운로드 편의를 제공하기 위해 전 세계적으로 여러 개의 미러사이트들을 운영한다. 이러한 기법은 하드웨어 또는 소프트웨어에 의해 구현될 수 있다. 미러링은 레이드 시스템의 보편적인 특징이다. 노벨 네트웨어와 같은 일부 운영 체계들은 디스크 미러링을 소프트웨어적으로 지원한다. 이러한 기술이 자기테이프 저장 시스템에 적용되었을 때에는 그것을 미러링이라고 하지 않고 "트위닝"(twinning)이라고 불린다. 미러링에 비해 좀 더 낮은 가격으로 데이터 손실을 최소화할 수 있는 대안은, 디스크를 자기 테이프에 정기적으로 백업하는 것이다. 웹 사이트가 아닌 로컬 컴퓨터의 데이터를 실시간으로 백업하는 것은 '디스크 미러링'이라 불린다. 불법이라면 구글 같은 경우에는 DMCA 테이크다운이 걸려야 한다. 크롤링 해서 데이터를 개인 하드에 소장하는 것까지는 합법이다. 배포하면 그 순간부터 합법과 불법이 갈린다. 특히 박제 목적의 경우에는 임시 조치가 내려질 수도 있다.[1]
종류[편집]
- 스위치 미러링
네트워크 장비인 스위치의 설정에 의해 스위치 포트로 들어오고 나가는 패킷들의 특정한 포트에 미러링 시킬 수 있다. 제어 및 통제 솔루션은 해당 미러링 포트에서 복사된 패킷을 전달받게 됩니다. 단점은 스위치를 통한 미러링의 경우 스위치 자체에 부하가 심해지면, 미러링 패킷이 유실될 수 있다. 스위치 자체 내에서 소프트웨어적인 미러링을 하게 때문에 스위치의 부하가 심해지면 미러링보다는 스위치 본연의 임무가 더 우선시 되기 때문에 미러링은 우선순위에서 밀릴 수밖에 없다. 그러나, 별도의 장비(미러링 탭)가 추가되지 않는다는 점에서 스위치 미러링을 사용하는 경우도 있다.
- 탭 미러링
인풋 포트 1개, 아웃풋 포트 2개로 구성되어 있다. 스위치 미러링과 다르게 물리적(기계적)으로 복사가 이루어지기 때문에 패킷 유실률은 거의 없다. 단점은 네트워크 라인(선) 중간에 들어가야 하는 것이기 때문에 어디에 설치할지 포인트를 잘 잡아야 한다는 것이다. 즉, 어느 위치에 설치해야 회사 내의 원하는 패킷 트래픽 또는 전체 패킷 트래픽을 모두 받아볼 수 있는지 판단해야 한다.[2]
서버역할[편집]
대기 서버에 완벽한 데이터베이스 복사본을 이용하여 데이터베이스의 이중화를 유지한다. 또한 클러스터링에 비해 약 3초 미만의 시간 내에 서비스가 이어진다. 그리고, 특별한 장비의 요구 사항이 없다. 그렇기 때문에 네트워크에 연결되어 있는 일반적인 저 사양의 장비로 훌륭하게 데이터가 용성을 구현할 수 있다. 또한 구현도 쉽다. 그리고, 문제가 발생하면 자동으로 서버의 역할을 교대하여 서비스를 유지한다. 이럴 때 데이터베이스 서버에 연결된 클라이언트 측에서는 어떤 서버를 사용하는지 모르는 상태에서 서버의 변경이 가능하다. 자동적인 데이터베이스 미러링을 구현하기 위해서는 다음과 같은 역할을 가진 서버가 있어야 한다.
역할 설명 주 서버(Principal Server) 데이터베이스를 가지고 서비스를 운영하는 서버 미러 서버(Mirror Server) 주 서버의 데이터베이스의 복사본을 유지하는 서버 감시 서버(Witness Server) 서버 간의 연결과 주 서버의 문제 발생 시 자동적으로 문제점을 해결하는 서버
구성[편집]
데이터베이스 미러링은 상황에 맞게 3가지 구성 방법이 있다.
- 감시 서버를 포함한 동기화 미러링(Synchronous mirroring) : 데이터의 손실이 없고 자동으로 장애 조치를 지원한다. 주 서버에서 일어난 트랜잭션이 미러 서버에 기록이 정확하게 이루어져야만 주 서버에 커밋이 된다. 데이터의 손실이 없는 장점에 비해 성능에 영향을 줄 수 있다.
- 감시 서버를 포함한 비동기화 미러링 방식(Asynchronous mirroring) : 동기화 미러링 방식과는 달리 주 서버에서 트랜잭션이 바로 커밋 된다. 이런 이유로 동기화 방식에 비해 성능이 좋다. 이 방식은 주 서버와 미러 서버 간의 거리가 멀리 떨어지거나 서버 간의 지연이 있는 경우 고려할 수 있는 방식이다.
- 감시 서버를 포함하지 않은 동기 미러링 : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.[3]
미러 서버 구성하기[편집]
주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.[3]
미러 데이터베이스 구성하기[편집]
미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.[3]
미러링 구성을 위한 끝점 구성하기[편집]
- 미러 서버에 파트너 끝점 구성하기
- 주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 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 사용자 정의 코딩 필요 사용자 정의 코딩 필요
위의 표는 네 가지 가용성 기술의 여러 가지 특성을 요약한 것이다. 다음 절에서는 몇 가지 자세한 비교를 제공한다.[4]
데이터베이스 미러링 및 클러스터링[편집]
데이터베이스 미러링과 장애 조치 클러스터링 사이의 가장 중요한 차이는 각각이 제공하는 중복의 수준이다. 데이터베이스 미러링은 데이터베이스 수준의 보호를 제공하는 반면, 클러스터링은 서버 인스턴스 수준의 보호를 제공한다. 다른 중요한 차이점은 데이터베이스 미러링에서 주 서버와 미러 서버가 서로 다른 이름을 가진 별개의 SQL 서버 인스턴스인 반면, 클러스터의 SQL 서버 인스턴스는 클러스터의 어떤 노드가 인스턴스를 호스팅 하는지에 관계없이 동일하게 유지되는 하나의 가상 서버 이름과 IP 주소를 얻는다는 것이다. 서버 수준에서 데이터베이스를 보호해야 하는 경우(예를 들어, 응용 프로그램이 같은 데이터베이스 서버에서 동시에 많은 데이터베이스에 액세스해야 하는 경우), 장애 조치 클러스터링이 더 적절한 선택일 수 있다. 그러나 한 번에 한 데이터베이스에 대한 가용성을 제공하도록 연결된 경우 데이터베이스 미러링은 여러 가지 장점을 갖고 있다. 클러스터링과 달리 데이터베이스 미러링은 전용 하드웨어가 필요하지 않으며 공유 저장 공간이 있는 잠재적인 오류 지점이 없다. 데이터베이스 미러링은 다른 고가용성 기술보다 훨씬 빨리 대기 데이터베이스를 서비스로 가져오며 클라이언트 쪽 장애 조치의 경우 ADO.NET 및 SQL 네이티브 액세스 클라이언트의 새로운 기능에서 잘 작동한다. 클러스터 내에서 데이터베이스 미러링을 사용할 수 없지만 클러스터 인스턴스 데이터베이스의 핫 대기 서버를 만드는 방법으로 데이터베이스 미러링 사용을 고려할 수 있다. 이렇게 하면 클러스터 장애 조치가 데이터베이스 미러링의 시간 초과 값보다 길기 때문에 발생할 때 클러스터 장애 조치에 반응합니다. 클러스터 노드가 미러링 상태가 된다.[4]
데이터베이스 미러링 및 트랜잭션 복제[편집]
데이터베이스 미러링 및 트랜잭션 복제는 모두 원본 서버의 트랜잭션 로그 읽기를 기준으로 하지만 기술은 상당히 다르다. 트랜잭션 복제에 대한 자세한 내용은 SQL 서버 온라인 설명서의 관련 항목을 참조하면 된다. 트랜잭션 복제는 게시자 데이터 베이스의 사용자 트랜잭션을 몇 초 만에 가입자에 전달할 수 있기 때문에 고가용성에 주로 사용된다. 데이터베이스 미러링은 복제만큼 또는 복제보다 더 빠르다는 장점이 있지만 사용자 테이블과 관련된 트랜잭션만이 아니라 모든 데이터베이스의 트랜잭션을 전달한다. 트랜잭션 복제는 보고를 위해 여러 게시자에게 데이터를 확장하는 적절한 기술이다. 데이터베이스 미러링은 트랜잭션 복제와 호환되며 게시자 데이터베이스의 핫 대기를 유지하는 방법으로 가장 유용하다. 로그 전달 같은 복제 게시자를 보호하는 다른 방법은 게시자 자체 가입자에 앞서 게시자를 위해 대기 서버를 유지할 수 없다. 즉, 트랜잭션 복제는 트랜잭션 로그 백업 스키마보다 훨씬 빠르게 가입자에게 트랜잭션을 전달할 수 있다. 데이터베이스 모니터링이 아주 빠르므로 게시자 데이터베이스의 hot 대기를 유지하는 데 훨씬 적합하다. 그러나 게시자가 실패하는 경우 복구된 대기 데이터베이스를 게시자로 수동으로 다시 설정하고 배포 서버에 다시 연결해야 한다. 따라서 게시자 서버를 대기 서버로 유지하기 위해 로그 전달을 사용하는 경우 현재 수행해야 한다.[4]
데이터베이스 미러링 및 로그 전달[편집]
데이터베이스 미러링 및 로그 전달은 SQL 서버 데이터베이스의 복원과 복구 기능에 의존한다. 데이터베이스 미러링 미러 데이터베이스는 계속 복구 중 상태에 있으며, 주 서버에서 트랜잭션을 계속해서 재생한다. 로그 전달 보조 서버는 트랜잭션 로그 백업에서 주기적으로 적용된 트랜잭션을 재생한다. 대량 로그 데이터가 트랜잭션 로그 백업에 추가하기 때문에 로그 전달은 대량 로그 복구 모델에서 작동할 수 있다. 반면에 데이터베이스 미러링은 주 서버에서 미러 서버로 로그 레코드를 직접 전송하며 대량 로그 데이터를 전달할 수 없다. 많은 경우 데이터베이스 미러링은 고가용? 데이터 중복을 제공할 수 있다. 그러나 응용 프로그램이 한 서버의 여러 데이터베이스에 의존하는 경우 로그 전달은 동일하게 유효한 방법일 수 있다. 앞 절의 “다중 데이터베이스 고려 사항”을 참조하는 게 좋다. 또한 로그 전달이 가용성을 보충할 수 있는 데이터베이스 미러링 시나리오가 있다. 예를 들어, 고가용성 데이터베이스 미러링 구성을 가질 수 있으며 재해 복구 목적을 위해 주 서버를 원격 사이트에 로그 전달할 수 있는 방법을 보여준다. 여기의 장점은 전체 사이트의 손실이 발생하는 경우 보조 사이트에서 데이터를 사용할 수 있다. 그러나 데이터베이스 미러링 장애 조치의 경우 서버 B에서 원격 대기 서버로의 로그 전달은 일반적으로 다시 초기화해야 한다. 데이터베이스 미러링을 보완하기 위해 로그 전달을 사용하는 또 다른 시나리오는 데이터베이스 미러링 세션이 재해 복구에 사용되는 주 서버에 대한 로컬 대기 서버로 사용되는 것이다. 이 경우 미러링 세션은 원격 사이트의 미러 서버가 원격 대기 서버인 고성능 모드에 있다. 고성능 모드에서 주 서버가 실패하고 미러 서버가 강제 서비스 복구를 사용하여 복구된 경우 데이터 손실 가능성이 있다. 이전 주 서버를 로그 전달하고 이전 주 서버의 트랜잭션 로그 파일이 손상되지 않은 경우 주 서버의‘tail of the log’ 백업을 만들어 트랜잭션 로그에서 로그 레코드의 마지막 세트를 얻을 수 있다. 대기 로그 전달 데이터베이스에 다른 모든 트랜잭션 로그 백업이 적용된 경우 대기 서버에 로그 백업의 끝을 적용할 수 있으며 이전 주 서버의 데이터가 손실되지 않는다.[4]
결론[편집]
데이터베이스 미러링은 데이터베이스 중복을 위한 고가용성과 고성능 솔루션을 전달할 수 있는 새로운 SQL 서버 2005 기술이다. 데이터베이스 미러링에서 주 서버의 트랜잭션 로그 버퍼가 디스크에 기록될 때마다 트랜잭션 로그 레코드는 주 서버에서 미러 데이터베이스로 직접 전송된다. 이 기술은 주 서버와 거의 최신 상태로 미러 데이터베이스를 유지할 수 있으며 커밋 된 데이터는 손실되지 않는다. 고가용성 작동 모드에서는 주 서버가 실패하는 경우 미러 서버는 자동으로 새로운 주 서버가 되고 데이터베이스를 복구한다. 새로운 ADO.NET 또는 SQL 네이티브 액세스 클라이언트 드라이버를 사용하여 응용 프로그램은 클라이언트 서버에서도 자동 장애 조치를 수행할 수 있다. 데이터베이스 미러링은 SQL 서버 2005에서 지원하는 고가용성 기술에서 중요한 새 옵션이 되고 있다.[4]
각주[편집]
- ↑ 미러링 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%EB%A7%81
- ↑ NAVER CLOUD PLATFORM, 〈네트워크(Packet)을 제어하는 기술 (Mirroring / Inline / Proxy)〉, 《미디엄》, 2019-09-30
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 〈데이터베이스 미러링〉, 《디비가이드넷》
- ↑ 4.0 4.1 4.2 4.3 4.4 〈데이터베이스 미러링 및 고가용성 기술〉, 《디비가이드넷》
참고자료[편집]
- 미러링 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%EB%A7%81
- 〈데이터베이스 미러링〉, 《디비가이드넷》
- NAVER CLOUD PLATFORM, 〈네트워크(Packet)을 제어하는 기술 (Mirroring / Inline / Proxy)〉, 《미디엄》, 2019-09-30
같이 보기[편집]