MySQL Replication은 MySQL이 기본적으로 지원하는 데이터 복제 방식입니다.
MySQL Replication은 read-write가 가능한 Master와 read-only인 Slave로 구성되는데, Master는 쿼리 로그에 해당하는 binary log를 남기고, Slave는 asynchronous하게 이를 가져가서 반영하는 역할을 합니다. 설정도 간단해, 1-3줄 정도의 설정만 해주면 됩니다. 간단한 동작 방식에 기초해서 Multi-slave, Multi-master, Replication chaining 등의 구성 등이 가능합니다.
MySQL Replication의 문제점들
Master와 Slave가 최소한의 정보만 공유하는 단순한 방식이 장점인 동시에 단점으로 작용합니다.
- Master-Slave pair 관리:서버들이 많아질 경우, Master와 Slave의 짝을 관리하는 것이 쉽지는 않습니다. Master와 Slave의 짝을 다른 어디선가 관리해주어야 합니다.
- 실패 상황에서의 복구:당연히 자동으로 복구한다든가 하는 기능을 MySQL이 제공하지는 않습니다. Master가 실패했을 경우, Slave를 Master를 바꾼다든가, Slave의 데이터를 Master로 복사해준다든가 하는 작업은 순전히 수작업이 됩니다. Slave가 실패했을 때도, 마찬가지 입니다. Slave의 일시적인 오류라면, Slave는 자신이 반영한 로그의 위치를 기억하고 있긴 하지만, 이에 따른 복구도 사람 손이 갑니다.
- binary log의 관리: Master는 Slave에 대해서 don’t care이므로, 언제 binary log를 삭제할 지는 주기 등을 사용합니다. 물론 삭제하는 command가 있지만, Slave들의 정보를 반영해서 자동으로 삭제하는 기능은 없습니다.
- asynchronicity: Slave는 Master와 같은 데이터를 가지고 있다고 보장할 수 없으므로, Slave가 Master의 쿼리 처리량을 따라가지 못하게 되면, consistency 문제가 발생할 소지가 있습니다. 따라서, 애플리케이션에서 이러한 점을 신경써주어야 합니다. 이러한 점들 때문에, MySQL Replication을 백업으로 생각하지 말라는 조언들이 등장합니다.
1, 2, 3번의 경우에는 도구를 이용해서 극복할 수 있습니다. 1번, 2번에 대해서는 어느 정도 도구를 만들어 쓰고 있는데, 인터페이스를 웹 인터페이스로 개선하고 좀 더 자동화할 필요가 있습니다. Maakit이라든가 MySQL Replication Manager 등을 참고해볼만 합니다.
4번의 문제에 대해서는 MySQL Replication이 아닌 대안을 찾는 것이 옳을지도 모르겠습니다. 구글에서는 semi-sync 모드를 위한 패치를 내놓기도 했습니다.
MySQL Replication의 대안들
일반적으로 MySQL Replication을 얘기할 때는 다음과 같은 대안들을 함께 얘기합니다.
- MySQL Cluster: MySQL이 직접 지원하는 것 중에는 MySQL Cluster가 있지만, 아직은 메모리 기반 엔진인 NDB만 지원하기 때문에 메모리의 크기에 제약을 받습니다.
- DRDB: 디바이스 수준에서 디스크를 분산하는 DRDB를 MySQL과 함께 사용합니다. MySQL Replication보다 failure에 안전한 것은 아니지만, sync가 어긋난 상태는 최소화됩니다. 하지만, failover node (i.e. slave)는 MySQL 쿼리를 처리할 수 없다는 크나큰 제약이 있습니다. 백업의 용도로는 적절하리라고 생각합니다.
예전부터 관심을 두고 있던 Sequoia와 같은 데이터베이스 클러스터링 솔루션도 한번 써보고 싶고, 최근에 화제가 되고 있는 MySQL Proxy 와 같은 Proxy들(SQL Relay, dpm, Spock Proxy)을 사용해서 Replication을 잘할 수 없을까 생각이 들기도 하는데, 당장은 시간이 없다는 변명을 하렵니다.