[Database] Master, Slave DB

지금까지 일반적으로 DB를 사용하는데에 있어서 Replication 기법을 사용하지 않고 프로젝트를 진행했었다.

대규모 프로젝트를 참여하지 않아봐서 그런 것일 수도 있지만 회사도 그렇고,

Git에 있는 프로젝트를 보면 이중화 구성으로 되어있는 몇몇 프로젝트들이 master-slave 구조로 되어있다.

이번엔 Master, Slave 이중화(Replication)에 대해 알아볼 것이다.

 

DB Replication 동작원리

Replication 원리

1. Client가 쓰기 작업을 요청한다.
2. 쓰기 쿼리 요청(Insert, Update, Delete)은 Master DB가 받는다.
3. Master는 변경 사항을 Binary log 파일에 기록한다. 이후 DB에 Commit한다.
4. Slave는 현재까지 기록한 event 정보를 가져 다음 이벤트 정보를 Master에게 전송한다.
5. Slave IO Thread에서 event 정보를 Catch
6. Binary Log를 Slave DB 각각의 Relay Log에 저장한다.
7. Slave SQL Thread에서 Relay Log를 읽어 기록한다.
8. Slave는 최종적으로 변경사항을 DB에 Commit 한다.

Slave는 읽기 쿼리 요청(Select)에 사용된다.

(5)(6) 과정에서는 Master 쓰레드, (4)(7) 과정에서는 Slave I/O 쓰레드, (8) 과정에서는 Slave SQL 쓰레드가 동작한다.

 

 

Replication 에는 여러 방식이 있다. 그 중 Async방식과 semi-sync 방식이 있다.

Async는 Master DB에 Commit을 우선 한 후에 replication 과정을 거친다.

반면에 semi-sync 방식은 Slave가 Relay log 파일에 이벤트를 기록했는지 확인된 이후에 Master DB commit을 한다.

방식에 따라 데이터 손실 가능성, 성능 측면에서 차이가 발생한다.

 

이러한 Master & Slave 구조를 가지면 DB에 대한 트래픽 분산을 위해서 Mysql Replication을 통해 트래픽 집중 문제를 해결할 수 있다.

Master에게는 데이터 동시성이 아주 높게 요구되는 트랜잭션을 담당한다.

Slave에게는 읽기만 데이터 동시성이 꼭 보장될 필요는 없는 경우에 읽기 전용으로 데이터를 가져오게 된다.

 

일반적으로 Front에서 데이터를 읽어들일 때, 꼭 데이터 일관성이 필요한 경우와 아닌 경우에 대한 API가 나누어지게 된다.

그런 경우에 읽기전용으로 트랜잭션을 사용하여 디비에 대한 트래픽을 분산할 수 있다.