# DB Replication 이란?

**DB Replication**은 데이터베이스의 데이터를 원본 데이터베이스(Source)에서 복제본 데이터베이스(Replica)로 동기화하는 프로세스.

대규모 애플리케이션 환경에서는 데이터의 지속적인 가용성과 신뢰성이 매우 중요하기에, 원본(Source) 서버와 복제(Replica) 서버간의 동기화는 필수.

## 목적

* 고가용성
* 읽기 부하 분산
* 백업 및 복구

## 작동 방식

1. **Source 서버**에서 데이터 변경(INSERT, UPDATE, DELETE)을 수행.
2. 변경 작업을 **Binary log**에 기록.
3. **Replica 서버**에서 Source 서버의 로그를 읽어와 **Relay log**에 저장.
4. Replica 서버가 **Relay log를 기반으로** 데이터베이스를 업데이트.

## Binary Log(바이너리 로그)를 저장하는 방식

Replication은 Source 서버에서 발생하는 모든 데이터 변경 사항을 Replica 서버로 복제하여 두 서버간의 데이터 일관성을 유지하는 메커니즘.

이 과정은 주로 Binary log를 기반으로 이루어지며, Binary log는 Source 서버에서 실행된 모든 데이터 변경 쿼리를 기록하는 역할을 함. MySQL에서는 이 Binary log를 저장하는 방식으로 **(1)Row, (2)Statement, (3)Mixed**의 세가지 방식을 제공, 각 방식은 고유한 장단점을 가지고있음.

## Row

* Row 방식은 데이터베이스의 각 행별로 **변경된 내용**을 정확히 기록함.
* 데이터 일관성을 매우 높게 유지할 수 있다는 큰 장점이 있음.
  * 특정 행이 수정되었을 때 그 행의 이전 상태와 변경된 상태 모두를 기록, 복제 서버에서도 원본 서버와 동일한 데이터 상태를 유지할 수 있음
  * 하지만 모든 행의 변경 사항을 저장하기 때문에 Binary log 파일의 크기가 급격히 증가할 수 있어 저장 공간에 부담을 줄 수 있는 단점

## Statement

* 데이터 **변경을 일으킨 SQL 문 자체**를 Binary log에 기록. 이 방식은 로그 파일의 크기를 상대적으로 작게 유지할 수 있어 저장 공간을 절약할 수 있는 장점이 있음.
* 하지만 실행할 때마다 다른 값을 반환하는 함수와 같이 비확정적(non-deterministic) SQL 쿼리가 실행될 경우, 동일한 쿼리가 Source와 Replica 서버에서 다른 결과를 초래할 수 있어 데이터 불일치 문제가 발생할 수 있음.
  * 예를 들어, SELECT NOW()와 같은 함수는 실행 시점에 따라 다른 결과를 반환, 이를 포함한 쿼리는 복제시 문제가 될 수 있음.

## Mixed

위와같은 문제를 보완하기 위해 Mixed 방식을 제공함. row 기반과 statement 기반을 혼합하여 로그를 기록

* 비확정적 SQL이 아닌 경우에는 statement 방식을 사용하여 저장공간을 절약,

  비 확정적 SQL이 실행되는 경우에는 row 방식을 사용하여 데이터 일관성을 유지

  이를 통해 두 방식의 장점을 모두 활용할 수 있으며, 데이터 불일치 문제를 최소화 할 수 있음. (but, 구현이 복잡할 수 있음)

## 복제 과정

**Source 서버**에서 데이터 변경 쿼리가 실행되고, 선택된 로그 저장 방식에 따라 Binary log에 기록된 후, **Replica 서버**의 IO Thread가 Binary log를 읽어와 Replica 서버의 Relay log로 전송함.

**Relay log**는 Replica 서버에서 Source 서버의 Binary log를 저장하는 **임시 저장소** 역할을 하며, **이곳에 저장된 로그를 기반으로** Replica 서버의 SQL 스레드가 **실제 DB에 변경 사항을 적용**함.

이 과정은 효율적으로 설계되었고 일반적으로 약 100m/s 이내에 데이터 동기화가 완료됨. 이러한 빠른 동기화 속도 덕분에 원본과 복제 데이터간의 데이터 일관성이 실시간에 가깝게 유지 가능