실제 어렵지 않으니.. 슥~ 보시면 슥~ 이해가 되실 겁니다.. ^_^

<- 높은 자율성(지연많음)                                 낮은자율성(지연없음) ->

오른쪽으로 갈수록? 다른 서버에서 데이터를 수정하면? 나머지 서버역시 잠금이 걸려

데이터를 사용이 불가해 진다.. 라는 거지요. 하지만 트랜젝션의 일관성은 매우

높은 겁니다... 그렇다면? 왼쪽으로 간다면?

잠금이 걸리는 시간이 일정시간(정해진 시간일수 있음) 이며 트랜젝션 일관성은 떨어져

서버가 자율성이 높아지는 거지요 ^_^

쉽지요~ 그럼 방식을 자세히 함 들여다 보도록 하지요.. ^_^

2 Phase Commit

분산트랜젝션을 사용하는 것입니다.. 데이터의 업데이트가 신속하며 그에따르는 부하

역시 심하지요... 실제로는 복제가 아니란걸 아시겠지요 ^_^

Transactional Replication

변경된 내용만을 Subscriber로 보내는 방식입니다...

1) 데이터를 변경시키면 변경 내용이 Puiblisher의 Publisher로그에 기록 됩니다.

2) 이를 Distributor의 로그 리더(Log Reader Agent)가 읽어 Distributor의

Distribution 데이터베이스에 저장합니다.

3)Distribution Agent가 저장된 로그를 읽어 변경 부분만 subscriber로 넘겨 줍니다.

Snapshot Replication

스냅샷은 동기화를 시키는 작업을 말합니다...

Publisher의 데이터와 Subscriber의 데이터를 모두 동기화 시켜 버리는 거지요...

그렇다면? 왜 통째로 보내는 스냅샷이 필요한가?

10M분량의 DB가 있는데.. 이 DB는 변경작업이 많아 기록되는 로그가 하루에 100M

가 된다고 생각해 보세요... 그럼 어떨가요?

이때 Transactional Replication을 쓴다면? 배보다 배꼽이 크니 차라리...

Snapshot Replication을 쓰는게 좋다.. 라는 거지요...

Merge Replication

양쪽에서 변경된 것을 서로 주고 받아 Merge(붙인다)시킨다고 보면 됩니다.

즉 Publisher / Subscriber의 개념이 전혀 없이 데이터를 주고 받는 거지요..

진행 순서라면...

1)최초 스냅샷이 성공적으로 이루어 집니다.

2)변경 내용에 대한 정보가 Merge Agent에 의해 감시 됩니다.

이 내용이 distribution DB에 기록 됩니다.(데이터는 Repldata 디렉토리, 정보만 Distribution

DB에 저장됨)

3)Distribution Agent가 변경 내용을 다른 쪽 서버로 보내거나 받습니다.

4) 이과정에서 충돌이 생기면? Distribution DB에 정보를 기록합니다. 이후 설정된

우선순위로 하나의 데이터를 이기게 만드는 거지요....

이런 충돌의 해결을 위해 머지 복제에서는 rowguid라는 컬럼이 테이블에 생성되며

충돌 해결시에 사용합니다.

Updating Subscriber

트랜젝션 복제와 스냅샷 복제에 사용이 가능한데....

받는 쪽에서도 데이터를 수정할 수 있게 해준다는 겁니다.

받는쪽에서 수정할 때는 분산 트랜젝션을 사용하여 데이터를 수정하게 되므로 수정과

동시에 보내는 서버의 데이터가 수정되고 이 데이터가 다시 다른 받는 서버들에게

전달되어 데이터의 일관성을 유지시켜 줍니다...

이 옵션을 사용하려면? 반드시 DTC서비스가 보내는 서버와 받는 서버에서 시작되어

있어야 합니다.

흠... 이제가지가 방식에 따르는 분류였습니다... 다음으로는 복제의 모델에 따르는

분류를 보겠습니다. ^_^

6. Replication(복제)란? _ 3. 복제의 다양한 방법(1) 문서의 끝입니다.