Database Replication

Database Replication이란?

레플리케이션(Replication)은 실시간 복제본 데이터베이스 서버를 운영하는 것을 의미한다. 기준이 되는 서버를 마스터(master) 서버라고 하고, 마스터 서버와 동일한 내용을 갖는 또 다른 서버를 ‘레플리카(Replica)`라고 한다.

• Master - Slave 관계
• 다양한 용어
  • 원본 서버 : Master, Main, Primary, Publisher, Active
  • 레플리카 서버 : Slave, Standby, Secondary, Subscriber

왜 나왔을까?

기본적으로는 데이터 안정성 때문이다.

(크게 3가지 부하분산(Load Balancing), 고가용성(High Availabilty), 백업 등)

생각해보자.

1. 만약 어떠한 원인으로 인해 데이터가 손상 되었다면 우리의 대처는 ?

• 가장 최신의 백업본을 복구하여 사용한다.
  • 데이터 백업을 주기적이고 자동으로 되도록 설정해 놓아도 백업된 시간과 장애가 발생한 시간 사이의 데이터 변경 사항들은 모두 소실된다. (매우 큰 단점!)
• 레플리카 서버를 사용
  • 아주 약간의 딜레이가 있지만 거의 실시간으로 마스터 서버와 동일한 데이터를 갖고 있기에 장애 복구 시 데이터 소실이 최소화 된다.
  • 마스터 서버로 승격이 가능하기에, 마스터 서버로 승격시켜서 기존 마스터 서버를 대체할 수 있다.

2. 기본적으로 서버에 SELECT 요청이 너무 많다!! 나누자 !

 

Master DB에서는 Insert, Update, Delete(DML), DDL 명령어를 처리하고 Slave DB에서는 Select 처리만 해서 사용한다면 부하를 분산하는 효과를 얻을 수 있다.

Replication 유형

데이터베이스에서 데이터를 복제하는 방식은 크게 동기와 비동기 방식이 있다.

동기식 복제 (Synchronous Replication)

Master 서버에서 데이터 변경(insert, update 등)이 발생하면, 모든 Slave 서버에 즉시 반영 완료된 후 클라이언트에게 응답한다. Slave 노드까지 적용되는 것을 보장하는 방식

• 장점 : 데이터 정합성이 뛰어나고, 장애 발생 시 데이터 손실이 거의 없다.
• 단점 : 속도가 느리고, Master 서버가 모든 Replica의 응답을 기다려야 하므로 트랜잭션 처리 속도가 저하될 수 있다.

비동기식 복제 (Asynchronous Replication)

Master 서버에서 변경 사항을 기록한 후, 일정 시간 간격으로 Slave 서버에 데이터를 전송한다.

• 장점 : Master 서버의 성능이 저하되지 않으며 빠른 응답 가능
• 단점 : 데이터 정합성이 보장되지 않고, 장애 발생 시 일부 데이터 유실 가능성 있음

반동기식 복제 (Semi-Synchronous Replication)

Master 서버가 최소 한 개 이상의 Replica에서 데이터를 수신했다는 응답을 받은 후 클라이언트에게 응답함.

• 장점 : 동기식보다 빠르고 비동기식보다 데이터 정합성이 높음.
• 단점 : 일부 데이터 손실 가능성이 있으며, 속도도 완전한 비동기보다는 느림
• 예시 : 온라인 쇼핑몰의 주문 시스템에서, 주문 데이터가 최소한 하나의 백업 서버에 저장된 후 고객에게 "주문 완료" 메시지를 보여주는 방식이다.

MySQL Replication 동작 원리

MySQL은 기본적으로 비동기 복제 방식을 사용한다.

Master 노드에서 변경되는 데이터 이력을 바이너리 로그(Binary Log)에 기록하면, Replication Master Thread가 비동기적으로 읽어서 Slave 쪽으로 전송하는 방식이다.

• 바이너리 로그란?
• DDL(Create, Drop, Alter), DML(Insert, Update, Delete)을 통해 데이터베이스, 오브젝트, 데이터에 생성,수정,업데이트를 했을 시 그 변화된 이벤트를 기록하는 이진 파일이 있는데 이것을 바이너리 로그라고 한다. (show나 select등 조회 문법 같은 경우에는 제외됨)

Replication을 위해 반드시 필요한 요소

• Master에서의 변경을 기록하기 위한 바이너리 로그
• 바이너리 로그를 읽어서 Slave 쪽으로 데이터를 전송하기 위한 Master Thread
• Slave에서 데이터를 수신하여 Relay Log에 기록하기 위한 I/O Thread
• Relay Log를 읽어 해당 데이터를 Slave에 적용하기 위한 SQL Thread

레플리케이션 Flow

 

1. 클라이언트(App)에서 Commit을 수행
2. Connection Thread는 스토리지 엔진에게 해당 트랜잭션에 대한 Prepare(Commit 준비)를 수행한다.
3. Commit 전 바이너리 로그에 변경 사항(update, insert 등) 기록
4. 스토리지 엔진에게 트랜잭션 Commit 수행
5. Master Thread는 비동기적으로 Binary Log를 읽고 Slave로 전송 (마스터 쓰레드는 이 역할만 하면됨)
6. Slave의 I/O Thread는 Master로부터 수신한 변경 데이터를 릴레이 로그(Relay Log)에 기록한다.
7. Slave의 SQL Thread는 Relay Log에 기록된 변경 데이터를 읽어서 스토리지 엔진에 적용한다!

레플리케이션을 활용한 다양한 구성