_대문 | 방명록 | 최근글 | 홈피소개 | 주인놈 |
FrontPage › 데이터복제에대한이슈
|
|
여기에서는 2-Phase Commit의 개념과 Microsoft SQL Server 2000의 복제에 대한 설명을 한다. [edit]
1 복제의 개요 #복제는 분산 트랜잭션의 2-Phase Commit의 부하의 대안과 원격 사이트간의 데이터의 일치성을 보장하기 위해서 생겨난 것이다. 물론 복제 방식에 따라서 동기화의 시간차는 존재한다. 만약 동기화의 시간 차이를 무시 할 수 있다면 복제를 권장한다. 2-Phase Commit의 개념은 다음 그림에 잘 설명되어 있다.
![]() 2-Phase Commit을 사용하게 되면 Site1의 table1에 대해서 작업이 끝날 때까지 Site2의 Table1은 Commit하지 못하는 결과를 초래하게 된다. 그러므로 시간을 두고 복제를 이용하여 데이터를 동기화시키는 작업을 하게 된다. MSSQL Server 2000의 복제를 사용하려면 몇 개의 용어를 알아야 한다. 용어는 다음과 같다.
[edit]
2 복제 유형의 장단점 #
[edit]
3 복제 성능과 관련된 일반적인 고려사항 #
[edit]
4 배포서버 튜닝 #배포자는 복제에 관련된 데이터를 저장하고 있다. 배포자가 하는 역할은 게시된 아티클을 저장하고, 구독자에게 전달하는 역할을 한다. 게시된 데이터의 변경되는 양에 따라(트랜잭션의 크기와 양) 배포자의 부하는 증감한다. 배포자의 경우는 대부분 Disk I/O에 가장 많은 영향을 받는다.
배포서버의 트랜잭션로그는 RAID1이나 RAID1+0으로 잡는다. 트랜잭션 로그 파일의 크기는 충분히 크게 잡는 것이 좋다. 배포데이터베이스는 쓰기 작업이 많으므로 RAID5보다는 RAID 0 또는 RAID10을 권장한다. 주의해야 할 것은 배포데이터베이스의 크기를 충분히 잡아야 한다는 것이다. 만약 구독자에 문제가 생긴다면 며칠이건 데이터를 보관해야 하기 때문이다. 스냅샷 폴더는 배포자에 두는 것이 일반적이다. 스냅샷이 가끔 발생하고 구독자가 소수인 경우는 스냅샷을 게시자에 저장 할 수도 있다. 게시자에 스냅샷을 두면 네트워크 트래픽은 감소하지만 게시자의 오버헤드는 증가하고, 네트워워크를 이용하지 않아도 되므로 스냅샷 생성이 더 빠르다. 스냅샷이 만들어지는 동안에는 잠금이 유지되므로 스냅샷이 가장 빨리 만들어지는 경로를 택하는 것이 중요하다. [edit]
5 스냅샷 복제 튜닝 #스냅샷 복제에서 고려해야 할 사항은 게시자, 배포자, 구독자의 I/O 성능과 네트워크의 대역폭이다. 즉, 스냅샷이 얼마나 빨리 만들어지는가와 생성된 스냅샷을 구독자에게 얼마나 빨리 적용시키는가가 성능의 관건이다. 그러므로 스냅샷이 가장 빨리 만들어지는 경로에 스냅샷을 저장하는 것이 바람직하다. 게시와 배포가 같은 서버자원을 사용한다면 배포에 대한 오버헤드가 증가될 수 있음은 반드시 고려해야 한다. 5GB의 데이터베이스를 10Base(약 1MB)를 옮기는 데는 약 1.4시간이 걸린다.
|
돈을 잃은 건 잃은 게 아니다. 명예를 잃은 건 조금 잃은 것이다. 용기를 잃은 건 모두 잃은 것이다. |