MySQL에 Replication이 레포트 된 것은 2000년 5월에 릴리즈 된 3.23으로부터, 4.0에 그 구조가 일부, 고쳐진것으로, 비교적 [시든]기능으로, 필자의 감촉으로는 안정성과 신뢰성은 충분히 높다고 할수 있다.
또, MySQL본체에 Replication의 기능이 들어가있는것도 특색이며, Replication을 위해 외부 어플리케이션을 준비할 필요가 없이, 설정도 비교적 간단하므로,가볍게 Replication을 구성하는 것이 가능하다.
본문에는, MySQL의 Replication의 특색과 구조를 소개한 후, Replication의 설정, 상태확인, 트러블 슈팅보다 실전적인 내용의 설명을 한다.
또, 본문의 동작확인은, 다음의 환경에서 실시했다.
OS:Linux(Fedora Core 2)
MySQL:4.0.20(MySQL AB의 rpm패키지)
일반적으로, Replication이란, 다른 서버에 데이터베이스를 복제하는 것을 말한다.
복제는 LAN과 인터넷등 네트워크를 경유해서 행해지므로, 물리적으로 떨어진 장소에 있는 서버에 데이터베이스를 Replicate하는 것이 가능하다.
복제의 방법에는 동기와 비동기의 2종류가 있다.
동기
복제의 경우는, Replication을 구성하는 모든 서버에 항상 모두 동일한 데이터를 갖는 것이 보장되지만, 한편으로 데이터의
동기를 취하기 위해 다른 서버의 응답을 기다릴 필요가 있으므로, 서버의 대수가 많으지면, 많아질수록, 전체의 응답성이 낮아질
가능성이 있다.
반대로, 비동기복제는, 서버대수의 증가에 의한 성능의 저하는 거의 없지만, 짧은 시간에 관찰하면, 서버간 데이터의 동기가 보장되지 않는다는 문제가 있다.
주로 Replication의 구성에는 마스터슬레이브와 멀티마스터가 있다.
마스터슬레이브구성은, 갱신계의 쿼리를 받는 것은 마스터서버뿐이며, 슬레이브는 마스터로부터
전파된 것 이외의 갱신처리는 할수없다.
멀티마스터는, 어떤 서버에도 갱신계의 쿼리를 받아들일수 있는 구성이다.
대표적인 Replication의 형태는, 복제의 방법과 구성의 조합으로 4가지를 생각할수 있습니다만,
비동기마스터슬레이브가 나쁘고, 동기 멀티마스터가 좋다는 것이 아니라, 각각 장단점이 있으므로, 요건에 맞게 나누어 보자.
MySQL의 Replication으로 가능한것 |
부하분산기능을 통해서, 슬레이브서버군에 참조계의 쿼리를 부하분산하는 것이 가능하다.
다만, 위에 기술한대로, MySQL의 Replication은 비동기인것에 주의할 필요가 있다.
구체적으로는,
전혀 갱신하지않은 테이블, 또는 클라이언트접근이 없는 야간의 배치처리에만 있는 마스터 테이블에 대한 참조계의 쿼리와 같은,
슬레이브에의 전파의 지연이 문제가 되지않는 쿼리는 부하분산하는 것이 가능하지만, 유저정보의 갱신을 마스터에 대해서 행한직후에
슬레이브에 그 유저의 정보를 질의하는 경우에는, 얻은 결과가 다른 위험성이 있다.
마스터에 어떤 장애가 발생해서 서비스불능이 된 경우, 슬레이브가 대신에 서비스를 하는것으로,
짧은 다운타임에 서비스를 재개하는 것이 가능하다.
그러나, 불행히도, 마스터의 절체를 자동으로 행하는 기능은 MySQL본체에는 들어있지않으므로, 절체처리는 수동으로 하던가, 절체프로그램을 만들 필요가 있다.
http://dev.mysql.com/doc/mysql/ja/Replication_Features.html
데이터의 정합성을 가지면서 백업을 하는것에는, MySQL을 정지해서 오프라인 백업을 하던가,
쓰기 락을 해서 온라인 백업을 할 필요가 있다.
그러나, Replication구성이라면, 슬레이브의 데이터가 백업데이터가 되며, 풀백업을 하는 경우에는 슬레이브의 데이터를 백업하면, 마스터가 제공하고 있는 서버스에는 일절 영향없이 백업을 하는것이 가능하다.
MySQL의 Replication으로 불가능한 것 |
갱신계 쿼리의 부하를 복수의 서버에 분산하는 것은 불가능하다.
우선, 단순한 마스터슬레이브 구성에는 마스터는 1대밖에 없으므로, 갱신계의 쿼리는 이 마스터에 집중시키는 것 밖에 없다.
다음으로 듀얼마스터 구성을 생각해보자.MySQL의 Replication에는 슬레이브는 다른 슬레이브의 마스터로 되는 것이 가능하므로, 그림3과 같은 듀얼 마스터구성으로 하는 것이 가능하다.
그러나, 마스터간에 갱신처리가 경합할 가능성이 있으므로, 보다상위의 레이어로 갱신대상이 되는테이블에 쿼리의 발행처의 마스터를 구별하는등의 연구가 필요하다.
예를 들어 유저정보의 갱신은 마스터A에 제품정보의 갱신은 마스터B에 와 같은 것이다.
이것으로, 갱신계의 쿼리를 분산하는 것이 가능합니다만, 사실, 부하의 분산으로는 될수없다.
마스터A에 대해서행해진 갱신처리는, Replication에 의해 마스터 B에도 실행되므로,결국, 양 마스터에 갱신계의 쿼리가 실행되는것에 의해, 갱신계 쿼리의 분산은 되어도 갱신처리의 부하를 분산한 것은 아니기 때문이다.
앞절의 갱신계의 부하분산과 같도록, 갱신계의 쿼리는 Replicate되어 슬레이브에도 처리되므로, 갱신계의 쿼리가 많은 경우는 슬레이브에도 똑 같은 부하가 걸립니다.
