📌등장배경

가장 단순한 DB는 하나의 서버에 하나의 DB가 연결 되어있는 구조를 가진다. 이러한 구조는 크게 두가지의 문제점을 일으킨다.

• 사용자가 늘어날수록 즉, 트래픽이 증가할수록 하나의 DB가 모든 쿼리를 처리하기가 힘들어진다. Query의 대부분을 차지하는 Select를 어느 정도 해결하기 위해 Replication이란 방법이 나오게 되었다. (부하 분산)
  
• DB는 Disk의 직접적인 I/O가 발생하여 병목이 가장 크게 발생할 수 있는 부분으로 하나의 서버에 하나의 DB의 구조일때 SPOF(단일장애점. single point of failure)에 해당한다.

📌“레플리카” 란?

• 데이터베이스의 부하를 분산시키는 데이터베이스 이중화 방식 중 하나로, 하나의 Master DB와 N대의 Slave DB로 구성된다.

📖사용목적

• 데이터베이스의 부하 분산
• 데이터 백업

📚데이터베이스의 부하 분산

• Write 관련 작업들은 Master DB 에서 처리를 하고 Read 관련 작업들은 Slave DB 에서 처리를 통해 부하는 분산 시키는 구조. → 대부분의 서비스들은 Read 관련 작업들이 많기 때문에 Slave DB 를 여러 대 두어 분산시킬 수 있다. → Master DB에는 데이터의 변경이 필요한 INSERT, UPDATE, DELETE 등의 쿼리(등록, 수정, 삭제)가 필요할때 사용하고(쓰기 작업), Slave DB에는 Select문이 필요할때(읽기 작업) 사용한다.
  

출처) https://nesoy.github.io/articles/2018-02/Database-Replication

📚데이터 백업

• Master 서버를 데이터 원본 서버, Slave서버를 백업서버로 지칭할때

  먼저 Master 서버에 DBMS의 등록/수정/삭제의 업데이트가 생기는 즉시 Slave 서버의 변경된 데이터를 전달한다. Master 서버의 장애가 생겼을 경우 Slave 서버로 변경하여 사용할 수 있다.

📌동작원리

1. 애플리케이션 서버로부터 오는 데이터 삽입, 수정, 삭제 쿼리를 Master서버에 보내면,
   1) Master는 쿼리를 처리하고 Binary log thread를 사용해 변경내역(쿼리나 변경된 ROW자체)를 Binary log 에 모두 기록한다.
   2) Master의 스토리지 엔진에서 트랜잭션을 수행한다.
2. Slave 의  I/O Thread 가 변경 내역을 요청하여
3. Master Thread 는 비동기적 으로(복사되는 시간을 기다려주지 않음) Binary log를 읽어 Slave 서버의 I/O Thread에 전송한다. → 데이터 정합성 문제 발생
4. Slave 의 I/O Thread 는 Master로 부터 받은 변경 데이터들을 Relay log 에 저장한다.
5. Slave의 SQL Thread 는 Replay log의 기록들을 읽어 변경내용을 자신의 스토리지 엔진에 최종 적용한다.

📌단점

• 데이터 정합성 문제
  • 비동기방식으로 Master/Slave 서버 간 데이터 동기화를 진행하기 때문에 Slave로 복사 되는 시간을 온전히 기다려 주지 않아 Master 와 Slave 간의 Sync 를 맞추는 간격 사이에서 데이터의 정합성이 깨질 수 있다.
  • Slave가 Master와 같은 데이터를 가지고 있다고 보장할 수 없다.

cf) 레플리카(Replica)와 레플리케이션(Replication)은 같은 말을 지칭한다.