#title 데이터 복제에 대한 이슈
[[TableOfContents]]
여기에서는 2-Phase Commit의 개념과 Microsoft SQL Server 2000의 복제에 대한 설명을 한다. 
==== 복제의 개요 ====
복제는 분산 트랜잭션의 [2-Phase Commit]의 부하의 대안과 원격 사이트간의 데이터의 일치성을 보장하기 위해서 생겨난 것이다. 물론 복제 방식에 따라서 동기화의 시간차는 존재한다. 만약 동기화의 시간 차이를 무시 할 수 있다면 복제를 권장한다. 2-Phase Commit의 개념은 다음 그림에 잘 설명되어 있다. 

attachment:replication01.jpg

2-Phase Commit을 사용하게 되면 Site1의 table1에 대해서 작업이 끝날 때까지 Site2의 Table1은 Commit하지 못하는 결과를 초래하게 된다. 그러므로 시간을 두고 복제를 이용하여 데이터를 동기화시키는 작업을 하게 된다. MSSQL Server 2000의 복제를 사용하려면 몇 개의 용어를 알아야 한다. 용어는 다음과 같다. 

 * 게시자: 복제할 데이터 제공
 * 배포자: 복제할 데이터를 저장하는 용도와 복제의 제어
 * 구독자: 복제할 데이터를 받아서 저장

복제의 종류에는 스냅샷, 트랜잭션, 병합 복제와 같은 3가지 복제 방법이 사용된다. 복제의 유형에 따라서 오버헤드의 수준이 달라지고, 데이터의 일관성 정도도 달라진다. 각각의 복제유형을 파악하고 해당 업무에 맞는 복제 유형을 선택하여 구현해야 한다. 

==== 복제 유형의 장단점 ====
||복제방식||장/단점||
||스냅샷 복제||-. 특정시점의 데이터베이스 상태를 복제[[BR]]-. 게시자와 구독자간의 지속적인 오버헤드를 유발하지 않음[[BR]]-. 구독자에 있는 데이터베이스가 스냅샷이 찍힌 시점의 상태||
||트랜잭션 복제||-. 아티클에 이루어진 변경사항을 트랜잭션로그에서 가져와 배포자에 전파하고, 배포자는 구독자를 전파[[BR]]-. 일관성 정도가 가장 좋다.[[BR]]-. 트랜잭션 로그를 읽어와 트랜잭션을 다시 수행함에 따른 지속적인 오버헤드
||병합복제||-. 트랜잭션 복제는 트랜잭션 변경을 전파하지만 병합복제는 주기적으로 변경된 내용을 구독자로 전달.[[BR]]-. 증분백업과 유사[[BR]]-. 게시자와 구독자가 모두 데이터베이스 내용을 변경할 수 있도록 설계됨||

==== 복제 성능과 관련된 일반적인 고려사항 ====

 * 최소한의 데이터만 복제(데이터의 최소 중복)
 * 로그파일에 대한 디스크 경합을 줄인다.
 * 시스템이 한가한 시간에 트랜잭션 복제와 병합복제를 수행
 * I/O 성능이 좋은 시스템에 스냅샷 폴더 지정
 * 업무에 따라 배포 튜닝

==== 배포서버 튜닝 ====
배포자는 복제에 관련된 데이터를 저장하고 있다. 배포자가 하는 역할은 게시된 아티클을 저장하고, 구독자에게 전달하는 역할을 한다. 게시된 데이터의 변경되는 양에 따라(트랜잭션의 크기와 양) 배포자의 부하는 증감한다. 배포자의 경우는 대부분 Disk I/O에 가장 많은 영향을 받는다. 
 
'''디스크'''
배포서버의 트랜잭션로그는 RAID1이나 RAID1+0으로 잡는다. 트랜잭션 로그 파일의 크기는 충분히 크게 잡는 것이 좋다. 배포데이터베이스는 쓰기 작업이 많으므로 RAID5보다는 RAID 0 또는 RAID10을 권장한다. 주의해야 할 것은 배포데이터베이스의 크기를 충분히 잡아야 한다는 것이다. 만약 구독자에 문제가 생긴다면 며칠이건 데이터를 보관해야 하기 때문이다. 
 
'''스냅샷 위치'''
스냅샷 폴더는 배포자에 두는 것이 일반적이다. 스냅샷이 가끔 발생하고 구독자가 소수인 경우는 스냅샷을 게시자에 저장 할 수도 있다. 게시자에 스냅샷을 두면 네트워크 트래픽은 감소하지만 게시자의 오버헤드는 증가하고, 네트워워크를 이용하지 않아도 되므로 스냅샷 생성이 더 빠르다. 스냅샷이 만들어지는 동안에는 잠금이 유지되므로 스냅샷이 가장 빨리 만들어지는 경로를 택하는 것이 중요하다. 

==== 스냅샷 복제 튜닝 ====
스냅샷 복제에서 고려해야 할 사항은 게시자, 배포자, 구독자의 I/O 성능과 네트워크의 대역폭이다. 즉, 스냅샷이 얼마나 빨리 만들어지는가와 생성된 스냅샷을 구독자에게 얼마나 빨리 적용시키는가가 성능의 관건이다. 그러므로 스냅샷이 가장 빨리 만들어지는 경로에 스냅샷을 저장하는 것이 바람직하다. 게시와 배포가 같은 서버자원을 사용한다면 배포에 대한 오버헤드가 증가될 수 있음은 반드시 고려해야 한다. 5GB의 데이터베이스를 10Base(약 1MB)를 옮기는 데는 약 1.4시간이 걸린다. 

==== 트랜잭션 복제 튜닝 ====
트랜잭션 복제는 로그파일이 중요하다. 그러므로 로그파일이 저장될 공간에 대한 점검이 필요하다. 로그의 읽기/쓰기가 모두 수행되므로 좋은 성능의 I/O 시스템이 필요하다. 트랜잭션 로그는 RAID1 또는 RAID10으로 구성하면 좋다. 트랜잭션 복제는 다른 복제유형보다 I/O에 대한 고려사항이 적다. 왜냐하면 작은 I/O가 자주 발생하기 때문이다. 트랜잭션 로그가 많이 수정되는 경우 로그판독기 수행주기를 늘려줘 게시자의 성능을 높이는 것도 좋다. 트랜잭션 복제는 기본키가 없다면 불가능하다. 
 
==== 병합 복제 튜닝 ====
병합복제의 가장 큰 장점은 양방향 복제가 가능하다는 것이다. 그러나 GUID 컬럼이 추가로 생성된다. 이는 버전에 의한 데이터의 일관성을 관리하기 위함이다. 게시자, 배포자, 구독자의 모두 충분한 I/O성능을 유지해야 무리 없이 복제작업이 진행된다.