달력

12

« 2024/12 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

'SQL'에 해당되는 글 2

  1. 2011.01.13 SQL Server의 이중화 솔루션 소개
  2. 2009.04.15 SQL Server 자료에 대한 접근성 향상
2011. 1. 13. 11:43

SQL Server의 이중화 솔루션 소개 Who&What2011. 1. 13. 11:43

Cloud Portal 구축중 이슈해결을 위해 SQL 복제 구현이 필요하게 되었습니다. 
복제와 비슷한 여러 이중화 기술들이 존재하고 각각 어떠한 환경과 요구사항에서 필요한지 살펴보려 합니다
 

데이터 사이즈가 커지면서 여러 가지 이유로 이중화 솔루션이 필요하게 됩니다. SQL Server에서 제공하는 이중화 솔루션은 어떤 것들이 있는지 알아 보고 향후 이중화 솔루션에 대해 고려해야 할 때 조금이나마 도움이 되었으면 좋겠습니다.

 

목차.

1.     복제(Replication)

2.    미러링(Mirroring)

3.    로그 전달(Log Shipping)

4.    MSCS(MS Cluster Service)

 

 

1. 복제(Replication)

복제는 한 데이터베이스에서 다른 데이터베이스로 데이터와 데이터베이스 개체를 복사 및 배포한 다음 데이터베이스 간에 동기화를 수행하여 일관성을 유지하는 기술입니다. 복제된 대상 DB는 온라인 상태를 유지하게 되므로 다른 일련의 역할을 수행할 수 있게 됩니다.

 

복제의 논리적 구조 (잡지의 개념으로 생각하면 이해가 쉽습니다.)

- 잡지사(게시자)에서는 하나 이상의 출판물(게시)을 생산합니다.

- 출판물(게시)에는 하나 이상의 기사(아티클)가 있습니다.

- 잡지를 배포하는 배급업자(배포자)가 있습니다.

- 구독자는 각자가 구독하는 출판물(게시)을 받아 봅니다.


 

SQL Server에서 제공하는 복제 솔루션

트랜잭션 복제

Transaction Replication

- 가장 많이 사용되는 유형으로 데이터 변경에 대한 로그를 읽어 비동기적으로 데이터를 대상DB에 반영.

- 동일한 데이터가 5회 변경될 경우 마지막 데이터가 아닌 5번의 변경 모두가 대상 DB에 각각 반영됨.

- 기본적으로 row 단위로 데이터가 반영.(한번에 5건을 업데이트 하는 쿼리 수행시 5번의 업데이트 단일 row 업데이트 쿼리로 변경되어 동기화가 진행)

- 다른 복제에 비해 짧은 동기화 시간을 가짐.

- 게시자 또는 구독자가 Oracle인 경우 사용 가능함.

스냅숏 복제

Snapshot Replication

- 지정한 개체의 모든 데이터를 대상DB에 반영.

- 동기화가 진행되는 동안 구독자의 데이터를 사용할 수 없음.

- 지정한 개체의 사이즈가 큰 경우 동기화에 시간이 오래 걸림.

- 데이터 사이즈가 작고, 많은 업데이트가 발생하는 경우 유용함.

- 사용예시 : 슈퍼마켓 지점과 본점의 데이터를 매일 새벽 동기화.

병합 복제

Merge Replication

- 게시자와 구독자 모두가 데이터 변경을 할 수 있음.

- 동일한 데이터가 5회 변경될 경우 변경 데이터의 마지막 값을 가지고 있다가 동기화시 마지막 값을 대상 DB에 반영함.

- 트리거를 통하여 변경되는 행의 대해 마지막 변경값을 시스템 테이블로 관리함.

- 충돌 발생시 지정한 우선순위에 따라 어떤 값을 반영할지 결정함.

- 사용예시 : PDA PC간의 데이터 동기화

P2P 복제

P2P Replication

- 모든 노드가 게시와 구독의 역할 모두를 수행함.

- 중간의 1개 노드가 장애 발생시에도 다른 노드를 통하여 데이터 동기화 하여 복제 가용성을 높일 수 있음.

- 양방향 트랜잭션 복제와 유사한 형태로 동작함.

 

 

2. 미러링(Mirroring)

- 미러링은 데이터베이스 가용성을 높이기 위한 소프트웨어 솔루션입니다.

- 미러링은 데이터베이스 단위로 구현되며 전체 복구 모델을 사용하는 데이터베이스에서만 작동합니다.

- 미러링은 데이터베이스를 제공하는 주서버(Principal Server)와 장애 조치를 위한 미러서버(Mirror Server)로 기본구성을 하며, 운영 모드에 따라 모니터 서버(Witness Server)를 추가하여 장애 발생시 자동 장애조치(Failover)를 수행할 수 있습니다.

 

미러링의 구성도

 

미러링의 운영 모드

SAFETY FULL

보호 우선 모드

- 모니터 서버를 두어 주 서버에서 장애 발생시 자동으로 미러 서버가 주 서버의 역할을 하도록 자동 장애조치를 지원함.

- 주 서버와 미러 서버의 트랜잭션이 동기적으로 수행되어 변경된 데이터가 미러 서버에도 반영 되어야 주 서버의 Commit이 완료됨.
-
트랜잭션이 두 파트너에서 모두 커밋되지만 트랜잭션 대기 시간이 길어짐

SAFETY OFF

보호 우선 모드

- “SAFETY FULL 보호 우선 모드에서 모니터 서버가 없는 운영모드.

성능 우선 모드

- 주 서버와 미러 서버의 트랜잭션이 비동기적으로 수행되어 미러 서버의 Commit을 기다리지 않고 주 서버의 Commit이 완료됨.

- 비동기 작업을 통해 주 서버는 최소 트랜잭션 대기 시간으로 실행될 수 있지만 데이터가 손실될 수 있는 위험이 있음.

 

미러링의 또다른 기능

- 스냅샷을 통한 조회 : 미러 서버의 데이터베이스는 일반적으로 오프라인 상태가 유지됩니다. 하지만 데이터베이스 스냅숏 기능을 이용하여 데이터베이스를 읽을 수 있는 시점을 지정해 읽기 전용으로 사용할 수 있습니다.

- 로그 스트림 압축 : SQL Server 2008 부터는 주 서버에서 미러 서버로 데이터를 보내기 전에 로그 스트림을 압축할 수 있습니다.

- 페이지복원 : 미러링에 참여중인 데이터베이스는 데이터 페이지를 읽지 못하게 하는 특정 오류 유형을 자동으로 해결하려고 시도합니다. 페이지를 읽지 못하는 파트너는 다른 파트너로부터 새 복사본을 요청합니다. 이 요청이 성공하면 읽을 수 없는 페이지는 새 복사본으로 대체되고 일반적으로 오류가 해결됩니다.

 

 

3. 로그 전달(Log Shipping)

로그 전달을 사용하면 주 서버 데이터베이스에서 별도의 보조 서버에 있는 하나 이상의 보조 데이터베이스로 트랜잭션 로그 백업을 자동으로 보낼 수 있습니다. 트랜잭션 로그 백업은 각 보조 데이터베이스에 개별적으로 적용됩니다. 모니터 서버라고 하는 선택적인 세 번째 서버는 백업과 복원 작업의 기록 및 상태를 기록하고 예약된 대로 작업이 실행되지 않으면 선택적으로 경고를 발생시킬 수 있습니다.

 

로그 전달의 구성도

로그 전달의 특징

- 로그 전달 구성은 자동으로 주 서버에서 보조 서버로 장애 조치(Failover)되지 않습니다. 주 데이터베이스를 사용할 수 없을 경우 수동으로 임의의 보조 데이터베이스를 온라인 상태로 전환할 수 있습니다.

- 보조 서버의 데이터베이스는 일반적으로 읽기 전용 상태를 유지하지만 복원 작업 진행시 모든 연결이 끊어지게 됩니다.

- SQL Server 2008 부터는 압축 백업을 이용하여 좀 더 빠르게 로그 전달을 수행할 수 있습니다.

 

 

4. MSCS(MS Cluster Service)

SQL Server 장애 조치 클러스터는 Windows Server 장애 조치 클러스터 위에 구축되어 전체 SQL Server 인스턴스에 고가용성을 제공합니다.

SQL Server 장애 조치 클러스터는 네트워크에서 한 대의 컴퓨터처럼 보이지만 현재 노드를 사용할 수 없을 때 노드 간 장애 조치(Failover) 기능을 제공합니다. 예를 들어 디스크 이외의 하드웨어 오류, 운영 체제 오류 또는 계획된 운영 체제 업그레이드 작업 중에 다른 노드에서 SQL Server 인스턴스를 구성하여 서비스를 유지할 수 있습니다. 그러나 장애 조치 클러스터는 디스크 오류에 대한 대비책은 아닙니다.

 

MSCS의 구성도

 

- Heartbeat 라인을 통하여 각 노드의 상태를 서로 체크하게 됩니다.

- 외부에서는 항상 동일한 Virtual IP를 바라보며, 어떤 노드가 Active한지를 알 필요가 없습니다.

- 공유 스토리지를 사용하기 때문에 데이터 동기화의 비용이 들지 않습니다.

- 구성 방식에 따라 각 노드를 Active-Passive , Active-Active로 구성할 수 있으며, 최대 16개 노드를 구성할 수 있습니다.

 

 

참고자료.

http://msdn.microsoft.com/ko-kr/library/bb500348.aspx

http://msdn.microsoft.com/ko-kr/library/bb522583.aspx

http://www.microsoft.com/korea/sqlserver/2008/whats-new.aspx

 


하만철 / Ha Man-cheol

:
Posted by 에너지발전소
2009. 4. 15. 11:38

SQL Server 자료에 대한 접근성 향상 Who&What2009. 4. 15. 11:38

Microsoft.com에서 제공하는 SQL Server관련 정보는 크게 다음 2곳을 통해서 전달된다. 최근에는 한글 site도 영문과 동일한 UI로 변경되어 정보의 일관성과 전달 능력이 한층 개선된 모습을 볼 수 있다.

SQL Server의 특성상 고객이 Developer와 IT Pro 양쪽 분에 걸쳐 있는 경향이 강하다. 그래서, 과거에는 특정 내용을 찾을 때 MSDN과 TechNet중 어디에 해당 자료고 있는지 아는 것이 어려웠고, 자료를 올리는 입장에서도 어디에 올려야 맞는지 혼란스러운 경우가 많았다.

바뀐 디자인에서는 UI뿐만아니라, 내부 디자인에 많은 변화가 있었다. 일명 "core content" 개념을 도입하여 Developer와 IT Pro에 동일하게 내용을 적용하는 것이 그것이다. 즉, 핵심 컨텐츠들을 양쪽 site에 동일하게 보여지고, 개발자나 IT Pro의 고유한 내용을 담고 있는 것은 해당 site에만 게시되는 방식이다.

 

  • A : DevCenter
  • B : TechCenter
  • AnB : Core Content

예를들어, DevCenter의 Community page를 보자. 이 페이지의 오른쪽 상단부에 "View this page on TechNet"라는 구문을 볼 수 있다. 또한, 페이지 하단에는 Developer 중심의 event, webcast, virtual lab등을 볼 수 있다.

반대로 TechNet에서 이 페이지를 보면, 오른쪽 상단부에 "View this page on MSDN"이라는 문구를 볼 수 있고, 하단에는 IT Pro중심의 content들이 (있으면) 뜨도록 설계된 화면을 볼 수 있다.

결론적으로, 좀 더 똑똑해지고 사용하기 편해진 DevCenter, TechCenter를 통해 원하는 자료에 대한 접근성이 한층 증가되었다. 빠른 속도로 늘어가는 데이터에 효과적으로 접근하기 위해 Know-where와 search의 중요성이 점점 증가하고 있다. 이런 시점에 나온 site개편은 아주 효과적으라고 생각된다.

작은 TIP을 하나 소개하자면, 검색 결과 URL에서 en-us라고 나온 화면이 있다면, 이것을 ko-kr로 변경해 볼 수 있다. 만약 한글화된 페이지가 있다면 나올 것이고, 그렇지 않다면 동일하게 영문 페이지가 보여질 것이다. 이 방법은 특히 온라인 BOL을 볼 때 아주 유용하다.

:
Posted by 에너지발전소