replication 을 통해 slave 를 구성해 본 사람이라면
이 구성이 얼마나 서비스에 영향을 주는지 알고 있을거다.
일반적으로 replication one by one 하나씩 master 에 들어온 DML쿼리를 slave 에 적용하게 된다.
이는 쿼리 하나의 수행시간이 길어지면 뒤따라 오는 쿼리의 딜레이를 줄 수 있기에 서비스에 지장을 줄 수 있다.
그리고 update ~~ (select ~~ 의 이중 쿼리의 경우 4.x 버젼에서 slave 의 데이타가 틀려지게 적용이 된다.
아주 엄청난 버그인 셈이다.
slave 를 붙이는 이유중 하나는 백업용도이며 master 가 죽었을시 대체하는 식으로 추가하는 것으로만 사용한다.
이를 보안한것이 더블 마스터구조이다. 아래에 설명하듯이..
Master - Master 구조를 가지게 된다.
예를들어 구성은 "Master1" <--- 양방향 replication ---> "Master2" 로 구성하고 양방향 replication 을 주도록한다.
"Master1" 과 "Master2" 에는 [게시판1] 과 [게시판2] 의 데이타가 존재하며
"Master1" 에는 [게시판1] 만 서비스하고 "Master2" 는 [게시판2] 만 서비스한다.
[게시판1] 의 장애시 "Master2" 로 access 를 하게되어 장애시 보안될 수 있는 구조이다.
Master - slave 구성시, Master 에는 write 쿼리만 Slave 는 select 쿼리만 주는 것이 일반적이다.
이러면 Master 에는 부하가 적고 slave 에만 부하율이 높아 불균형한 서비스를 하게 되지만
위와 같이 하게 되면 정확한 분산이 주어진다.
replication 하는 데이타는 서비스 데이타가 아니기 때문에
간섭 현상도 없어서 딜레이되거나 해도 무방하다.^^
MySQL Replication, 한번 시도해 볼만 하다.
주말에 테스트 한번 해봐야 겠다.
출처는 "관련 링크" 에...
|
|
|
