DB Replication에 대해서 설명해주세요.

1일 1CS(Computer Science)

DB Replication에 대해서 설명해주세요.

표자 2025. 5. 12. 08:57

DB Replication이란? 🤔

DB Replication은 하나의 데이터베이스(Source)에서 다른 데이터베이스(Replica)로 데이터를 복제하는 기술입니다. 쉽게 말해 원본 데이터의 '백업 친구들'을 만드는 과정이죠!

DB Replication이 필요한 이유 🎯

고가용성(High Availability) ⚡: 주 서버가 다운되어도 복제 서버가 대신 서비스 제공
부하 분산(Load Balancing) 🔄: 읽기 작업을 여러 서버에 분산
데이터 백업(Data Backup) 💾: 데이터 손실 방지
지리적 분산(Geographic Distribution) 🌍: 전 세계 사용자에게 빠른 서비스 제공

Replication 작동 방식 ⚙️

MySQL을 예로 들면 복제 과정은 다음과 같습니다:

기록(Write) 📝: Source 서버에서 데이터 변경 발생
로깅(Logging) 📒: 변경사항이 Binary Log에 기록됨
전송(Transfer) 📤: Replica 서버의 I/O 스레드가 Binary Log 내용 가져옴
저장(Store) 💾: 가져온 내용을 Relay Log에 저장
적용(Apply) ✅: SQL 스레드가 Relay Log의 변경사항을 Replica DB에 적용

// Node.js에서 MySQL 복제본 설정 예시
const mysql = require('mysql2');

const replicaPool = mysql.createPoolCluster();

// Source DB 연결
replicaPool.add('SOURCE', { 
  host: 'source-db.example.com', 
  user: 'user', 
  password: 'password'
});

// Replica DB들 연결
replicaPool.add('REPLICA1', { 
  host: 'replica1.example.com', 
  user: 'user', 
  password: 'password'
});

Binary Log 저장 방식 🗂️

1. Row 기반 방식 📋

변경된 데이터 행 자체를 기록합니다.

✅ 장점:

데이터 일관성 최고!
모든 변경사항이 정확히 복제됨

❌ 단점:

로그 파일 크기가 매우 커짐
많은 디스크 공간 필요

2. Statement 기반 방식 📜

실행된 SQL 문장을 그대로 기록합니다.

✅ 장점:

로그 파일 크기가 작음
저장 공간 효율적

❌ 단점:

NOW(), RAND() 같은 함수 사용시 문제 발생
데이터 불일치 가능성 있음

3. Mixed 기반 방식 🔀

상황에 따라 Row와 Statement 방식을 혼합해서 사용합니다.

✅ 장점:

두 방식의 장점을 모두 활용
효율성과 정확성 균형 유지

❌ 단점:

설정이 복잡할 수 있음
예측하기 어려운 상황 발생 가능

실전 예시: Next.js로 Replication 활용하기 🚀

// Next.js API 라우트에서 읽기/쓰기 분리 예시
export default async function handler(req, res) {
  const db = req.method === 'GET' 
    ? await connectToReplica() // 읽기 작업은 Replica로
    : await connectToSource();  // 쓰기 작업은 Source로
    
  // 이후 데이터베이스 작업 수행
}

Replication Lag 문제 ⏱️

Source와 Replica 사이에 지연이 발생할 수 있습니다. 일반적으로 100ms 이내지만, 네트워크 문제나 부하가 심할 때 더 길어질 수 있어요.

// React에서 Replication Lag 고려하기
function ProfileEditor() {
  const saveProfile = async (data) => {
    await saveToDatabase(data);
    // 저장 후 바로 데이터를 읽으면 Replica에 아직 반영 안 될 수 있음
    await new Promise(r => setTimeout(r, 200)); // Lag 고려한 딜레이
    const updatedData = await fetchFromDatabase();
    setProfile(updatedData);
  };
  
  return <Form onSubmit={saveProfile} />;
}

정리: 어떤 방식을 선택해야 할까요? 🤷‍♂️

Row 방식: 데이터 정확성이 최우선일 때 (금융, 의료 등)
Statement 방식: 저장 공간이 제한적이고 비확정적 함수가 적을 때
Mixed 방식: 대부분의 경우 균형 잡힌 방식으로 추천

마치며 📝

DB Replication은 백엔드 개발자라면 꼭 알아야 할 핵심 기술입니다. 특히 DCIM이나 FMS 같은 대규모 데이터센터 관리 시스템을 개발할 때는 더욱 중요하죠. 복제 설정, 모니터링, 장애 복구 계획까지 꼼꼼히 준비해두면 안정적인 서비스 운영이 가능합니다!

이제 DB Replication에 대해 이해하셨나요? 다음에는 Sharding이나 Partitioning에 대해 알아보는 것도 좋을 것 같습니다! 🚀

DB Replication에 대해서 설명해주세요.

백엔드와 관련된 질문이에요.

DB Replication은 데이터베이스의 고가용성과 데이터 안정성을 보장하기 위해 널리 활용되는 핵심 기술입니다. 특히, 대규모 애플리케이션 환경에서는 데이터의 지속적인 가용성과 신뢰성이 매우 중요하기 때문에, 원본(Source) 서버와 복제(Replica) 서버 간의 데이터 동기화는 필수입니다. MySQL 기준으로 설명하겠습니다.

바이너리 로그(Binary log)를 저장하는 방식은?

Replication은 Source 서버에서 발생하는 모든 데이터 변경 사항을 Replica 서버로 복제하여 두 서버 간의 데이터 일관성을 유지하는 메커니즘입니다. 이러한 과정은 주로 Binary log를 기반으로 이루어지며, Binary log는 Source 서버에서 실행된 모든 데이터 변경 쿼리를 기록하는 역할을 합니다. MySQL에서는 이 Binary log를 저장하는 방식으로 Row, Statement, Mixed의 세 가지 방식을 제공하며, 각 방식은 고유한 장단점을 가지고 있습니다.

Row

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

Statement

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

Mixed

이러한 문제를 보완하기 위해 MySQL은 Mixed 방식을 제공합니다. Mixed 방식은 상황에 따라 row 기반과 statement 기반을 혼합하여 로그를 기록합니다. 비확정적 SQL이 아닌 경우에는 statement 방식을 사용하여 저장 공간을 절약하고, 비확정적 SQL이 실행되는 경우에는 row 방식을 사용하여 데이터 일관성을 유지합니다. 이를 통해 두 방식의 장점을 모두 활용할 수 있으며, 데이터 불일치 문제를 최소화할 수 있습니다. 다만, 구현이 다소 복잡할 수 있다는 단점이 존재합니다.

복제 과정

Source 서버에서 데이터 변경 쿼리가 실행되고, 선택된 로그 저장 방식에 따라 Binary log에 기록된 후, Replica 서버의 IO Thread가 Binary log를 읽어와 Replica 서버의 Relay log로 전송합니다. Relay log는 Replica 서버에서 Source 서버의 Binary log를 저장하는 임시 저장소 역할을 하며, 이곳에 저장된 로그를 기반으로 Replica 서버의 SQL 스레드가 실제 데이터베이스에 변경 사항을 적용합니다. 이 과정은 매우 효율적으로 설계되어 일반적으로 약 100밀리초 이내에 데이터 동기화가 완료됩니다. 이러한 빠른 동기화 속도 덕분에 원본과 복제 서버 간의 데이터 일관성이 실시간에 가깝게 유지될 수 있습니다.

728x90

저작자표시 (새창열림)