🎯 DB Replication
DB Replication은 데이터베이스의 데이터를 여러 서버에 복제하여 동일한 데이터를 수직적으로 확장하여 유지하는 기술이다. 이 과정에서 하나의 서버(Master Server)에서 데이터를 작성하고, 다른 서버(Slave Server)로 복제하여 데이터의 일관성을 유지한다. 이러한 과정은 주로 Binary log를 기반으로 이루어지며, Binary log는 Master Server에서 실행된 모든 데이터 변경 쿼리를 기록하는 역할을 한다. 이러한 방식은 데이터의 가용성을 높이고, 장애 발생 시 빠른 복구를 가능하게 한다.
💡 DB Replication의 필요성
현대의 애플리케이션은 대량의 데이터를 처리해야 하며, 이로 인해 데이터베이스의 부하가 증가한다. DB Replication은 이러한 부하를 분산시키고, 데이터의 가용성을 높이는 데 필수적이다. 보통 Create, Update, Delete의 작업을 Master Server에서 실행하고, 다수의 Slave Server에서 Read 작업을 수행하는 방법을 사용한다. 예를 들어, 사용자가 많은 웹사이트에서는 데이터베이스에 대한 읽기 요청이 많아지기 때문에, 복제된 서버를 통해 읽기 요청을 분산시킬 수 있다.
🤔 Read 작업을 Slave Server로 분산시키는 이유
읽기 작업이 단순히 “읽어서 끝”나는 게 아니라, I/O → 메모리 캐시 → CPU 파싱·필터링 → 네트워크 전송 → 동시성 관리의 전 과정을 거치기 때문에 다른 작업보다 리소스 소모가 크다.
📌 바이너리 로그(Binary log)를 저장하는 방식 (MySQL)
MySQL에서는 이 Binary log를 저장하는 방식으로 Row, Statement, Mixed의 세 가지 방식을 제공한다.
-
Row : 데이터베이스의 각 행별로 변경된 내용을 정확히 기록하는 방식이다. 이 방식은 데이터 일관성을 매우 높게 유지할 수 있다는 큰 장점이 있다. 예를 들어, 특정 행이 수정되었을 때 그 행의 이전 상태와 변경된 상태를 모두 기록하므로, 복제 서버에서도 원본 서버와 동일한 데이터 상태를 유지할 수 있다. 그러나 모든 행의 변경 사항을 저장하기 때문에 Binary log 파일의 크기가 급격히 증가할 수 있어 저장 공간에 부담을 줄 수 있는 단점이 존재한다.
-
Statement : 데이터 변경을 일으킨 SQL 문 자체를 Binary log에 기록하는 방식이다. 이 방식은 로그 파일의 크기를 상대적으로 작게 유지할 수 있어 저장 공간을 절약할 수 있는 장점이 있다. 하지만 실행할 때마다 다른 값을 반환하는 함수와 같이 비확정적(non-deterministic) SQL 쿼리가 실행될 경우, 동일한 쿼리가 Source와 Replica 서버에서 다른 결과를 초래할 수 있어 데이터 불일치 문제가 발생할 수 있다. 예를 들어, SELECT NOW()와 같은 함수는 실행 시점에 따라 다른 결과를 반환할 수 있기 때문에, 이를 포함한 쿼리는 복제 시 문제가 될 수 있다.
-
Mixed : 상황에 따라 row 기반과 statement 기반을 혼합하여 로그를 기록하는 방식이다. 비확정적 SQL이 아닌 경우에는 statement 방식을 사용하여 저장 공간을 절약하고, 비확정적 SQL이 실행되는 경우에는 row 방식을 사용하여 데이터 일관성을 유지할 수 있다. 이를 통해 두 방식의 장점을 모두 활용할 수 있으며, 데이터 불일치 문제를 최소화할 수 있다. 다만, 구현이 다소 복잡할 수 있다는 단점이 존재한다.
✅ Replication 과정
MySQL의 전통적인 복제(Replication)는 비동기(asynchronous) 방식이다. 전체 과정은 다음과 같은 흐름을 가진다.
- Master Server
└─(1) 데이터 변경 쿼리 실행
└─(2) 선택된 방식(Row/Statement/Mixed)으로 Binary Log에 기록 - Slave Server
└─(3) IO Thread가 Binary Log를 읽어 Relay Log로 저장
└─(4) SQL Thread가 Relay Log를 기반으로 실제 데이터베이스에 변경 적용
