[Real MySQL, 3장 - 아키텍처] MySQL에서의 복제(Replication)

1. 알고자 하는 것

• 데이터베이스에서 대용량 데이터를 처리하기 위한 가용성(Availability)과 확장성(Scalability)
• MySQL에서의 복제(Replication)
• 복제(Replication) 시 고려해야 할 주의사항
• Statement 포맷 방식과 Row 포맷 방식

 

 

2. 알게된 것

데이터베이스에서 대용량 데이터를 처리하기 위한 가용성(Availability)과 확장성(Scalability)

• 서비스 사용자의 수가 늘어나고, 서비스 아키텍처가 커짐에 따라 그에 따른 데이터는 기하급수적으로 많아진다.
• 이렇게 많아지는 데이터를 기존 하나의 데이터베이스만으로 관리하기 힘들다.
• 많은 데이터를 하나의 데이터베이스에서 다루게 되면 그에 따른 트래픽을 모두 하나의 데이터베이스가 감당해야 한다.
• 수많은 요청에 대해 하나의 데이터베이스가 처리하게 된다면 그 데이터베이스는 하나의 장애가 전체 서비스의 장애로 이어지는 단일 장애점(SPOF, Single Point Of Failure)이 되어 가용성까지 해치게 된다.
• 즉, 서비스가 커질수록 대용량 데이터를 다룰 수 있는 기법이 필요하다.
  • 수많은 요청에 대해서도 장애 없이 원활하게 동작할 수 있는 가용성(Availability)을 보장할 수 있어야 한다.
  • 수많은 데이터를 재설계없이 유연하게 저장하고 관리할 수 있는 확장성(Scalability)을 보장할 수 있어야 한다.

 

 

 

MySQL에서의 복제(Replication)

• MySQL에서 가용성과 확장성을 높일 수 있는 기법 중에는 복제(Replication)라는 것이 존재한다.
• 복제(Replication)는 2대 이상의 MySQL 서버를 Master-Slave 구조로 구성하여 데이터를 동기화한다.

(좌) Master / (우) Slave

 

• Master 서버는 데이터의 저장/수정/삭제에 대한 요청만을 담당한다.
• Slave 서버는 데이터의 조회에 대한 요청만을 담당한다.
• Master 서버는 데이터 변경 사항을 Binary Log에 기록한다.
• Slave 서버는 주기적으로 Master 서버의 Binary Log를 읽어와 I/O Thread를 통해 Relay Log에 기록한다.
• Relay Log에 저장된 변경 사항을 Replay를 통해 Slave 서버에 동기화한다.
• 데이터 변경과 데이터 조회에 대한 트래픽을 나누어 담당함으로써 트래픽 과부하로 인한 장애를 줄일 수 있다.
• 하나의 Master 서버에 여러 대의 Slave 서버를 구성할 수 있어, 높은 확장성을 제공한다.
• 또한, Master 서버 장애 시 Slave 서버를 Master 서버로 승격시켜 높은 가용성을 제공한다.

 

 

 

복제(Replication) 시 고려해야 할 주의사항

• 하나의 Slave 서버는 하나의 Master 서버만을 둘 수 있다.
• 하나의 Master 서버는 여러 대의 Slave 서버를 둘 수 있다.
• 사용자 실수 및 애플리케이션 오류로 인해 Slave 서버에 데이터 변경 작업을 수행해 데이터 동기화에 문제가 발생하지 않도록 Slave 서버는 Read-Only로 설정한다.
• Slave 서버의 사양은 Master 서버와 동일한 사양이 적합하다.
  • Binary Log에 기록된 수많은 데이터 변경 작업을 Slave 서버는 하나의 Thread만으로 처리하므로 이를 감당할 수 있는 사양이 필요하다.
• 복제가 불필요한 경우에는 Binary Log의 기록을 중지한다.
  • Binary Log를 안전하게 동기화하여 기록하기 위해 갭 락(Gap Lock)을 유지하는 등의 많은 자원을 소모한다.

 

 

Statement 포맷 방식과 Row 포맷 방식

• Binary Log를 기록하는 방식에는 Statement 포맷 방식과 MySQL 5.1부터 추가로 제공되는 Row 포맷 방식이 존재한다.
• Statement 포맷 방식은 Binary Log에 수행된 SQL 쿼리를 기록해 해당 쿼리를 Replay 하는 방식이다.
  • 데이터의 변경이 많은 쿼리라도 SQL 쿼리 하나만이 Slave 서버로 전달되므로 네트워크 트래픽이 적다.
  • 쿼리를 수행하기 때문에 Master 서버와 Slave 서버 간 데이터 동기화를 위해 REPEATABLE READ(반복 가능한 읽기) 수준을 유지해야 하므로 Lock으로 인해 복제 지연이 발생할 수 있다.
• Row 포맷 방식은 Binary Log에 데이터의 변경 레코드를 기록해 해당 변경 레코드를 Replay 하는 방식이다.
  • 데이터의 변경이 많을수록 변경 사항이 모두 레코드 형식으로 Slave 서버로 전달되므로 네트워크 트래픽이 많다.
  • 변경 사항 자체가 레코드로 기록되어 있어 즉시 적용되므로 READ-COMMITTED 수준에서도 동작해 복제 지연에서 효율적이다.

 

 

 

3. 정리

• 서비스가 커질수록 대용량 데이터에 대한 대응이 필요하다.
• 대용량 데이터에 대해서는 높은 가용성과 확장성을 필요로 한다.
• Master-Slave 구조로 각 역할 별 트래픽을 분산하고, Binary/Relay Log를 통해 데이터를 동기화 할 수 있는 복제(Replication)를 통해 가용성과 확장성을 높일 수 있다.
• 데이터 동기화, 시스템 사양, 서비스의 상황을 적절히 고려하여 복제의 효율을 최적화 할 수 있도록 한다.

 

---

Reference

• Real MySQL