1. MySQL Limitations Part 1 : Single - Threads Replication

|글의 요약|
현재 mysql 의 replication 구성시, 마스터의 binary log의 슬레이브로의 적용은 SQL i/o thread를 통한 single thread 밖에 지원되지 않는 실정이다. single thread를 통해 마스터에서 일어난 변경내용을 순차적으로 슬레이브에 적용되게 되지만, 이런 환경 때문에 슬레이브가 마스터에서의 변경속도보다 항상 느릴 수 밖에 없고, 그 외 리플리케이션 구성의 단점을 들며, 문제를 해결 할 수 있는 몇가지 대안을 제시하고 있다.

#.single thread replication 문제점
1. 구성 시 cpu사용률이 높다.
=>마스터 슬레이브 모두에 리플리케이션의 구성을 위한 추가적인 process가 필요
(여기서 process란 Master: binlog 보내기위한, Slave: relay log 변환,적용 위해 필요한 추가적인 process들을 말함)

2. single thread 구조로 인해(순차적인 binlog의 적용), 연속적인 update 구문등이 발생 시 슬레이브가 마스터만큼의 속도를 따라 잡지 못함.

3. 많은 어플리케이션들의 연결
=> 일반적으로 select와 같은 read목적이 대부분이고 write는 그들 중 일부이기 때문에 큰 문제점으로 보지 않음.
    하지만, 충분히 많은 어플리케이션들이 DB에 붙는다면 성능에 문제가 될 수도 있다.no matter how large the read-to-write ratio is.
(결국 많은 replication을 구성하게 되면 성능 저하는 피할 수 없다는 의미)

#.필자가 생각한 해결책
1. DRBD(Distributed Replicated Block Device ) 리플리케이션을 사용하라.
  |DRBD|
     - 리눅스 커널 모듈로 분산저장장치로 사용됨
     - 리눅스 서버끼리 블럭 디바이스를 공유하기 위해 사용: 결과적으로 파일시스템과 데이터 공유의 목적
     - BRBD implements a block device , 스토리지로 사용될 수 있고 primary에서 하나 이상의 secondary로 가는 데이터들이 복사되어
        진다.
     - distributed block device는 DRBD service에의해 다루어 진다.
     - DRBD block device로 기록 된 데이터들은 서버들 사이에서 분산(배포)된다.

     - 각각의 DRBD 서비스들은 DRBD 블럭 디바이스에서 물리적인 장치로 데이터를 적는다.
      |원리|
             ㄱ) primary에서 데이터에서 물리적인 블럭 디바이스에 데이터를 쓰면, secondary의 DRBD서비스로 배포된다.
             ㄴ) secondary 쪽에서 DRBD를 통해 받은 데이터를 secondary쪽 물리적인 블럭 디바이스로 적어준다.
             ㄷ) 양쪽 서버 모두 DRBD 블럭디바이스로부터 데이터를 읽어오게 되고, 이것은 물리적인 블럭디바이스에 의해 다루어 진다.

             

 

데이터는 블럭레벨에서 양쪽의 DRBD 서버의 동기화에 의해서 공유된다.
이는 failover 지원에 대한 HA 해결 책이 될 수 있다.

문제점: standby server가 느려지는 문제점이 생길 것이다. 읽기는 불가능하고 장애에 대한 복구용(failover)으로만 쓰인다. 또한 비용적인 문제가 뒤따른다.

2. 조각(Shard) = 시간이 오래 걸리는 쿼리들을 짧은 단위로 나누는 것을 의미
 슬레이브가 마스터의 write 부하량을 따라잡을 수 없기 때문에 짧은 단위로 나눠 슬레이브에서의 처리 속도를 증가시키는 방법이다. 하지만 이런 해결책은 피하는 것이 좋을 듯 하다.

3. 리플리케이션을 어플리케이션단에서 구성하라. (리플리케이션에서 마스터& 슬레이브 동시 write 시킨다... 마스터로 write -> slave대신에)
 

- 이 경우, 데이터 변형을 해야할 시에(내부에서) 마스터 & 슬레이브에 각각 한번씩, 두번 적용을 해줘야 하는 번거로운 문제가 생긴다.

4. slave의 빠를 데이터 복제를 위한 외부 프로세스의 개발 시도.


#.필자가 생각하고 듣고 토론했던 몇가지 생각들

1. 하나의 데이터베이스당(DB= mysql,information,test 등의 db를 의미!!!) - 하나의 쓰레드
독립적으로 구성된 DB 각각에 어플리케이션 연결 구성 - slave: binlog에 각 DB에 대한 event가 발견되면 해당하는 DB의 thread를 가동시키고, 해당 리플리케이션 event를 그 thread에 넘겨준다.

2. slave쪽의 thread pool과 각 DB에게 적용되는 thread할당은 각각 서로 조화되며 할당된다.
할당자 thread: 릴레이로그에서 이벤트의 트랜잭션의 끝까지 읽어오고, 전체 트랜잭션문을 worker thread로 넘겨준다.
worker thread: commit부분까지 전부 수행한 후 commit구문은 실행하지 않은 상태로 다시 할당자 thread에게 현재 상태를 알려준다.
할당자 thread: relay log의 슬레이브의 모든 트랜잭션 부분이 올바르게 적용되었는지를 확인 후 해당 트랜잭션에 commit처리를 한다.
=> 이것의 의미는 commit이 된 binary log만을 넘기는 현재 방식에서, commit이 되지 않았지만 마스터에서 이루어 지고있는 변경사항을 슬레이브에도 함께 적용하다가 마스터쪽에서 commit이 발생하면 슬레이브쪽도 해당 변경사항을 commit시켜주는 방법으로 속도면에서 기존 방식보다 빠를 수 있다.

만약, deadlock이나 lock wait time 같은 에러가 발생하면 할당자thread가 worker thread에게 roll back을 지시한 뒤
문제가 된 트랜젝션을 재실행하거나, 문제되었던 부분부터 동시적이지 않게 순차적으로 다시 트랜잭션을 실행해 나가도록 만든다.

3.(마스터)DB하나에서 생성 된 다양한 바이너리 로그들: (슬레이브) 하나의 binlog/ 하나의 replication process할당.
=> 이것은 다양한 마스터들을 리플리케이션 구성할 수 있는 좋은 이점이겠지만, 현재로써는 불가능한 기술이다.


#.이 해결책들은 균형을 유지하는 다른 유형들이다.(These solutions represent different types of trade-offs)
solution 1) only works for specific uses, and I don’t think it’s general-purpose enough.
1번 해결책은 특정한 경우에만 작용한다. 그리고 나는 이것이 충분히 일반적인 목적이라고 생각하지 않는다.

Solution 2) has potentially complex behavior that might not work well in some cases, such as when deadlocks are common; but it is overall the least disruptive or different from the user’s point of view.
2번 해결책은 deadlock이 자주 일어나는 몇몇의 상황에서 작동되지 않는 잠재적인 복합적 동작을 가지고 있다.
하지만 이것은 전체적으로 최소한의 지장을 초래하는 것 이거나 사용자의 관점(시점)과 다른 것이다.

3번 해결책은 바이너리 로그 코드를 변경하는것을 요구하게 되는데 이것은 위험하다. 또한 슬레이브 쪽에 여러개의 master.info 파일과
슬레이브를 운영하기 위한  새로운 SQL 구조(relay log인가??)의 유지하는 것을 요구한다. 하지만 이것은 필자가 개인적으로 원하는 운영방식이 아니다. multiple threads 를 복구 해야할 일이 있을 때 그 위치를 multiple binlog에서 어떻게 찾을 것인가??

해결책에 상관없이, 모든 상황에 적용되지 않는다는 것은 확실하다.; 가장 일반적인 경우들은 최소한 적당한 트랜잭션 isolation 레벨과 함께 InnoDB를 쓰는 것이 요구된다. 이 대처는 single-thread replication의 디폴트 조건이 될 것이고, multi-thread을 위한 유일한 방법이 될 것이다.

필자는 2번의 해결책에 1번 해결책을 선택적으로 결부시킨 방법이 최선이라 생각한다.
 
|출처| http://www.mysqlperformanceblog.com/2010/10/20/mysql-limitations-part-1-single-threaded-replication/