2015-05-24

[MySQL] Replication (3) - Replication을 사용하는 이유

 지난번 글에서 MySQL replication이 무엇인지 설명하면서, replication은 cluster와 다르게 동기화되는 것을 기다리지 않아도 돼서 빠르므로, 실시간 동기화가 필요하지 않은 경우에 사용된다고 하였다. 그렇다면 실시간 동기화가 필요 없는 경우는 어떤 경우들이 있을까?
 이번 글에서는 MySQL이 추천하는 적절한 replication 사용 방법에 대해서 알아보도록 하겠다.

백업

 replication의 주목적은 데이터를 백업하는 것이다. MySQL은 데이터의 지속성을 보장해준다. 하지만 아쉽게도 데이터베이스 이외의 다양한 이유(e.g. 하드디스크)로 데이터베이스를 복구할 수 없게 되는 일이 있다. 이런 경우를 대비하여, 다른 컴퓨터에 데이터를 복사하여 마스터 데이터를 복구할 수 없으면 복사된 슬레이브의 데이터를 이용하여 데이터를 복구할 수 있게 한다.

아카이브

 단순 백업을 위해서 뿐 아니라 아카이브를 만들기 위해서도 replication이 사용된다. mysqldump를 이용하면 데이터를 복사하여 아카이브를 만들 수 있다. 하지만 쿼리를 수행 중인 데이터베이스에 mysqldump를 실행하면, 깨진 데이터가 들어올 수 있다. 이는 MySQL enterprise backup을 이용하면 해결할 수 있지만, replication을 이용해서 해결할 수도 있다.

 지난번 글에서 설명하였듯이, 슬레이브의 SQL thread를 정지시키면, 마스터의 데이터를 읽어와서 relay log를 만들지만, 데이터베이스는 업데이트하지 않는다. 따라서 SQL thread만 정지시켜 놓으면, 안전하게 mysqldump를 실행할 수 있다. 이를 이용하여 서비스 중인 데이터베이스의 데이터를 서비스를 중지시키지 않고 아카이브를 만들기 위해서 replication을 사용하기도 한다.

부하 분산

 혹은 쿼리를 분산시키기 위한 목적으로도 사용된다.
서버별로 다른 슬레이브에서 값을 읽게 한다

 대부분의 웹 서비스는 데이터의 변경에 비해서 데이터를 읽는 작업이 많다. 이런 경우 슬레이브를 이용하여 부하를 분산시킬 수 있다. 혹은 로그 분석기처럼 고정된 데이터를 다양하게 하는 서비스의 경우도 replication을 사용하는 것이 좋다. 이런 서비스들은 replication을 이용하여 데이터를 읽는 것을 슬레이브에서 수행하면 부하를 분산시킬 수 있다.

지역 분산

 혹은 글로벌 서비스를 위하여 지역별로 다른 슬레이브를 구성할 수도 있다.
지역별로 슬레이브를 만든다.
 간혹 전 세계를 상대로 같은 데이터를 서비스해야 하지만, 레이턴시도 매우 중요한 서비스들이 있다. 보통 이런 서비스의 경우 데이터베이스는 공유하고, 지역별로 서버를 둔 뒤, 서버 메모리 캐시 같은 것을 사용하는 것이 일반적이다. 하지만 replication을 사용하면 위의 복잡한 작업을 간단하게 해결할 수 있다.


 이상으로 replication의 다양한 사용방법을 알아보았다. 하지만 이는 어디까지나 MySQL 매뉴얼에서 추천하는 일반적인 사용법이고, 실제로 활용할 방법은 무궁무진하다. 중요한 것은 cluster와 차이점을 이해하고 적절한 지점에 사용하는 것이다.

MySQL Replication

2015-05-23

[MySQL] Replication (2) - Replication은 어떻게 동작하는가

 지난번 글에서는 replication이 무엇인지 알아보았다. 이번에는 MySQL replication이 어떻게 동작하는지 살펴볼 것이다.


 replication은 다음과 같은 순서로 진행된다.
  1. 마스터 데이터베이스가 binary log를 만들어 이벤트를 기록한다.
  2. 각 슬레이브는 어떤 이벤트까지 저장되어 있는지를 기억하고 있다.
  3. 슬레이브의 IO thread를 통해서 마스터에 이벤트를 요청하고 받는다.
  4. 마스터는 이벤트를 요청받으면 binlog dump thread를 통해서 클라이언트에게 이벤트를 전송한다.
  5. IO thread는 전송받은 덤프 로그를 이용하여 relay log를 만든다.
  6. SQL thread는 relay log를 읽어서 이벤트를 다시 실행하여 슬레이브에 데이터를 복사한다.


 각각을 자세히 설명하면 다음과 같다.

binary log

 MySQL은 데이터 혹은 스키마를 변경하는 이벤트들을 저장할 수 있다. 이 이벤트들이 저장된 것을 binary log라고 부른다.

 binary log의 주목적은 데이터를 복구하는 것이다. 아카이브된 데이터가 있고, 아카이브 된 다음에 들어온 이벤트를 기록한 binary log가 있으면, 원하는 시점으로 데이터를 복구할 수 있다.
 데이터베이스를 변경하는 모든 이벤트가 저장되어 있으므로 이를 슬레이브에서 다시 실행하는 것만으로도 복사된 데이터베이스가 만들어진다.


binlog dump thread

 replication을 위해서는 마스터에 저장된 binary log를 슬레이브로 전송해야 한다. 이를 위해 마스터에서는 스레드를 만드는데 이를 binlog dump thread라고 부른다.
 binlog dump thread가 하는 일은 단순하다. 슬레이브가 이벤트를 요청하면 binary log에 락을 걸고, event를 읽어 슬레이브로 이벤트를 전송한다. 이때, binary log를 너무 긴 시간 락하지 않기 위해서 슬레이브에 전송하기 전에 binary log를 읽고 바로 락을 해제한다.


 마스터는 슬레이브에 대한 정보를 전혀 가지고 있지 않다. 슬레이브가 있는지 없는지, 몇 개의 슬레이브가 붙어있는지, 각 슬레이브가 어디까지 데이터를 복사했는지, 보내야 할 이벤트가 있는지 전혀 모른다. 그저 슬레이브가 이벤트를 요청하면 그에 해당하는 이벤트를 보내줄 뿐이다. 덕분에 마스터는 큰 부하 없이 데이터를 복사할 수 있다.

 binlog dump thread는 슬레이브가 마스터에 컨넥트할 때 생성되지만, 여러 개의 슬레이브가 붙어도 단 하나의 스레드만 생성된다.

I/O thread


 슬레이브는 마스터에 없는 2개의 스레드가 있다. 그중 하나가 I/O thread다. 각 슬레이브는 자신이 어디까지 데이터를 복사했는지 기억하고 있다.
I/O thread는 슬레이브가 마지막으로 읽었던 이벤트를 기억하고 있다가, 마스터에게 다음 이벤트를 전송해 달라고 요청한다. 마스터의 binlog dump thread가 이벤트를 보내주면 이것을 Relay log에 저장한다.
 따라서 I/O thread가 정지된 상황에서 마스터의 binary log가 지워지면, 슬레이브는 마스터의 데이터를 복제할 수 없다.

Relay log

 슬레이브는 I/O thread를 통해서 받은 이벤트를 로컬에 있는 file에 저장한다. 이를 relay log라고 부른다.
 보통 relay log는 SQL thread가 이벤트를 읽고 나면 지운다. 따라서 어느 정도 이상의 크기가 되지 않는다. 하지만 SQL thread가 멈추어 있으면 relay log는 계속해서 크기가 커지게 된다. 그렇게 되면 I/O thread는 자동으로 새 relay log 파일을 만들어, 파일이 너무 커지는 것을 막는다.

SQL thread

 SQL thread는 I/O thread가 만든 relay log를 읽어 실행을 시키고, relay log를 지운다. SQL을 실행시키는 스레드와 마스터로부터 값을 복사해오는 스레드가 분리되어 있다는 것은 매우 중요한 특징이다.

 보통 MySQL의 데이터를 백업하여 아카이브를 만드는 것은 mysqldump를 이용한다. 하지만 mysqldump는 MySQL이 쿼리를 실행하고 있을 때 실행되면 데이터가 깨지는 문제가 발생한다. 하지만 replication을 이용하면, 슬레이브의 SQL thread만 정지시키면 되기 때문에 안전하게 백업을 만들 수 있다.

MySQL Replication

2015-05-15

[MySQL] Replication (1) - Replication은 무엇인가

 MySQL replication은 데이터베이스를 그대로 복사하여 데이터베이스를 한 벌 더 만드는 기능이다. 언뜻 보면 MySQL cluster와 비슷하지만, 말 그대로 분산환경을 만들어서 single point of failure를 없애려는 cluster와는 달리 MySQL replication은 단순히 데이터를 복제한다.

 따라서 모든 데이터가 동기화되는 cluster와는 달리, replication은 동기화가 비동기적으로 발생한다. 따라서 어떤 데이터베이스에는 데이터가 업데이트되어 있지만, 다른 데이터베이스에서는 업데이트되지 않을 수도 있다.

 또한, 마스터와 슬레이브로 나누어지기 때문에 데이터를 변경하는 쿼리는 단 하나의 데이터베이스에만 요청할 수 있다. 다시 말해서 슬레이브의 데이터를 변경하면, 마스터에 그 변경은 반영되지 않고, 동기화하는 도중 에러를 발생시키기도 한다.

 cluster와 비교하면 replication은 동기화도 보장되지 않고 쿼리를 분산할 수도 없어 cluster 대신 사용할 이유가 없어 보인다. replication은 어떤 용도로 사용될까?

 replication이 cluster에 비해서 가지는 가장 큰 장점은 cluster에 비해서 값의 변경이 매우 빠르다는 것이다. cluster는 값을 변경하려고 하면 클러스터 군을 이루는 다른 서버들도 값이 변경되었다는 것을 확인해 주어야 한다. 하지만 replication은 마스터의 값만 변경하면 되기 때문에, 값을 변경하는 쿼리가 매우 빠르게 실행된다.

 그래서 주로 실시간 동기화가 필요 없는 경우 cluster대신 replication을 사용한다.

MySQL Replication