MySQL replication FAQ 간이 번역

새로운 사이트 로 이전했습니다. 이하의 내용은 더이상 관리되고 있지 않습니다.

MySQL replication에 대해서 조사하는 중에 읽은 FAQ를 간이 번역해 보았다.
원문:http://dev.mysql.com/doc/refman/5.0/en/faqs-replication.html#qandaitem-B-13-1-11

B.13.1: Slave는 상시 master에 접속해 있어야 하나?
No. 몇시간, 심지어 몇 일이라도 끊어져 있어도 됨. 재접속해서 그동안 update된 내용을 catch up할 수 있다.
다시 해석하면, slave는 sync되지 않은 상태로 있을 수 있다는 말. 상시 sync하는 방법도 있음.
접속이 끊어져 있는 동안의 내용을 나중에 replication할 수 있으려면 master에 binary 로그가 남아 있어야 한다.


B.13.2: 네트워킹은 필수 인가?
Yes. 공유 메모리나 UNIX소켓 등은 지원되지 않으므로 skip-networking 옵션이 On이 아니여야 한다.

B.13.3: Slave가 master로 부터 얼마나 늦어져 있는지 어떻게 확인하나? 즉 slave로 replicate된 마지막 SQL문을 확인하는 방법은?
SHOW SLAVE STATUS의 Seconds_Behind_Master를 확인한다. 자세한 내용은 “Checking Replication Status”문서를 참고.
Slave의 SQL쓰레드가 master로 부터 읽은 event를 실행하면 event의 타임스템프로 자신의 시각도 변경한다. show process list에서
slave의 sql 쓰레드 time란(현재 상태가 지속된 시간) 이 마지막의 replicate한 시간과 현재 시간의 차를 의미한다. 이렇게 마지막
replication된 시각이 확인 가능하다. 예를 들어 1시간 동안 disconnection되었다가 재접속하면 slave의 SQL쓰레드의 process list의 time값이
갑자기 3600부근으로 변경될 것이다. 이는 3600초 이전의 SQL문을 실행하고 있다는 의미이다.

B.13.4: slave가 master의 update차이를 따라 잡을동안 master를 block시킬 수 있나?
1. master에서 아래의 명령 실행
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
log파일명과 position을 메모

2. slave에서 위에서 메모한 내용으로 아래와 같이 실행
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
master_post_wait에 대한 replication가 완료 될 때까지 select는 block된 상태가 된다.

3. master lock해제
mysql> unlock tables;

B.13.5: 양방향 replication을 할 경우 주의점은?
replication에서 locking은 아직 지원되지 않는다. 즉 distributed atomic update를 보장하지 않는다.
즉 client A가 master1에 update를 하고 동시에 client B가 master2에 client A와 상이한 update를 해버렸을 경우.
master1의 내용이 master2에 replication된 시점이라도 client A가 보는 master2의 내용은 이미 master1과는 다른 상태가 된다.
update가 상반되지 않는다라는 자신이 있다면 양방향을 사용해도 된다.

하지만 양방향 replication은 하나의 update에 복수의 replication을 반드시 동반하기 때문에 성능상의 이정도 기대하기 어렵다.


B.13.6: 내 시스템의 성능향상을 위해서 replication은 어떻게 활용하면 좋은가?
하나의 서버를 master로 하고 모든 write를 master로 집중시킨다. 최대한 많은 slave를 준비해서 read를 master + slave로 분산시킨다.
slave를 실행할 때 --skip-innodb, --low-priority-updates, --delay-key-write=ALL 옵션을 ON하면 많은 성능상의 이점을 얻을 수 있다.
slave에서는 트렌젝션 처리가 필요없기 때문에 이렇게 해서 InnoDB대신에 MyISAM을 쓰게 하는 것이다.

B.13.7: replication을 활용해서 성능을 높이기 위해서 client 코드는 어떻게 준비하는 것이 좋은가?

Section 16.3.3, “Using Replication for Scale-Out”. 참고

B.13.8: 어떤 때 그리고 어떻게 replication이 성능을 높여 주는가?
읽기가 많고 쓰기가 적을 때 (블로그, 포럼) 성능을 높여준다. 이론적으로 single master와 복수개의 slave를 무한대로 늘릴 수 있다면
네트웍 bandwidth가 받쳐주는 한계까지 또는 master가 헨들가능한 update 한계까지 성능을 높일 수 있다. 
slave를 얼마나 늘릴 수 있는지 얼마나 성능이 올라갈려는지는 알려면 현재 사용하는 query패턴과 전형적인 master와 slave에 가하는
read, write 량의 상관관계를 조사해야 한다.

가상의 시스템에서 replication을 통해서 얻을 수 있는 이점
reads, writes를 각각 초당 읽기/쓰기횟수라고 하고
시스템에 부하의 10%가 write이고 90%라 read라고 하자.

벤치마킹 결과: reads = 1200 - 2 * writes
즉 write가 없는 상태에서 최대 1200 read가 가능. 평균 쓰기 시간은 read의 두배정도이고 선형관계이다.

master와 slave가 같은 성능을 가지고, 1개의 master와 N개의 slave가 있다면 각 서버의 성능은
reads = 1200 - 2 * writes
reads = 9 * writes / (N + 1)  <- read는 write의 9배이고 각 서버들로 split됨.
9 * writes / (N + 1) + 2 * writes = 1200
writes = 1200 / (2 + 9/(N + 1))

최대 1200 read이고 평균 1번의 쓰기에 9번의 읽기가 일어날 경우, 마지막 방정식이 N개의 slave가 있을 때  최대 write가능 수를 의미한다.
이 식을 사용하면 아래와 같은 결론이 나온다.

N = 0 이면(no replication) 초당 1200/11 (= 109) write가 가능
N = 1 이면 최대 184 write가 가능
N = 8 이면 최대 400 write가 가능
N = 17 이면 최대 480 write가 가능
N이 무한대로 갈 수록 600 write(5.5배)에 접근하지만 8대만 늘려도 4배의 write 성능향상은 얻을 수 있다.

이 결론은 네트웍 성능이 무한대라고 가정했고 시스템에 영향을 끼치는 다른 요인들을 무시했을 때의 결과이다. 대부분의 경우
N대의 replication으로 얻을 수 있는 성능향상의 결과를 이렇게 심플하고 정확하게 구할 수 없다.
하지만 아래의 질문에 대한 답을 구하는 것으로 replication에 의한 성능 향상을 어느정도 예상할 수 있다.

read/write 비율
read를 줄일경우 write가 얼만큼 더 가능한가?
네트웍 성능이 허용하는 slave의 대수는?

B.13.9: replication을 이용해서 여분(redundancy)의 정보를 가지게 하거나 고가용성을 어떻게 제공할 수 있나?
여분의 정보를 구현하는 방법은 어플리케이션과 상황에 따라서 달라진다. 고가용성 솔루션(자동 오류 복구)을
구현하려면 액티브 모니터링에 커스텀 스크립트나 써드파티의 툴이 필요하다.
수동으로 처리하려면 문제가 생긴 master로 부터 특정slave를 보도록 어플리케이션에서 대응하던지
DNS를 변경하는 것으로 대응할 수 있다.
자세한 내용은 Section 16.3.6, “Switching Masters During Failover”. 참고

B.13.10: Master가 SQL베이스 로그인지 Row베이스 로그인지 어떻게 확인할 수 있나?
statement-based, row-based
SHOW VARIABLES LIKE 'binlog_format';
binlog_format 시스템 변수를 확인하면 된다.row-based가 권장이지만 특정 상황에서 
statement-based가 사용될 경우가 있다.
자세한 내용은 Mixed Binary Logging Format을 참조

B.13.11: Slave에게 row-based replication을 사용하도록 할 수 있나?
Slave는 자동으로 판단한다.

B.13.12: GRAND, REVOKE 같은 statement는 replicate하지 않도록 할 수 있나?
 --replicate-wild-ignore-table=mysql.% 옵션을 주고 서버를 실행하면 mysql DB에 있는 테이블은 replication하지 않게 된다.

B.13.13: 여러 종류의 OS가 혼재한 상황에서도 replication은 동작하나? (예> master는 Linux, Slave는 Mac OS X 이나 Windows)
Yes

B.13.14: 여러종류의 하드웨어 아키텍트가 혼재해도 되나?(예> master 64bit, slave 32bit)
Yes



Comments