MySQL Replication 이해하기 (Master - Slave)

 

MySQL을 사용할 때 이중화 구성(Master - Slave)을 하는 경우가 많습니다. 데이터가 날아가는 것을 방지하기 위해서입니다. 이러한 이중화 구성을 이해하기 위해 Replication 과정을 정리하고자 합니다.

 

1. Master와 Slave의 역할

Master는 등록/수정/삭제 쿼리 요청이 있을시 Binarylog를 생성하여 Slave로 전달합니다.

Slave는 Master의 정보를 복제해놓는 역할을 담당합니다. 또한 읽기 쿼리 요청을 담당합니다. (select)

쿼리 요청을 분담함으로써 DB 부하를 분산할 수 있습니다.

 

 

2. Replication 과정

• (1) Client가 쓰기 쿼리 작업을 요청합니다. 쓰기 쿼리요청은 Master DB가 받습니다.
• (2) Master는 변경사항을 Binary log 파일에 기록합니다. 이후 DB에 반영(commit)합니다.
• (3) Slave는 현재까지 기록한 이벤트 정보 (GTID=2)를 가지고 다음 이벤트 정보를 Master에게 요청합니다.
• (4) Master는 Binary log 파일에서 최신 이벤트 정보(GTID=3)를 읽어
• (5) Slave에게 전송합니다.
• (6) Slave는 Master에게 받은 이벤트 정보(GTID=3)를 Relay log 파일에 기록합니다.
• (7) Slave는 최종 변경사항을 DB에 반영(commit)합니다.

(4)(5) 과정에서는 Master 쓰레드, (3)(6) 과정에서는 Slave I/O 쓰레드, (7) 과정에서는 Slave SQL 쓰레드가 동작합니다. 자세한 내용은 아래에서 설명해보겠습니다.

 

참고로, replication에는 방식이 여러가지가 있습니다. 그 중에서 Async방식과 semi-sync 방식을 정리하였습니다.

Async는 Master DB에 commit을 우선 한 후에 replication 과정을 거칩니다. 반면에 semi-sync 방식은 Slave가 Relay log 파일에 이벤트를 기록했는지 확인된 이후에 Master DB commit을 진행합니다. 방식에 따라 데이터 손실 가능성, 성능 측면에서 차이가 발생합니다.

 

log_slave_updates 옵션을 활성화 (ON)하면, Slave에서도 binary log 파일을 기록한다. 이 옵션은 slave 서버들을 연결할 시 활성화한다. 왜냐하면 하나의 slave는 다른 slave의 마스터가 되어야 하기 때문이다. www.mysqlkorea.com/sub.html?mcode=manual&scode=01&m_no=21430&cat1=6&cat2=205&cat3=0&lang=k

 

 

3. Master와 Slave에서 동작하는 프로세스 확인하기

show full processlist \G;

 

Master

1) Master Thread

Binary Log 를 읽어서 Slave 쪽으로 데이터를 전송한다. 즉 Slave가 client 입장에서 요청을 하고, Master가 server 입장에서 응답을 하는 구조이다. Slave는 복제용 계정(rpl_user)으로 접속한다.

 

Slave

1) Slave I/O Thread

Master로부터 Binary log 데이터를 받아 Relay Log 라는 로그 파일에 순차적으로 기록한다.

해당 쓰레드의 상태는 여러가지가 있다. Waiting for master to send event 는 master와 성공적으로 연결되어 있으며 master가 binary log 데이터를 보내주기를 기다리는 상태이다. (참고)

 

2) Slave SQL Thread

relay log에 반영된 내용을 읽어 DB에 반영한다.

해당 쓰레드의 상태는 여러가지가 있다. (참고) Wating for work from SQL thread는 남아 있는 DB 반영 작업(쿼리)을 기다리는 상태이다. 

 

 

참고링크

MySQL - Replication 구조 - Rain.i