mysql의 DB서버 복제원리

[im1sun]

Mysql의 Replicatoin 개념을 정리하고 프로젝트 중 AI 모델 재학습 시 900만 건의 데이터를 조회하면서 생기는 DB의 부하를 줄이기 위한 포스터입니다.

1. 복제(Replication)
   복제(Replication)는 1개 이상의 레플리카(replica) 저장소가 소스 저장소와 동기화를 자동으로 유지하는 과정이다. 사용하기 위한 최소 구성은 Master / Slave이다.

Master DBMS 역할
웹서버로 부터 데이터 등록/수정/삭제 요청시 바이너리로그(Binarylog)를 생성하여 Slave 서버로 전달하게 된다. (웹서버로 부터 요청한 데이터 등록/수정/삭제 기능을 하는 DBMS로 많이 사용)

Slave DBMS 역할
Master DBMS로 부터 전달받은 바이너리로그(Binarylog)를 데이터로 반영하게 된다. (웹서버로 부터 요청을 통해 데이터를 불러오는 DBMS로 많이 사용)

2. Mysql Repication 사용 목적
   mysql 리플리케이션의 사용목적은 크게 실시간 Data 백업과 여러대의 DB 서버의 부하를 분산시킬 수 있다.

먼저 데이터의 백업이다.

예를 들어 Master 서버를 데이터의 원본서버, Slave 서버를 백업 서버로 지칭하였다.

Master 서버에 DBMS의 등록/수정/업데이트가 생기는 즉시 Slave 서버의 변경된 데이터를 전달하게 된다. 이러한 과정으로 백업을 할 수 있으며, Master 서버의 장애가 생겼을 경우 Slave 서버를 DB로 사용할 수 있다.

DBMS의 부하 분산이다.

사용자의 폭주로 인해 1대의 DB서버로 감당할 수 없을 때, MySQL 레플리케이션을 이용하여 같은 DB 데이터를 여러대로 만들 수 있기 때문에 부하를 분산시켜줄 수 있다.

위에서도 얘기했듯이 Master 서버는 등록/수정/삭제를 처리하는 서버로 사용하고, Slave 서버는 서버의 데이터를 읽는 용도로 사용하며 부하를 분산시킬 수 있다.

이 외에도 복제의 장점들엔 다음과 같은 것들이 있다.

분석
원본 데이터에 실시간 데이터가 생성되고, 원본 데이터에 성능 이슈없이 레플리카에서 분석을 할 수 있다.
원거리 데이터 분산
원본데이터에 접근하지 않고도, 원격 사이트에서 사용 할 로컬 데이터 복사본을 생성할 수 있습니다.

3. 복제의 원리
   아래는 MySQL의 Master-Slave 복제 원리이다.

MySQL에서 복제는 바이너리 로그 파일에 데이터에 대한 모든 변경사항을 기록한다.

1. 레플리카가 초기화가 된다면, 2개의 쓰레드 작업을 생성

2. 하나는 I/O 쓰레드로 원본 인스턴스에 연결하고 한 줄씩 바이너리 로그를 읽는다. 그리고 레플리카 서버의 Relay 로그에 해당 내용들을 복사.

3. 두번째 쓰레드는 SQL 쓰레드로, relay 로그를 읽고 레플리카 인스턴스에 최대한 빠르게 적용다.

MySQL의 **마스터–레플리카 복제(replication)**는
기본적으로 **마스터에서 발생한 변경사항(쓰기 작업)**을 **바이너리 로그(Binary Log)**에 기록하고,
레플리카가 이 로그를 읽어서 동일한 변경을 재실행하는 방식입니다.

아래에서 전체 원리를 단계별로 정리해 드릴게요.

1. 기본 개념
   마스터(Master): 원본 데이터베이스, 쓰기(INSERT/UPDATE/DELETE) 작업이 발생하는 서버

레플리카(Replica): 마스터를 복제하여 데이터를 실시간 또는 지연 동기화하는 서버

복제 방식: 기본은 비동기(Asynchronous)지만, Semi-sync / Group Replication 같은 방식도 있음

2. 동작 원리 (비동기 복제 기준)
   [클라이언트] → (쓰기 쿼리) → [마스터] → Binary Log 기록 → [레플리카] → Relay Log 저장 → SQL Thread 실행

1.) 마스터에서 데이터 변경 발생
예: INSERT INTO user VALUES (1, '홍길동');
마스터는 이 쿼리를 실행하고 변경 내역을 Binary Log(binlog)에 기록합니다.

2.) 레플리카의 I/O Thread
레플리카는 마스터에 복제 계정(REPLICATION SLAVE 권한)으로 연결되어 있습니다.
레플리카의 I/O Thread가 마스터의 binlog를 읽어와서 자신의 Relay Log에 저장합니다.

3.) 레플리카의 SQL Thread
Relay Log를 읽고, 거기에 기록된 변경 쿼리(또는 이벤트)를 순서대로 실행합니다.
결과적으로 마스터와 동일한 데이터 상태가 됩니다.