Situation

---

• 타 지역에 온프레미스 환경에서, 실시간으로 운영중인 sql-server(mssql)가 하나 존재
• 이 데이터를 활용하여 독립적인 서비스를 하나 만들고자 함.
• 독립적인 CRUD를 해당 sql-server에 접근하기에는 방화벽, 성능, 개발에 대한 자유도, 안정성 등 여러 이슈가 있기 때문에 동기화된 개발용 database를 구축할 필요가 있음

Solution

Replication

• 주 서버와 보조 서버간의 데이터 배포 방식
• 주 서버가 보조 서버에게 데이터를 전달한 후, 보조 서버에서 다른 구독 서버들에게 데이터를 전달하여 각 구독 서버들이 최종 사용자에게 데이터를 전달하는 방식으로 replication 구성
• 주 서버(publisher)의 데이터를 보조서버(disbributor)에게 전달
• 사용자(subscriber)가 분산될 수 있음
• 테이블 단위로 복사도 가능
• 구축 비용이 저렴
• 디스크 고장 시 복구가 가능

Log shipping

• 주 서버의 로그 파일을 보조 서버에 일정한 주기로 복사하는 방식

• 1 : M 관계를 가짐
• 자동 장애조치 기능은 없음
• 실시간 동기화는 아님
• 디스크 고장 시 복구가 가능함
• 구축 비용이 저렴

Mirroring

• 주 서버의 변경 내용을 미러 서버로 실시간 적용하는 방식
• 주 서버와 미러 서버를 구성한 후, 모니터 서버를 따로 두어 실시간으로 동기화되는 것 감지
• 일반적으로는 available하게 만들기 위해서 사용하는 방식임
• 자동 장애조치 가능
• 오류 탐지가능(모니터 서버)
• 하나의 미러 서버만 구성 가능
• 구축 비용이 저렴
• 디스크 고장 시 복구 가능

Cluster

• 두 개의 서버가 하나의 스토리지를 바라보면서 스토리지에 주 서버에 데이터를 이관하여 스토리지를 기준으로 이중화 하는 방식
• 별도의 공유 스토리지 구축이 필요
• 스토리지 장애 발생 시 복구 불가능
• 구축 비용이 비쌈(storage)
• 서버 이중화 및 공유 스토리지를 사용해서 서버 수준의 고 가용성을 제공

Always On

• Mirroring 방식의 단점인, Mirroring DB 에 직접 작업이 불가능한 점을 해결할 수 있는 방법
• 주서버와 백업용 서버, 읽기전용 서버 와 같은 보조 서버를 두고 동기화 한 후 작업하는 방식
• 보조 서버에서도 작업이 가능(Read)
• 오류 탐지 가능
• 자동 장애조치 가능
• 디스크 고장시 복구 가능
• 구축 비용 저렴한 편

해결책

가용성을 위함이라기보단, 개발서버에서 데이터를 활용할 수 있는 방법이 주 목적이라는 점을 고려했을때, Replication이나 Log shipping이 맞는 방법으로 보임. 특히 과제별로 데이터베이스가 다르게 구성되어있다는 점과, 이미 서비스가 운영중이고 클라우드(AWS, Azure) 와 같은 클라우드 서비스가 아닌점을 고려했을때, 스토리지를 따로 뺴는 클러스터라던지 always on 방식은 맞지 않을 것으로 보임

Replication

Terminology

Article

• Replication을 적용할 하나의 오브젝트로써, 테이블, 뷰, 프로시저와 같은 하나의 대상을 의미

Publication

• 퍼블리셔에 존재하는 Article들의 집합

publisher

• Sql Server의 인스턴스로써, Publishing할 Article들을 소유하고 있는 인스턴스

Subscriber

• 1개 이상의 publisher를 구독하고 있는 인스턴스

Distributor

• publisher에게서 article을 얻어서, Subscriber에게 전달해주는 역할

Type 1. Snapshot Replication

• 가장 쉬운 방법
• Snapshot Agent라고 불리는 프로세스가 존재
• 순서는 아래와 같음

1. lock tables
2. takes a snapshot
3. update distributor
4. deliver snpashot to subscriber

• C,U,D가 빈번하지 않는 경우에 효과적임, 스냅샷 스케쥴링을 우리가 원하는 순서대로 할 수 있기 때문
• High impact when the snapshot agent runs, high latency, modifications on the subscriber would be lost when the new snapshot is delivered.

Type 2. Transactional Replication

• Snapshot agent가 아닌 log reader agent가 존재
• log 를 읽고, transaction을 파악해서 distributor에게 전달
• 실시간 적용에 가장 효과적으로 사용
• Pull && push subscription 이 존재함

Type 3. Merge Replication

• Transactional Replication과 유사
• subscriber에서 업데이트가 될 수 있고, 이 변경사항이 publisher에게도 적용될 수 있다는 점이 특징임

참고문서

공식문서

방화벽