MYSQL : Master Slave replication

DB를 이중화하기 위한 방법 중 하나로 Master DB / Slave DB 를 구성할 수 있다

 

서버에 의해 DBMS에 요청이 들어왔을 때,

Master는 쓰기만 하고 Slave는 읽기만 한다

 

Master와 Slave 간의 동기화를 맞추기 위해

기본적으로 비동기로 Slave가 Master의 데이터를 받는다

 

비동기 방식에는 아래 두 가지가 있다

fully async : replica를 기다리지 않음

semi async : replica의 acknowledge를 기다림 [기본값]

 

 

Slave가 데이터를 동기화하는 과정

 

replica 생성 과정

 

1. Master DB는 write 발생 시 binary log(dump file) 생성

2. Dump thread : Slave의 I/O thread 요청 시 스레드 시작, dump 파일 전달

3. I/O thread : Master DB에 binary log 요청, binary log로 relay log 업데이트

 * Global Transaction IDentifier(GTID) : master db가 transaction 시 생성

 * slave가 어디까지 로그를 가져왔는 지 GTID로 식별하고, slave에 문제가 생겨도 GTID로 복구할 수 있다

4. SQL Thread : relay log로 Slave DB 동기화

 

Replication 구성을 하는 이유

단일DB로 구성했을 때는 트랜잭션을 하나의 DB가 담당한다

Master-Slave 이중화에서는

Master에서는 write만, Slave에서는 read만 수행하여 부하분산으로 더 빠르다고 생각할 수 있다

하지만, Slave DB는 결론적으로 동기화를 맞추기 위해 단일DB와 동일하게 write와 read가 수행한다

 

하지만 로그 파일로부터'만' write 과정이 일어나기 때문에 Slave DB는

1. constraints(ex. foreign key) 체크할 필요 없음

2. MVCC(동시성 제어)를 통한 lock이 발생하지 않음

로 인해 속도가 더 빠르다

 

Scale

Scale horizontally : DB 개수를 늘림(multi master도 가능함)

Scale vertically : 하드웨어 용량을 늘림

  * 하드웨어 용량을 늘리려면 더 큰 용량의 DB로 이관해야 함, 이 때 서비스 저하나 중단이 발생할 수 있다.

 

출처

https://www.oracle.com/technetwork/community/developer-day/mysql-replication-presentation-485890.pdf

https://stackoverflow.com/questions/12981230/why-is-the-slave-machine-faster-for-reading-than-master-in-database-replication