데이터 사이즈가 커지면서 여러 가지 이유로 이중화 솔루션이 필요하게 됩니다. 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
세상은 변해가고 따라가기도 벅참을 느낄때.. 잠깐 하늘을 바라보세요..
http://blog.naver.com/hanoul76psy?Redirect=Log&logNo=102116636
